hdfs2.0

昨天跟做技术预研的同事讨论下hdfs2.0的新架构。因为我并没仔细看hdfs2.0的文档，这里简单总结下对于2.0 framework的初步理解，有不对的地方欢迎指出。

1.元数据服务器（mds metadata server，在hdfs叫name node）集群，hdfs2.0中称其为federation。举个例子，有三个元数据服务器mds1、mds2、mds3组成一个federation。hdfs的根目录下有三个目录，/a、/b、/c。那么/a只可能位于三个mds中某一个上面，例如/a对应mds1,b对应mds2,c对应mds3,/a路径下的所有子目录和子文件也都由mds1管理。这样三个mds就分别维护了三个独立的命名空间。client在初始化的时候会从所有的mds上获取该mds所维护的根目录的子目录有哪些。

hdfs2.0的元数据服务器集群方案非常简单，本身无法保证file在元数据集群中的负载均衡，需要用户来保证。也就是说app最好做到/a、/b、/c三个路径下的文件尽量一样多。

相对而言ceph就做了很多负载均衡的工作，ceph汇报root的子树动态裁剪到不同的mds上，而且ceph也做了元数据的副本，考虑了mds集群的ha。

上次面试有人说我在做的文件系统跟hdfs2.0做的事情是类似的，当时不了解hdfs2.0就没回答。其实我们的方案比hdfs2.0还是有很大不同的。个人感觉，hdfs2.0的风格秉承最初的风格，就是设计尽量的简单，不没考虑复杂的架构。

2.client元数据缓存，同事说client会在本地缓存一个目录树，不清楚这个目录树是否支持索引。1.0版本实际上无论mds还是client都不会维护目录树的结构，不关心父子关系会让系统简单很多，当然也导致全路径长度的限制。

3.data node具备已经的元数据管理能力，其实就是mds部分能力下沉到datanode。1.0版本中，mds实际上是可以看到到data node上的具体的物理盘，2.0版本mds只关心节点，以及节点的大小（即一个节点包含多少个block，感觉block其实跟一致性哈希里面的虚节点的概念类似），不在关心一个chunk在节点上的具体位置，具体位置由data node自己决定。

以上几点可能细节有出入，不过大致的思路应该是对的。