HDFS文件系统如何查看文件对应的block

问题导读：
1.文件与block的信息被保存在什么文件中？
2.如何查看整个目录树？
3.可以通过什么方式查看文件与block的对应关系？





（1）文件分割后，会有一个  文件 --> block的映射，这个映射是持久化到硬盘中的，具体的映射关系表是在FSNamesystem.java中构建的（该部分的构建使用的是FSDirectory.java的功能，filename - blockset）；
有了文件到块的映射表就可以通过文件找到blocklist；
（2）datanode的选取，hadoop有它本身的机制，一般来说，datanode默认是三个，选取的是不同机架的datanode，同机架里选一台，另一个机架里选取两台（安全性等考虑）；
（3）block写入datanodes，选取的三个datanode，比如说是A、B、C，先写给A，A再写给B，B再写给C；然后B收到C的写入成功，A收到B的写入成功，然后告诉namenode 和 client写入成功；
（4）真正写的并不是block，而是比block更小的好像是chunk ， 还包括有各种校验。






上面说一个大体的过程，下面详细介绍一下，也就是从原理角度来理解。其实这里面有一个问题，我们能否通过命令来查看一个文件的所组成的block，它应该具有Java api,但是对于shell 命令，目前还没有发现。所以如果我们想查看一个文件所处的block，可以提取BlocksMap的信息。

具体大家想可以详细看看他们的原理

NameNode节点是就是HDFS的大脑。想了解HDFS文件系统，必须了解大脑结构。 咱们就从NameNode节点开始。NameNode类中，关于HDFS文件系统的存储和管理都交给了FSNamesystem负责。下面介绍一下FSNamesystem的逻辑组成和类图。
1. FSNameSystem层次结构
一些概念
INode:  它用来存放文件及目录的基本信息：名称，父节点、修改时间，访问时间以及UGI信息等。
INodeFile: 继承自INode，除INode信息外，还有组成这个文件的Blocks列表，重复因子，Block大小
INodeDirectory：继承自INode，此外还有一个INode列表来组成文件或目录树结构
Block(BlockInfo)：组成文件的物理存储，有BlockId，size ，以及时间戳
BlocksMap: 保存数据块到INode和DataNode的映射关系
FSDirectory：保存文件树结构，HDFS整个文件系统是通过FSDirectory来管理
FSImage：保存的是文件系统的目录树
FSEditlog:  文件树上的操作日志
FSNamesystem: HDFS文件系统管理

这些概念之间的层次关系:




我们都知道，在NameNode内存中存在两张很重要的映射表：
   1. 文件系统的命名空间(文件目录树) 主要是 文件和Block映射关系 (保存在FSDirectory)
   2. Block 和 INodeFile & DataNode的映射关系 (保存在FSNamesystem)

在上图中，左边黑线部分是
1 数据结构的层次关系；红线部分是
2 关系的层次结构
(其中block & DataNode这个共用)
下面详细的介绍上图所表示的关系：
文件系统 FSNamesystem
FSNamesystem 主要有两个对象：文件系统(FSDirectory)根节点rootDir 和BlocksMap映射表 (Block -> { INode, datanodes, self ref } )

文件系统目录FSDirectory
保存文件目录结构(INodeDirectory树)，实现FSImage和FSEditLog操作实现。

INode ( INodeFile & INodeDirectory )
在HDFS中，无论目录还是文件，都是INode。INode有两个派生类INodeFile和INodeDirectory。
INodeFile是INode文件类，INodeDirectory是INode目录类。每一 INodeDirectory孩子节点都是由INodeDirectory目录或INodeFile文件列表构成。这样就形成了一棵INode树形结构。  
NameNode内存中保存着HDFS整个文件系统形成的树，这棵树保存在FSDirectory对象内。

Block & BlocksMap & BlockInfo
HDFS物理存储单元是Block(缺省的Block大小为64M)，每个Block会有几个副本(缺省是3个)，这些Block都是存储在不同数据节点上的。映射关系保存在BlocksMap。

Block & INodeFile
每个INodeFile都有一个Block列表组成。每一个block有多个副本(缺省3个副本), 各副本保存在不同的数据节点上。 这样在文件与Block和DataNode之间形成一个映射关系表。这张关系表就保存在FSDirectory对象 .

FSImage & FSEditlog(FSDirectory)
由于目录树(FSDirectory)在NameNode内存中保存，机器也有掉电的时候。若只保存在内存那势必会造成数据的丢失。因此，系统会周期性的保存文件目录树到NameNode本地文件系统，生成FSImage。主要由FSImage和FSEditLog，这两个类负责目录树持久化。
当 HDFS系统非常庞大时，FSImage也会非常大，这样不能文件系统发生任何操作时，就更新到FSImage，所以一段时间内文件系统的操作日志会记录到FSEditLog。到一定时间会把操作日志FSEditLog同步到FSImage，这样就形成完整的文件目录树。
   2. FSNameSystem 主要类关系图




这个类图可以分成三个部分
Bock相关的部分(BlocksMap & BlockInof & Block)
INode相关的部分(INode & INodeDirectory & INodeFile & INodeDirectoryWithQuota)
FSImage & FSEditLog (Storage & StorageInfo)
其中
BlockInfo是Block的加强类，增加了INodeFile的引用和DataNode列表
INodeFirectoryWithQuota 是INodeDirectory的增强类，增加了Quota限制功能

从层次关系图和类图中，可以看出FSNamesystem中各数据结构之间的关系。了解FSNamesystem, 那么HDFS的文件系统就了解了90%。

这里在补充一些内容：下面内容说明了，我们的文件对应的block id映射信息存在BlocksMap中，那么BlocksMap存在什么位置？BlocksMap存放于fsimage文件中。
fsimage在什么位置：首先对于hadoop1.x是由hdfs-site.xml中hadoop.tmp.dir来配置的，如下图所示


下面我们从路径中来找到fsimage,如下图所示。






BlocksMap

从以上fsimage中加载如namenode内存中的信息中可以很明显的看出，在fsimage中，并没有记录每一个block对应到哪几个datanodes的对应表信息，而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储，而是在所有datanode启动时，每个datanode对本地磁盘进行扫描，将本datanode上保存的block信息汇报给namenode，namenode在接收到每个datanode的块信息汇报后，将接收到的块信息，以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport，而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。

BlocksMap的内部数据结构如下：

如上图显示，BlocksMap实际上就是一个Block对象对BlockInfo对象的一个Map表，其中Block对象中只记录了 blockid，block大小以及时间戳信息，这些信息在fsimage中都有记录。而BlockInfo是从Block对象继承而来，因此除了 Block对象中保存的信息外，还包括代表该block所属的HDFS文件的INodeFile对象引用以及该block所属datanodes列表的信息（即上图中的DN1，DN2，DN3，该数据结构会在下文详述）。

因此在namenode启动并加载fsimage完成之后，实际上BlocksMap中的key，也就是Block对象都已经加载到 BlocksMap中，每个key对应的value(BlockInfo)中，除了表示其所属的datanodes列表的数组为空外，其他信息也都已经成功加载。所以可以说：fsimage加载完毕后，BlocksMap中仅缺少每个块对应到其所属的datanodes list的对应关系信息。所缺这些信息，就是通过上文提到的从各datanode接收blockReport来构建。当所有的datanode汇报给namenode的blockReport处理完毕后，BlocksMap整个结构也就构建完成

这么艰涩我居然看完了

好文啊！！！！！！！！！

斑竹：hadoop fsck filename -file -blocks不是可以查看文件对应的块吗？

/user/hive/warehouse/userdb.db/employ/employee1.txt 162 bytes, 1 block(s):  OK
0. BP-907579389-192.168.2.136-1450397645134:blk_1073741856_1032 len=162 repl=2

Status: HEALTHY
Total size:    162 B
Total dirs:    0
Total files:   1
Total symlinks:                0
Total blocks (validated):      1 (avg. block size 162 B)
Minimally replicated blocks:   1 (100.0 %)
Over-replicated blocks:        0 (0.0 %)
Under-replicated blocks:       0 (0.0 %)
Mis-replicated blocks:         0 (0.0 %)
Default replication factor:    2
Average block replication:     2.0
Corrupt blocks:                0
Missing replicas:              0 (0.0 %)
Number of data-nodes:          2
Number of racks:               1
FSCK ended at Sat Dec 19 19:42:19 CST 2015 in 36 milliseconds


BP-1619066087-192.168.2.136-1450190319876为该namenode对应的blockpoolid
blk_1073741864_1040为指定文件对应的BLOCK元数据名称，如果有多个BLOCK会显示多个

tsyzzxq 发表于 2015-12-23 02:36
**** 作者被禁止或删除 内容自动屏蔽 ****

我的怎么没有类似于这一行：
0. BP-907579389-192.168.2.136-1450397645134:blk_1073741856_1032 len=162 repl=2

显示内容如下：
[hadoop@master ~]$ hadoop fsck /user/hadoop/sort/data -file -blocks
FSCK started by hadoop from /192.168.80.100 for path /user/hadoop/sort/data at Thu May 19 11:50:53 CST 2016
.Status: HEALTHY
Total size: 36 B
Total dirs: 0
Total files: 1
Total blocks (validated): 1 (avg. block size 36 B)
Minimally replicated blocks: 1 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks:  0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks:  0
Missing replicas:  0 (0.0 %)
Number of data-nodes:  4
Number of racks:  1
FSCK ended at Thu May 19 11:50:53 CST 2016 in 1 milliseconds


The filesystem under path '/user/hadoop/sort/data' is HEALTHY

又看了一遍