技术领域―海量存储计算

 技术领域—海量存储计算

 

PB时代的来临

Petabyte，2的50次方个字节。这个对很多人还是很陌生的计量单位，已经变得越来越普遍和触手可及。2004年8月，GOOGLE日常任务输入的数据已经达到了3PB ；2005年Mark Hurd从Teradata来到HP出任CEO，开始建设基于Neo View的8PB的HP EDW。2006年，YAHOO构建了世界上第一个基于ORACLE RAC的PB级别数据中心。2007年9月，GOOGLE的日常任务的输入数量膨胀到403个PB，而输出文件的尺寸也达到了14PB。2008年6月，wired杂志刊登标题为The Petabyte Age的文章，不仅是互联网行业，越来越多的传统行业公司的数据中心也开始达到PB的数据量级。时至今日，最近看到的一个新闻是一家名为Zynga的社会游戏公司在2010年的 Oracle Open World 上宣布，他们每天的数据净增量达到了1个PB，每个礼拜需要新增1000台服务器存储这些数据。

再来看看我们自己公司内部的情况，基于hadoop的云梯一群集已经达到了1400台服务器的规模，淘宝数据仓库的数据量已经达到了1PB（实际存储3PB）；B2B的数据仓库的数据量也已经达到了320TB，预计2011年底必然会达到1PB。越来越多的用户和业务数据被记录在案，10亿条记录，只能存放B2B中文站2天的页面曝光访问(CTR)记录。在这样一个数据不断膨胀的时代中，数据已经如洪水般汹涌泛滥。数据查找和调用困难，一些用户提出申请之后往往要等到第二天才能得知结果，直接影响到了用户满意度的提升和新业务的布局。在技术上，我们需要一个怎样的技术基础架构，才能够满足数据量的不断膨胀下的计算和存储需求。而当我们解决了最基础的数据量和计算能力这个温饱问题后，开始把目光移向数据服务、数据价值的时候，我们又需要怎样的技术基础架构，能够将如此海量的数据提供对外的服务，将我们对数据的认识直接转换为数据的产品并为我们的最终客户带来真正的价值？

 

THE NOSQL MOVEMENT

在谈论我们的技术基础架构前，我还想先花点时间谈谈最近非常热的NOSQL。对于大多数开发人员而言，NOSQL更多时候意味着Say NO to SQL，或者Non-Schematic。传统的关系数据库模型和应用代码对象模型通常是以不同方式建立起来的，这导致开发人员需要将代码映射到关系模型去克服这种不兼容性。这个过程被称为对象/关系映射。而基于K/V的方式天生是基于对象的，相比基于关系模型和Schema的RDBMS更为简洁（对象/关系 VS 序列化/反序列化）；底层代码中的对象类的映射关系比对象/关系映射要直接得多。这种简洁的开发模式对于很多相对明确简单的业务场景，很大程度上提高了开发人员的效率，显著减少了开发时间。

对于很多系统架构师而言，在数据量如此膨胀的今天，一个必须要考虑的特性是系统的可伸缩性（Scalability），这个特性正变的越来越重要，以至于在重要性程度方面已经开始凌驾，甚至侵蚀其他系统特性。RDBMS经过20多年的历史，数据一体化管理和分析已经发展的非常成熟了。RDBMS为数据库用户提供了简单、健壮、灵活以及兼容性的组合，但它在其中每个领域里的性能，不一定就优于其他追求某一项好处的独立替代方案[1]。在系统的可伸缩性上，RDBMS传统的方案是向上扩展（Scale Up），但通常只能单台服务器节点上进行（或者是在单组存储上水平扩展）。Scale Up的方案操作简单,但是规模有限,代价越来越大。即便抛开Scale Up的价格和规模问题，对可伸缩性的需求，可能会变化得非常迅速和庞大。如果你的系统负载一夜之间翻倍，你能在多少时间内完成硬件升级？这一特点使得RDBMS在大型应用场景被大幅限制，唯一的可选方案是Scale Out,通过增加多个逻辑单元的资源,并使它们如同一个集中的资源那样提供服务来实现系统的扩展性。Sharding是一种scale out的扩展方法，但目前还没有非常成功的Sharding框架，关系数据库的复杂性开始影响Scale Out所能达到的潜在的扩展规模。当试图扩展到成百上千个节点（而不是几个）的时候将导致系统的复杂性不堪重负。

如同google倡导的那样，The Data center as a Computer。对于一个从来没有见过PB的数据量，上千台机器的新人工程师，系统的扩展性要求能让他像在单机上一样开发。在这种情况下，基于分布式、具有扩展性的键值存储处理模式逐渐出现，为此甚至会而牺牲掉关系数据库所带来的其他好处。使用大量且相对廉价的机器作为存储与计算结点以解决海量数据环境下的昂贵的硬件成本问题；采用键/值对(key/value pair的泛型结构)存储，系统提供基本get(key),put(key, value),delete(key)等数据访问接口；所有的数据都被看做是键/值对，这使得整个系统模型非常简单，大多数系统采用“一致性哈希”（Consistent Hashing）来实现数据（键/值对）的群集分布、快速定位查找以及动态扩展时减少需要重新分布的虚拟节点的数目。数据在结点上存在分割与冗余，保证高可用性及性能；同时牺牲部分的数据一致性要求实现数据的高可用性和分区容错性。根据CAP theorem，数据的一致性、高可用性和数据分布三个方面是相互制约的，不可能同时达到最好。

 

万能的钥匙？

键/值对是面向于对象的，所有该对象的数据都能随时被被存储进该项目中。这个模型允许一个单一的项目包含完所有相关数据，以此消除对多表的数据连接的需求来扩充能满足的业务场景。而在关系数据库中，数据需要被联接到一起，以便能重组为相关属性。对于数据的整合，这样一个稀疏存储(sparse storage)的数据模型是相当合适的，我们可以把来自不同业务系统的数据，根据统一个对象实体的KEY值放置入同一个数据域中。比如Member的信息，我们可以把来自网站的，CRM的，P4P的不同的源系统的Member信息按照同一个Key值整合到同一个对象实体中，利用Non-Schematic的特性实现用户属性的任意增删，从而构造一张超级的大宽表，整合了该用户的所有属性。

虽然在关系数据库中的需求在键/值数据库已大为减少，但是有些东西（关系联接）还是不可避免。那些关系一般存在于核心实体之间。比如说，用户的产品（Product/Offer）、订单（Order）、反馈（Feedback）和用户信息表(Member)之间的关系。一个用户会拥有多个产品，订单，反馈。在描述一个用户所拥有的产品，订单和反馈的时候，是没有无法将所有这些产品，订单，反馈的属性信息都写入到用户的属性表中（虽然在技术上可以用多个嵌套表或者Super Column Family来实现），在这个时候，两个实体对象之间的Join不可避免。

当我们在一个键/值对的平台上积累汇总并整合来自各个业务系统的用户数据，而且通过键/值对的方式，你已经可以对外提供基于某个KEY（比如某个用户）的海量并发访问，同时获得极强的系统可伸缩性。现在你想为客户创造新价值，或者还想利用这些数据产生新的收入。你就会发现自己被严重限制了，甚至连直接的分析型查询都很困难。在键/值对存储的平台上，类似追踪（用户的）使用模式、基于用户历史提供建议等事情，即便不是不可能也是非常困难的。当需要进行数据的范围查找，多个搜索条件的合并这些情况下，这些应用对于RDBMS来说并不是太大的问题的问题，但是因为NoSQL DB“分布式框架”本身的特性，使得键/值对平台中并不能很好支持范围检索（包括非等值比较），集合和针对集合的多个布尔表达式（Union/And/Or…）等等操作。虽然有一些技术手段(比如分布式二级B树索引，前置哈希索引，全文倒排索引)可以部分解决这些查询问题，你会发现必须在系统中引入了越来越多复杂的机制来实现这些功能，实现的成本是巨大的，并导致整个系统的复杂度因此大大增加。结果，你将不得不从键/值数据库中分离出来的，建立一个独立的分析型数据库，以便执行那样的分析。你该在哪里才能做这样的事情？又该如何去做？归根结底，虽然规模和可伸缩性是一项重要考虑因素，但不要把它排在使用数据，将数据转换成为资产的能力的前面。如果你的系统中沉淀的数据无法给用户带来真正的价值，这世上的一切伸缩性都将一无是处[1]。

 

接下来就公司目前使用的几种不同类型的系统谈谈个人看法：

基于键/值的分布式存储

分布式键/值存储目前在B2B使用的比较广泛的Cassandra，包括国际站，CRM,DW目前都在使用。Cassandra它在设计上整合了Google Big table和Amazon的 Dynamo优点的系统，在系统的设计上有很多的可取之处。一方面继承了Dynamo在 集群方面的技术，另一方面又借鉴了Bigtable的 数据模型，这使得Cassandra区别于Dynamo单纯的key/value结构，具有更丰富的数据表现形式。Cassandra系统架构中一个闪亮的发光点是全对称设计，没有master节点的单点故障（相对而言，hadoop的hdfs的name node的单故障点目前还没有一个太好的解决方案）。Cassandra采用Gossip 协议主要用来管理集群会员信息，通讯效率非常高,只需要Log(N)回合就可以将状态传递给集群的N个节点，每隔T秒,每个节点都会自增自己的Heartbeat信息并通过Gossip传递给其他节点。

另一个显著的优点是，虽然Cassandra被设计为一个AP的系统，但是Cassandra允许你根据实际的需要来满足不同的系统特性。如果系统要求必须100%的读取到之前写入的内容，可以将Consistency Level设置为ALL要求所有节点都有数据的一致的副本，这时候系统不具有对任何节点失效和分区容错性。而如果为了获取最佳的性能，将Consistency Level 设置为ONE的情况下，从任意一个保存有这个副本的节点获取数据就可以（此时系统拥有了非常高的可用性和分区容错性）。而Consistency Level 设置为QUORUM，则意味着大部分存放该数据的节点上的副本是一致的，这是一个折衷的设计，系统提供了合理的节点失效与网络分裂的耐受性的同时也提供了很高的一致性。C,A,P在Cassandra中可以按需设置。

虽然Cassandra拥有了如此多的优点，它的缺点同样也同样显著。因为其底层存储设计的特性，Cassandra 则更适合于实时事务处理和提供交互型数据，而不适合于数据仓库、大型数据的处理和分析，这点从开发人员的背景上也能看出端倪。对于cassandra的性能描述，江湖传言多有误会的地方，据Facebook的工程师Avinash Lakshman介绍，Cassandra仅用0.12毫秒就可以写入50GB的数据，比MySQL快了超过2500倍。这应该是个谬误。

找来Avinash Lakshman的PPT对照：

MySQL > 50 GB Data ;Writes Average : ~300 ms;Reads Average : ~350 ms;

Cassandra > 50 GB Data;Writes Average : 0.12 ms;Reads Average : 15 ms;   

这里的0.12毫秒的写入速度应该是50GB的数据库尺寸下单个KV的写入速度，而不是系统写完50GB的时间。如果真要在0.12毫秒内写完50GB，意味着这个系统每秒能写入50/0.12*1000G=416TB。在实际的测试中，每次读取Cassandra至少要将本地数据节点内该KEY的所有数据都读取出来，MERGE最新的Timestamp的VALUE后返回结果，系统的读取性能表现的较为糟糕。

         8月13号发布的Cassandra 0.7 beta1版本，有很多很吸引人的特性，在读取的性能上，做了很大的改进。

包括：

Ø  开始重点使用RowCache，将其读取性能提升了8X。

Ø  支持secondary index，目前的实现机制就是用反转的方式，支持联合索引。

Ø  支持hadoop格式的输出，可以使得数据仓库更容易从Cassandra中抽取数据。

Ø  无索引的筛选过滤查询仍然不支持，需要再通过hadoop的M/R实现。

 

基于文档的分布式数据库

我们目前在使用Mongo DB在构建一个基于客户的实时分析的系统。Mongo DB的名字来自humongous这个单词的中间部分，从名字可见其野心所在就是海量数据的处理。跟CouchDB一样，Mongo是一个面向文档的JSON数据库，被设计为一个真正的对象数据库，而不是一个纯粹的键/值存储。Mongodb的内存映射文件机制以及schema-free的特点，让我们可以保持高速添加数据，不用担心数据库会出现堵塞。另外，MongoDB支持非常丰富的查询功能。几乎常用的SQL功能在它里面都有相应的方法来实现。而且支持索引，能够根据某一列进行WHERE条件快速筛选。MongoDB适合用来描述一个具有个性化特征的实体对象正，快速无阻塞的数据数据并行写入功能以及丰富的查询功能是MongoDB的亮点，对于实时分析、logging、全文搜索这样的场景是合适的选择。

MongoDB其中一个问题是占用空间过于虚高，原来1G的flatfile它需要4倍的磁盘空间存储。另一方面mongodb的sharding到现在为止仍不太成熟。Mongo DB没有像其他一些NOSQL产品那样选择一致性哈希来进行数据分片。它使用的是一种RANGE-BASED机制来进行数据的分片，在使用sharding功能的时候会让你指定一个COLUMN作为SHARD KEY。 我们尝试通过一致性哈希算法来自己做DB之间的切片，把数据人工分到不同的机器上。采用自己实现的分片机制，性能相对使用Mongo DB自带的sharding，性能更稳定，且更新速度一直保持在一个比较快的水平。 当然，自己来实现数据分片，很多功能都需要自己手工来实现。比如说where条件的筛选，需要在每台机器上都执行一遍，然后再对各个结果集进行一个合并。GROUP BY也一样，先在每台机器上GROUP BY一下，然后还要再来一次。而使用MongoDB自带的sharding功能的时候，你只需要发一条命令给它，它会自动进行处理，直接返回最终的结果给你。

 

基于分布式文件的数据库

      hadoop/Hbase/Hive/PIG是我们目前更为使用广泛的一项技术，在全球范围hadoop也受到越来越多的关注，Shelton在他的presentation中很自豪的说hadoop是海量数据处理的趋势和未来。2010年参加hadoop峰会达到了1000人（门票在开幕10天前就卖光了），包括James Gosling 也参加了这次峰会。Yahoo和facebook在hadoop上实现的应用令人印象极其深刻。Irving声称 “我们相信Hadoop已经为主流企业的应用做好了准备”。

      看看Yahoo们用hadoop都在做些什么，他们使用hadoop个性化他们的主页：[4]

Ø  实时服务系统使用Apache从数据库中读取从user到interest的映射

Ø  每隔5分钟，他们使用生产环境中的Hadoop集群基于最新数据重新排列内容，并每7分钟更新结果

Ø  每个星期，他们在Hadoop科研集群上重新计算他们关于类别的机器学习模式

Facebook透露了更多使用hadoop的技术细节，他们展示了Hive与Hbase和RCFile的集成。Facebook正在尝试将HBase用于数据仓库里对于维度属性的持续更新。他们将Hive集成到20个节点的HBase集群——从Hive向HBase载入6TB gzip压缩的数据块用了30个小时，在这种配置下可以达到30GB/每小时的增加载入速率。在HBase运行表扫描比执行原生的Hive查询要慢五倍（使用了RCFile，Hive中一种新的存储格式，将数据按列式存储。采用这种格式，平均减少了20%的存储需求，同时可以达到更好的性能）[3]

Facebook使用hadoop一个成功的经验是：95%的Facebook任务由Hive写成，通常可以在HIVE中可以用类SQL语言在十分钟内完成一个任务（Schroepfer特别给了一个hadoop job和HIVE job的对比页面）。Facebook提供一个称之为为HiPai的Web工具让业务分析师使用Hive，只需要简单的撰写查询语句，支持查询载入仓库的近20000个表。say NO to SQL？NOWAY!对于绝大多的数据的分析任务而言，SQL是一种非常简单、易懂、结构化且高效的语言，学习和使用成本都很低，能极大的降低使用者的门槛，将数据开放给更多的非技术的业务分析人员使用，从业务的角度理解并消费数据。对于数据分析人员而言，SQL是一个最简单犀利的武器，远没有到对SQL说NO的时候。

另一个重要的变化是：虽然在最开始被设计为批量任务处理（包括HDFS也是一个只允许一次写入的文件系统），Hadoop一直被看做不适合于实时的数据分析，数据的实时更新一直是困扰hadoop的一个问题。从06年的研究到07年的科学影响分析再到08年日常生产任务，当前yahoo已经做到了每个页面点击背后都有hadoop。facebook通过将Hbase，Hive等各个模块之间的协作整合，一步一步从每天的批处理过渡到实时的查询——预见将会出现最快查询在一分钟内就可以返回的系统，这必将为一系列新兴的应用开启大门。

必须看到，hadoop还不是一个完善的系统，包括这次峰会中Irving也提到的，当hadoop的集群扩张到一定程度的时候，资源的调度机制在大量不同优先级的任务之间的调度就会显的开始有些捉襟见肘（一般的认为2000节点是hadoop的一个门槛，yahoo已经构建了一个4000节点的群集）。去年yahoo在map reduce上改善的重点是在混合压力的情况下，保证工作工作负载的健壮性，构造新的调度容量程序，通过安全围栏（safety rails）来保证资源使用限制。

另一个问题还是老调重弹的非全对称式的设计。为了减轻HDFS的Name Node的单点故障问题他们都将数据复制到多个群集，分布式文件系统的中断可以使用备份文件系统来弥补和解决name node出现的故障。同时，为了保证应用的之间的解耦，无论是yahoo还是facebook，都将他们的hadoop群集根据应用分解成多个群集。

 

到这里已经��嗦了大约6000字谈论了很多的背景和现状，外面世界和公司内部的情况。数据中心将成为整个企业数据化运营中一个环节，如yahoo号称的那样，data center behind every click；数据中心为各个业务系统以及企业的外部用户提供分析整合后的数据，通过对数据的整合和汇总计算，发现数据的规律与价值并通过数据服务提供给最终用户，可以预见数据中心会越来越多的面临来自以下两个方面的需求和挑战：

Ø  随着对外提供数据服务的增加，数据中心将会成为整个企业服务流程中的一个环节，对数据分析的结果需要直接的对外提供服务。这要求数据中心的系统平台能够对于广告信息投放，用户兴趣预测，推荐引擎这样的业务都能够有更快的刷新计算频率（1分钟刷新），计算完成的结果能近乎实时的被前台应用服务所直接访问、应用；数据中心提供的数据服务要求是基于事件触发（Event Driving Architecture）更为灵活主动的架构，并直接面对网站用户，要求7*24的系统可用性以及每日亿万级别PV的并发访问需求；

Ø  提供数据服务的客户越来越多，常规的数据报表的开发需要更为简单直观，对报表组件工具需要组件化，做客户化定制封装；客户消费数据的能力也越来越强，我们需要一个更为开放的平台，让更多用户随时可以面对数据，随时按照自己的想法来获取所希望的数据；

 

现在，让我们放松一下，连接上Pasiv Device跟随Dream Architect，开始从现实系统进入未来的梦境的旅程，一起来构造属于阿里巴巴未来所需要计算存储平台。

 

Overall System Architecture

       系统的总体架构将满足以下特性：

Ø  Distributed & Parallel

如前文所述，系统的可伸缩性是我们的系统架构中必须要考虑的一个重要因素，解决Scale Out的必由之路是走分布式计算的道路。将系统的数据、服务请求、负载压力都能均摊到多个处理节点中。根据业务的需要，可以通过垂直分区（比如将业务功能拆分不同的功能模块，并将这些不同的功能模块交由不同的处理单元实现）和水平分区（比如将一组数据元素切分为许多个实例，并这个数据元素的不同数据实例交由不同的处理单元完成）来实现功能的分布式。

分布式带来的另一个好处并行化，将一个任务拆解为许多个逻辑单元，将这许多个逻辑单元交由多个处理单元并行的处理从而大幅提升批处理任务的性能。

Ø  Transparent & Elasticity

后台复杂的分布式逻辑对应用和开发人员隐藏，能让开发人员开发代码像在单机上一样开发。

数据群集存储服务，应用对数据访问透明，无需关心存储的位置；遵循于CAP theorem的跨多节点数据分布模型而设计，支持数据的水平伸缩。这意味着对于多数据中心和动态供应（在生产集群中透明地加入/删除节点）的必要支持，也即弹性[2]。

Ø  High Availability &  Fault Tolerance

Data Center发展到今天，已经不再是一个单纯的后台系统。随着应用的深入和实时化的推进，Data Center越来越前台化，需要提供7*24可用性级别；任意硬件设备导致的宕机是完全不可接受的；在系统的设计中，不应当把鸡蛋都放在一个篮子中，需要尽量避免应用的中心点，否则这个中心点很容易就会变成故障的单点而损害整个系统的可用性。比如Master节点的存在（facebook和yahoo为了避免HDFS namenode的单点，不得不构建了两组群集互为备份）或者一个全局的配置文件或者一个基于关系型数据库的元数据管理中心系统（比如facebook最近的这次因为一个错误的配置文件变更导致中心数据库死锁最终导致整个服务不可用）。像cassandra这样的全对称（Completely Symmetric）设计是一种优雅的设计，这在架构上杜绝了任意一个单点不会对系统造成致命的影响。

当我们的服务器群集扩展到几千台几万台的时候，你不能要求整个系统的任意硬件或者软件是不会发生损坏的，这就要求在系统架构上设计上保证当系统中确实发生故障的时候（软件的或者硬件的），系统应当能够主动的对这些故障进行监控，并通过启用备用节点将故障进行恢复，所有的这一切都应当是自动完成的。

Ø  Dynamic Resource pool management supporting mixed workloads

系统之间的消息传递采用事件驱动的架构。每个服务所能占用的资源和任务的优先级是不同的，对于不同等级的服务按照配额和优先级保证资源的配置管理，同时总是保证在用户的配额内服务总是能成功，任务调度程序需要更加的智能与快速，能在尽可能短的时间内分配给任务必要的资源并快速启动任务；

Ø  NUMU Architecture

根据阿姆达尔定律（Amdahl’s Law）并行处理器环境中的速度受制于程序串行的部分。对于传统 SMP 来说，CPU 增多未必系统性能就好，因为共享系统总线的限制了 CPU 数量，CPU 越多内部通信量越大共享总线越容易达到瓶颈。而 NUMA 架构通过给每个核提供单独的本地内存，减少多个CPU对于内存以及共享总线的竞争。在设计上，将每颗CPU和内存都划分为独立的逻辑单元，让系统的变得简洁并进而提高系统的可扩展性。

 

Data Tier

在数据层，提供结构化和半结构化的数据存储服务；对于不同的访问模式（汇总分析查询、K/V方式的主键访问）允许制定不同的存储策略以保证系统性能（按照需要读取的列全列扫描或者通过索引的快速扫描）使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模，而不是使用固定的关系模式元组来构建数据模型。

Ø  Mixed Storage Model

NSM（N-ary Storage Model），即基于行的存储模型。随着硬件的发展，NSM对于缓存的利用率较低。NSM在每个磁盘页面中连续的存储记录，使相对页面的偏移记录每条记录的开始。

DSM（Decomposition Storage Model）。列存储模型并不是一个新鲜的概念，在1985年就已经提出，2005年左右随着数据分析应用的广泛开展获得新生。对数据的使用，特别是分析的需求，常常只使用一条记录的一部分数据。为了减少IO的消耗，提出了“分解存储模型”。DSM将关系垂直分为n个子关系，属性仅当需要时才加以存取访问。对于涉及多个属性的查询来说需要额外的开销用于连接子关系。

PAX（Partition Attribute Across）。PAX是记录在页面中的混合布局方式，结合了NSM和DSM的优点，避免了对主存不需要的访问。PAX首先将尽可能多的关系记录采用NSM方式加以存储。在每个页面内，使用按属性和minipage进行类似于DSM的存储。在顺序扫描时，PAX充分利用了缓存的资源。同时，所有的记录都位于相同的页面。对于记录的重构操作，仅仅在minipage之间进行，并不涉及跨页的操作。相对于DSM来说，对于多属性的查询来说PAX优于DSM，因为DSM需要更多的跨页重构时间。

混合存储模型，我们可以将所有的数据都理解为由Key/Value/Description（column name）构成的三元组存储模型。KV模型允许你按照你想要的模式来组织数据的存储，如果应用总是按照行来访问的（比如总是访问某个用户的大部分数据），那么就可以把数据按照同一个Key组织在一起（实际上就是NSM），而如果某个应用总是分析汇总查询，可以按照Description（column name）将数据组织在一起（DSM或者PAX的实现）。

Ø  Column Exchange

基于列存储的对同一对象实体的全量属性快速Merge实现。基本思想是通过DSM模型存储数据，对不同属性通过不同的数据服务进行数据的全量刷新，极端情况，可以考虑对同一个实体(数据粒度相同)的每个属性建立一个数据全量刷新服务。传统的关系模型中，如果有A,B,C,D表需要整合成一个对象，总是需要将A和B得到A’,A’和C进行JOIN得到A’’,再将A’’和D进行JOIN，得到最终的结果宽表。CE可以在最大程度上避免构建宽表过程中，后置属性的更新任务（比如刷新来自D表的任务）对前置任务（比如刷新来自C表的任务）的依赖，只需要建立一个独立的任务来刷新来自D表的属性，并得到一个D’,通过Column Exchange（可以把他想象成分区表的分区交换），将D‘快速的Merge进目标宽表中，而无需依赖刷新其他属性的任务。在这个过程中，目标宽表始终是处于可用状态，无需等待最后一个刷新D的任务完成后才能对外提供服务。

Ø  Parallel update with Non-Schematic

陶勇说这是个有意思的需求，对于跨表merge/join是一个有力补充；也是一个非常具有技术挑战和难度的问题。是dandelion data model在对于实时变更的维度数据实现方式，大致的思想是将应用属性与对象实体之间进行解耦， 在Non-Schematic的数据模型下，允许我们通过不同的服务对同一个对象实体（Key）不同的属性进行并行更新，每个服务只关注于自己需要更新的属性信息，不同的服务之间即使更新的同一个对象实体，相互之间也无需通信，没有关联。当实体的需要新增某个属性的时候，只需要为该属性新增一个服务，无需调整其他的服务。同样的，当某个属性不再需要的时候，只需要停用该属性的服务，对其他属性同样不会产生影响。在技术上，只需要通过对Key的Set方法进行属性更新，对并行写入的性能要求很高，要求不同服务对同一Key值的更新是完全无锁，不阻塞的。

Ø  Pluggable Storage Engine

存储引擎应当是可插拔的，在大多数情况下人们发现基于组合方案的解决方案是最佳的选择。既能通过内存数据存储支持高性能，又能在写入足够多的数据后存储到磁盘来保证持续性。

Ø  Snapshot

通过对实时数据区的snapshot功能，获得一个整合后的数据主题的快照；基于该快照，进行数据的深度整合加工、分析，该区域为固定报表和数据挖掘、数据分析探查的数据输入；接口数据区的数据是整合的，记录历史的；

Ø  Compress

寻求不同类型数据的最佳压缩模式和算法。虽然当前SATA硬盘已经降到一个较低的价格，在海量的数据环境下，压缩还是可以取得非常高的效益。Yahoo报道说在他们hadoop群机上，采用压缩降低了20%的存储。淘宝采用了极限存储后，每日净增数据量从25TB降低到12TB。在我们实际测试中，通过对数据的预排序和列存储后，在未改变压缩算法的前提下，对OFFER表的压缩率从1:5提升到1:20。对数据采用压缩可以取得另两个收益是：降低了数据同步到不同数据中心的数据带宽，同时降低了对磁盘IO吞吐率的需求，从而减轻了对磁盘的压力，这对保护磁盘，降低系统故障率都能有很高的贡献。

 

Service Tier

数据层的结构化或者半结构化的数据，允许根据特定的需求选择合适的编程语言对数据进行直接的访问，可以允许SQL,C，R，PERL,PYTHON等不同的编程语言在数据接口层之上直接开发，允许采用Map Reduce编程模式进行海量大规模数据处理编程；允许常驻的服务进程访问数据并直接对外提供海量并发的查询访问；

 

Interface Tier

为了消除底层多样化的数据存储带来的耦合性因素，在上层进行访问接口的抽象，它能够很好的支持多样化的数据存储需求，并且隔离底层变化带来的影响。

 

长期来看，我们尝试构建支持混合负载与混合应用场景的分布式计算存储平台，满足上述的系统特性。在获得系统的可伸缩能力的同时，通过各种不同的可插拔组件和数据模型满足各种不同的业务需求。

短期内（至2011年3月），我们关注以下技术实现：

Ø  在前台查询环境中，实现K/V查询时数据的路由自动化；

Ø  在前台查询环境中，多节点的多表的数据汇总分析查询，联合查询；

Ø  在前台查询环境引入列存储引擎，并在此基础之上，实现列交换；

Ø  在前台查询环境，支持Schema-free的并发数据更新；

Ø  在后台计算平台引入列存储引擎，并在此基础之上，实现列交换；

 

看到此行的同学们，相信我们拥有共同的梦想，热切的希望大家能一起参与和投入海量存储计算平台的技术领域！