Hadoop学习系列之菜鸟学习HDFS/GFS

今天上曹老师的软件体系结构，课程上讨论了有关hadoop的文件系统HDFS，虽然之前对HDFS已经略有了解，但是以讨论和思考不断展开的教学 方式还是让听课的我收获颇多,所以先谢曹春老师。本文将不会进行章节上的划分，但是在过程中提到一些问题（加粗文字），问题之后是解决方案或者是HDFS 里面关于此问题的设计方案，如果你跟我一样是HDFS菜鸟的话，请看到问题的时候先进行一些自己的思考，然后再接着往下看。当然笔记中肯定有不少错误的地 方，欢迎指正。

　　BigData成为一个热门词语已有很长时间，大数据首先需要解决的问题就是存储的问题，这如何存储就成为一个问题， 当然我们可以Scale up，比如说原来你的服务器的存储能力是500GB，你买来新的大容量的硬盘，或采用磁盘阵列，让你的存储扩大到几个TB，然后呢？几个TB不够了你继续 升级么？或许升级是可行方案，但是代价会变的很高：你不得不花费大量的财力去买一台新的机器，然后原来高价买来的机器被替代后变得没什么用，这显然不是你 想看到的，一个更好的解决方案是Scale out，即购买多台廉价的机器来进行分布式存储，把数据分散到多台机器上存储。分散存储带来的一个问题：当我的程序需要数据的时候，我该到那去取数据？即我这么多数据该怎样进行管理？一 个直截了当的想法就是我使用一台服务器记录各个文件的位置信息，然后当程序需要数据的时候，先到服务器这儿来查找文件在哪儿，得到位置信息后，然后我的程 序再到相应位置去读或者修改文件。事实上Google的GFS和hadoop的HDFS都是这么做的，只不过Google的主节点叫master，存储数 据的节点叫chunkserver，换到HDFS里面主节点叫namenode，存储数据的节点叫datanode。主节点上保存了整个分布式文件的目录 结构，从节点上则保存着大量的数据，具体的工作步骤如下：

　　1.在程序运行前，数据已经存储在GFS/HDFS文件系统中；程序实行时应用程序会告诉主节点所要访问的文件名或者数据块索引是什么。

　　2.主节点根据文件名会数据块索引在其文件目录空间中查找和定位该文件或数据块，并找数据块在具体哪些数据节点上；将这些位置信息回送给应用程序

　　3.应用程序根据主节点返回的具体数据块位置信息，直接访问相应的数据节点

　　4.应用程序根据主节点返回的具体数据块位置信息直接读取指定位置的数据进行计算处理

 

 

Figure 1：GFS基本构架和工作原理

 

Figure 2：HDFS基本构架和工作原理

　　以为这就完了么，不，我们前面说过，我们存储数据的节点是使用大量的廉价机器，这就意味着这些机器会时不时的出点问题，也就是说我们面临着数据节点的失效问题，并且这种实效会经常发生，比如一台机器3年坏一次，如果有上千台机器的话，每天都会有机器坏掉。数据节点的失效带来两个问题：1、失效节点如何处理；2、我们怎样检测数据节点是否失效。 失效的问题很容易想到的一个方法就是数据冗余，即对数据做多个备份，在HDFS中可以通过配置文件设置备份的数量，如果不进行设置，这个数量默认为3，也 就是工业界一般认为较为可靠的备份数目；数据节点失效是由主节点来进行的，称为心跳检测，也就是主节点周期性的去检测数据节点的有效性，如果检测不到心 跳，主节点就去寻找新的节点替代，然后将数据重新分布到其他节点上。主节点除了上述功能外，还负责整个集群的负载均衡。

　　我们刚才说到对数据一般是需要做3个备份，那么我们在读数据或写数据的时候怎样处理备份之间的同步问题呢？在 HDFS/GFS中，当对数据进行更新时，仅当3个备份的数据都更新成功时，才认为数据保存成功。GFS/HDFS上存储的数据块副本，在物理上以一个本 地的Linux操作系统的文件形式存储，每一个数据块再划分为64KB的子块，每个子快有一个32位的校验和，读数据时会检查校验和以保证使用的不是失效 的数据，另外在主节点上存有每个数据块的校验和，HDFS/GFS客户端在读取完数据之后会将所读取的数据块的校验与主节点上的校验和进行对比，以验证数 据的有效性。显然3个副本都写成功才算数据更新成功的方案在效率方面有所欠缺，关于多个副本之间数据的同步及有效性问题，亚马逊的Dynamo存储引擎里 有一个解决方案，该论文的链接将在本文末尾给出。

　　主节点我们可以采用性能比较好、比较稳定的机器，但是这并不意味着这台机器不会坏掉，那么我们如何应对主节点失效的问题呢？ 备份是肯定的，在主节点上，目录信息在内存中的镜像会定期重写到硬盘中，这样的每次写入的数据称为一个checkpoint，另外主节点上还有关于 checkpoint的变更记录的日志文件Journal，checkpoint不会被修改，每次生成一个新的checkpoint的时候就将原来的替换 掉。为了防止checkpoint和Journal的损坏，主节点会在多个目录下保存这两个文件。另外在一些子节点上也存有checkpoint和 Journal。除此之外还有一个BackupNode， BackupNode能够创建周期性的checkpoints，它还在内存中维护了一个文件系统名字空间(即目录信息)的最新映像，该映像会一直与 NameNode状态保持同步。当主节点宕机后，可以启用此节点。主节点的切换，HDFS通常是需要几个小时的，Google宣称自己可以在很短时间内完 成切换。另外淘宝宣称自己的分布式文件系统TFS也可以在几秒内完成主节点的切换工作。 

　　HDFS/GFS成功的一个重要原因是它的可扩展性，当存储容量不够时，直接增加新的节点就可以。这个过程 是这样的，当加入一个新的节点时，新节点会向主节点发送一个block report来声明它所拥有的block副本，主节点会给新增加的节点分配一个ID并将block report中的信息存入目录信息。通常情况下，子节点会周期性的向主节点发送block report，在HDFS中这个时间是一小时。

　　另外一个重要的问题是：如果单个文件很大，并且会经常被访问，怎么处理？相信各位看到这儿的已经想到了，前 面已经提到了block这个概念，HDFS/GFS中是按块存储文件的，每个块的大小是64M，这个值在HDFS中也是可以设置的，也就是说大的文件会被 分成很多块存储到不同的节点上，这样做显而易见的一个好处是大的文件可以并行读取从而以很快的速度读取出来。文件很大是一个问题，文件小同样也是一个问 题，显然一个64M的块只放一个图片文件太浪费了。关于小文件的存储依然有人在不断研究，淘宝上的数据就有很多是这种类型的小文件，因此他们开发了自己的 分布式文件系统TFS，较好的解决了这个问题。

　　好了，关于HDFS/GFS就写到这儿了，当然里面肯定有许多不完善或者错误的地方，欢迎指正。

本文来自大笤帚---扫清一切障碍，奋勇向前冲的大笤帚！