【分布式计算】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

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