海量存储计算

技术领域—海量存储计算

 

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），但通常只能单台服务器节点上进行（或者是在单组存储上水平扩展）。ScaleUp的方案操作简单,但是规模有限,代价越来越大。即便抛开Scale Up的价格和规模问题，对可伸缩性的需求，可能会变化得非常迅速和庞大。如果你的系统负载一夜之间翻倍，你能在多少时间内完成硬件升级？这一特点使得RDBMS在大型应用场景被大幅限制，唯一的可选方案是Scale Out,通过增加多个逻辑单元的资源,并使它们如同一个集中的资源那样提供服务来实现系统的扩展性。Sharding是一种scale out的扩展方法，但目前还没有非常成功的Sharding框架，关系数据库的复杂性开始影响Scale Out所能达到的潜在的扩展规模。当试图扩展到成百上千个节点（而不是几个）的时候将导致系统的复杂性不堪重负。

如同google倡导的那样，The Datacenter as a Computer。对于一个从来没有见过PB的数据量，上千台机器的新人工程师，系统的扩展性要求能让他像在单机上一样开发。在这种情况下，基于分布式、具有扩展性的键值存储处理模式逐渐出现，为此甚至会而牺牲掉关系数据库所带来的其他好处。使用大量且相对廉价的机器作为存储与计算结点以解决海量数据环境下的昂贵的硬件成本问题；采用键/值对(key/value pair的泛型结构)存储，系统提供基本get(key),put(key,value),delete(key)等数据访问接口；所有的数据都被看做是键/值对，这使得整个系统模型非常简单，大多数系统采用“一致性哈希”（ConsistentHashing）来实现数据（键/值对）的群集分布、快速定位查找以及动态扩展时减少需要重新分布的虚拟节点的数目。数据在结点上存在分割与冗余，保证高可用性及性能；同时牺牲部分的数据一致性要求实现数据的高可用性和分区容错性。根据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的namenode的单故障点目前还没有一个太好的解决方案）。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;WritesAverage : 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条件的筛选，需要在每台机器上都执行一遍，然后再对各个结果集进行一个合并。GROUPBY也一样，先在每台机器上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在mapreduce上改善的重点是在混合压力的情况下，保证工作工作负载的健壮性，构造新的调度容量程序，通过安全围栏（safety rails）来保证资源使用限制。

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

 

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

Ø  随着对外提供数据服务的增加，数据中心将会成为整个企业服务流程中的一个环节，对数据分析的结果需要直接的对外提供服务。这要求数据中心的系统平台能够对于广告信息投放，用户兴趣预测，推荐引擎这样的业务都能够有更快的刷新计算频率（1分钟刷新），计算完成的结果能近乎实时的被前台应用服务所直接访问、应用；数据中心提供的数据服务要求是基于事件触发（EventDriving 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可用性级别；任意硬件设备导致的宕机是完全不可接受