vlambda博客
学习文章列表

HDFS小文件分析实践

 本文作者为中国移动云能力中心大数据团队软件开发工程师景泓斐,本篇文章从小文件过多造成的影响展开,详细介绍了HDFS中元数据fsimage获取方式,分析元数据的数据库选型,以及小文件分析的全过程实践




01



背景介绍



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


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

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

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

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


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




02



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文件,具体内容如下图所示:

HDFS小文件分析实践


其中第一行展示的是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}





03



数据库选型




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

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

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

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


HDFS小文件分析实践





04



小文件分析过程




小文件分析的整个过程可分成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查询某个特定租户的小文件情况等。





05



总结和思考




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

(1)与hive元数据相结合

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

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

(2)多线程优化

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






-  END -


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