本篇文章从小文件过多造成的影响展开，详细介绍了 HDFS 中元数据 fsimage 获取方式，分析元数据的数据库选型，以及小文件分析的全过程实践。

背景介绍

线上生产环境 Hadoop 集群通常会产生大量的小文件，影响了 NameNode 性能以及租户程序的运行。由于租户数量太多，业务流程各不相同，很难去针对性的解决小文件问题，所以我们希望找到产生小文件较多的目录和租户，从而针对某一租户的业务去进行优化。

大量的小文件带来的影响主要有 3 点：

（1）HDFS 中的每个目录，文件和块都表示为 NameNode 内存中的对象，如果小文件过多，会占用大量内存，单台 NameNode 受限于内存无法存储更多的数据；

（2） 重新启动时，它必须从本地磁盘上的缓存中读取每个文件的元数据，这意味要从磁盘读取大量的数据，会导致启动时间延迟；

（3）NameNode 必须不断跟踪并检查集群中每个数据块的存储位置，这是通过监听数据节点来报告其所有数据块来完成的，块越多消耗的网络带宽越大。而且在读取大量小文件的时候，每次读写文件都需要先从 namenode 获取文件元数据信息，然后与 datanode 建立连接进行寻址，这种访问方式会严重影响性能，增加集群负载。

因此，通过小文件分析，我们能更方便的定位到可能存在问题某个租户或程序，加快处理小文件的效率，并且通过每日采集分析，使运维人员对集群整体的文件情况有全面的了解。

FSImage 文件解析

想要清楚 HDFS 的小文件情况，那对 HDFS 目录和文件的整体分析是必不可少的，而这些信息都存储在元数据中，也就是 fsimage 文件。fsimage 包含 Hadoop 文件系统中的所有目录和文件 idnode 的序列化信息；对于文件来说，包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等；而对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。

我们可以根据 dfs.namenode.name.dir 配置的元数据目录，找到 namenode 对应的 fsimage，由于 fsimage 是经过编码的文件，不能直接查看，需要通过 HDFS 提供的解析工具转为 CSV 格式的文件才能查看。通过下面的指令可以将 fsimage 解析为 csv 格式的文件：

hdfs oiv -p Delimited -i fsimage_xxxxxx -o fsimage.csv

其中-p Delimited 表示转为 csv 格式（也可以选择其他格式，如 xml），-i 表示 fsimage 文件的绝对路径，-o 表示输出文件的绝对路径。

执行后生成的 fsimage.csv 文件，具体内容如下图所示：

其中第一行展示的是 fsimage 中的字段信息：

Path(文件或目录的路径),Replication(副本数),ModificationTime(最近编辑时间),AccessTime(最近访问时间),PreferredBlockSize(默认块大小),BlocksCount(Block 数量),FileSize(文件大小),NSQUOTA(数量配额，限制目录或文件数量),DSQUOTA(空间配额，限制目录大小),Permission(权限),UserName(用户名),GroupName(用户组)。

除了使用 hdfs oiv 命令外，在程序中我们也可以通过如下调用 API 的方式去获取：

OfflineImageViewerPB.run(new String[]{        "-i", inputFile,        "-o", outFilePath,        "-p", "Delimited"});

其中填入的参数与 oiv 命令一致，而使用 OfflineImageViewerPB 接口需要引入 hadoop-hdfs 依赖：

org.apache.hadoophadoop-hdfs${hadoop-version}

数据库选型

有了基本的元数据后，我们需要将数据导入到数据库中进行分析。在数据库的选择方面，我们采用了 ClickHouse 作为分析元数据的数据库。原因有以下几点：

（1）分析 fsimage 属于典型的 OLAP 场景，数据量较大，通常一个 fsimage 文件大小有 10G+，所以选择 OLAP 平台，常见的如 ClickHouse，Hadoop 平台（hive，spark）等；

（2） ClickHouse 是比较轻量级的，从性能，易用性等角度能很好满足我们的需求，而 Hadoop 平台整体部署的成本和运维成本都比较高；

（3）ClickHouse 性能非常好，列式存储，数据压缩，多核计算等特性能够充分利用单台机器的 CPU 和存储资源，使得单节点 ClickHouse 就能满足 fsimage 分析场景。

小文件分析过程

小文件分析的整个过程可分成 4 个步骤：

（1）通过与 NameNode 交互，获取该集群的 fsimage 文件，保存在本地；

（2）将 fsimage 转为 CSV 格式的可读文件；

（3）将 CSV 文件导入 ClickHouse 数据库中；

（4）ClickHouse 执行 sql 分析 fsimage。

在数据导入到 ClickHouse 后，我们主要对原始数据进行了以下分析：

（1）根据 Permission 字段的开头第一位是否为“d”,将数据分为文件和目录两部分；

（2）对于文件部分的数据，按照文件大小 FileSize 和最近访问时间 AccessTime 两个维度进行分类。按文件大小分为 0，0-1MB，1MB-32MB，32MB-64MB，64MB-128MB，128MB-256MB，256MB-512MB，512MB 以上。按访问时间离当前时间的时间差，分为半年以下，半年到一年，一年以上；

（3）对于目录部分的数据，需要对路径进行分层，比如/user 的层级为 1，/user/admin 的层级为 2，然后结合文件数据统计/user 下有多少的子文件，以及统计之前分类的文件大小段和时间段的数量；

（4）最后我们会得到下图所示的一张目录表，这张表中展示的是文件系统中的所有目录信息，包括这个目录下各文件大小分段和时间段的文件数量，块数量，所属用户和用户组等。

通过查询此表，可以完全了解集群目录的整体情况，在此表的基础上进行一些定制化的查询，比如查询根目录就能统计出整个集群的文件总数，小文件数，平均文件大小，冷热数据量等，再比如根据 username 查询某个特定租户的小文件情况等。

总结和思考

至此，整个小文件分析的流程都走完了，但这只是一个基本的实践方式，还有很多细节可以进行完善，下面列出几个可以完善和优化的点。

（1）与 hive 元数据相结合

在生产环境中，Hive 作业由于参数设置不合理或者数据源等问题，经常会出现大量小文件，而 hive 的数据是存储在 HDFS 之上的，所以也可以利用之前的分析结果来查看 hive 表的小文件情况。

我们可以通过 hive metastore 提供的 api，去访问 metastore 获取元数据信息，这些信息包括库名，表名，表路径，分区数等，而表路径就是 HDFS 上的目录，所以我们同样可以获取每张 hive 表所占的小文件个数，甚至是每个分区的小文件个数。

（2）多线程优化

在小文件分析过程中，fsimage 转 csv 文件的步骤是最耗时的，一个 15G 的 fsimage 往往要耗时 40-60 分钟，如果是按天来分析，在分析多个 fsimage 的情况下无法做到数据的及时性。通过后台查看进程资源使用情况，发现这个解析过程大部分时间只在单核跑，并未充分使用多核性能。所以在分析流程上加入多线程，同时分析多个 fsimage 文件可以充分利用物理机的计算资源，大大缩短分析时长。