作者：phylips@bmy 2011-10-15
虽然标题有些诡异，但是实际上转成英文就一目了然了：Dynamo Dremel ZooKeeper Hive。这几个系统之间本身没有太过紧密的联系，只是最近休假期间把它们四个粗略看了一遍，因此放到一块简要总结一下。就这四篇比较来看，其中Dremel和Hive相对容易理解些，Dynamo和ZooKeeper则相对深奥一些。
首先来看Dremel，它主要做了三件事：将嵌套记录转换为列式存储，并提供快速的反向组装；类sql的查询语言；类搜索系统的查询执行树。通过列式存储降低io，将速度提高一个数量级，这类似于诸如Vertica这样的列存式数据库，与传统行式存储不同，它们只需要读取查询语句中真正必需的那些字段数据；通过类搜索系统的查询执行系统取代mr(MapReduce)，再提高一个数量级。它类似于Hive，应该说查询层像Hive，都具有类似于SQL的查询语言，都可以用来做数据挖掘和分析；但hive是基于mr，所以实时性要差，Dremel则由于它的查询执行引擎类似于搜索服务系统，因此非常适合于交互式的数据分析方式，具有较低的延迟，但是通常数据规模要小于mr；而与传统数据库的区别是，它具有更高的可扩展性和容错性，结构相对简单，可以支持更多的底层存储方式。其中的数据转化与存储方式，巧妙地将嵌套记录转换成了列式存储，同时还能够快速的进行重组，是其比较独特的一点。
现在的一个趋势是，每当业界的大公司(尤其是google这样的)每发表一篇相关论文，通常都会产生一个与之对应的开源系统。比如GFS/HDFS，MapReduce/Hadoop MapReduce，BigTable/HBase，Chubby/ZooKeeper，Protobufs/Avro，Stubby/Avro，FlumeJava/Plume，Dapper/Avro。那么google发表这篇Dremel之后，Hadoop家族是否也会出来这样的类似系统呢？狭义的Hadoop实际只包含HDFS和Hadoop MapReduce，此外还有一堆围绕着它的各种辅助系统，它们共同组成了一个完整的生态系统，比如HBase，Hive，ZooKeeper等等。Hadoop最初出发点是用于搜索系统的离线数据处理中，目前它正逐步成为海量数据处理的通用性系统。Dremel实际上已经很类似于Pig和Hive，尤其是Hive具有了RCFile之后，最大不同之处在于底层执行机制，Dremel没有采用MapReduce，而是使用了一个分布式的查询聚合树，目前一些Online Hadoop原型中已经采用了类似机制。同时Hadoop未来肯定会支持更多的非MapReduce的查询执行引擎。新一代的Hadoop计划分离出一个通用的资源管理器，并支持在此之上的不同的任务调度执行方式，以及各种编程模型，这样就可以使用除MapReduce之外的模型，支持像MPI，迭代计算，Pregel，Dryad，Dremel这样的一些执行引擎。目前伯克利已经构建了一个类似的资源管理器实现：Mesos。一些处理框架比如MPI，Spark已经可以运行在它上面。目前Dremel的各个内部组件基本上都已经存在一些类似开源实现了，因此实现一个类Dremel的系统应该是有很多现成东西可以利用的，不需要再像当初Doug(Doug Cutting)和Mike(Mike Cafarella)实现Hadoop那样。
再看Dynamo。可以将Dynamo和Bigtable看成当今两个非常重要的NoSQL系统流派。与Bigtable相比，Dynamo底层存储是基于一致性hash的，是一个分布式hash结构，采用了很多P2P的技术，完全去中心化，同时在CAP的选择上，dynamo选择了AP；而Bigtable则采用LSM-tree作为存储引擎，同时上层数据库还具有一个类似于数据库中的B+树索引，更侧重于CP。Dynamo通过一致性哈希进行分区，这样就可以方便地进行增量式扩展；通过vector clock进行版本记录和读时冲突解决，提高了写可用性；使用NRW进行配置权衡；采用merkle tree进行内容差异检测；采用gossip进行成员管理和失败检测。由于受路由表的限制，Dynamo扩展性要弱些，Amozon的论文中大概提到了几百台集群的规模。要理解Dynamo，首先需要理解一致性hash，vector clock，merkle tree，gossip这样的一些基础性技术。
ZooKeeper。虽然源于Chubby，但是ZooKeeper本身进行了比较大的改动，与chubby相比,没有直接提供锁的接口，采用wait free机制避免阻塞；也有多副本，但通过原子性广播协议进行副本更新，同时每个副本都可以处理读请求，因此具更高可用性；无handle；使用观察者机制管理客户端缓存；在分布式系统中所担任角色与chubby一致，通常为分布式应用提供协调服务，可以用来实现配置文件管理，组管理，leader选举，锁这样的一些机制。Chubby本身就已经依赖了很多的基础技术，比如Paxos，Leases等。而要理解ZooKeeper，还要搞清楚wait-free机制，原子性广播这样的一些技术。
所以说Zookeeper和Dynamo要相对难理解些，因为它们都依赖了很多颇具理论性的东西。
最后看一下Hive。目前也已经有很多类似系统，比如Pig，Sawzall。与Pig，Sawzall相比，Hive的最大特点是：类sql，同时提供了metastore。起初主要承担了一个sql到mr的翻译器的角色，RCFile出来后，使得它的存储方式更方便做数据挖掘，更接近传统数据仓库。此外，Google最近又发表了一篇Tenzing，与Hive想比，Tenzing的优势在于它跟底层所依赖的MapReduce系统都是一个公司内的产品，因此它可以对MapReduce做很多改动，以满足Tenzing某些特殊性的需求，最大化Tenzing的性能。
参考资料：
Dremel与Hadoop
http://www.quora.com/How-will-Googles-Dremel-change-future-Hadoop-releases
Amazon S3与Google Storage Service的类似系统