Dynamo VS Bigtable

存储云结构比较——Dynamo VS Bigtable

 

 

比较典型的存储云基础系统有Amazon 公司的Dynamo 系统与Google 公司的Bigtable 系统，这两种系统不但已经开始是商用（参见S3 服务和 Google App Engine 服务），而且都公开了比较详细的实现论文（尤其dynamo 系统论文格外详尽——可见Amazon 公 司的无私和自信）。它们各自实现架构迥异，存储特性不一，但都结构优美，技术上各有可称道的地方，可谓各有千秋，却又殊途同归。下面我们将针对它们两者存 储数据的要求、体系架构、扩容、负载均衡、容错、数据存取及查询等我觉得重要的方面进行一些点到为止分析比较，以辨明良莠。

 

数据结构化问题

 

首先要提到的是两者存储数据属性上的区别，虽然两者都是以key/value 形式进行存储，但Dynamo 偏向存储原数据，因为其所存储的数据是非结构化数据，对value 的解析完全是用户程序的事情，Dynamo 系统不识别任何结构数据，都统一按照binary 数据对待；而Bigtable 存储的是结构化或半结构化数据（web 数据特点就是介于结构化和非结构化之间，因此称为半结构化数据。我这里不展开说它了，不了解半结构化数据的赶紧看http://www.click2earth.com/post/105.html ），其value 是有结构的数据——就如关系数据库中的列一般，因而可支持一定程度的Query( 比如可按单列进行）。这点上看Bigtable 更接近数据库（接近而不是等价！至于和关系数据库的具体区别可去google 一下，网上论述可不少！）；另外, Bigtable 所存储的数据都是以字符串格式实现，所以对主建或者列（以及其自动加上的时间戳）排序都是以字符序进行，而dynamo 的键值并非以字符串存储，而是统一经过md5 算法转后成16 字节md5_key 存储的，因此对数据的访问必须知道key 才可进行，故而对扫表( 用游标）或者query 访问则无能为力。当然在dynamo 的基础上，配合一些方式我们实现query 也并不可能，一些具体方式我们后面慢慢探讨！

 

控制与存储架构比较

 

Dynamo 是采用DHT （分布哈希表，请参看http://www.click2earth.com/post/117.html ）作为基本存储架构和理念，这个架构最大特点是能让数据在环中“存储”均匀，各存储点相互能感知（因数据需要在环内转发，以及相互之间进行故障探测，因此需要节点之间的通讯），自我管理性强，因为它不需要Master 主控点控制，有点是无热点，无单点故障危险——插一句，目前新浪的memcachedb( 改造memcached ，增加了持续化能力）其实可认为是这种架构的最简单代表（数据进入系统后，使用DHT 算法均匀的发送到存储节点上，而最后存储引擎采用Berkelery DB ，将数据持续化到本地硬盘）。 Bigtable 的控制是采用传统的server farm 形式，使用一个主控服务器＋多个子表服务器构成。而数据存储形式是采用多维Map 的稀疏结构, 可看成是由多个列表组成，所谓稀疏是说每条记录并非要求有全列。其数据（包括索引，日志，记录数据）最终是存储在分布文件系统DFS 之上——数据被以DFS 所特有的文件形式分布存储在各各节点之上。相比DHT 的存储环自管理技术，它需要有master 主 控服务器来负责监控各客户存储节点（分配子表，失效检测，负载均衡等），另外索引文件的根也是集中存储，需要客户端首先读取（之后可以采用预读和缓存的技 术减少读取索引表的次数）。这种集中控制的做法有一个缺陷就是系统存在单点故障 —— 因此单点需要高可用性，如记录恢复日志或双机备份等——但好处是更人为可控，方便维护，且集中管理时数据同步易于方便——显然，更新集中存储的原数据（如 数据索引或节点路由等）相比DHT 环中各个节点存储的原数据（如membership ，即各点的路由关系）需要利用“闲谈机制”依次通知式地进行渐近更新要容易许多。

 

容错问题

 

Dynamo 和Bigtable 都不是实验室应付领导参观，或者是炫耀技术的Demo ，而是要实实在在进行商业运营的产品，因此首先要考虑的是机器成本问题！最节约的方式就是采用普通PC 服务器（目前市场价格大约2 ／3 千元就能买到存储1T 数据的机器——自然是没有显示器，声卡这些外设的）作为存储机器。但做过大数据处理的人都知道，IDE/STAT 硬盘的稳定性和寿命是无法和真正服务器中的SCSI 硬盘相媲美（除硬盘外的其余部件的稳定性和寿命也一样和服务器差距颇大），在压力下损坏那是家常便饭——据Google 说，1000 台机器的集群中，平均每天坏掉一台机器——因此设计之初就将硬件故障认为是常态的，也就是说容错成为设计优先考虑的问题了。鉴于上述原因，Dynamo 和Bigtable 的 数据都是冗余存放，也就是说一份数据会被复制成数份（副本数是可以根据数据要紧程度指定的），并被分散放在不同的机器上，以便发生机器宕机（偶然性宕机或 网路不通属于临时故障，而硬盘坏掉则是永久故障，永久故障需要进行故障恢复——从副本恢复数据）时还有可用副本可继续提供服务——通常存放三个副本就已经 可以高枕无忧了，因为要知道三个副本同期坏的可能性小到了1000*1000*1000 分之一。 Dynamo 的冗余副本读写策略比较有趣，它定义了：N,W,R 三个参数。其中N 代表系统中每条记录的副本数，W 代表每次记录成功写操作需要写入的副本数，R 代表每次记录读请求最少需要读取的副本数。只要W+R >N 就可以保证数据的一致性。因为W+R>N 时读写总会有交集——必定最少有W ＋R －N 个读请求会落到被写的副本上，所以必然会读到“最后”被更新的副本数据（至于谁 “最后”的判断需采用时间戳或者时钟向量等技术完成——有逻辑关系先后由时钟向量判断，否则简单的用时间戳先后判断. 详情去看dynamo 论文吧）。这种做法相比我们最朴素的想法——我们直观的想法一定认为如果系统要求记录冗余N 份，那么每次就写入N 份，而在读请求时读取任意一份可用记录即可——要更安全，也更灵活。说其更安全是指数据一致性更能被保证：比如说客户写入一条记录，该记录有三个副本在三个不同点上，但是其中一个点临时故障了，因此记录没有被写入／更新。那么在对该记录再读取时，如果取两点（R=2 ）则必然会读取到最少一个正确的值（临时故障点有可能在读是恢复，那么读出的值则不存在或者不是最新的；若临时故障点还未恢复，则读请求无法访问其上副本）。而使用我们传统方法可能读到发生临时故障的那点，此刻就有可能读出现错误记录（旧的或者不存在），因此可以看到加大W,R 可提高系统安全性；说其更灵活则是指可通过配置N,W,R 这几个参数以满足包括访问方式、速度和数据安全等迥异需求的各种场景：比如对于写多读少的操作，可将W 配低，R 配高；想法对于写少读多的操作，则可将W 配高，R 配低。 Bigtable 的容错问题论文中没有详细讲，我想它应该是将该任务交给其下的DFS 处理了：DFS 是在文件chunk （64M ）写入chunk 服务器时，将数据chunk 传播给最近的N-1 个chunk 服务器，从而确保了系统中每个chunk 存在多个副本，而这些chunk 的位置信息都会记录在master 服务器的文件原数据中。再访问文件时，会先获得原数据，再从可用的chunk 服务器中获取数据，因此一个chunk server 发生故障不影响数据完整性，照样能读。另外DFS 的故障的恢复等工作也是在master 服务器监控下将某个副本chunk 进行复制，以恢复故障机器上的数据副本。最后值得提一下的是，Dynamo 对于临时故障的处理方式是：找到一台可用机器，将数据暂时写到其上的临时表中，待临时故障恢复后，临时表中的数据会自动写回原目的地。这样做得目的是达到永远可写（那怕该云中只有一台机器可用，那么写请求的数据就不会丢失）。这个需求未见Bigtable 提到，但从其架构上看DFS 对写操作来说，应该也是能达到接近Dynamo 的永远可写需求的（master 会帮助选择一个可写的chunk server 作为写请求的接受者的，因此系统只要master 不可用，最少再有一台可用chunk server 机器就以满足。

 

扩容问题

 

对 于一个存储可视为无限大的存储系统来说，扩容需求（扩容需求除了存储容量不足外，存储节点并发处理能力不足，也会要求扩容）自然无法逃避，而且对于在线服 务系统扩容时期要尽量不停止服务或者尽可能短的停止服务，因此优美的扩容方案是存储云中最值得关注的要点之一。我们还是先来说说Dynamo 系统的扩容策略和实现。试想一下，将一个机器中的指定数据表扩容，首先需要将这个数据表劈开成两个表，然后再把其中一个转移到另外一台新机器上去。而这里的劈表动作说起简单，作起来则颇为费力，因为无论数据表是按照键值区间有序组织（如DHT 环方式), 或键值本身有序组织（如Bigtable 方式) ，都不可避免的需要扫描整个数据表（特耗资源的操作，绝对会影响其他服务的）才能从中挑选出一部分有序数据移到新表中，从而保证劈开后的两个表仍然维持有序结构。为了避免笨拙的扫表工作，Dynamo 取巧了，它会将md5 key 所围成的环行区间，尽量划分的粒度细一些，也就是多分成一些较小的区间／段（一个段对应存在硬盘上的一个数据表），但是要求一个物理机器不只存储一个段，而是存储连续区间的一组段表，这样以来在扩容时就能将劈大表的操作给回避了。比如将环分成1024 段（存储数据上规模时，实际部署时段表要分的更细致得多），然后又规定每个存储点维护64 个段表，那么全部数据起先可部署在 16 个机器的存储环上。如果发现某个机器存储不下64 个段表时（或者承受不了当前的并发请求量时），则将其中部分段表转移到新扩容的机器上去即可，比如从原机器上转移32 个段表拷贝到新机器即可完成扩容——这种小表迁移避免了对大表拆分时的扫表、劈表动作。当然你会说这种扩容有限制，只能扩容6 次。没错, 因此在实际存储环之初, 是需要估计数据总量, 扩容次数等问题的, 但这绝对值得。Dynamo 除了段表思想值得学习外，还提出了扩容期间不停服务这种要求很是可爱。我们也尝试过这种高可用性扩容设计，其主要任务是要理清楚，从而细致处理扩容期间( 包括数据扩容和路由更新) 的访问请求的状态机。另外要说的是扩容时为了不影响正常请求访问, 都将扩容例程安排在低优先级进行, 让它在正常读写请求压力小时再偷偷进行！对于Bigtable 扩容问题Google 本身的论文描述有些暧昧，但却可在另一个类Bigtable 系统——hypertable ——那里看到比较清晰的说法。Hypertable 是Bigtable 的开源C++ 实现。由于Hypertable 中记录存储是被集合成固定大小的tablet （默认的最大值是每个200M ）存在DFS 上——而DFS 本身具有可扩容性（允许在线添加新机器到server farm 中）—— 因此Hypertable 存储总空间的扩容不存任何问题。其要作的只是当子表（Range 段) 过大时，需要将其从中间key 劈开成两个新表，把包含后半段key 范围的新字表迁移到别的range server 上去。注意这种分子表的实现路数似乎仍然需要去扫描表，在这一点上我个人认为不如Dynamo 做的聪明、利索。关于hypertable 的表的管理值得大家去留心，但这里不多说了。( 请看hyptertable 站点：http://www.hypertable.org/documentation.html/ )

 

负载均衡问题

 

负载均衡（意义在于数据存储均衡和访问压力均衡）对于Dynamo 系统而言是天生的优势，因为它采用了DHT 方式将数据都均匀存储到各个点了，所以没有热点在（或者说要热，则环中所有的点一起热），各点的数据存储量和访问压力应该都是均衡的（这点由md5 算法特性决定）。 另外这里还要提一下Dynamo 系统中的Virtual Node 概念——VNODE 可看成一个资源容器（类似于虚拟机），存储作为一个服务运行于其中。引入VNODE 目的在于将资源管理粒度单元化。 比如一个VNODE 让你且只让你管理5G 硬盘，500M 内存等，那么你就只能使用这么多资源。这样有两个显而易见的好处：1 方便管理不同配置的异构机器，比如资源多的机器多部署一些VNODE , 而资源少的机器少不部署一些VNODE 。 2 对于扩容大有好处，因为DHT 环 中加入一个新节点，如果想保持数据均匀分布的特性，那么必须将全环的数据都要移动才有可能，这样无疑增加了网络震荡，因此最理想的方式是在环内每个点都进 行扩容，这样就只需要移动旁边节点的数据了。那么单增加一个或几个机器显然不能均匀分配环的其他存储点旁，因此需要将一台物理机器划分成众多个VNODE ，这样才有可能能将这些VNODE 比较均匀的散布在环内其他节点旁了。随着逐步添加机器，那么数据均匀性逐步提高，可见这是一种逐渐式的数据均衡过程。对于Bigtable 的负载均衡是也是基于传统上server farm ：依靠一个master 服务器监视子表 server 的负载情况，根据所有子表服务器的负载情况进行数据迁移的，比如将访问很热的列表迁移到压力轻的子表服务器上( 数据最终还是落在了chunk server —— DFS 上的存储服务点，从层级结构上来说处于子表服务器之下）。具体做法你可参见他们的论文，总的来说有没有太多创新。

 

数据存取和查询问题

 

Dynamo 和Bigtable 两种体系都支持key/value 形式的记录插入，而且也支持主建的随机查询。不过前面已经提到了如果需要按照列进行查询，或者需要range 的query 查询，则Dynamo 就无能为力了，只能使用Bigtable 架构（但要知道Bigtable 并没有关系数据那么强，对于query 的支持也仅仅是支持条件是单个列，不能以多列为目标进行复合条件查询，更别说join 查询等）。从这点上说bigtable 更接近数据库，而Dynamo 则是一个简单的存储系统。 amazon 在S3( 可能基于Dynamo) 之后，推出了支持query 的Simpledb 系统。 该系统和Bigtable 很类似，但似乎功能更强，它支持=, !=, <, > <=, >=, STARTS-WITH, AND, OR, NOT, INTERSECTION AND UNION 等复杂的query 操作。这真是个出色的产品，不幸的是amazon 并没有向对Dynamo 那样慷慨的公开发表其实现的论文，因此大家只能猜测其实现，有的说是在Erlang 上重写的，有的说在Dynamo 基础上开发的，有的说是抛开Dynamo 全新实现的, 目前说法众多，无从得知。这里我仅仅就我个人的认知，谈谈假如在Dynamo 上是如何实现Query 功能类似的功能。 首先能想到的是为Dynamo 增加schema ，也就是将value 划分成逻辑列，这样以来在存储时可以按列建立索引文件，那么就自然可以实现对列的 query 。索引文件内容可以是列值到主建集合的映射，其存储以文件形式存在于分布文件系统之上。当对列进行query 时，首先在索引文件中找到对应的主建集合，然后在以主建从Dynamo 中获得记录。不过这样作有一定限制： 1 分 布文件系统需要能支持并发修改文件能力（因为索引文件需要频繁改变），而大多数分布文件系统为了数据一致性和效率的考虑，都只能支持并发追加操作，因此要 想实时的完成数据更新的同时支持查询操作有难度——简单的方法是定期更新索引文件，那么副作用就是查询的结果不是最新的；2 只能对预先建立索引的单列进行排序（当然可以建立联合索引），并不能支持对任列，或者任意的复合条件完成query 查询——我是没想到什么好办法。 另外一个方法是使用关系数据库作Dynamo 的存储引擎——如果你看过Dynamo 的论文，可否记得它提到了实际的存储引擎可使用Berkelery DB 或者mysql 等 ——，那么在存储环中进行查询的操作可化整为零：将查询任务路由到各各存储节点上分别进行查询之后，再将结果收集起来，对于需要排序的请求则还要再集中进 行排序一次。这种做法把索引等等的工作都交由关系数据库去作，我们作的只是需要汇总结果。在这个思路上可以进一步结合数据分发Partition 策略：不再按照md5 key 那样在节点上均匀的存放数据，而是按照列作partition 篇分发数据，如地址属性中的Beijing,xi an 等不同地名的数据路由到指定不同节点上，那么在按地名进行查询时，则可以直接将请求下发到对应存储节点，这样避免了全环下发查询人物，能更有效的完成以列为条件的复杂查询。除此外，还可以对列进行区间排序partation, 如对年龄列，按照0 －10 岁一个区间，10 －20 一个区间，20 －30 一个区间，而每个区间存储在不同节点上，这种有序区间部署方法可支持按列排序查询要求。不过有得必有失，partition 存放的缺点是数据不够均匀，因此负载不平衡，所以需要能把partation 节点纵向扩容，比如把负责20 －30 区间的存储节点多搞几个以分担并发压力。

 

 

当前计算云的架构实现

 

存 储云的商业模式是出卖存储能力，而计算云的商业模式是出卖计算能力。存储云的基础技术是分布存储，而计算云的基础技术是分布计算——更准确说在是“并行计 算“。并行计算的作用是将大型的计算任务拆分，然后再派发到云中的节点进行分布式的并行计算，最终再将结果收集后统一整理（如排序、合并等）。 如果说云计算云是并行计算的升华的话，那么只在一个层面上有所进步 —— 计算资源虚拟化：计算云中的所有计算资源都被看成一个可分配和回收的计算资源池，用户可根据自己的实际需求购买相应的计算资源。 这种资源虚拟化得益于近日重新兴起的虚拟机技术，采用虚拟机实现资源的虚拟化，既可以避免了硬件异构的特性（无论什么样的硬件机器主要攒在一起，其计算资 源都可被量化到计算资源池中，并被动态分配），更可以实现资源的动态调整，因此能极大的节约了云中的计算资源（动态调整就是不需要重新启动系统就可调整资 源大小，这是虚拟化技术的最大用处之一）。这种虚拟化和我们在自己机器上安装的虚拟机所采用的虚拟化技术大同小异，其异处就在于我们个人用户的使用模式是 将一台物理机器的资源虚拟化成多份，以使得其能同时启动多个操作系统；而云中的虚拟化技术是将多个物理机器的资源虚拟化成一个大的资源池，让用户感觉是一 个巨大资源的机器——但是要知道只有任务在能并行计算的前提下，资源池虚拟化才有意义。比如用100 个386 机器组成的计算云可以处理1T 的日志数据，如果日志数据的处理可以被并行进行，那么可让每个386 机器都处理1 ／100T 的数据，最后将所有中间结果合并成最后结果。但是如果任务无法平行差分，再大的计算池也没用（云计算应用是有限的，目前最能用的上的是web 网站——数据量大，但处理相对简单）。 总而言之：计算云的架构可以看成是：并行计算＋ 资源虚拟化。

 

 

并行计算架构(Map/Reduce)

 

对于资源虚拟话的问题，这里不作讨论了，有机会我们专门起个话题进行深入探讨。这里主要说说云中的并行计算方式。并行计算是个老话题了，很多基于MPI 的并行计算软件处处可见。MPI 采用任务之间消息传递方式进行数据交换，其并行开发基本思路是将任务分割成可以独立完成的部分，再下发到各计算节点分别计算，计算后各节点将各自的结果汇总到主计算点进行最终汇总，各点之间的的交互由消息传递完成。对于并行计算面临的主要问题是： 1 算法是否可以划分成独立部分；2 获取计算数据以及中间结果存储代价很高，因为海量数据的读取会带来沉重的IO 压力——如在处理诸如page rank 等互联网应用上，很大程度上大量、频繁的读取分布存储的网页数据造成了任务计算速度的瓶颈。对于第一个算法问题，从计算架构上考虑勉为其难，关键在于分割算法。而对于第二个IO 压力问题，最好的解决办法莫过于Hadoop 项目项目所用的Map/Reduce 方式，其思想很简单，就是将计算程序下发到数据存储节点，就地进行计算，从而避免了在网络上传输数据的压力。这并非一个创新思想，很久之前就有诸多尝试（比如IBM 曾经搞国一个叫Aglet 的移动代理项目，就是将计算程序下发到各节点计算和收集信息），但对于海量数据处理的今天这种方式无疑最具吸引力，代价最小。简单说Map 是一个把数据分开的过程，Reduce 则是把分开的数据合并的过程。如Hadoop 的word count 例子：用Map 把[one,word, one,dream] 进行映射就变成了[{one,1}, {word,1}, {one,1}, {dream,1}] ，再用Reduce 把[{one,1}, {word,1}, {one,1}, {dream,1}] 归约变成[{one,2}, {word,1}, {dream,1}] 的结果集。 关于Map/Reduce 的抽象方法是map/recduce 的精髓之一，但本文不多说它了（你可参看函数语言或其他种种资料，这里不在赘述），本文主要想谈谈Map 的数据来源问题。

 

MAP/REDUCE 数据来源

 

Map 的数据来源初看也并非什么问题，无非就是读本地数据而已（前面已经说过计算程序作为map 的回调算子——借用java 的说法——被转移到了数据所在地再执行）。然而具体在海量数据处理的应用场景下就必须考虑和分布存储系统搭配了。 Hadoop 的搭配方式最简单，就是和其下的分布文件系统DFS 配合: 通过文件系统的原数据来定位文件块的分布节点位置，然后将回调算子下发到其上，已顺序读取的方式从本地文件系统上读取数据。对于日志文件分析等应用，上述做法效率很高，因为日志文件读取可是顺序读取，文件系统的预读特点可充分利用 —— 离线日志分析是利用map/reduce 分析的典型应用。 但我们也应看到Map/Recduce 的使用也有明显的局限性：第一是，如果对于较为复杂的输入要求，比如需要对数据集合进行query 查询，而非顺序读取文件的输入，则不能直接使用Hadoop 的Map/Recduce 框架；第二是，其下的分布文件系统为了一致性考虑，不支持多个并发写，而且写后不能修改，这些特性对日志等事后分析效果不错，但对于数据需要实时产生的场景有些勉为其难了。因此考虑是否能将Dynamo ，甚至是Bigtable 等分布存储系统或者分布类数据库系统在Map/Recduce 环境下使用便成了新的需求。不过我感觉Bigtable 的存储结构似乎不大容易实现在本地环境内完成进行较为复杂的查询（比如多列的符合查询，不一定能完成，且更不容易在本地完成——应为它无法避免到远程取数据，而如果一旦跨机器进行查询则又带来了过多的网络I/O ，违背了Map/Reduce 架构进行并行计算的设计初衷。那么Dynamo 是否可满足负责query 需求呢？ 如果采用上文在查询时提到的方法：给记录定义对应的schema ，并存储在存储点上将其存在传统的关系数据库中（可以在需要列上建立索引），那么将“回调算子——这里就是query 语句了”下发到其上，则可按照传统方式在本地进行query ！这样以来既符合了Map/Reduce 的初衷，又能满足复杂输入需求，同时还能不影响数据的实时产生。因此我认为灵活、方便的并行计算架构可以由Dynamo 或其变种存储系统（如上文所说的partition 方式）＋ Map/Reduce 完成。

 

当前几种云计算架构中的明星系统

 

目前云计算中的各种子系统可谓风起云涌，层出不穷。我这里简单提及几个我了解过的项目，大家有兴趣的话可重点跟踪它们，近一步了解云计算知识。 1 Bigtable /Dynamo 上文已经讲过了。 2 Hbase 是Hadoop 的一个子项目，类似于Bigtable , 最适合使用Hbase 存储的数据是非常稀疏的数据（非结构化或者半结构化的数据）。Hbase 之所以擅长存储这类数据，是因为Hbase 和Bigtable 一样，是列导向的存储机制 3 Couchdb 是Apache 下的一个面向文档存储，由Erlang 开发而成，和其他新型存储系统一样它同样是分布存储系统，具有很好的扩展性。但不同在于没有任何统一的schema 可言，数据组织是平坦的，无行无列。如果需要查询等操作，则借助于用户自己提供的聚合与过滤算子，以Map/Reduce 方式进行对文档信息进行全文检索处理——这个角度上说它也能实现类似数据库的查询，可方式方法完全不同——但它提供了一个view 的数据关系逻辑接口，对用户而言，可以想象成传统的表。 4 Simpledb 是amazon 公司开发的一个可供查询的分布数据存储系统，它是Dynamo 键值存储的补充和丰富，目前用在其云计算服务中。其具体实现方式没有论文公开。 5 Pig 是yahoo 捐献给apache 的一个很有趣项目，它不是一个系统，而是一个类SQL 语言, 具体目标是在MapReduce 上构建的一种高级查询语言。目的是把一些运算编译进MapReduce 模型的Map 和Reduce 中, 允许用户可以自己的功能. Pig 支持的很多代数运算、复杂数据类型（tuple,map) 、统计运算（COUNT ，SUM ，AVG ，MIN ，MAX ）和相关数据库检索运算（FILTER ，GROUP BY ，ORDER ，DISTINCT ，UNION ，JOIN ，FOREACH ... GENERATE ）