HDFS小文件处理

缺点：

• 存储层面：1个文件块，占用namenode多大内存150字节

128G能存储多少文件块？ 128 g* 1024m1024kb1024byte/150字节 = 9.1亿文件块

每个小文件都有一份元数据，其中包括文件路径，文件名，所有者，所属组，权限，创建时间等，这些信息都保存在Namenode内存中。所以小文件过多，会占用Namenode服务器大量内存，影响Namenode性能和使用寿命

• 计算层面：每个小文件都会起到一个MapTask，1个MapTask默认内存1G。浪费资源

默认情况下MR会对每个小文件启用一个Map任务计算，非常影响计算性能。同时也影响磁盘寻址时间

解决方法：

• 采用har归档方式，将小文件归档

将多个小文件打包成一个后缀为.har文件

类似于window里的压缩包，对外是一个整体

• 采用CombineTextInputFormat

将多个小文件从逻辑上规划到一个切片中，交给一个 MapTask 处理。

• 小文件场景开启JVM重用；如果没有小文件，不要开启JVM重用，因为会一直占用使用到的task卡槽，直到任务完成才释放。

Hadoop里每个task任务的执行都会启动JVM进程来运行。

启动一个新的JVM进程将耗时1秒左右，对于运行时间较长（比如1分钟以上）的job影响不大，但如果都是时间很短的task，那么频繁启停JVM会有开销。

注意：JVM重用技术不是指同一Job的两个或两个以上的task可以同时运行于同一JVM上，而是排队按顺序执行。
eg：开始3s。运行小文件的任务1s。结束3s。然后在重复这样处理小文件。

Hadoop中有个参数是mapred.job.reuse.jvm.num.tasks，默认是1，表示一个JVM上最多可以顺序执行的task数目（属于同一个Job）是1。也就是说一个task启一个JVM。

一个tasktracker最多可以同时运行的task数目由mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum决定，并且这两个参数在mapred-site.xml中设置。默认是2，注意这个数字指的是同一个job的task数量。

如果task属于不同的job，那么JVM重用机制无效，不同job的task需要不同的JVM来运行。

​ JVM重用可以使得JVM实例在同一个job中重新使用N次，N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间

<property>
    <name>mapreduce.job.jvm.numtasks</name>
    <value>10</value>
    <description>How many tasks to run per jvm,if set to -1 ,there is  no limit</description>
</property>