【分布式计算】DFS && BigTable

1.背景

分布式计算的发迹应该是google在2003年发表的三篇paper。各自是GFS、MapReduce、BigTable。

当中MapReduce大家都非常熟悉了。不懂的同学也能够看看我之前写的文章【分布式计算】MapReduce的替代者-Parameter Server

为什么google会搞分布式计算这件事儿呢，由于在那个年代每天会产生几个T的日志，可是当时的磁盘仅仅同意存储几百G的文件，07年之前淘宝的全部数据都是用完就删除的，由于没地方存。后来，人们认识到数据是值钱的，所以须要一种存储策略来存储大数据。于是google就用了分布式存储系统。

这里主要介绍下GFS和BigTable。

2.DFS（相应hadoop的HDFS）

DFS是一种分布式文件存储系统。常规的文件系统是树状结构存储的，每一个文件有一个指针指到磁盘上的某个区域。

早期的DFS是单点结构的。有一个master节点负责管理每一个文件的namespace（文件存储在哪个机器的哪个磁盘上。如s3/dick2）。要存储一个非常大的数据。例如说一个10P的数据，首先是切片，例如说依照64M切片。每一个block存在某一个机器的某个磁盘上。总体的结构例如以下：

这里面就会衍生出三个问题，

       第一个是master节点假设挂了，整个文件系统就不能work了，这个是单点的一个缺陷。

       第二个问题是，一但slave中的某个磁盘破损了，磁盘破损率在2%左右，也就是每天都有破损的。这里有一个冗余机制，就是每一个block会分配到多个磁盘上备份~

       第三个问题是，磁盘是不停的被读写的，master是怎样获得每一个磁盘的信息的，这个功能依赖于一种叫做heart-beat的机制，每隔几秒钟，master就要遍历每一个slave得到它们的最新状况。

3.BigTable（相应Hadoop的HBase）

假设说DFS是磁盘级别的分布式存储。那么BigTable就是内存级别的分布式存储。

BigTable的存储结构是HashTable，以key-value的形式存储。

应用场景是一些在线的service。

例如说GoogleEarth，每一个地名（key）会相应一系列的meta（value），世界上有无数个地名，这是一个非常大的文件。假设从磁盘中拿，例如说输入一个巷子的名字，过10分钟用户才干拿到结果。这是不能接受的。我们须要将这些key-value做成cache缓存在内存中。显然单机内存的极限。例如说300G也是无法缓存这么大的文件的。这就须要多个机器一起缓存，这个策略就是BigTable。

可是，一但一个机器出现failover的情况。整个缓存就出现了gap，BigTable有一个机制就是，不断地将文件underfile到DFS中。防止文件丢失。

/********************************

* 本文来自博客  “李博Garvin“

* 转载请标明出处:http://blog.csdn.net/buptgshengod

******************************************/