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 信息：

最后，大家如果有问题，欢迎留言讨论！

关键词：