写点什么

HDFS 小文件分析实践

  • 2022 年 4 月 20 日
  • 本文字数:2562 字

    阅读完需:约 8 分钟

本篇文章从小文件过多造成的影响展开,详细介绍了 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 文件可以充分利用物理机的计算资源,大大缩短分析时长。

用户头像

移动云,5G时代你身边的智慧云 2019.02.13 加入

移动云大数据产品团队,在移动云上提供云原生大数据分析LakeHouse,消息队列Kafka/Pulsar,云数据库HBase,弹性MapReduce,数据集成与治理等PaaS服务。

评论

发布
暂无评论
HDFS小文件分析实践_hdfs_移动云大数据_InfoQ写作社区