Hadoop 集群运维的思考---(1)小文件优化

1小文件优化的驱动力

1.1NN 内存和HDFS文件的数量关系计算.

 一般来说, NameNode管理文件File、目录Directory、块Block对象, 每一个对象的大小约在150 B.大小.

 假设有一个192MB的文件, 它会切分称128M+64M, 就会有2个block 文件+ 1个文件对象, 占用大约450B的空间. 

 如果128个1M的文件会占据 256(128文件+128块)对象需要36M左右的内存.

1.2对NameNode的影响.

 NameNode启动时间变长、性能下降.

 NameNode JVM FGC 风险高.

2小文件的产生

2.1HDFS中的原数据

 举个例子, Spark写入业务数据到HDFS , 业务有忙闲之分, 但是控制程序如果写的不好, 那么在忙的时候, 业务产生的数据,可能是300M*10份, 而过了峰值以后, 就可能会产生10M*10份的数据.显然后者就是小文件.

2.2Hive 表运算产生

比如MR 任务中, reducer配置较大, 会输出很多小文件.

2.3YARN job history log.

每个任务都会有日志文件, 这些日志文件大小不一, 有的可能不足1M.

 

3小文件优化的办法

3.1找到“有小文件”的文件夹

l平均文件size越小越好

l文件数量越多越好

 

 HDFS目录路径格式如下: 

/hive/warehouse/<DB名>/<表名>/<分区名> ；

/hbase/<表名> ；

 

首先计算TOPN占据存储的文件夹,当平均文件<30M时,需要关注这个文件夹, 是小文件数多的文件夹.同时需要注意,当文件个数较少时, 比如第三行,那么也无需做小文件合并.

 

 

TOPN 大的文件夹

文件夹名称	文件大小	文件个数	块个数	平均文件大小
/hive/test	312TB	6563901	6595185	50M
/hive/db1	190T	39723117	46103517	5M
/hbase/cloumn	10G	356	270	27M

 

 

3.2小文件合并的方法和工具

1、不常用的数据表,使用HAR压缩

 

 提供用户配置HAR压缩策略:

1)输入不常用文件夹/目录列表 2) 输入指定日期,在该日期之前的数据均可压缩成HAR

 当满足以上策略时,系统自动运行结果.

 

2、开发合并小工具

 

根据实际生产情况, 可以针对按照日期来分区的Hive表, 开发如下小工具.

 

用户输入需要合并的hive /db /表名称

用户输入分区 开始时间-结束时间.

 

给出合并的结果: 总计文件数/合并后的文件数/ 参与合并的分区数/节约的存储空间

 

给出合并后的检查: 合并前的entry count /合并后的entry count, 测试数据表可用性.

 

删除旧文件.