淘宝数据魔方技术架构解析读后感
现代社会最具商业价值的就是数据，淘宝网拥有国内最具商业价值的海量数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。淘宝在数据存储和处理领域在国内互联网公司中一直保持比较靠前的位置，而且由于电子商务领域独特的应用场景，淘宝在数据实时性和大规模计算及挖掘方面一直在国内保持着领先，因此积累了很多的实践的经验和产品，《淘宝数据魔方技术架构解析》以数据魔方为例，向我们介绍了淘宝在海量数据产品技术架构方面的探索。
《淘宝数据魔方技术架构解析》将淘宝数据产品的技术架构分为五层，，分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。
淘宝对海量数据的处理自然用到大数据，淘宝的数据处理架构总体成为“云梯”。”云梯”是一个有1500个节点的Hadoop集群，在“云梯”上，每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。
一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。
“云梯”的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。为此，淘宝针对前端产品设计了专门的存储层。在这一层，淘宝有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom。
1、MyFOX
淘宝数据产品选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上，为了应对海量数据，淘宝设计了分布式MySQL集群的查询代理层——MyFOX，使得分区对前端应用透明。存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上，并且正在以每天超过6亿的增量增长着（如图2所示）。这些数据被近似均匀地分布到20个MySQL节点上。在MyFOX现有的20个节点中，并不是所有节点都是“平等”的。一般而言，数据产品的用户更多地只关心“最近几天”的数据，越早的数据，越容易被冷落。为此，出于硬件成本考虑，我们在这20个节点中分出了“热节点”和“冷节点”
（1） 热节点：
存放最新的、被访问频率较高的数据。对于这部分数据，希望能给用户提供尽可能快的查询速度，所以在硬盘方面，我淘宝选择了每分钟15000转的SAS硬盘，按照一个节点两台机器来计算，单位数据的存储成本约为4.5W/TB。
（2） 冷节点
冷数据”选择了每分钟7500转的SATA硬盘，单碟上能够存放更多的数据，存储成本约为1.6W/TB。
2、NoSQL
在用户所选择的过滤条件不确定的情况下，解决全属性问题的思路有两个：一个是穷举所有可能的过滤条件组合，在“云梯”上进行预先计算，存入数据库供查询；另一个是存储原始数据，在用户查询时根据过滤条件筛选出相应的记录进行现场计算。很明显，由于过滤条件的排列组合几乎是无法穷举的，第一种方案在现实中是不可取的；而第二种方案中，原始数据存储在什么地方？答案肯定不是关系型数据库。淘宝选择了HBase作为Prom的底层存储引擎。之所以选择HBase，主要是因为它是建立在HDFS之上的，并且对于MapReduce有良好的编程接口。现场计算方面，我们对Hbase进行了扩展，Prom要求每个节点返回的数据是已经经过“本地计算”的局部最优解，最终的全局最优解只是各个节点返回的局部最优解的一个简单汇总。很显然，这样的设计思路是要充分利用各个节点的并行计算能力，并且避免大量明细数据的网络传输开销。
一个良好的架构固然能够在很大程度上降低开发和维护的成本，但它自身一定是随着数据量和流量的变化而不断变化的。