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, 测试数据表可用性.
删除旧文件.
标签：文件,运维,HDFS,合并,Hadoop,hive,---,文件夹,NameNode From： https://www.cnblogs.com/xieqisheng666/p/16963853.html