阿里巴巴陶勇谈海量数据技术架构

1. 请先向大家介绍一下阿里巴巴网站，它目前的数据量大致在什么样的规模。从当初起步       发展到现在，经历了哪些重要的阶段，每个阶段又有哪些特点？ 
        阿里巴巴网站目前来讲分为中文站、国际站，还有一些国际交易和日本站之类的一些站点。我们核心表的数据量大概都是在亿和十亿级别，在这样的一个数量级下面，都会涉及到一些容量方面、性能方面，以及分布式方面的一些问题。整个网站发展到现在已经11年到12年的时间。我们的数据量也从最开始的很少一点，扩大到现在的规模，尤其是近几年更是呈爆发式的增长。数据库层面来讲，关键点是两个，一个是之前我们一直采用的Oracle数据库，不管是中文站还是国际站，Oracle数据库有非常多的优点，但是随着数据量的飞速增长，无论是用小机也好，还是更高端的存储也好，都会带来瓶颈的问题。我们在07年末，08年初的时候意识到了问题，因为那时候，我们的数据量呈现急剧上升的趋势。当时我们考虑的是将数据库进行拆分，拆分现在对于大家来说都已经耳熟能详了，包括水平拆分和垂直拆分。如果从数据库角度来讲，就两个阶段，是99年到08年，然后08年到现在的这个阶段。08年相当于是我们从单一的Oracle数据源跨越到多数据源支持的一个关键时间点。从08年开始，我们经历了大概一到两年的时间，将中文站最核心的表，以及和它关联的一些表拆分到了MySQL上，这时我们已经通过数据库的水平拆分，将数据均匀的拆分到了MySQL集群上面。不管是TPS （Transaction Per Second）也好，容量也好，都极大的缓解了之前Oracle遇到过的问题，包括它的逻辑读写非常大，CPU也一度飙升到三四十之类的问题等。从目前来讲，阿里巴巴的数据库，相对于其它互联网的一些网站，比如说淘宝，比如说Twitter之类的，本身还是有一些特点的，目前来讲，还是会员服务的性质为主。对于会员来讲，数据的一致性以及可用性要求都是非常高。与传统互联网企业相比，现在大多数新型的互联网企业在数据存储方面的要求可能有细微的差别。所以另外一点，数据要从集中式走向分布式。还有一点就是阿里巴巴网站相对于其他的站点而言，是少有的跨多个IDC，具备容灾备份的站点。不管是中文站还是国际站都有多个站点分布在不同的国内，甚至是国外的一些机房里面，这样的话，在包括数据一致性以及数据同步这一块，都会有一些特有的解决方案，大致就是这些特性。

2. 针对如此大量的数据采取什么样的策略来保障，即能快速响应用户的请求，又能够及时应对业务的发展呢？ 
        从数据库层面或者数据访问层面来讲无非就是两点，第一点，是压力如何分摊，分摊的目的就是为了把集中式变为分布式，这是其一。另外，采用多种的存储方案，不同的业务数据，它必然会有不同的特点，针对不同的特点，我们会采用例如Oracle来存储，或是MySQL来存，使用集中式的存储，还是分布式的存储，是采用传统的RDBMS，还是采用KV Store，或者是其他的一些存储方案。综合以上两点，从数据拆分来讲，我们目前在B2B更多的是水平拆分，我们把一张数据量非常大的表，上亿级别数据量的表，把它从Oracle里边搬出来，拆分到MySQL里边，这是一种水平拆分的方式。我们偶尔会采用一些垂直拆分的方案，但是垂直拆分方案相对而言，是一种过渡方案，最终还是为了达到水平拆分的目的。其实水平拆分主要为了解决两个问题，一个是，底层存储的无关性。另外一个就是随着数据量以及访问请求包括TPS、QPS（Query Per Second）的压力增长，我们能够通过线性的去增加机器就能够满足要求。此外还可以利用线性的这种增长方式，去支持压力和数据量的增长。至于多存储方案而言，其实这跟我们的业务是有紧密关系的，比如说我们非常核心的数据，目前还是选择存储在Oracle里面。像一些大数据量的，压力非常大的这种表，我们就选择把它拆分到MySQL数据库里面去。还有一种，其实就是简单的，比如说KV Store，跟目前的NoSQL的这种选型类似，就相当于把一些关系型不是特别明显的，例如网站的一些用户属性以及一些Property之类的数据，我们都把它放到KV Store里边去，大致，就是用这些技术手段来解决，应该说，最关键的一些技术解决方案，大致就是这些。

3.  刚才也提到其实阿里巴巴的数据，分布在不同的区域，对于这些不同地域的数据中心，同步是怎么处理的，采用什么样的方法，效果怎么样？ 
        去年在QCon的时候，潘磊做过大致的介绍。当然现在我这边是有些更新了，因为这一块目前是我来负责，就目前来讲，其实有三个产品来密切配合解决这样的一些问题，这三个产品分别是Erosa、Eromanga和Otter。可能听上去会让人感觉有点摸不着头脑，不知道是干什么的，Erosa简单的说就是做MySQL的Bin-Log时时解析，我们会对MySQL也好，还是一些其他的KV Store也好，他的BIN-LOG进行时时解析，解析完了之后，会放到Eromanga，Eromanga是什么东西？其实就是增量数据的发布订阅的产品，Erosa产生了时时变更的数据发布到Eromanga。然后，这时候，不管是搜索引擎也好，还是数据仓库也好，还是一些关联的业务方也好，他就可以通过订阅的方式，把这些时时变更的数据时时的通过Push或者是Pull的方式拉到他的业务端，然后进行一些业务处理。还有一块是Otter，其实更多的是它的定位，就是跨IDC的数据同步，之前是国际站，现在是中文站，中文站我们也有容灾站点，应该不光是说容灾站点，应该是AA站点，这时候，我们要求我们的数据能够及时的反映到两边去，我们是通过Otter来解决这方面的问题。Otter，其实就是类似于业界，比如说现在SharePlex的这种方式的数据同步的方式，双向同步的数据解决方案，相比而言，不管是数据库的同步，还是说SharePlex的同步也好，我们做了一些定制化，包括对业务数据关联的一些文件系统同步，我们是按照事务的方式来将数据通过Otter重组应用到另外站点的数据库里面去，这是相对于目前业界的一些商业产品不同的地方。另外一个，数据同步冲突这一块，其实阿里巴巴站点，虽然我们现在新的一些架构都极力避免同一条数据在两IDC机房里面的数据库中同时被修改，但是由于一些历史原因，的确存在有一些业务既在这个机房里变更，与此同时，他也会在另一个机房里面被变更，这时候怎么解决同步冲突。这时候我们其实这是这一块我们目前来讲，是最难解决，但是目前又还急需解决的，我们目前，当然现有的版本，暂时是一种比较简单的方式去解决问题的。其实就是以那个站点数据为优先，站点A，比如说A机房的站点的数据是优先的，不管怎么样，它就覆盖到B的，今后我们会有一些包括业务相关的策略，包括变更的时间，及冲突合并之类的方式来解决到这种双向同步，以及变更冲突这方面的一些问题。从时时效果来看，目前来讲，Erosa和Otter，目前承担了几乎B2B所有的，不管是跨IDC的还是说从跨站点的，比如说我们从中文站同步到DW，还是从国际站同步到DW，同步到其他的一些数据源。那目前来讲，基本上现在已经是遍地插满旗帜，大致情况是这样的。

4. 其实缓存在整个系统架构中的地位还是相当高的，像阿里巴巴这样的系统，是如何使用缓存的。另外，是怎样设计好系统的缓存结构？
        缓存这个东西，首先在阿里巴巴来讲，它其实是分为几个级别的，从前到后，比如说从用户最开始发起HTTP请求，到最后访问数据库，目前来讲，是分了三级缓存的，包括图片，包括页面的缓存。然后直到最后面的包括数据的缓存、图片的缓存，以及静态页面的缓存，相对而言，都是采用热点数据方式，包括提高他的命中率，基本上我们的命中率都非常高，前端相对而言都比较高。对于后端比如说数据缓存这一块，目前来讲，分为Local Cache和Remote Cache，应该叫Distribute Cache。就相当于说，我们会把一些不怎么变化的比如说属性数据，用户属性，或是一些其他的属性数据，会在Server启动的时候，将其加载到Local Cache，这时，就不需要关心一致性的问题，反正就是启动之后就加载到Local Cache，这是一种缓存。还有一种，就是Remote Cache，相当于是分布式的Cache。就B2B来讲，目前Cache的实现策略非常多，实现的底层不管是包括Berkeley DB也好，还是Memcache DB也好，实际有很多的。同时我们在前端也做了一层封装，无论底层的Cache是用哪一种存储实现，都能根据业务场景需要，提供出一些最优推荐。对于如何提高缓存命中率，如何进行缓存的设计，我说下B2B的一些选择。就前端图片和页面来讲，我们会把一些动态页面静态化。静态化这块我们有相应的产品来支持动态页面静态化。数据缓存这块，我们更多的是从对象缓存的角度来看，缓存命中率更关键的是把缓存力度划分的越细，命中率相对会越高。另外一块，缓存跟业务是具有相关性的，在做架构设计时，需要确定哪些是需要缓存到里面的，因为缓存并不是无限大的。另外，缓存是有有效期的，不可能无限的让他存在那儿，要真是如此的话，他就不叫Cache，叫Store了，所以这块，大致就是这样一些机制。第一个是注意切分力度，什么样的业务需要保证什么样的力度，有些细力度，有些粗力度。还有一块，如何保证缓存的生命周期，他的有效期是多久，因为不可能把所有东西都缓存到Cache里面去。

5. 刚才也提到对数据库的拆分，那其实在数据量非常大的情况之下，数据库拆分是今后一定要去进行的一件事情，在拆分的过程中，是如何保证即不间断服务，又能进行平滑的过度？ 
        其实在阿里巴巴，特别是在技术部，这边的团队有一个比较有意思的称谓，叫做拆迁大队。三国杀游戏里有个人物叫甘宁，就是专门负责拆牌的，这个团队其实就是把目前Oracle中大数据量的表拆成MySQL的。目前来讲，我们拆分，其实是有几个拆分策略的，第一个是按字段拆分，这是最细力度的。比如说一张表我按某个字段Company拆掉，我就按COMPANY_ID来拆，这是一种方式，还有一种是按表来拆，我把这张表拆到MySQL，那张表拆到MySQL集群，更类似于垂直拆分。还有一种是按Schema拆分，Schema拆分就相当于说，这是跟应用相关的。比如说我B2B这样应用，我会把它拆分到这个Schema机群里面来。另外W服务我会把它的数据库拆到另外MySQL机群。但是对外提供的还是这一组，就是前面我也提到了，我们说的Cobar，可能还没提到，就是说我们其实拆分负责数据拆分，我们有产品叫做Cobar，Cobar其实类似于MySQL Proxy，他解析了MySQL所有的协议，就相当于是说，我们是可以把它看成MySQL Server来访问的，它前端是挂了很多Cobar Server的。根据Schema拆也好，按照表拆也好，在Cobar上面会根据你的需要，去定义自己的拆分策略。拆分好后，就自动会路由到MySQL不同的服务器上面去。还有一方面其实最关键的是，拆掉了之后，怎么样做数据的扩容，其实我们从08年发展到现在，只能说还在路上，因为有些自动化以及自动化的配置，其实跟流动计算是相关的，我怎么样要让正在运行的，让某MySQL机器人上来，然后，把比如说这里有一千万数据，我把它对等的拆成各五百万，拆到集群上面，然后再把这台老的，MySQL上面的五百万老数据干掉，我们最终理想的状况是想自动化的完成，但目我们还是更多的是纯人工的方式来做，就相当于是说先把这500万搬过去，这时候其实有拆分原则的，但是我们内部，搬过去之后，然后再把这边的切掉，这是纯人工的。就数据迁移来讲，我们内部，是有严格的五步走的策略，要把Oracle的一张表或者是数据库拆分到MySQL上面去，这时候我们有严格的五个步骤来做的，每个步骤做完了，第一步骤做完了才能做第二个，第二个步骤做完了，做第三个，简单来讲其实就是说第一个Oracle读写，MySQL写，就是慢慢的把一些数据写到MySQL里面去，这时候要做过程就是要把Oracle的的数据要做一次数据搬迁，迁移到MySQL上面。后面，就是设一些阀值。比如说产生ID以上的一些数据，就写到MySQL，以下的数据写到Oracle。第二步是Oracle读写，然后MySQL读，再到后面的一步一步的走，都有不同的策略，这时候，当这五步完成了之后，整个数据就迁移完了，最开始的第一个是最大的表，我们才迁移拆分，花了漫长的将近两年时间，有一些原因是因为业务资源的配合问题，还有一块我们是在摸着石头过河，我们需要吃到一些亏，然后我们要去改进，吃到一些亏我们要去改进。但是到现在拆分基本上都是在两三个月就能搞定。我们没有像一些那种新兴公司，他们做数据迁移就是直接通知用户，我停一天，或者我停几个小时，然后我把数据迁过去，你可以继续登陆上来。基本上我们是不允许这么干的，所以我们通常来讲，要么就是晚上，很短的时间点，我们把数据做一次迁移。另外一块，我们要保证应用基本上不会受到影响，也就是说他可能需要配合我们做一些Restart，但是他的相关的一些操作，尽量不会影响到我们的网站用户，大致就是这么多。

6. 针对分库分表的情况有没有使用一些框架或者工具来为开发和部署提供便利？
        分库分表都是在Cobar产品里面的，Cobar分为两类，分别是Cobar Client和Cobar Server，根据业务的需要进行选择，Cobar Server是一组独立的（Stand Alone）的Server集群，Cobar Client就是第三方的Java包，他就直接嵌入到应用上面去。然后他的拆分规则都是直接写到应用的配置文件里面的。这是我们自主开发的，没有用到外面的一些开源的工具，包括我们的SQL Parser，既然要做数据拆分，必然要解析SQL，SQL，我们之前也是自己写的。最近新的版本已经改用纯手写的，我们计划是提升大概四到六倍甚至十倍的性能，说到这点，我们的Cobar Client还是我们的SQL Parser，今年都有计划把它开源出去，相当于是说我们吃了很多我们要回馈一些出来。还有一些工具，就是我们有一组，不管是测试环境也好，还是线上的预发布环境也好，都有一组服务器提供给业务去负责查询一些业务数据，或者说查询测试环境的一些数据，去检查它的路由规则是不是正确，大致就是这些东西。

7. 我们下面来谈一谈关于后台海量数据的处理上的一些问题，对于后台海量数据的处理，阿里巴巴的系统是如何设计，有没有使用到类似Hadoop这样的技术？ 
        后台系统，目前后台系统通常B2B是有专门的部门叫数据仓库，就是DW部门的，他们会把我们的数据都拉过去，然后在那边进行一些分析。目前来讲，其实五花八门用的很多，比如说Oracle Rac，比如说Greenplum，当然也会用到我们的Cobar，还会用到前面提到的Erosa。其实之前来讲，首先后台基本上是一些离线数据，但是近几年，特别是从09年开始，我们对于后台的一些报表分析这一块，对于数据的时时性要求也越来越高。从去年我们时时数据中心上了Erosa以后，我们数据时效性，从一天已经缩短到了五分钟，甚至会更快。另外一方面，Hadoop应用在B2B相对而言比较少的，因为我们更多的是采用了Greenplum这种方式来做，就是做一些BI分析也好，还是报表分析也好，复杂SQL都是通过Greenplum来做的。但是，随着我们的DW业务也在增长，所以他有一些时时性的查询需求，目前我们Cobar也会提供，他们也搭建了一套Cobar集群，来提供这样的在线数据服务，其实相当于现在DW我们已经搭建了一套相当于是分布式数据库的原形，只是我们是东品西凑的把它拼起来的，但是效果不错，但是，总感觉不是很爽。所以接下来我们要做的，就是能够搭建一套适用于网站OLTP，也适用于DWOLAP的这样的一套或者是说你可以认为两个子领域的平台，这样的话，就能够做到技术可控，无论是数据访问也好，还是整体性能也好，都能够被满足，至少不会比现有的差，大致情况就这样。

8. 如果说将来有一天像阿里巴巴也要对外开放自己的数据，就好像现在淘宝一样，他也有自己的淘宝开放平台。那在您看来，会对系统带来什么样的挑战，应该如何应对？ 
        其实我们已经走得很慢了，另外，B2B Open平台目前已经在做了，我们现在的技术储备相对而言都已经建立起来了。其实更多的是一些商务上面的，或者是说我们对外的一些开发社区也好，还是说我们的应用一旦上来之后，包括流量监控，一些API的设计，这块东西，其实我们比淘宝也好，这块我们是走的相对慢的。但是我们已经从淘宝借鉴了非常多的经验。从技术储备上来讲，我们的技术底层，包括服务平台，包括Open平台，已经有一个叫做Ocean的产品，就的专门做Open Platform。这一块，技术已经搭建起来了，我们现在也在摸索，在尝试着在几个业务方面，开放一些业务数据出去，然后提供给外部调用。整个这一块东西，因为实际上，我这块负责的不是特别多，但是我大致对整个技术部的技术领域大致都了解一些，所以基本的情况就是这样的。但是更细节，可能需要等我们的Open平台搭建出来了之后，整个开发社区也就会出来，大家也可以关注一下那方面的一些东西。