为啥集群小文件治理那么重要，你真的懂吗？

Posted 2021-10-20 涤生手记

        小文件是 Hadoop 集群运维中的常见挑战，尤其对于大规模运行的集群来说可谓至关重要。如果处理不好，可能会导致许多并发症。Hadoop集群本质是为了TB,PB规模的数据存储和计算因运而生的。为啥大数据开发都说小文件的治理重要，说HDFS 存储小文件效率低下，比如增加namenode负载等，降低访问效率等？究竟本质上为什么重要？以及如何从本质上剖析小文件，治理小文件呢？今天就带你走进小文件的世界。

 1.什么是小文件？

       日常生产中HDFS上小文件产生是一个很正常的事情，有些甚至是不可避免，比如jar，xml配置文件，tmp临时文件，流式任务等都是小文件的组成部分。当然更多的是因为集群设置不合理，造成一些意料之外的小文件产生。实际公司生产中对于小文件的大小没有一个统一的定义。一般公司集群的blocksize的大小在128/256两者居多。首先小文件大小肯定是要远小于blocksize的文件。一般公司小文件的大小定义如1Mb，8Mb,甚至16Mb，32Mb更大。根据公司实际集群状态定义，因为有些情况合并小文件需要消耗额外的资源。

      既然剖析小文件，那么不可避免的要先剖析hdfs的存储原理。众多周知了，HDFS上文件的数据存储分为namenode元数据管理和实际数据文件。hdfs上的数据文件被拆分成块block，这些块block在整个集群中的datanode的本地文件系统上存储和复制，每个块也维护者自己的blockmeta信息。namenode主要维护这些文件的元数据信息，具体namenode的解析参考我的其他博客。

如下一个某个文件的某个block在data上存储的情况。

2.小文件的产生

1.流式数据，如flume,kafak,sparkstreaming,storm,flink等，流式增量文件，小窗口文件，如几分钟一次等。

2.MapReduce引擎任务：如果纯map任务，大量的map；如果mapreduce任务，大量的reduce；两者都会造成大量的文件。出现这种情况的原因很多，果分布表的过度分区，输入大量的小文件，参数设置的不合理等，输出没有文件合并等。

3.spark任务过度并行化，Spark 分区越多，写入的文件就越多。

4.文件的压缩与存储格式不合理；一般生产公司很少使用textfile这种低效的文件格式了。

使用压缩，降低文件的大小，同时也会降低文件的总块数。注意文件存储格式和压缩不合理只是加剧小文件问题，不是产生小文件的本质。

3.小文件的危害

3.1小文件对namenod的影响

如下图1，一个文件192Mb，默认blocksize=128Mb，副本个数为3,存储为2个block。

 如下图2,同样一个文件192Mb，默认blocksize=128Mb，副本个数为3,存储为192个block

      namenode的namespace中主要占存储对象是文件的目录个数，文件（文件名长度）以及文件block数。根据namenode实际使用经验来看，一个存储对象大概占用150字节的空间。HDFS上存储文件占用的namenode内存计算公式如下：

       Memory=150bytes*(1个文件inode+(文件的块数*副本个数))

     如上图1 ，一个文件192Mb，默认blocksize=128Mb，副本个数为3,存储为2个block,需要namenode内存=150*（1+2*3）=1050  Bytes

     同理，图2 一个文件192Mb，默认blocksize=128Mb，副本个数为3,存储为192个block，需要namenode内存=150 x (192 + (192 x 3)) = 115200 Bytes

尖叫总结：

1 .从上面可以看出，同样的一个文件，大小不同形态的存储占用namenode的内存之比相差了109倍之多。所以如果对于单namenode的集群来说，大量的小文件的会占用大量的namenode堆内存空间，给集群的存储造成瓶颈。有些人可能会说我们联邦，多组namenode不就没有这个问题了，其实不然，且往下看

2.当 NameNode 重新启动时(虽然生产上这种情况很少)，它必须将文件系统元数据fsimage从本地磁盘加载到内存中。这意味着如果 namenode 元数据很大，重启会更慢（以我们公司3亿block，5万多个文件对象来说，重启一次1.5小时，期间应用不可用）其次，datanode 还通过网络向 NameNode 报告块更改；更多的块意味着要通过网络报告更多的变化，等待时间更长。

3.更多的文件，更多的block,意味着更多的读取请求需要由 NameNode 提供服务,这将增加 RPC 队列和处理延迟，进而导致namenode性能和响应能力下降。官方介绍说接近 40K~50K RPCs/s 人为是极高的负载。实际使用来看比这低时对于namenode来说性能都会打很大的折扣。

3.2 小文件对datanode影响

      文件的block存储是存储在datanode本地系统上，底层的磁盘上，甚至不同的挂载目录，不同的磁盘上。大量的小文件，意味着数据着寻址需要花费很多时间，尤其对于高负载的集群来说，磁盘使用率50%以上的集群，花费在寻址的时间比文件读取写入的时间更多。这种就违背了blocksize大小设计的初衷（实践显示最佳效果是：寻址时间仅占传输时间的1%）。这样会造成磁盘的读写会很慢，拥有大量小文件会导致更多的磁盘搜索。如下磁盘延迟：

3.3小文件对计算的影响

        基于HDFS文件系统的计算，blokc块是最小粒度的数据处理单元。块的多少往往影响应用程序的吞吐量。更多的文件，意味着更多的块，以及更多的节点分布。

        比如以MapReduce任务为例（hive等），在 MapReduce 中，会为每个读取的块生成一个单独的 Map 任务，如果大量小文件，大量的块，意味着着更多任务调度，任务创建开销，以及更多的任务管理开销（MapReduce 作业的 application master 是一个 Java 应用，它的主类是 MRAppMaster。它通过创建一定数量的bookkeeping object跟踪作业进度来初始化作业，该对象接受任务报告的进度和完成情况）。虽然可以开启map前文件合并，但是这也需要不停地从不同节点建立连接，数据读取，网络传输，然后进行合并，同样会增加消耗资源和增加计算时间，成本也很高。

      同样，如果是spark计算引擎，executor的一次读取和处理一个分区，默认情况下，每个分区是一个 HDFS 块，如果大量的小文件，每个文件都在不同的分区中读取，这将导致大量的任务调度开销，同时每个 CPU 内核的吞吐量降低。

     简单总结一下：小文件对于计算的影响就是需要大量节点之间频繁建立联系，数据传输等，浪费资源，消耗时间长。其次小文件相关大量的任务初始化时间甚至比计算时间还长，造成计算资源的使用浪费，降低集群的吞吐量。

     后续请见小文件多维度治理....................

   大多数开发人员都弄错的Hive与MapReduce小文件合并问题