关于hdfs分片和分块

1.分块

从2.7.3版本开始，block size由64 MB变成了128 MB的。

在分布式的HDFS集群上，Hadoop系统保证一个块存储在一个datanode上。

HDFS的namenode只存储整个文件系统的元数据镜像，这个镜像由配置dfs.name.dir指定，datanode则存有文件的metainfo和具体的分块，存储路径由dfs.data.dir指定。

2.分片

由InputFormat这个接口来定义的，其中有个getSplits方法。这里有一个新的概念：fileSplit。每个map处理一个fileSplit，所以有多少个fileSplit就有多少个map（map数并不是单纯的由用户设置决定的）。

我们来看一下hadoop分配splits的源码：

//分片期望值大小 = 总的文件大小/分片数量
long goalSize = totalSize / (numSplits == 0 ? 1 : numSplits);
//最小分片数量
long minSize = Math.max(job.getLong("mapred.min.split.size", 1), minSplitSize);
 
 //文件读取过程
for (FileStatus file: files) {
  Path path = file.getPath();
  FileSystem fs = path.getFileSystem(job);
  if ((length != 0) && isSplitable(fs, path)) { 
    long blockSize = file.getBlockSize();
    long splitSize = computeSplitSize(goalSize, minSize, blockSize);
    
    long bytesRemaining = length;
    while (((double) bytesRemaining)/splitSize > SPLIT_SLOP) {
      String[] splitHosts = getSplitHosts(blkLocations,length-bytesRemaining, splitSize, clusterMap);
      splits.add(new FileSplit(path, length-bytesRemaining, splitSize, splitHosts));
      bytesRemaining -= splitSize;
    }
 
    if (bytesRemaining != 0) {
      splits.add(new FileSplit(path, length-bytesRemaining, bytesRemaining, blkLocations[blkLocations.length-1].getHosts()));
    }
  } else if (length != 0) {
    String[] splitHosts = getSplitHosts(blkLocations,0,length,clusterMap);
    splits.add(new FileSplit(path, 0, length, splitHosts));
  } else { 
    //Create empty hosts array for zero length files
    splits.add(new FileSplit(path, 0, length, new String[0]));
  }
}
 
return splits.toArray(new FileSplit[splits.size()]);
 //分片核心函数
protected long computeSplitSize(long goalSize, long minSize, long blockSize) {
	//分片大小的决定性公式：max（最小分片大小，min(期望分片大小，块的大小)）
    return Math.max(minSize, Math.min(goalSize, blockSize));
}

totalSize：是整个Map-Reduce job所有输入的总大小。

numSplits：来自job.getNumMapTasks()，即在job启动时用org.apache.hadoop.mapred.JobConf.setNumMapTasks(int n)设置的值，给M-R框架的Map数量的提示。

goalSize：是输入总大小与提示Map task数量的比值，即期望每个Mapper处理多少的数据，仅仅是期望，具体处理的数据数由下面的computeSplitSize决定。

minSplitSize：默认为1，可由子类复写函数protected void setMinSplitSize(long minSplitSize) 重新设置。一般情况下，都为1，特殊情况除外。

minSize：取的1和mapred.min.split.size中较大的一个。

blockSize：HDFS的块大小，默认为64M，一般大的HDFS都设置成128M。

splitSize：就是最终每个Split的大小，那么Map的数量基本上就是totalSize/splitSize。

接下来看看computeSplitSize的逻辑：首先在goalSize（期望每个Mapper处理的数据量）和HDFS的block size中取较小的，然后与mapred.min.split.size相比取较大的。

3.hdfs小文件解决方案

对于小文件问题，Hadoop本身也提供了几个解决方案，分别为：Hadoop Archive，Sequence file和CombineFileInputFormat。

（1） Hadoop Archive

Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。

对某个目录/foo/bar下的所有小文件存档成/outputdir/ zoo.har：

hadoop archive -archiveName zoo.har -p /foo/bar /outputdir

当然，也可以指定HAR的大小(使用-Dhar.block.size)。

HAR是在Hadoop file system之上的一个文件系统，因此所有fs shell命令对HAR文件均可用，只不过是文件路径格式不一样，HAR的访问路径可以是以下两种格式：

har://scheme-hostname:port/archivepath/fileinarchive

har:///archivepath/fileinarchive(本节点)

可以这样查看HAR文件存档中的文件：

hadoop dfs -ls har:///user/zoo/foo.har

输出：

har:///user/zoo/foo.har/hadoop/dir1

har:///user/zoo/foo.har/hadoop/dir2

使用HAR时需要两点，第一，对小文件进行存档后，原文件并不会自动被删除，需要用户自己删除；第二，创建HAR文件的过程实际上是在运行一个mapreduce作业，因而需要有一个hadoop集群运行此命令。

此外，HAR还有一些缺陷：第一，一旦创建，Archives便不可改变。要增加或移除里面的文件，必须重新创建归档文件。第二，要归档的文件名中不能有空格，否则会抛出异常，可以将空格用其他符号替换(使用-Dhar.space.replacement.enable=true 和-Dhar.space.replacement参数)。

（2） Sequence file

sequence file由一系列的二进制key/value组成，如果为key小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。

Hadoop-0.21.0中提供了SequenceFile，包括Writer，Reader和SequenceFileSorter类进行写，读和排序操作。如果hadoop版本低于0.21.0的版本，实现方法可参见(3)。

（3）CombineFileInputFormat

CombineFileInputFormat是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。

分享我之前的一个笔记：
问题：默认情况下，TextInputFormat对任务的切片是按照文件规划切片的，一个map对应一个切片，当小文件很多时，会产生很多maptask，处理效率很低。
解决：最好的办法：使用数据处理的最前端，将小文件先合并成大文件，再上传到HDFS后续分析。
补救策略：如果小文件已经在HDFS中了，可以使用另一个InpuFormat来切片（CombinerInputFormat），他的切片逻辑和FileInputFormat不同，它可以将多个小文件规划到同一个切片中，这样将小文件交给maptask。

setMaxInputSplitSize（）//设置文件的最大可以是4M
setMinInputSplitSize（）//设置文件的最小可以是2M
故很多的小文件交给mptask时大小为2M-4M之间

参考博客：
https://blog.csdn.net/xueyao0201/article/details/80591904
https://blog.csdn.net/lisongjia123/article/details/78837009
https://blog.csdn.net/ZG_24/article/details/80635056
https://blog.csdn.net/huangjin0507/article/details/51798629