由于性能评价，HDFS需要优化，在考虑Federation HDFS
HDFS只有一个name space, 它使用全部的块。 而Federation HDFS 中有多个独立的namespace，每个命名空间使用一个block Pool。
Bolck Pool : 维护单个命名空间的所有block。
注意区分：Data node是一个物理概念，而block pool是一个重新将block划分
的逻辑概念。
NameNode、DataNode、SecondaryNameNode存储结构是什么样子的呢。
NameNode存储结构：
{dfs.namenode.name.dir}
|---VERSION
|---fsimage
|---edits
首先看下VERSION里面是什么
namespaceID:代表的是文件系统唯一标识，文件系统首次格式化时产生。没有注册到namenode之前的datanode都不知道namespaceID，所以可以通过这个来检查新建的datanode
clusterID：集群ID
cTime：NameNode存储系统创建时间，首次格式化文件系统这个属性是0，当文件系统升级之后，该值会更新到升级之后的时间戳
storageType：说明该存储目录是namenode的数据结构
layoutVersion：是一个负整数，用来描述HDFS持久化数据结构的版本的。这个版本与Haoop版本号无关，当文件系统布局发生改变他就回减一，但是此时HDFS也需要升级，否则新的namenode无法使用。
blockpoolID：块池id，用来做什么的，我现在暂时也不太清除。
编辑日志和镜像文件
fsimage镜像文件存储着文件系统所有目录和文件的元数据信息即inode序列化信息。每一个inode是文件或目录的元数据内部描述方式，对于文件存储比如副本级别、修改时间、块大小等等。fsimage并不存储描述datanode的信息。因为datanode加入集群后会定期向namenode发送块的映射信息。
edits编辑日志如果这样会不断增长，这样每当重启namenode时候会比较慢，这时候文件系统就处于离线状态，这并不是用户想要的。可以通过运行辅助namenode来解决。
为主Namenode中的元数据创建检查点，进行编辑日志和镜像文件合并。
(1)辅助namenode要求主namenode停止使用edits文件，暂时使用新的edits文件。
(2)辅助namenode从主namenode那里获取fsimage和edits文件
(3)辅助namenode将fsimage加入到内存，然后根据edits执行文件操作，创建新的fsimage
(4)辅助namenode将新的fsimage发送到主namenode中
(5)主namenode用新的fsimage替代原先的fsimage，并且使用(1)中的eits代替旧的edits文件。
这就是为什么SecondaryNamenode也需要一台独立服务器的原因了。他的操作和namenode差不多
这个创建检查点需要两个配置控制，第一就是dfs.namenode.checkpoint.period属性设定，每隔多长时间创建一次检查点，默认是3600即一个小时。第二就是dfs.namenode.checkpoint.txns这个hadoop1中是fs.checkpoint.size，我在hadoop2.2中没有找到与之类似，但是估计是这个，当编辑日志达到这个配置的大小即使没有到达之前配置的时间也会创建检查点。
SecondaryNameNode中的current目录与namenode的一样，因为创建检查点不仅为主namenode创建检查点数据，也是辅助namenode也有一份检查点数据，用来备份namenode元数据，尽管他不是最新的。如果主namenode挂了，并且没有NFS，可以使用SecondaryNamenode作为主namenode，当dfs.namenode.name.dir中没有元数据的时候就会从dfs.namenode.checkpoint.dir中载入检查点数据。这就是为什么两者目录为什么设计成一样的原因了，不用担心覆盖现有的元数据。
DataNode的目录结构：
{dfs.datanode.data.dir}
|--VERSION
|--BP-792156149-127.0.1.1-1431433217275
|--current
|--finalized
|--VERSION
VERSION内容与namenode类似，他的namespaceID是datanode首次向namenode访问获取的，storageID是每个datanode的id，namenode通过他来区分不同的datanode
看到BP-792156149-127.0.1.1-1431433217275这个让我明白了namendoe上面的那个blockpoolId了，这时hadoop1中没有的，在这个BP-792156149-127.0.1.1-1431433217275目录里面放着这个块池的current，里面还有一个VERSION这个VERSION才有namespaceID，而外层那个只有storageID
在hadoop2中数据块存放到块池中的finalized中以blk_为前缀，有两种类型：块文件和块文件元数据信息(以meta结尾)块文件存储数据，块文件信息存储版本号以及校验和等信息。
如果dfs.namenode.data.dir指定了不同磁盘的多个目录，数据会以轮转的方式写入到磁盘中，当同一个datanode不会存储相同的块。
如果你有时候连续格式化文件系统，会产生datanode与namenode 的namespaceID不同，这时候你启动不了datanode因为namenode并不认识这个datanode，你需要将datanode的namespaceID与namenode相匹配。
{dfs.namenode.name.dir}
|---VERSION
|---fsimage
|---edits
首先看下VERSION里面是什么
namespaceID:代表的是文件系统唯一标识，文件系统首次格式化时产生。没有注册到namenode之前的datanode都不知道namespaceID，所以可以通过这个来检查新建的datanode
clusterID：集群ID
cTime：NameNode存储系统创建时间，首次格式化文件系统这个属性是0，当文件系统升级之后，该值会更新到升级之后的时间戳
storageType：说明该存储目录是namenode的数据结构
layoutVersion：是一个负整数，用来描述HDFS持久化数据结构的版本的。这个版本与Haoop版本号无关，当文件系统布局发生改变他就回减一，但是此时HDFS也需要升级，否则新的namenode无法使用。
blockpoolID：块池id，用来做什么的，我现在暂时也不太清除。
编辑日志和镜像文件
fsimage镜像文件存储着文件系统所有目录和文件的元数据信息即inode序列化信息。每一个inode是文件或目录的元数据内部描述方式，对于文件存储比如副本级别、修改时间、块大小等等。fsimage并不存储描述datanode的信息。因为datanode加入集群后会定期向namenode发送块的映射信息。
edits编辑日志如果这样会不断增长，这样每当重启namenode时候会比较慢，这时候文件系统就处于离线状态，这并不是用户想要的。可以通过运行辅助namenode来解决。
为主Namenode中的元数据创建检查点，进行编辑日志和镜像文件合并。
(1)辅助namenode要求主namenode停止使用edits文件，暂时使用新的edits文件。
(2)辅助namenode从主namenode那里获取fsimage和edits文件
(3)辅助namenode将fsimage加入到内存，然后根据edits执行文件操作，创建新的fsimage
(4)辅助namenode将新的fsimage发送到主namenode中
(5)主namenode用新的fsimage替代原先的fsimage，并且使用(1)中的eits代替旧的edits文件。
这就是为什么SecondaryNamenode也需要一台独立服务器的原因了。他的操作和namenode差不多
这个创建检查点需要两个配置控制，第一就是dfs.namenode.checkpoint.period属性设定，每隔多长时间创建一次检查点，默认是3600即一个小时。第二就是dfs.namenode.checkpoint.txns这个hadoop1中是fs.checkpoint.size，我在hadoop2.2中没有找到与之类似，但是估计是这个，当编辑日志达到这个配置的大小即使没有到达之前配置的时间也会创建检查点。
SecondaryNameNode中的current目录与namenode的一样，因为创建检查点不仅为主namenode创建检查点数据，也是辅助namenode也有一份检查点数据，用来备份namenode元数据，尽管他不是最新的。如果主namenode挂了，并且没有NFS，可以使用SecondaryNamenode作为主namenode，当dfs.namenode.name.dir中没有元数据的时候就会从dfs.namenode.checkpoint.dir中载入检查点数据。这就是为什么两者目录为什么设计成一样的原因了，不用担心覆盖现有的元数据。
DataNode的目录结构：
{dfs.datanode.data.dir}
|--VERSION
|--BP-792156149-127.0.1.1-1431433217275
|--current
|--finalized
|--VERSION
VERSION内容与namenode类似，他的namespaceID是datanode首次向namenode访问获取的，storageID是每个datanode的id，namenode通过他来区分不同的datanode
看到BP-792156149-127.0.1.1-1431433217275这个让我明白了namendoe上面的那个blockpoolId了，这时hadoop1中没有的，在这个BP-792156149-127.0.1.1-1431433217275目录里面放着这个块池的current，里面还有一个VERSION这个VERSION才有namespaceID，而外层那个只有storageID
在hadoop2中数据块存放到块池中的finalized中以blk_为前缀，有两种类型：块文件和块文件元数据信息(以meta结尾)块文件存储数据，块文件信息存储版本号以及校验和等信息。
如果dfs.namenode.data.dir指定了不同磁盘的多个目录，数据会以轮转的方式写入到磁盘中，当同一个datanode不会存储相同的块。
如果你有时候连续格式化文件系统，会产生datanode与namenode 的namespaceID不同，这时候你启动不了datanode因为namenode并不认识这个datanode，你需要将datanode的namespaceID与namenode相匹配。
参考：https://www.cnblogs.com/tieandxiao/p/8799287.html