标签：文件 存储 为啥 懂吗 集群 blocksize namenode block
小文件是 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 内核的吞吐量降低。
简单总结一下：小文件对于计算的影响就是需要大量节点之间频繁建立联系，数据传输等，浪费资源，消耗时间长。其次小文件相关大量的任务初始化时间甚至比计算时间还长，造成计算资源的使用浪费，降低集群的吞吐量。
后续请见小文件多维度治理....................
标签：文件,存储,为啥,懂吗,集群,blocksize,namenode,block 来源： https://blog.csdn.net/qq_26442553/article/details/117444740
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。