《淘宝海量数据处理产品技术架构精品》由会员分享，可在线阅读，更多相关《淘宝海量数据处理产品技术架构精品（33页珍藏版）》请在金锄头文库上搜索。
1、淘宝大数据量产品技术架构张轩丞（朋春）淘宝网-数据平台与产品部关于张轩丞（朋春）淘宝数据平台与产品部（杭州）vi党，脚本语言爱好者关注NodeJS，cnode社区组织者之一：我是aleafs数据平台与产品数据产品用户淘宝网淘宝卖家供应商消费者搜索、浏览、收藏、交易、评价.一些数字淘宝主站：30亿店铺、宝贝浏览10亿计的在线宝贝数千万量级交易笔数数据产品：50G统计汇总结果千万量级数据查询请求平均20.8ms的响应时间（6月1日）海量数据带来的挑战计算计算的速度处理吞吐量存储存储是为了更方便地查询硬盘、内存的成本查询“大海捞针”全“表”扫描架构总览主站备库RAC主站日志数据源MyFOXProm存
2、储层数据中间层 / glider查询层数据魔方淘宝指数开放API产品Hadoop集群 / 云梯计算层实时流数据DataX / DbSync / TimeTunnel1500节点，每日40000 JOB，处理数据1.5PB，凌晨2点结束，结果20T今天的话题关系型数据库仍然是王道NoSQL是SQL的有益补充用中间层隔离前后端缓存是系统化的工程关系型数据库仍然是王道关系型数据库有成熟稳定的开源产品SQL有较强的表达能力只存储中间状态的数据查询时过滤、计算、排序数据产品的本质拉关系做计算SELECT IF(INSTR(f.keyword, ) 0, UPPER(TRIM(f.keyword), CO
3、NCAT(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
4、(50002535) AND thedate = 2011-07-07 GROUP BY f0 ORDER BY SUM(f.search_num) DESC LIMIT 0, 100存储在DB中的数据Billions2010/8/122010/10/12010/11/202011/1/92011/2/282011/4/192011/6/82011/7/2800.10.20.30.40.50.60.7分布式MySQL集群字段+条目数分片MyISAM引擎离线批量装载跨机房互备云梯APPMySQL集群数据装载数据查询MyFOX透明的集群中间层MyFOX透明查询基于NodeJS，1200QPS数据装
5、载路由计算数据装入一致性校验集群管理配置信息维护监控报警MyFOX-数据查询取分片数据（异步并发）取分片结果合并（表达式求值）合并计算缓存路由SQL解析语义理解查询路由字段改写分片SQL计算规则APC缓存XMyFOX-节点结构MyFOX热节点（MySQL）15k SAS盘，300G * 12，raid10内存:24G成本:4.5W / T冷节点（MySQL）7.2k SATA盘，1T * 12，raid10内存:24G成本:1.6W / T路由表30天无访问的冷数据新增热数据小结根据业务特点分库分表冷热数据分离降低成本，好钢用在刀刃上更有效地使用内存SQL虽牛，但是如果继续用MySQL来存储数
6、据，你怎么建索引？NoSQL是SQL的有益补充全属性交叉运算不同类目的商品有不同的属性同一商品的属性对有很多用户查询所选择的属性对不确定Prometheus定制化的存储实时计算Prom数据装载 PromHbaseHbaseHbase索引：交易id列表属性对交易1（二进制，定长）交易2Prom数据查询求SUM(alipay)属性属性值笔记本尺寸13寸笔记本定位商务定位节点11, 2, 3, 4, 5, 6, 7, 8, 9节点21, 2, 3, 4, 5, 6, 7查索引求交集节点21, 2, 4, 6, 7本地SUM运算（Hbase扩展）汇总计算写入缓存Prom数据冗余明细数据大量冗余牺牲磁盘
7、容量，以得到：避免明细数据网络传输变大量随机读为顺序读小结NoSQL是SQL的有益补充“预算”与“现算”的权衡“本地”与“集中”的协同其他的数据来源Prom的其他应用（淘词、指数等）从isearch获取实时的店铺、商品描述从主站搜索获取实时的商品数异构数据源如何整合统一？用中间层隔离前后端pengchun$ tail /logs/glider-rt2.log127.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数据中间层
8、Glider多数据源整合UNIONJOIN输出格式化PERCENT / RANK OVER JSON输出Glider架构DispatcherController配置解析请求解析一级缓存actionMyFOXProm二级缓存datasourceJOINUNIONfilter缓存是系统化的工程glider缓存系统前端产品一级缓存data二级缓存URL请求，nocache?nocache?nocache?Min (ttl)ttl, http headeretag, http header小结用中间层隔离前后端底层架构对前端透明水平可扩展性缓存是把双刃剑降低后端存储压力数据一致性问题缓存穿透与失效回顾关系型数据库仍然是王道分库分表、冷热分离NoSQL是SQL的有益补充用冗余避免网络传输和随机读用中间层隔离前后端异构数据源的整合缓存是系统化的工程数据一致性、穿透与雪崩矛盾之美SQLNoSQL计算时机“预算”Hadoop / 实时计算引擎“现算”MySQL + 中间层Hbase + 中间层计算场所本地MySQL单机Hbase Region Server集中MyFOX中间层Prom中间层数据存储冷7200 SATA盘HDFS热15000 SAS盘 + 缓存HDFS + 缓存谢谢
