分布式系统工程实现：GFS&Bigtable设计的优势，互联网营销

　　目前，知名度比较高的通用存储系统包括：Google GFS&Bigtable，Amazon Dynamo，Microsoft Azure存储系统及Yahoo PNUTS。其中，GFS&Bigtable，Azure存储系统及Yahoo PNUTS都有总控节点，Amazon Dynamo采用去中心化的P2P设计。

　　Amazon Dynamo看起来很优美，比如Dynamo论文中提到的技术比较酷，Dynamo没有中心节点，可以支持更大的系统规模。然而，Dynamo不是我心目中的理想架构，因为Dynamo有一致性的问题，系统设计复杂但解决的问题有限。如果需要保证一致性，就必须要求同一时刻对同一份数据只有一个更新节点，Dynamo显然不符合要求，可能出现数据丢失等不一致的情况。虽然对于很多场景能够通过冲突合并来解决，另外，Dynamo由于采用一致性Hash的方法进行数据分布，数据不是连续存储的，不能支持高效的扫描操作，所以数据模型只能是简单的<Key, Value>模型，不能支持类似数据仓库这种需要扫描某个用户且单个用户数据量可能特别大的应用场景。总之，去中心化的系统一般有两个问题：1,一致性问题；2,顺序扫描效率低下。

　　GFS和Bigtable两层的设计是一个几乎完美的组合。GFS本质上是一个弱一致性系统，可能出现重复记录、记录乱序等各种问题（后续有文章专门分析原因），Bigtable是GFS之上的一个索引层，为了服务百PB级别的应用，采用两级的B+树索引结构。GFS保证成功的记录至少写入一次并由Bigtable记录索引，由于Bigtable是一个强一致性系统，整个系统对外表现为强一致性系统。为了保证Bigtable的强一致性，同一时刻同一份数据只能被一台机器服务，且Bigtable论文中的Tablet Server对每个Tablet是没有备份的。当Tablet Server宕机时，由于只需要排序很少的操作日志并且加载服务的Tablet的索引，宕机恢复可以做到一分钟以内。Bigtable分裂和迁移到只需要修改或者加载索引数据，因此效率很高，整个系统的扩展性很好。GFS&Bigtable架构广受质疑之处主要体现在两个方面：

　　1. GFS&Bigtable架构实时性不好。

　　2. Bigtable Tablet Server的单点问题。

　　第一个对Bigtable实时性的质疑，大体有两个原因：第一点是由于Bigtable的Tablet和GFS的Chunk可能不在一台机器上，读取操作可能要走网络；第二点是由于Bigtable每次随机读取都需要读取一块数据，比如16K, 32K或者64K。第一点可以通过本地化策略来解决，第二点由于磁盘的寻道时间一般为8~10ms，读取一整块的overhead不会太高，且Bigtable系统内部的Block Cache和Key-Value Cache可以解决很多问题。开源的HBase和Hypertable由于缺少大规模应用环境还不够稳定，实时性确实做得不好，不过这不是架构本身的问题，而是架构的复杂性导致的实现问题。

　　第二个对Bigtable的质疑，我们可以通过多数据中心的Replication来解决：同一个数据中心内部的Bigtable系统保证强一致性，机房之间通过回放操作日志进行数据同步，保证最终一致性。同一时刻只有一个集群提供写服务，其它集群提供读服务。当然，对应用方来说仍然是一整套系统，当某台Tablet Server宕机时，只影响短时间部分数据的写服务，读服务如果不要求强一致性不受影响。

　　描述CAP理论时我们经常会说，Dynamo是AP的系统，Bigtable是CA的系统。然而，Bigtable的分区可容忍性做得也还不错：Bigtable在机房断电，机房之间网络故障时仍然可以对外提供服务。假设在三个机房部署了三套Bigtable集群，且采用三机房五节点的方式部署了Chubby服务，任何一个机房断电或者某两个机房之间网络故障系统仍然能够对外服务。多个机房同时故障或者三个机房被分成三个区的情况理论上有可能，工程上可以认为不可能。所以，不要为了满足CAP理论上的特性而设计系统，业务需求才是本质。

　　总之，GFS&Bigtable设计在可扩展性，容错，负载平衡等各方面都有很大的优势，并且集群越大优势越明显，问题是整套系统过于复杂，对工程师，应用环境，管理层忍耐力都是一个考验。