淘宝海量数据产品的技术架构 - Mainz

标签: 淘宝 量数 产品 | 发表时间:2014-04-01 07:19 | 作者:Mainz
出处:
淘宝海量数据产品的技术架构是什么,又是如何应对双十一的海量访问的?先看图:

20085857-197801ef9d9c448fa3c21a25ffa7aaae

按照数据的流向来划分,我们把淘宝数据产品的技术架构分为五层(如图1所示),分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们的数据来源层,这里有淘宝主站的用户、店铺、商品和交易等数据库,还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。

 

在数据源层实时产生的数据,通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上,这个集群我们称之为“云梯”,是计算层的主要组成部分。在“云梯”上,我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据,这里的计算结果很可能是一个处于中间状态的结果,这往往是在数据冗余与前端计算之间做了适当平衡的结果。

 

不得不提的是,一些对实效性要求很高的数据,例如针对搜索词的统计数据,我们希望能尽快推送到数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的,为此我们做了流式数据的实时计算平台,称之为“银河”。“银河”也是一个分布式系统,它接收来自TimeTunnel的实时消息,在内存中做实时计算,并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中,供前端产品调用。

 

容易理解,“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为,对于“云梯”来说,它的定位只是做离线计算的,无法支持较高的性能和并发需求;而对于“银河”而言,尽管所有的代码都掌握在我们手中,但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中,避免不了分层,最终仍然落到了目前的架构上。

 

为此,我们针对前端产品设计了专门的存储层。在这一层,我们有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom,在后面的文字中,我将重点介绍这两个集群的实现原理。除此之外,其他第三方的模块也被我们纳入存储层的范畴。存储层异构模块的增多,对前端产品的使用带来了挑战。为此,我们设计了通用的数据中间层——glider——来屏蔽这个影响。glider以HTTP协议对外提供restful方式的接口。数据产品可以通过一个唯一的URL获取到它想要的数据。

 

以上是淘宝海量数据产品在技术架构方面的一个概括性的介绍。

分布式MySQL集群的查询代理层——MyFOX

淘宝数据产品选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上,为了应对海量数据,我们设计了分布式MySQL集群的查询代理层——MyFOX,使得分区对前端应用透明。

20085853-90aa1831a2304f9aba5477651e2749de

目前,存储在MyFOX中的统计结果数据已经达到10TB,占据着数据魔方总数据量的95%以上,并且正在以每天超过6亿的增量增长着(如图2所示)。这些数据被我们近似均匀地分布到20个MySQL节点上,在查询时,经由MyFOX透明地对外服务:

20085853-627a9fdcd29242eb83bb6ed5081ef645

值得一提的是,在MyFOX现有的20个节点中,并不是所有节点都是“平等”的。一般而言,数据产品的用户更多地只关心“最近几天”的数据,越早的数据,越容易被冷落。为此,出于硬件成本考虑,我们在这20个节点中分出了“热节点”和“冷节点”(如上图)

顾名思义,“热节点”存放最新的、被访问频率较高的数据。对于这部分数据,我们希望能给用户提供尽可能快的查询速度,所以在硬盘方面,我们选择了每分钟15000转的SAS硬盘,按照一个节点两台机器来计算,单位数据的存储成本约为4.5W/TB。相对应地,“冷数据”我们选择了每分钟7500转的SATA硬盘,单碟上能够存放更多的数据,存储成本约为1.6W/TB。将冷热数据进行分离的另外一个好处是可以有效提高内存磁盘比。从图4可以看出,“热节点”上单机只有24GB内存,而磁盘装满大约有1.8TB(300 * 12 * 0.5 / 1024),内存磁盘比约为4:300,远远低于MySQL服务器的一个合理值。内存磁盘比过低导致的后果是,总有一天,即使所有内存用完也存不下数据的索引了——这个时候,大量的查询请求都需要从磁盘中读取索引,效率大打折扣。

NoSQL是SQL的有益补充

在MyFOX出现之后,一切都看起来那么完美,开发人员甚至不会意识到MyFOX的存在,一条不用任何特殊修饰的SQL语句就可以满足需求。这个状态持续了很长一段时间,直到有一天,我们碰到了传统的关系型数据库无法解决的问题——全属性选择器(如下图所示)。

淘宝数据魔方技术架构解析【转】

这是一个非常典型的例子。为了说明问题,我们仍然以关系型数据库的思路来描述。对于笔记本电脑这个类目,用户某一次查询所选择的过滤条件可能包括“笔记本尺寸”、“笔记本定位”、“硬盘容量”等一系列属性(字段),并且在每个可能用在过滤条件的属性上,属性值的分布是极不均匀的。在图5中我们可以看到,笔记本电脑的尺寸这一属性有着10个枚举值,而“蓝牙功能”这个属性值是个布尔值,数据的筛选性非常差。

在用户所选择的过滤条件不确定的情况下,解决全属性问题的思路有两个:一个是穷举所有可能的过滤条件组合,在“云梯”上进行预先计算,存入数据库供查询;另一个是存储原始数据,在用户查询时根据过滤条件筛选出相应的记录进行现场计算。很明显,由于过滤条件的排列组合几乎是无法穷举的,第一种方案在现实中是不可取的;而第二种方案中,原始数据存储在什么地方?如果仍然用关系型数据库,那么你打算怎样为这个表建立索引?

这一系列问题把我们引到了“创建定制化的存储、现场计算并提供查询服务的引擎”的思路上来,这就是Prometheus(如下图所示)。

淘宝数据魔方技术架构解析【转】

从图中可以看出,我们选择了HBase作为Prom的底层存储引擎。之所以选择HBase,主要是因为它是建立在HDFS之上的,并且对于MapReduce有良好的编程接口。尽管Prom是一个通用的、解决共性问题的服务框架,但在这里,我们仍然以全属性选择为例,来说明Prom的工作原理。这里的原始数据是前一天在淘宝上的交易明细,在HBase集群中,我们以属性对(属性与属性值的组合)作为row-key进行存储。而row-key对应的值,我们设计了两个column-family,即存放交易ID列表的index字段和原始交易明细的data字段。在存储的时候,我们有意识地让每个字段中的每一个元素都是定长的,这是为了支持通过偏移量快速地找到相应记录,避免复杂的查找算法和磁盘的大量随机读取请求。

淘宝数据魔方技术架构解析【转】

上图用一个典型的例子描述的Prom在提供查询服务时的工作原理,限于篇幅,这里不做详细描述。值得一提的是,Prom支持的计算并不仅限于求和SUM运算,统计意义上的常用计算都是支持的。在现场计算方面,我们对HBase进行了扩展,Prom要求每个节点返回的数据是已经经过“本地计算”的局部最优解,最终的全局最优解只是各个节点返回的局部最优解的一个简单汇总。很显然,这样的设计思路是要充分利用各个节点的并行计算能力,并且避免大量明细数据的网络传输开销。

用中间层隔离前后端- glider

上文提到过,MyFOX和Prom为数据产品的不同需求提供了数据存储和底层查询的解决方案,但随之而来的问题是,各种异构的存储模块给前端产品的使用带来了很大的挑战。并且,前端产品的一个请求所需要的数据往往不可能只从一个模块获取。

举个例子,我们要在数据魔方中看昨天做热销的商品,首先从MyFOX中拿到一个热销排行榜的数据,但这里的“商品”只是一个ID,并没有ID所对应的商品描述、图片等数据。这个时候我们要从淘宝主站提供的接口中去获取这些数据,然后一一对应到热销排行榜中,最终呈现给用户。

淘宝数据魔方技术架构解析【转】

从本质上来讲,这就是广义上的异构“表”之间的JOIN操作。那么,谁来负责这个事情呢?很容易想到,在存储层与前端产品之间增加一个中间层,它负责各个异构“表”之间的数据JOIN和UNION等计算,并且隔离前端产品和后端存储,提供统一的数据查询服务。这个中间层就是glider(如图所示)。

除了起到隔离前后端以及异构“表”之间的数据整合的作用之外,glider的另外一个不容忽视的作用便是缓存管理。上文提到过,在特定的时间段内,我们认为数据产品中的数据是只读的,这是利用缓存来提高性能的理论基础。

glider中存在两层缓存,分别是基于各个异构“表”(datasource)的二级缓存和整合之后基于独立请求的一级缓存。除此之外,各个异构“表”内部可能还存在自己的缓存机制。细心的读者一定注意到了图3中MyFOX的缓存设计,我们没有选择对汇总计算后的最终结果进行缓存,而是针对每个分片进行缓存,其目的在于提高缓存的命中率,并且降低数据的冗余度。

大量使用缓存的最大问题就是数据一致性问题。如何保证底层数据的变化在尽可能短的时间内体现给最终用户呢?这一定是一个系统化的工程,尤其对于分层较多的系统来说。

用户的请求中一定是带了缓存控制的“命令”的,这包括URL中的query string,和HTTP头中的“If-None-Match”信息。并且,这个缓存控制“命令”一定会经过层层传递,最终传递到底层存储的异构“表”模块。各异构“表”除了返回各自的数据之外,还会返回各自的数据缓存过期时间(ttl),而glider最终输出的过期时间是各个异构“表”过期时间的最小值。这一过期时间也一定是从底层存储层层传递,最终通过HTTP头返回给用户浏览器的。

缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。

有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。在数据魔方里,我们采用了一个更为简单粗暴的方法,如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

缓存失效时的雪崩效应对底层系统的冲击非常可怕。遗憾的是,这个问题目前并没有很完美的解决方案。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。在数据魔方中,我们设计的缓存过期机制理论上能够将各个客户端的数据失效时间均匀地分布在时间轴上,一定程度上能够避免缓存同时失效带来的雪崩效应。

结束语

正是基于本文所描述的架构特点,数据魔方目前已经能够提供压缩前80TB的数据存储空间,数据中间层glider支持每天4000万的查询请求,平均响应时间在28毫秒(6月1日数据),足以满足未来一段时间内的业务增长需求。尽管如此,整个系统中仍然存在很多不完善的地方。一个典型的例子莫过于各个分层之间使用短连接模式的HTTP协议进行通信。这样的策略直接导致在流量高峰期单机的TCP连接数非常高。所以说,一个良好的架构固然能够在很大程度上降低开发和维护的成本,但它自身一定是随着数据量和流量的变化而不断变化的。我相信,过不了几年,淘宝数据产品的技术架构一定会是另外的样子。

其他文章摘要:

【1】海量数据领域涵盖分布式数据库、分布式存储、数据实时计算、分布式计算等多个技术方向。

对于海量数据处理,从数据库层面来讲无非就是两点:1、压力如何分摊,分摊的目的就是为了把集中式变为分布式。2、采用多种的存储方案,针对不同的业务数据,不同的数据特点,采用RDBMS或采用KV Store,选择不同数据库软件,使用集中式或分布式存储,或者是其他的一些存储方案。

 

【2】将数据库进行拆分,包括水平拆分和垂直拆分。

水平拆分主要解决两个问题:1、底层存储的无关性。2、通过线性的去增加机器,支持数据量以及访问请求包括TPS(Transaction Per Second)、QPS(Query Per Second)的压力增长。其方式如把一张大数据表按一定的方式拆分到不同的数据库服务器上。海量数据从集中式走向分布式,可能涉及跨多个IDC容灾备份特性。

 

【3】阿里巴巴的数据对不同地域数据的处理方法。

由三个产品密切配合解决:是Erosa、Eromanga和Otter。Erosa做MySQL(或其他数据库库)的Bin-Log时时解析,解析后放到Eromanga。Eromanga是增量数据的发布订阅的产品。Erosa产生了时时变更的数据发布到Eromanga。然后各个业务端(搜索引擎、数据仓库或关联的业务方)通过订阅的方式,把时时变更的数据时时的通过Push或Pull的方式拉到其业务端,进行一些业务处理。而Otter就是跨IDC的数据同步,把数据能及时反映到不同的AA站。数据同步可能会有冲突,暂时是以那个站点数据为优先,比如说A机房的站点的数据是优先的,不管怎么样,它就覆盖到B的。

 

【4】对于缓存。

1、注意切分力度,根据业务选择切分力度。把缓存力度划分的越细,缓存命中率相对会越高。2、确认缓存的有效生命周期。

 

【5】拆分策略

1、按字段拆分(最细力度)。如把表的Company字段拆掉,就按COMPANY_ID来拆。

2、按表来拆,把一张表拆到MySQL,那张表拆到MySQL集群,更类似于垂直拆分。

3、按Schema拆分,Schema拆分跟应用相关的。如把某一模块服务的数据放到某一机群,另一模块服务的数据放到其他MySQL机群。但对外提供的整体服务是这些机群的整体组合,用Cobar来负责协调处理。

 

(原文: http://server.51cto.com/taobao2012/


本文链接: 淘宝海量数据产品的技术架构,转载请注明。

相关 [淘宝 量数 产品] 推荐:

淘宝海量数据产品的技术架构 - Mainz

- - 博客园_Mainz's Blog
淘宝海量数据产品的技术架构是什么,又是如何应对双十一的海量访问的. 按照数据的流向来划分,我们把淘宝数据产品的技术架构分为五层(如图1所示),分别是数据源、计算层、存储层、查询层和产品层. 位于架构顶端的是我们的数据来源层,这里有淘宝主站的用户、店铺、商品和交易等数据库,还有用户的浏览、搜索等行为日志等.

淘宝Pinterest产品扎堆 开放下规则隐忧

- - ITeye博客
3月的一天,所有阿里巴巴集团中层以上干部,都目不转睛的望着台上的这位演讲人. 他演讲的课题是长江、黄河、草原是如何形成一个个小的生态圈,不同的生态圈又是如何构建成一个稳定的生态系统的. 这是阿里巴巴集团员工被通知要无条件接受轮岗后,阿里巴巴集团组织部所召开的第一次内部大会. 台上的演讲者是马云从大自然保护协会请来的一位生态学研究专家.

淘宝大牛做基础产品的体会

- - 互联网 - ITeye博客
一个公司大了,总有部分人要去做一些通用的东西给大家用,我这里说的基础产品就是这类通用性质的东西,不一定高科技,但是一定很多人依赖你的东西来完成各种各样的功能. 做这样的东西,有些体会可以说下. 首先,能集中存储的,就不要分布存储,数据集中存储有单点的危险,但是比之分布式存储带来的复杂度不可同日而语.

淘宝数据产品技术架构分析

- - 互联网分析沙龙
淘宝网拥有国内最具商业价值的海量数据. 截至当前,每天有超过30亿的店铺、商品浏览记录,10亿在线商品数,上千万的成交、收藏和评价数据. 如何从这些数据中挖掘出真正的商业价值,进而帮助淘宝、商家进行企业的数据化运营,帮助消费者进行理性的购物决策,是淘宝数据平台与产品部的使命. 为此,我们进行了一系列数据产品的研发,比如为大家所熟知的量子统计、数据魔方和淘宝指数等.

正祥的淘宝海量数据库思考分享

- alex zhao - 淘宝核心系统团队博客
正祥(阳振坤老师)最近在个人新浪博客上发表了一系列针对淘宝分布式数据服务系统思考性文章,特此分享. 淘宝海量数据库之一:来自业务的挑战. 淘宝海量数据库之二:一致性选择. 淘宝海量数据库之三:事务的ACID. 淘宝海量数据库之四:系统架构与跨表事务. 淘宝海量数据库之五:数据结构.

淘宝自主研发的海量数据库OceanBase开源

- beralee - cnBeta.COM
OceanBase是一个支持海量数据的高性能分布式数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成. 在设计和实现OceanBase的时候暂时摒弃了不紧急的DBMS的功能,例如临时表,视图(view),研发团队把有限的资源集中到关键点上,当前 OceanBase主要解决数据更新一致性、高性能的跨表读事务、范围查询、join、数据全量及增量dump、批量数据导入.

淘宝海量数据库之六-克服随机IO难题

- William - 阳振坤的博客
与传统磁盘相比,SSD固态盘提供了非常好的随机读性能,单盘可达35000IOPS (4KB)甚至更高,并提供512MB/s或以上的读出带宽. 但通常SSD盘的随机写性能甚至比一般磁盘更差,这是因为,尽管SSD的读和写都以4KB页(page)为单位,但SSD写入前需要先擦除已有内容,而擦除以块(block)为单位,一个块(block)通常是128个连续的页(page),即512KB.

[原]淘宝Buy+负责人胡晓航:从技术和产品维度看Buy+ VR购物

- - 雷锋网
导语:阿里巴巴是怎么做VR购物的. 此次公开课我们邀请到了Buy+负责人胡晓航,为你解答所有这些疑问. 一年一度的网购狂欢节“双十一”刚刚过去,这不仅仅是购物者的盛宴,也是各种新技术登场的时刻,其中就包括Buy+ . 有很多人喜欢网购体验,端着手机、电脑、Pad一页页浏览商品,但也有许多人怀念线下购物,那种和姐妹一起逛街、聊天,拿起一件商品查看标签和价格的感觉.

淘宝“伤”城

- 品味视界 - FT中文网_英国《金融时报》(Financial Times)
秦苏为英国《金融时报》中文网撰稿. 中国互联网的野蛮生长,再次震惊了电子商务市场. 10月11日晚间,为抗议淘宝商城大幅提高技术服务年费和保证金,约7000家中小卖家通过YY网络语音等组织方式,对韩都衣舍、欧莎、七格格、优衣库等大卖家进行攻击,包括利用规则进行购物、给差评、到货付款或申请退款等. 通过集中拍下某商品,导致这些商家的大部分商品下架“被拍死”.

淘宝维权记

- loudly - 马日拉
我先是在八月上旬从淘宝卖家“偶遇燕燕”处购买了两张高凳. 货送到时仅用塑料气泡纸包装,无硬纸包装. 因为外包装并无破损,所以当时就签收了. 快递走后,拆开包装,发现其中一个凳子凳面完全裂成两半,一个凳脚连接处完全碎裂. 两张凳子平放在一起,高度有一公分以上的落差,说明:1.卖家为减小货物体积,省略了硬质外包装,虽然物品表面由于有气泡纸保护完全无损,但运送途中,一个外形不规则的货物用脚指头想想也知道会因为堆叠、搬运等等情况,造成结构性的损毁.