淘宝海量数据产品技术架构
淘宝海量数据产品技术架构
View more presentations from aleafs
淘宝海量数据产品技术架构 - Presentation Transcript
- 淘宝海量数据产品技术架构
张轩丞（朋春）
淘宝网-数据平台与产品部
- 关于
- 张轩丞（朋春）
- 淘宝数据平台与产品部（杭州）
- vi党，脚本语言爱好者
- 关注NodeJS，cnode社区组织者之一
- pengchun@taobao.com
- weibo.com：我是aleafs
- 数据平台与产品
搜索、浏览、收藏、交易、评价...
淘宝网
淘宝卖家
供应商
消费者
- 一些数字
- 数据产品：
- 50G统计汇总结果
- 千万量级数据查询请求
- 平均20.8ms的响应时间（6月1日）
- 淘宝主站：
- 30亿店铺、宝贝浏览
- 10亿计的在线宝贝数
- 千万量级交易笔数
- 海量数据带来的挑战
- 计算
- 计算的速度
- 处理吞吐量
- 存储
- 存储是为了更方便地查询
- 硬盘、内存的成本
- 查询
- “大海捞针”
- 全“表”扫描
- 架构总览
数据源
主站备库
RAC
主站日志
DataX / DbSync / TimeTunnel
计算层
Hadoop集群 / 云梯
实时流数据
1500节点，每日40000 JOB，处理数据1.5PB，凌晨2点结束，结果20T
存储
层
MyFOX
Prom
查询
层
数据中间层 / glider
数据魔方
淘宝指数
开放API
产品
- 今天的话题
- 关系型数据库仍然是王道
- NoSQL是SQL的有益补充
- 用中间层隔离前后端
- 缓存是系统化的工程
- 关系型数据库仍然是王道
- 关系型数据库
SELECT IF(INSTR(f.keyword,' ') > 0, UPPER(TRIM(f.keyword)), CONCAT(b.brand_name,' ',UPPER(TRIM(f.keyword)))) AS f0,
SUM(f.search_num) AS f1,
ROUND(SUM(f.search_num) / SUM(f.uv), 2) AS f3,
ROUND(AVG(f.uv),2) AS f4
FROM dm_fact_keyword_brand_d f
INNER JOIN dim_brand b ON f.keyword_brand_id = b.brand_id
WHERE f.keyword_type_id = 1 AND f.keyword != ''
AND keyword_cat_id IN ('50002535')
AND thedate <= '2011-07-09'
AND thedate >= '2011-07-07'
GROUP BY f0
ORDER BY SUM(f.search_num) DESC LIMIT 0, 100
- 有成熟稳定的开源产品
- SQL有较强的表达能力
- 只存储中间状态的数据
- 查询时过滤、计算、排序
- 数据产品的本质
- 拉关系
- 做计算
- 存储在DB中的数据
- 分布式MySQL集群
- 字段+条目数分片
- MyISAM引擎
- 离线批量装载
- 跨机房互备
云梯
MyFOX
数据查询
数据装载
MySQL
集群
- 透明的集群中间层—MyFOX
- 透明查询
- 基于NodeJS，1200QPS
- 数据装载
- 路由计算
- 数据装入
- 一致性校验
- 集群管理
- 配置信息维护
- 监控报警
- MyFOX-数据查询
路由
SQL解析
APC
语义理解
查询路由
字段改写
分片SQL
计算规则
取分片
缓存
取分片数据（异步并发）
X
合并计算
缓存
结果合并（表达式求值）
- MyFOX-节点结构
MyFOX
路由表
冷节点（MySQL）
30天无访问的冷数据
新增热数据
7.2k SATA盘，1T * 12，raid10
内存:24G
成本:1.6W / T
热节点（MySQL）
15k SAS盘，300G * 12，raid10
内存:24G
成本:4.5W / T
- 小结
- 根据业务特点分库分表
- 冷热数据分离
- 降低成本，好钢用在刀刃上
- 更有效地使用内存
- SQL虽牛，但是…
如果继续用MySQL来存储数据，你怎么建索引？
- NoSQL是SQL的有益补充
- 全属性交叉运算
- 不同类目的商品有不同的属性
- 同一商品的属性对有很多
- 用户查询所选择的属性对不确定
- Prometheus
- 定制化的存储
- 实时计算
- Prom—数据装载
Prom
索引：交易id列表
属性对
Hbase
Hbase
Hbase
……
交易1（二进制，定长）
交易2
- Prom—数据查询
查索引
求交集
汇总计算
写入缓存
- Prom—数据冗余
- 明细数据大量冗余
- 牺牲磁盘容量，以得到：
- 避免明细数据网络传输
- 变大量随机读为顺序读
- 小结
- NoSQL是SQL的有益补充
- “预算”与“现算”的权衡
- “本地”与“集中”的协同
- 其他的数据来源
- Prom的其他应用（淘词、指数等）
- 从isearch获取实时的店铺、商品描述
- 从主站搜索获取实时的商品数
- …
- 用中间层隔离前后端
- [pengchun]$ tail ~/logs/glider-rt2.log
127.0.0.1 [14/Jun/2011:14:54:29 +0800] "GET /glider/db/brand/brandinfo_d/get_hot_brand_top/where… HTTP/1.1" 200 17 0.065
- 数据中间层—Glider
- 多数据源整合
- UNION
- JOIN
- 输出格式化
- PERCENT / RANK OVER …
- JSON输出
- Glider架构
Dispatcher
Controller
配置解析
请求解析
datasource
filter
一级缓存
action
MyFOX
Prom
JOIN
UNION
二级缓存
- 缓存是系统化的工程
- 缓存系统
URL请求，nocache?
data
etag, http header
前端产品
nocache?
glider
一级缓存
nocache?
ttl, http header
Min (ttl)
二级缓存
- 小结
- 用中间层隔离前后端
- 底层架构对前端透明
- 水平可扩展性
- 缓存是把双刃剑
- 降低后端存储压力
- 数据一致性问题
- 缓存穿透与失效
- 回顾
- 关系型数据库仍然是王道
- NoSQL是SQL的有益补充
- 用中间层隔离前后端
- 缓存是系统化的工程
