淘宝数据魔方技术架构解析汇编.pdfVIP

淘宝数据魔方技术架构解析 淘宝网拥有国内最具商业价值的海量数据。截至当前，每天有超过 30 亿的店铺、商品浏览记录， 10 亿在线商品数，上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘 宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。 为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。 尽管从业务层面来讲，数据产品的研发难度并不高；但在 “海量 ”的限定下，数据产品的计算、存储和检索 难度陡然上升。本文将以数据魔方为例，向大家介绍淘宝在海量数据产品技术架构方面的探索。 淘宝海量数据产品技术架构 数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整 个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。 图 1 淘宝海量数据产品技术架构 按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层（如图 1 所示），分别是数据源、 计算层、 存储层、 查询层和产品层。 位于架构顶端的是我们的数据来源层， 这里有淘宝主站的用户、 店铺、 商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力 所在。 在数据源层实时产生的数据，通过淘宝自主研发的数据传输组件 DataX 、DbSync 和 Timetunnel 准实 时地传输到一个有 1500 个节点的 Hadoop 集群上，这个集群我们称之为“云梯” ，是计算层的主要组成部 分。在 “云梯”上，我们每天有大约 40000 个作业对 1.5PB 的原始数据按照产品需求进行不同的 MapReduce 计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据，这里的计算结果很可能 是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。 不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到 数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平 台，称之为“银河” 。“银河”也是一个分布式系统，它接收来自 TimeTunnel 的实时消息，在内存中做实时 计算，并把计算结果在尽可能短的时间内刷新到 NoSQL 存储设备中，供前端产品调用。 容易理解， “云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云 梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所 有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系 统中，避免不了分层，最终仍然落到了目前的架构上。 为此，我们针对前端产品设计了专门的存储层。在这一层，我们有基于 MySQL 的分布式关系型数据 库集群 MyFOX 和基于 HBase 的 NoSQL 存储集群 Prom，在后面的文字中，我将重点介绍这两个集群的实 现原理。除此之外，其他第三方的模块也被我们纳入存储层的范畴。 存储层异构模块的增多， 对前端产品的使用带来了挑战。 为此，我们设计了通用的数据中间层—— glider ——来屏蔽这个影响。 glider 以 HTTP 协议对外提供 restful 方式的接口。 数据产品可以通过一个唯一的 URL 获取到它想要的数据。 以上是淘宝海量数据产品在技术架构方面的一个概括性的介绍，接下来我将重点从四个方面阐述数据 魔方设计上的特点。 关系型数据库仍然是王道 关系型数据库（ RDBMS ）自 20 世纪 70 年代提出以来，在工业生产中得到了广泛的使用。经过三十 多年的长足发展，诞生了一批优秀的数据库软件，例如 Oracle 、MySQL 、 DB2 、Sybase和 SQL