《淘宝数据魔方技术架构解析》读后感

 文章来源：https://kb.cnblogs.com/page/110840/  

　　我们知道，淘宝每天会产生海量数据，每天有超过数十亿的店铺信息、商品信息、商品浏览记录、订单信息、用户评价信息等数据。但是，随着淘宝的不断发展，淘宝对于海量数据的计算、存储、检索难度急剧上升。对此，淘宝经过一系列研发，提出了现在我们所熟知的量子统计、数据魔方、淘宝指数等。

　　淘宝数据技术架构可分为五层，分别为数据源、计算层、存储层、查询层、产品层。

　　数据源包含店铺、商家、商品、交易等数据库，以及用户浏览、检索商品的日志等内容。数据源是数据产品的最根源所在，只有拥有数据源，数据产品才可能对数据进行处理。

对于计算层，在淘宝中主要有两种计算平台——“云梯”和“银河”，他们是计算层的主要组成部分。“云梯”主要处理数据源层实时产生的数据，这些数据通过淘宝的数据传输组件DataX、DbSync、Timetunnel准确实时地传输到一个拥有大量节点的Hadoop集群上，这个集群我们就称之为“云梯”。在“云梯”上，不同的作业对于这些实时产生的数据根据不同的产品需求会进行不同的MapReduce计算，但是该计算结果可能并不是我们在前端看到的数据，而只是数据冗余与前端计算之间做了一个平衡的结果，它只是一个中间结果，在前端显示的数据是对这些计算结果进一步处理的结果。显然，如果我们希望某些数据可以尽快的传送到前端，这时候我们再使用“云梯”计算就比较慢了，因此就有了“银河”计算平台。“银河”，顾名思义，是“水流”，它是对流式数据进行处理，通过对来自Timetunnel的实时数据做实时计算，然后将计算结果在尽可能短的时间里更新到NoSQL数据库中，以便前端的使用。但是，这两种计算平台都不太适合用于实时的数据查询，“云梯”更适合用于离线计算，“银河”要想实现实时查询，需要完整地将数据接收，实时计算、存储、查询等功能都集成在这个计算平台上，显然，这又需要分层实现，最终又落到目前的架构上。

　　因为“云梯”和“银河”无法提供实时数据查询，淘宝针对前端设计了专门的存储层。首先，淘宝选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上，为了应对海量数据，淘宝设计了MyFox，它是分布式MySQL集群的查询代理层，使分区对前端应用透明。在MyFox中，根据需要数据的情况，将MyFox中的节点分为“冷节点”和“热节点”，“冷节点”，顾名思义，存放人们冷落、不太关心的数据，即一些访问频率较低，产生时间较长的数据，与之相对地，“热节点”存放的是最新产生的，用户访问频率较高的数据。不同的数据存放在效率不同的硬盘中，例如，“热节点”中的数据存放在SAS硬盘中，成本较高；“冷节点”中的数据存放在SATA硬盘中，成本较低。

　　但是，淘宝有一项功能如下图，

 

用户可以自由选择产品属性范围，虽然用用户用着很方便，但是对于开发人员就不那么方便了，用户选择的过滤条件我们无法确定，这时候如何使用SQL运距进行查询呢？也许你会说，用条件语句对所有可能的条件进行判定，那样对于两三个条件来说或许可以，但是对于淘宝这么多条件，要想列举出所有情况显然很难做到。所以对于这种情况，关系型数据库就不那么方便了。对此，淘宝的解决办法是使用Prometheus，并且以HBASE作为Prom的底层存储引擎。在存储数据时，以row-key键值对（属性与属性值的组合）进行存储，而row-key对应的值为column-family，即存放交易ID列表的index字段和原始交易明细的data字段。然后通过建立索引可以快速找到相应的记录，避免复杂的查找算法和磁盘的大量随机读取请求。

　　存储层利用了关系层数据库和NoSQL的数据库，为数据产品的不同需求提供了数据存储和底层查询的解决办法。但是各种异构的模块也为前端的使用带了很大的挑战，此外，我们所需要的数据也不会一直都在一个模块中获取。所以，究其本质来说，是异构“表”之间的join操作，淘宝在前端产品与后端存储之间加了一个通用的数据中间层——glider，来屏蔽这些影响，起到隔离作用及缓存管理。它通过HTTP协议对外提供restful方式的接口。数据产品可以通过一个唯一的URL获取到它想要的数据。

　　产品层包括数据魔方、淘宝指数等内容，在这里就不过多的解释了，本篇博客主要根据自己的理解对《淘宝数据魔方技术架构解析》这篇文章做了一下梳理，如有不当之处，还请批评指正！

转载于:https://www.cnblogs.com/qilin20/p/10590096.html