本文深入探讨了Hadoop中文件的物理分块和逻辑划分过程，解释了块大小、复制次数以及如何根据输入格式自定义数据划分。重点分析了Split的概念及其与Block的关系，展示了如何通过配置调整数据的映射任务数量，以及Split如何影响数据本地性和任务分配。此外，文章还详细阐述了记录行形式文本如何被划分到不同Block，以及如何确保Mapper正确处理跨Split的数据，避免不完整数据导致的结果错误。
Hadoop是怎么分块的
<name>dfs.block.size</name>
<value>67108864</value>
<description>The default block size for new files.</description>
</property>
<name>dfs.replication</name>
<value>3</value>
<description>Default block replication.
The actual number of replications can be specified when the file is created.
The default is used if replication is not specified in create time.
</description>
</property>
return Math.max(minSize, Math.min(goalSize, blockSize));
}
splits = JobClient.readSplitFile(splitFile);
} finally {
splitFile.close();
}
numMapTasks = splits.length;
maps = new TaskInProgress[numMapTasks];
Hadoop的初学者经常会疑惑这样两个问题：1.Hadoop的一个Block默认是64M，那么对于一个记录行形式的文本，会不会造成一行记录被分到两个Block当中？2.在把文件从Block中读取出来进行切分时，会不会造成一行记录被分成两个InputSplit，如果被分成两个InputSplit，这样一个InputSplit里面就有一行不完整的数据，那么处理这个InputSplit的Mapper会不会得出不正确的结果？对于上面的两个问题，首先要明确两个概念：Block和InputSplit
因此，以行记录形式的文本，还真可能存在一行记录被划分到不同的Block，甚至不同的DataNode上去。通过分析FileInputFormat里面的getSplits方法，可以得出，某一行记录同样也可能被划分到不同的InputSplit。
数据如何划分？Split如何调度（如何决定处理Split的Map程序应该运行在哪台TaskTracker机器上）？划分后的数据又如何读取？这就是本文所要讨论的问题。
先从一张经典的MapReduce工作流程图出发：
1、运行mapred程序；
2、本次运行将生成一个Job，于是JobClient向JobTracker申请一个JobID以标识这个Job；
3、JobClient将Job所需要的资源提交到HDFS中一个以JobID命名的目录中。这些资源包括JAR包、配置文件、InputSplit、等；
4、JobClient向JobTracker提交这个Job；
5、JobTracker初始化这个Job；
6、JobTracker从HDFS获取这个Job的Split等信息；
7、JobTracker向TaskTracker分配任务；
8、TaskTracker从HDFS获取这个Job的相关资源；
9、TaskTracker开启一个新的JVM；
10、TaskTracker用新的JVM来执行Map或Reduce；
……
对于之前提到的三个问题，这个流程中的几个点需要展开一下。
首先是“数据如何划分”的问题。
在第3步中，JobClient向HDFS提交的资源就包含了InputSplit，这就是数据划分的结果。也就是说，数据划分是在JobClient上完成的。在这里，JobClient会使用指定的InputFormat将输入数据做一次划分，形成若干个Split。
InputFormat是一个interface。用户在启动MapReduce的时候需要指定一个InputFormat的implement。InputFormat只包含了两个接口函数：
InputSplit[] getSplits(JobConf job, int numSplits) throws IOException;
RecordReader<K, V> getRecordReader(InputSplit split, JobConf job, Reporter reporter) throws IOException;
getSplits就是现在要使用的划分函数。job参数是任务的配置集合，从中可以取到用户在启动MapReduce时指定的输入文件路径。而numSplits参数是一个Split数目的建议值，是否考虑这个值，由具体的InputFormat实现来决定。
返回的是InputSplit数组，它描述了所有的Split信息，一个InputSplit描述一个Split。
InputSplit也是一个interface，具体返回什么样的implement，这是由具体的InputFormat来决定的。InputSplit也只有两个接口函数：
long getLength() throws IOException;
String[] getLocations() throws IOException;
这个interface仅仅描述了Split有多长，以及存放这个Split的Location信息（也就是这个Split在HDFS上存放的机器。它可能有多个replication，存在于多台机器上）。除此之外，就再没有任何直接描述Split的信息了。比如：Split对应于哪个文件？在文件中的起始和结束位置是什么？等等重要的特征都没有描述到。
为什么会这样呢？因为关于Split的那些描述信息，对于MapReduce框架来说是不需要关心的。框架只关心Split的长度（主要用于一些统计信息）和Split的Location（主要用于Split的调度，后面会细说）。
而Split中真正重要的描述信息还是只有InputFormat会关心。在需要读取一个Split的时候，其对应的InputSplit会被传递到InputFormat的第二个接口函数getRecordReader，然后被用于初始化一个RecordReader，以解析输入数据。也就是说，描述Split的重要信息都被隐藏了，只有具体的InputFormat自己知道。它只需要保证getSplits返回的InputSplit和getRecordReader所关心的InputSplit是同样的implement就行了。这就给InputFormat的实现提供了巨大的灵活性。
最常见的FileInputFormat（implements InputFormat）使用FileSplit（implements InputSplit）来描述Split。而FileSplit中有以下描述信息：
private Path file; // Split所在的文件
private long start; // Split的起始位置
private long length; // Split的长度，getLength()会返回它
private String[] hosts; // Split所在的机器名称，getLocations()会返回它
然后，配套使用的RecordReader将从FileSplit中获取信息，解析文件名为FileSplit.file的文件中从FileSplit.start到FileSplit.start+FileSplit.length之间的内容。
至于具体的划分策略，FileInputFormat默认为文件在HDFS上的每一个Block生成一个对应的FileSplit。那么自然，FileSplit.start就是对应Block在文件中的Offset、FileSplit.length就是对应Block的Length、FileSplit.hosts就是对应Block的Location。
但是可以设置“mapred.min.split.size”参数，使得Split的大小大于一个Block，这时候FileInputFormat会将连续的若干个Block分在一个Split中、也可能会将一个Block分别划在不同的Split中（但是前提是一个Split必须在一个文件中）。Split的Start、Length都好说，都是划分前就定好的。而Split的Location就需要对所有划在其中的Block的Location进行整合，尽量寻找它们共有的Location。而这些Block很可能并没有共同的Location，那么就需要找一个距离这些Block最近的Location作为Split的Location。
还有CombineFileInputFormat（implements InputFormat），它可以将若干个Split打包成一个，目的是避免过多的Map任务（因为Split的数目决定了Map的数目）。虽然说设置“mapred.min.split.size”参数也可以让FileInputFormat做到这一点，但是FileSplit取的是连续的Block，大多数情况下这些Block可能并不会有共同的Location。
CombineFileInputFormat使用CombineFileSplit（implements InputSplit）来描述Split。CombineFileSplit的成员如下：
private Path[] paths; // 每个子Split对应一个文件
private long[] startoffset; // 每个子Split在对应文件中的起始位置
private long[] lengths; // 每个子Split的长度
private String[] locations; // Split所在的机器名称，getLocations()会返回它
private long totLength; // 所有子Split长度之和，getLength()会返回它
其中前三个数组一定是长度相等并且一一对应的，描述了每一个子Split的信息。而locations，注意它并没有描述每一个子Split，而描述的是整个Split。这是因为CombineFileInputFormat在打包一组子Split时，会考虑子Split的Location，尽量将在同一个Location（或者临近位置）出现的Split打包在一起，生成一个CombineFileSplit。而打包以后的locations自然就是由所有子Split的Location整合而来。
同样，配套使用的RecordReader将从CombineFileSplit中获取信息，解析每一个文件名为CombineFileSplit.paths[i]的文件中从CombineFileSplit.startoffset[i]到CombineFileSplit.startoffset[i]+CombineFileSplit.lengths[i]之间的内容。
具体到划分策略，CombineFileSplit先将输入文件拆分成若干个子Split，每个子Split对应文件在HDFS的一个Block。然后按照“mapred.max.split.size”配置，将Length之和不超过这个值的拥有共同Location的几个子Split打包起来，得到一个CombineFileSplit。最后可能会剩下一些子Split，它们不满足拥有共同Location这个条件，那么打包它们的时候就需要找一个距离这些子Split最近的Location作为Split的Location。
有时候，可能输入文件是不可以划分的（比如它是一个tar.gz，划分会导致它无法解压），这也是设计InputFormat时需要考虑的。可以重载FileInputFormat的isSplitable()函数来告知文件不可划分，或者干脆就从头实现自己的InputFormat。
由于InputSplit接口是非常灵活的，还可以设计出千奇百怪的划分方式。
接下来就是“Split如何调度”的问题。
前面在划分输入数据的时候，不断提到Location这个东西。InputSplit接口中有getLocations()、InputFormat的implement在生成InputSplit的时候需要关心对应Block的Location，并且当多个Block需要放到一个InputSplit的时候还需要对Location做合并。
那么这个Location到底用来做什么呢？它主要就是用来给Split的调度提供参考。
先简单介绍一下JobTracker是怎样将一个Split所对应的Map任务分派给TaskTracker的。在前面的流程图中，第6步JobTracker会从HDFS获取Job的Split信息，这将生成一系列待处理的Map和Reduce任务。JobTracker并不会主动的为每一个TaskTracker划分一个任务子集，而是直接把所有任务都放在跟Job对应的待处理任务列表中。
TaskTracker定期向JobTracker发送心跳，除了保持活动以外，还会报告TaskTracker当前可以执行的Map和Reduce的剩余配额（TaskTracker总的配额由“mapred.tasktracker.map.tasks.maximun”和“mapred.tasktracker.reduce.tasks.maximun”来配置）。如果JobTracker有待处理的任务，TaskTracker又有相应的配额，则JobTracker会在心跳的应答中给JobTracker分配任务（优先分配Map任务）。
在分配Map任务时，Split的Location信息就要发挥作用了。JobTracker会根据TaskTracker的地址来选择一个Location与之最接近的Split所对应的Map任务（注意一个Split可以有多个Location）。这样一来，输入文件中Block的Location信息经过一系列的整合（by InputFormat）和传递，最终就影响到了Map任务的分配。其结果是Map任务倾向于处理存放在本地的数据，以保证效率。
当然，Location仅仅是JobTracker在分配Map任务时所考虑的因素之一。JobTracker在选择任务之前，需要先选定一个Job（可能正有多个Job等待处理），这取决于具体TaskScheduler的调度策略。然后，JobTracker又会优先选择因为失败而需要重试的任务，而重试任务又尽量不要分配到它曾经执行失败过的机器上。
JobTracker在分配Reduce任务时并不考虑Location，因为大部分情况下，Reduce处理的是所有Map的输出，这些Map遍布在Hadoop集群的每一个角落，考虑Location意义不大。
最后就是“划分后的数据如何读取”的问题。
接下来，在前面的流程图的第10步，TaskTracker就要启动一个新的JVM来执行Map程序了。在Map执行的时候，会使用InputFormat.getRecordReader()所返回的RecordReader对象来读取Split中的每一条记录（getRecordReader函数中会使用InputSplit对RecordReader进行初始化）。
咋一看，RecordReader似乎会使用Split的Location信息来决定数据应该从哪里去读。但是事实并非如此。前面也说过，Split的Location很可能是被InputFormat整合过的，可能并不是Block真正的Location（就算是，也没法保证从InputSplit在JobClient上被生成到现在的这段时间之内，Block没有被移动过）。
说白了，Split的Location其实是InputFormat期望这个Split被处理的Location，它完全可以跟实际Block的Location没有半点关系。InputFormat甚至可以将Split的Location定义为“距离Split所包含的所有Block的Location最远的那个Location”，只不过大多数时候我们肯定是希望Map程序在本地就能读取到输入数据的。
所以说，RecordReader并不关心Split的Location，只管Open它的Path。前面说过，RecordReader是由具体的InputFormat创建并返回的，它跟对应的InputFormat所使用的InputSplit必定是配对的。比如，对应于FileSplit，RecordReader要读取FileSplit.file文件中的相应区间、对应于CombineFileSplit，RecordReader要读取CombineFileSplit.paths中的每个文件的相应区间。
RecordReader对一个Path的Open操作由DFSClient来完成，它会向HDFS的NameNode获取对应文件在对应区间上的Block信息：依次有哪些Block、每个Block各自的Location。而要读写一个Block的时候，DFSClient总是使用NameNode返回的第一个Location，除非读写失败才会依次选择后面的Location。
而NameNode在处理Open请求时（getBlockLocations），在得到一个Block有哪些Location之后，会以DFSClient所在的地址为依据，对这些Location进行排序，距离越小的越排在前。而DFSClient又总是会选择排在前面的Location，所以，最终RecordReader会倾向于读取本地的数据（如果有的话）。
但是，不管Block是不是本地的，DFSClient都会向DataNode建立连接，然后请求数据。并不会因为Block是本地的而直接读磁盘上的文件，因为这些文件都是由DataNode来管理的，需要通过DataNode来找到Block所对应的物理文件、也需要由DataNode来协调对文件的并发读写。所以本地与非本地的差别仅仅在于网络传输上，前者是仅仅在本地网络协议栈上面绕一圈、而后者则是真正的网络通讯。在Block离得不远、且网络比较畅通的情况下，非Local并不意味着太大的开销。
所以Hadoop优先追求Map的Data-local，也就是输入数据存放在本地。如果不能满足，则退而求其次，追求Rack-local，也就是输入数据存放在同一机架的其他机器上，这样的话网络开销对性能影响一般不会太大。而如果这两种情况都不能满足，则网络传输可能会带来较大的开销，Hadoop会尽量去避免。这也就是之前提到的，在属于同一Split的Block没有共同Location的情况下，要计算一下离它们最近的Location的原因。
至此，关于InputFormat的数据划分、Split调度、数据读取三个问题就分析完了
============================================================================
http://www.geminikwok.com/2011/07/26/hadoop是怎么分å—çš„/
hadoop的分块有两部分。
第一部分就是数据的划分（即把File划分成Block），这个是物理上的划分，数据文件上传到HDFS里的时候，需要划分成一块一块，每块的大小由hadoop-default.xml里配置选项进行划分（大小不足一块时，便按实际大小存放）：
<property>
<name>dfs.block.size</name>
<value>67108864</value>
<description>The default block size for new files.</description></property>
这里设置的是每个块64MB。
数据划分的时候也可以设置备份的份数：
<property>
<name>dfs.replication</name>
<value>3</value>
<description>Default block replication. The actual number of replications can be specified when the file is created. The default is used if replication is not specified in create time. </description>
</property>
具体的物理划分步骤由Namenode决定，下面hadoop中的第二种划分，用来决定M/R运行时，一个map处理的数据量。
在hadoop中第二种划分是由InputFormat这个接口来定义的，其中有个getSplits方法。这里有一个新的概念：fileSplit。每个map处理一个fileSplit，所以有多少个fileSplit就有多少个map（map数并不是单纯的由用户设置决定的）。
我们来看一下hadoop分配splits的源码：
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) {
int blkIndex = getBlockIndex(blkLocations, length-bytesRemaining);
splits.add(new FileSplit(path, length-bytesRemaining, splitSize, blkLocations[blkIndex].getHosts()));
bytesRemaining -= splitSize; }
if (bytesRemaining != 0) {
splits.add(new FileSplit(path, length-bytesRemaining, bytesRemaining, blkLocations[blkLocations.length-1].getHosts())); }
} else if (length != 0) {
splits.add(new FileSplit(path, 0, length,blkLocations[0].getHosts()));
} else {
//Create empty hosts array for zero length files
splits.add(new FileSplit(path, 0, length, new String[0]));
}
}
从代码可以看出，一个块为一个splits，即一个map，只要搞清楚一个块的大小，就能计算出运行时的map数。而一个split的大小是由goalSize, minSize, blockSize这三个值决定的。computeSplitSize的逻辑是，先从goalSize和blockSize两个值中选出最小的那个（比如一般不设置map数，这时blockSize为当前文件的块size，而goalSize是文件大小除以用户设置的map数得到的，如果没设置的话，默认是1），在默认的大多数情况下，blockSize比较小。然后再取bloceSize和minSize中最大的那个。而minSize如果不通过”mapred.min.split.size”设置的话（”mapred.min.split.size”默认为0），minSize为1，这样得出的一个splits的size就是blockSize，即一个块一个map，有多少块就有多少map。
上面说的是splitable的情况，unsplitable可以根据实际情况来计算，一般为一个文件一个map。
下面是摘自网上的一个总结：
几个简单的结论：
1. 一个split不会包含零点几或者几点几个Block，一定是包含大于等于1个整数个Block
2. 一个split不会包含两个File的Block,不会跨越File边界
3. split和Block的关系是一对多的关系
4. maptasks的个数最终决定于splits的长度
还有一点需要说明，在FileSplit类中，有一项是private String[] hosts;
看上去是说明这个FileSplit是放在哪些机器上的，实际上hosts里只是存储了一个Block的冗余机器列表。
比如有个fileSplit 有4个block: Block11, Block12, Block13,Block14,这个FileSplit中的hosts里最终存储的是Block11本身和其备份所在的机器列表，也就是说 Block12,Block13,Block14存在哪些机器上没有在FileSplit中记录。
FileSplit中的这个属性有利于调度作业时候的数据本地性问题。如果一个tasktracker前来索取task，jobtracker就会找个 task给他，找到一个maptask，得先看这个task的输入的FileSplit里hosts是否包含tasktracker所在机器，也就是判断 和该tasktracker同时存在一个机器上的datanode是否拥有FileSplit中某个Block的备份。
但总之，只能牵就一个Block，其他Block就要从网络上传。不过对于默认大多数情况下的一个block对应一个map，可以通过修改hosts使map的本地化数更多一些。 在讲block的hosts传给fileSplit时，hosts中的主机地址可以有多个，表示map可以从优先从这些hosts中选取（只是优先，但hdfs还很可能根据当时的网络负载选择不是hosts中的主机起map task）。
知道这个特性之后，可以修改传回给fileSplit的hosts，在列表中只写block所在的那些hosts，这样hdfs就会优先将这些map放到这些hosts上去执行，由于hosts上有该block，就省掉了网络传输数据的时间。
这样做的话，在job很多的时候，可能会出现hot spot，即数据用的越多，它所在hosts上的map task就会越多。所以在考虑修改传给fileSplit的时候要考虑平衡诸多因素
============================================================================
Hadoop的初学者经常会疑惑这样两个问题：1.Hadoop的一个Block默认是64M，那么对于一个记录行形式的文本，会不会造成一行记录被分到两个Block当中？2.在把文件从Block中读取出来进行切分时，会不会造成一行记录被分成两个InputSplit，如果被分成两个InputSplit，这样一个InputSplit里面就有一行不完整的数据，那么处理这个InputSplit的Mapper会不会得出不正确的结果？对于上面的两个问题，首先要明确两个概念：Block和InputSplit
因此，以行记录形式的文本，还真可能存在一行记录被划分到不同的Block，甚至不同的DataNode上去。通过分析FileInputFormat里面的getSplits方法，可以得出，某一行记录同样也可能被划分到不同的InputSplit。
[java]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
对文件进行切分，splitSize
FileInputFormat对文件的切分是严格按照偏移量来的，因此一行记录比较长的话，其可能被切分到不同的InputSplit。但这并不会对Map造成影响，尽管一行记录可能被拆分到不同的InputSplit，但是与FileInputFormat关联的RecordReader被设计的足够健壮，当一行记录跨InputSplit时，其能够到读取不同的InputSplit，直到把这一行记录读取完成，在Hadoop里，记录行形式的文本，通常采用默认的TextInputFormat，TextInputFormat关联的是LineRecordReader，下面我们来看看LineRecordReader的的nextKeyValue方法里读取文件的代码：
[java]
43
44
45
46
47
48
[java]
49
50
51
52
53
54
55
56
57
58
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
while
newlineLength==0则以为一次do-while循环中读取的内容中没有遇到换行符，因maxBytesToConsume的默认值为Integer.MAX_VALUE，所以如果读取的内容没有遇到换行符，则会一直读取下去，知道读取的内容超过maxBytesToConsume。这样的出来方式，解决了一行记录跨InputSplit的读取问题，同样也会造成下面两个疑问：
1.既然在LineReader读取方法里面没有对考虑InputSplit的end进行处理，难道读取一个InputSplit的时候，会这样无限的读取下去么？
2.如果一行记录L跨越了A,B两个InputSplit，读A的时候已经读取了跨越A，B的这条记录L，那么对B这个InputSplit读取的时候，如果做到不读取L这条记录在B中的部分呢？
为了解决这两个问题，Hadoop通过下面的代码来做到：LineRecordReader的nextKeyValue方法。
[java]
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
[java]
143
144
145
146
147
148
149
扫一扫
1095
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
