分布式系统漫谈一 —— Google三驾马车: GFS,mapreduce,Bigtable

到分布式系统，就不得不提Google的三驾马车:Google fs[1],Mapreduce[2],Bigtable[3]。

虽然Google没有公布这三个产品的源码，但是他发布了这三个产品的详细设计论文。而且，Yahoo资助的Hadoop也有按照这三篇论文的开源Java实现:Hadoop对应Mapreduce, Hadoop Distributed File System (HDFS)对应Google fs,Hbase对应Bigtable。

Hadoop与google三大件：

Hadoop是很多组件的集合，主要包括但不限于MapReduce，HDFS，HBase，ZooKeeper。 

     MapReduce模仿了Google的MapReduce， 

     HDFS模仿了Google File System， 

     HBase模仿了BigTable， 

     所以下文只出现MapReduce、HDFS和HBase。
     简单来讲， HDFS和HBase是依靠外存（即硬盘）的存储模型和实现。HDFS是一个云存储的文件系统，它会把一个文件分块并分别保存，取用时分别取出再合并。重要的是，这些分块通常会在3台节点（即机群内的电脑）上有3个备份，所以即使出现少数电脑的失效（硬盘损坏、掉电等），文件也不会失效。如果说HDFS是文件级别的存储，那HBase则是表级别的存储。HBase是一个表模型，但比SQL数据库的表要简单的多，没有连接、聚集等功能。HBase表的物理存储是依赖HDFS的，比如把一个表分成4个文件，存到HDFS中。由于HDFS级会做备份，所以HBase级不再备份。
MapReduce则是一个计算模型，而不是存储模型；MapReduce与HDFS紧密配合，而非HBase。举个场景：如果你的手机通话信息保存在一个HDFS的文件callList.txt中，你想找到你与你同事A的所有通话记录并排序。因为HDFS会把callLst.txt分成几块分别存，比如说5块，那么对应的Map过程就是找到这5块所在的5台节点，让他们分别找自己存的那块中关于A的通话记录，对应的Reduce过程就是把5个节点过滤过的通话记录合并在一块并按时间排序。可见MapReduce的计算模型需要HDFS，但与HBase没有任何关系。
ZooKeeper本身是一个非常牢靠的记事本，最好用于记录一些概要信息。Hadoop依靠这个记事本来记录当前哪些节点正在用，哪些已掉线，哪些还备用等，以此来管理机群。

BigTable与GFS的关系： 

     GFS是分布式文件系统，BigTable 是建立在GFS之上的。就像文件系统需要数据库来存储结构化数据一样，GFS也需要Bigtable来存储结构化数据，每个Table都是一个多维的稀疏图，为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每个Tablets大概有 100-200 MB，每个机器存储100个左右的 Tablets。底层的架构是：GFS。由于GFS是一种分布式的文件系统，采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应的表移动到其他空闲机器上，然后快速重建。

BigTable是一个key/value分布式数据库，而GFS主要是一个分布式文件系统。bigTable存储结构化数据，GFS存储的是非结构化数据。另外BigTable的数据是存储在GFS上的。