首页 > 代码库 > 【分布式计算】DFS && BigTable
【分布式计算】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
******************************************/
【分布式计算】DFS && BigTable
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。