互联网公司技术架构资料.淘宝.数据魔方系统架构

淘宝数据魔方的系统架构殷琳君（长林）Agenda□数据产品总体架构□分布式MySQL集群□NoSQL存储与计算□统一的数据中间层□通用数据报表框架每天的数据□淘宝主站：•30亿店铺、宝贝浏览•千万量级交易笔数□数据产品：•60G统计汇总结果•千万量级数据查询请求海量数据带来的挑战□计算□存储□读写架构总览MyFOXProm存储层Hadoop集群计算层实时流数据数据中间层/glider查询层数据魔方淘宝指数开放API产品DataX/TimeTunnel主站备库RAC主站日志数据源分布式MySQL集群—MyFOX需求：□SQL查询□海量存储□可横向扩展□对应用透明□兼顾性能分布式MySQL集群—MyFOX□分库分表•基于业务特点□透明的中间层（MyFOX）•查询代理•数据装载•集群管理云梯APPMySQL集群数据装载数据查询MyFOXMyFOX—分片规则□冗余复制•小表•访问频繁•JOIN□条目切割•按路由字段的值，每N行切片•路由字段是一级索引•分散压力、并行查询示例：条目切割□切片•阈值（200W）•上浮动（5%）□装桶•一个桶装满再开新桶•“桶”即实际的物理表thedate=20100816,tid=11^A2090000thedate=20100816,tid=12^A2120000thedate=20100816,tid=13^A760000thedate=20100816,tid=14^A289thedate=20100816,tid=11^A2090000thedate=20100816,tid=12^A2000000thedate=20100816,tid=12^A120000thedate=20100816,tid=13^A760000thedate=20100816,tid=14^A289thedate=20100816,tid=11^A2090000thedate=20100816,tid=14^A289thedate=20100816,tid=12^A2000000thedate=20100816,tid=13^A760000thedate=20100816,tid=12^A120000MyFOX—数据查询SELECTIF(INSTR(f.keyword,'')0,UPPER(TRIM(f.keyword)),CONCAT(b.brand_name,'',UPPER(TRIM(f.keyword))))ASf0,SUM(f.search_num)ASf1,SUM(f.uv)ASf2,ROUND(SUM(f.search_num)/SUM(f.uv),2)ASf3,AVG(f.uv)ASf4FROMfINNERJOINdim_brandbONf.keyword_brand_id=b.brand_idWHEREf.keyword_type_id=1ANDf.keyword!=''ANDkeyword_cat_idIN('50002535')ANDthedate='2011-03-10'ANDthedate='2011-03-08'GROUPBYf0ORDERBYSUM(f.search_num)DESCLIMIT0,1500MyFOX—数据查询取分片数据（异步并发）取分片结果合并（表达式求值）合并计算缓存路由SQL解析语义理解查询路由字段改写分片SQL计算规则APC缓存XMyFOX路由层—语义理解WHEREthedate='2011-03-10'ANDthedate'2011-03-07'ANDtoprank_idIN(2,3)232011-03-08{toprank_id:2,thedate:2011-03-08}{toprank_id:“3,thedate:2011-03-08}2011-03-09{toprank_id:2,thedate:2011-03-09}{toprank_id:“3,thedate:2011-03-09}2011-03-10{toprank_id:2,thedate:2011-03-10}{toprank_id:“3,thedate:2011-03-10}MyFOX路由层—字段改写SELECTaASf0,SUM(f.search_num)ASf1,SUM(f.uv)ASf2,ROUND(SUM(f.search_num)/SUM(f.uv),2)ASf3,AVG(f.uv)ASf4•AVG（a）•1+SUM(a)•SELECT a FROM … ORDER BY b•重复查询列MyFOX缓存结果合并取分片数据查询层计算层缓存缓存•缓存哪部分数据？最终结果分片数据MyFOX—数据装载MyFOX热节点（MySQL）15kSAS盘，300G*12，raid10成本:4.5W/T冷节点（MySQL）7.2kSATA盘，1T*12，raid10成本:1.6W/T路由表30天无访问的冷数据新增热数据这个问题能解决吗Prom—应用场景□数据量很大□无法穷举所有可能的查询条件组合□大量穷举出来的条件组合无意义Prom—算法13寸、商务定位的笔记本昨天的交易金额是多少？1、查询13寸笔记本昨天的交易ID2、查询商务定位笔记本昨天的交易ID3、求交易ID交集4、根据3中的交易ID查询明细数据，按照金额进行汇总Prom—第一版Redis□Redis•Key-Value的内存数据库•支持List、Set等数据结构□瓶颈•大量随机读取明细•内存受限，数据持久化问题Prom—第二版HBase□定制化的存储•HBase建立在hdfs之上，和Hadoop无缝集成•可水平扩展□实时计算•百万记录Prom—HBase表设计Row-key列族1（交易ID，索引）列族2（交易明细）笔记本尺寸：13寸1，2，4，9{58,600,35},{72,999,14},{92,103,77},{36,702,101}笔记本定位：商务定位1，4，7{58,600,35},{92,103,77},{85,442,152}Prom—HBase实时计算求SUM(alipay)属性属性值笔记本尺寸13寸笔记本定位商务定位节点11,2,3,4,5,6,7,8,9节点21,2,3,4,5,6,7查索引求交集汇总计算写入缓存节点21,4本地SUM运算（Hbase扩展）Prom—小结□历史数据的实时计算□通用性强，支持sum,count,avg,groupby,sort□空间换时间•变大量随机读为顺序读•避免明细数据网络传输SQL与NoSQL□互为补充，适用场景不同□SQL□应用开发更简单□支持跨行跨表事务□运维更成熟□NoSQL□水平扩展性更好□更适合解决海量数据存储与计算统一的数据中间层—Glider□统一数据出口•类SQL•HTTPREST•JSON返回□前后端解耦□数据缓存管理Glider架构DispatcherController配置解析请求解析一级缓存actionMyFOXProm二级缓存datasourceJOINUNIONfiltergliderGlider缓存管理前端产品actioncachedatadatasourcecacheURL请求，nocache?nocache?nocache?ttlttl,httpheaderetag,httpheaderGlider—小结□用中间层隔离前后端•底层架构对前端透明•水平可扩展性□缓存是把双刃剑•降低后端存储压力•数据一致性问题通用数据报表框架—Cubex□通过配置生成报表，快速开发□与组件化、事件驱动的JS框架集成•基础服务封装：http,event•可复用的组件库•统一的组件生命周期管理，易于维护前端JS框架回顾MySQLHBase存储层Hadoop集群计算层实时流数据数据中间层查询层数据魔方淘宝指数开放API产品数据传输用户、店铺、商品库收藏夹日志数据源交易表……谢谢!