Hadoop源代码分析（重读GFS的文章）
前面的内容基本完成了对HDFS的分析，很微观，从宏观的角度，重读一遍Google的论文，再次把握这个系统，还是很有意义的。HDFS的设计目标和GFS是高度一致的，甚至HDFS上面的应用，也有对应的项目。
设计方面，从接口看，HDFS缺少快照和记录追加操作（下面分析），其他方面，如架构，单一主服务器，块尺寸，元数据的实现上，差别不大。操作日志的实现上，HDFS的实现方案应该更有优势，创建检查点对NameNode的影响很小。
GFS有快照和记录追加操作。快照操作可以用很低的成本创建文件或者目录树的拷贝。记录追加操作可以在保证原子性的前提下，允许多个客户端同时在一个文件上追加数据。HDFS目前是不支持这两个功能的，而且要支持的话，对系统的改动会非常大，特别是NameNode。缺乏快照的功能，其实还是很影响上层应用的，举个例子，Hbase的RegionServer管理的数据如果超过门限值，那么数据会进行一次划分。我们知道，这些数据其实是只读的，也就是说，如果我们有快照的功能，那么我们只需要对数据做一个快照， RegionServer就可个各自管理划分后的数据，当由于HDFS不支持快照，所以Hbase就使用丑陋的复制，来解决这个问题。
在数据一致性方面，HDFS相对于GFS，更简单。由于HDFS不支持GFS方式的记录追加操作，同时也不支持并行写，那么失败的写，HDFS的结果显然也是“不一致”；成功的则是写已定义。
写
记录追加
串行成功
已定义
已定义
部分不一致
并行成功
一致但是未定义
失败
不一致
系统交互方面，HDFS和GFS的差别还是比较大的。具体来说，就是DataNode上基本不处理租约，甚至看不到租约，这也很正常，毕竟HDFS没有并行写，也没有append。至于写操作的数据流，倒是实现了GFS一样的功能。
主服务器上的操作，HFDS也比较简单，它不区分读/写锁，只是用INodeFileUnderConstruction，表示文件处于写状态，而且对于文件所在的目录，也没有保护机制，你可以删除某个处于Construction的文件的父目录而不会出错（写文件的客户端在下一次向NameNode请求append会报错）。从这个角度来看，HDFS是没有锁机制的。垃圾回收上，HFDS也很单薄，目前并没有实现回收站的功能。
最后一个要点是容错和诊断，在这一点上，HDFS和GFS还是比较一致的。
总的来说，HDFS基本实现了GFS的一些目标，但还有很多的功能需要实现，以更好支持上面的应用。
页:
[1]