vlambda博客
学习文章列表

背景介绍

线上生产环境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文件可以充分利用物理机的计算资源，大大缩短分析时长。

-  END -

关于本周文章如果大家有疑问，或者有其他感兴趣的大数据内容，欢迎大家在评论区留言，后续会持续分享大数据领域的干货知识~