HDFS 使用类似 Linux 文件目录结构来抽象表示存储的数据结构，使用 inode 来表示目录或文件。
(资料图片)
当你通过 hdfs dfs -copyFromLocal /命令上传一份日志文件，还是使用计算引擎存储临时状态或计算结果，你看见 HDFS 目录上的所有文件，在实际存储时都会被切割加工成一个个的块（默认大小 128M，快还有副本默认 3 个），最后这些 block 的元数据信息会统一存储在 NameNode 中。
1. 什么是 Block
上面所说的块就是我们今天的主角 Block：HDFS 存储数据的基本单元，其核心属性有：
id：唯一标识，long 类型，默认情况下从 1073741824（2 的 30 次方）开始，每创建 1 个 block 自增 1；
blockName：块的名称，字符串 blk_ + id，例如 blk_1073741825、blk_1073741826 等；
numBytes：块的大小，long 类型，通常情况下 <= 128M，小于的原因要么文件本身大小 < 128M 或者是文件对应 blocks 的最后一块；
generationStamp：邮戳信息，long 类型，NameNode 中 GenerationStamp 类负责生成默认从 1000 开始，每创建 1 个 Block 自增 1，用于 DataNode 重新加入集群时检测过时的副本；
bcId：块集合 id 即 文件 inodeId，long 类型，NameNode 中 INodeId 负责生成默认从 16384（2 的 14 次方）开始，根目录 /使用 16385，之后每创建目录或文件自增 1。
2. 从文件到 Block
有的文件只有 1 个 block，有的却有多个，为什么会有多个？内部切割逻辑是什么？
我们假设变量 blockSize 表示 block 默认大小，文件如何切割会有以下 2 种情景：
情景 1：文件大小 <= blockSize
对于大小 <= blockSize 的文件只有 1 个 block。
情景 2：文件大小 > blockSize
对于大小 > blockSize 的文件至少有 2 个 block，block 数量计算可以理解为：(( 文件大小 * / blockSize)).longValue()
3. Block 物理存储
准备工作
为了调研做了一些前期准备工作：
搭建 hadoop 伪分布式集群；
查看 hadoop 集群状态；
上传文件到 HDFS；
查看上传文件元数据信息。
参照 HDFS 官网在本地搭建了伪分布式集群，可使用命令 hdfs dfsadmin -report查看集群状态：
上传本地 697M 的 hadoop 安装文件到 HDFS，通过 hdfs fsck查看文件被切割成 6 个 block：
# 创建 /tmp 目录
hdfs dfs -mkdir /tmp
# 上传文件
hdfs dfs -copyFromLocal /tmp
# 查看是否上传成功
hdfs dfs -ls -h /tmp
# 查看实际的 Block
hdfs fsck /tmp/ -files -locations -blocks
物理存储位置
那 HDFS 实际落盘文件存储在什么地方？
find /tmp -iname "blk_1073741825"
# 输出如下：
#/tmp/hadoop-root/dfs/data/current//current/finalized/subdir0/subdir0/blk_1073741825
cd /tmp/hadoop-root/dfs/data/current//current/finalized/subdir0/subdir0
ls -lh
从上图可以看出前 5 个 block 大小都是 128M，最后一个 block 是 57 M：697 - 128 * 5（MB）和预想的一致，此时还发现每个 block 都会对应 1 个数据文件和 1 个元数据文件，文件命名方式：
block 数据文件命名：blk_ + blockId
block 元数据文件命名：blk_ + blockId + _ + generationStamp + .meta
Block 数据文件验证
那 block 对应的数据文件仅仅是按 128M 大小进行切割吗？HDFS 有没有做其它的处理？
为了一探究竟，首先使用 split 命令按照 128M 大小切割原始的 hadoop 安装文件：
# 按照大小 128M 切割文件，文件切割后：
split -b 128M
# 对切割后的文件计算 md5ls | grep xa | grep -v 'grep' | xargs md5sum
原始文件最终切割成 xaa...xaf 6 个文件，之后计算每个文件的 md5。
现在让我们计算 6 个 block 数据文件的 md5：
ls -lhls | grep blk | grep -Ev 'grep|*.meta' | xargs md5sum复制代码
将上面的两种方式输出的结果进行对比，6 个文件的 md5 分别相等，那么可以说明：HDFS 仅仅是按照 128M blockSize 的大小做了切割。
有趣的实验：128M + 1 个字节的文件有几个 Block ？
如果上传 1 个 128M + 1 个字节的文件后，生成几个 block ？
# 生成 128M + 1 字节的文件，文件大小：128 * 1024 * 1024 + 1 = 134217729
fio -filename=/root/ -direct=1 -ioengine=libaio -bs=4k -size=134217729 -numjobs=1 -iodepth=16 -runtime=1 -thread -rw=write -group_reporting -name="write_test"
# 上传到 hdfs
hdfs dfs -copyFromLocal /tmp
# 查看究竟是几个 block
hdfs fsck /tmp/ -files -locations -blocks
看来 HDFS 切割 block 还是很认真的。
4. 下载 NameNode 元数据信息
NameNode 存储元数据信息的文件前缀为 fsimage_，下面定位下目录：
# 定位目录
find /tmp -iname "fsimage_*"# 定位个最大编号的
fsimagels -alht /tmp/hadoop-root/dfs/name/current/# 进入 home 目录，不要对 hadoop 工作目录造成影响
cd ~# 导出元数据信息到 xml 文件中
hdfs oiv -i /tmp/hadoop-root/dfs/name/current/fsimage_0000000000000000078 -o -p XML# 打开 文件
vim # xml格式化 :%!xmllint --format %
打开 同样可以定位到 block 信息：
最后，大家如果有问题，欢迎留言讨论！
关键词：
