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中的第二种划分。
在hadoop中第二种划分是由InputFormat这个接口来定义的，其中有个getSplits方法。这里就有了一个新的不为人熟知的概念：Split。Split的作用是什么，Split和Block是什么关系，下面就可以说明清楚。
在Hadoop0.1中，split划分是在JobTracker端完成的，发生在JobInitThread对JobInProgress调用inittasks()的时候；而在0.18.3中是由JobClient完成的，JobClient划分好后，把split.file写入hdfs里，到时候jobtracker端只需要读这个文件，就知道Split是怎么划分的了。
第二种划分只是一种逻辑上划分，目的是为了让Map Task更好的获取数据输入，仔细分析如下这个场景：
File 1 : Block11, Block 12, Block 13, Block 14, Block 15
File 2 : Block21, Block 22, Block 23
File1有5个Block，最后一个Block当然可能小于64MB；File2有3个Block
如果用户在程序中指定map tasks的个数，比如说是2（如果不指定的话maptasks个数默认是1），那么在
FileInputFormat(最常见的InputFormat实现）的getSplits方法中，首先会计算totalSize=8(可以对照源码看看，注意getSplits这个函数里的计量单位是Block个数，而不是Byte个数，后面有个变量叫bytesremaining仍然表示剩余的Block个数，有些变量名让人无语），然后会计算goalSize=totalSize/numSplits=4，对于File1，计算一个Split有多少个Block是这样计算的
long splitSize = computeSplitSize(goalSize, minSize, blockSize);
protected long computeSplitSize(long goalSize, long minSize, long blockSize) {
return Math.max(minSize, Math.min(goalSize, blockSize));
}
这里minSize是1（说明了一个Split至少包含一个Block，不会出现一个Split包含零点几个Block的情况），计算得出splitSize=4,所以接下来Split划分是这样分的：
Split 1: Block11, Block12, Block13,Block14
Split 2: Block15
Split 3: Block21, Block22, Block23
那用户指定的map个数是2，出现了三个split怎么办？在JobInProgress里其实maptasks的个数是根据Splits的长度来指定的，所以用户指定的map个数只是个参考。可以参看JobInProgress: initTasks()
里的代码：
try {
splits = JobClient.readSplitFile(splitFile);
} finally {
splitFile.close();
}
numMapTasks = splits.length;
maps = new TaskInProgress[numMapTasks];
所以问题就很清晰了，还如果用户指定了20个map作业，那么最后会有8个Split（每个Split一个Block），所以最后实际上就有8个MapTasks，也就是说maptask的个数是由splits的长度决定的。
几个简单的结论：
1. 一个split不会包含零点几或者几点几个Block，一定是包含大于等于1个整数个Block
2. 一个split不会包含两个File的Block,不会跨越File边界
3. split和Block的关系是一对多的关系
4. maptasks的个数最终决定于splits的长度
还有一点需要说明，在FileSplit类中，有一项是private String[] hosts;
看上去是说明这个FileSplit是放在哪些机器上的，实际上hosts里只是存储了一个Block的冗余机器列表。
比如上面例子中的Split 1: 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就从网络上传罢。
Hadoop的初学者经常会疑惑这样两个问题：1.Hadoop的一个Block默认是64M，那么对于一个记录行形式的文本，会不会造成一行记录被分到两个Block当中？2.在把文件从Block中读取出来进行切分时，会不会造成一行记录被分成两个InputSplit，如果被分成两个InputSplit，这样一个InputSplit里面就有一行不完整的数据，那么处理这个InputSplit的Mapper会不会得出不正确的结果？对于上面的两个问题，首先要明确两个概念：Block和InputSplit
1. block是hdfs存储文件的单位（默认是64M）；
2. InputSplit是MapReduce对文件进行处理和运算的输入单位，只是一个逻辑概念，每个InputSplit并没有对文件实际的切割，只是记录了要处理的数据的位置（包括文件的path和hosts）和长度（由start和length决定）。
因此，以行记录形式的文本，还真可能存在一行记录被划分到不同的Block，甚至不同的DataNode上去。通过分析FileInputFormat里面的getSplits方法，可以得出，某一行记录同样也可能被划分到不同的InputSplit。
============================================================================ 在执行一个Job的时候，Hadoop会将输入数据划分成N个Split，然后启动相应的N个Map程序来分别处理它们。
数据如何划分？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调度、数据读取三个问题就分析完了
============================================================================
、
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
1. block是hdfs存储文件的单位（默认是64M）；
2. InputSplit是MapReduce对文件进行处理和运算的输入单位，只是一个逻辑概念，每个InputSplit并没有对文件实际的切割，只是记录了要处理的数据的位置（包括文件的path和hosts）和长度（由start和length决定）。
因此，以行记录形式的文本，还真可能存在一行记录被划分到不同的Block，甚至不同的DataNode上去。通过分析FileInputFormat里面的getSplits方法，可以得出，某一行记录同样也可能被划分到不同的InputSplit。
1 publicList getSplits(JobContext job) throwsIOException {
2 longminSize = Math.max(getFormatMinSplitSize(), getMinSplitSize(job));
3 longmaxSize = getMaxSplitSize(job);
4
5 // generate splits
6 List splits = newArrayList();
7 List files = listStatus(job);
8 for(FileStatus file: files) {
9 Path path = file.getPath();
10 longlength = file.getLen();
11 if(length != 0) {
12 FileSystem fs = path.getFileSystem(job.getConfiguration());
13 BlockLocation[] blkLocations = fs.getFileBlockLocations(file, 0, length);
14 if(isSplitable(job, path)) {
15 longblockSize = file.getBlockSize();
16 longsplitSize = computeSplitSize(blockSize, minSize, maxSize);
17
18 longbytesRemaining = length;
19 while(((double) bytesRemaining)/splitSize > SPLIT_SLOP) {
20 intblkIndex = getBlockIndex(blkLocations, length-bytesRemaining);
21 splits.add(makeSplit(path, length-bytesRemaining, splitSize,
22 blkLocations[blkIndex].getHosts()));
23 bytesRemaining -= splitSize;
24 }
25
26 if(bytesRemaining != 0) {
27 splits.add(makeSplit(path, length-bytesRemaining, bytesRemaining,
28 blkLocations[blkLocations.length-1].getHosts()));
29 }
30 } else{ // not splitable
31 splits.add(makeSplit(path, 0, length, blkLocations[0].getHosts()));
32 }
33 } else{
34 //Create empty hosts array for zero length files
35 splits.add(makeSplit(path, 0, length, newString[0]));
36 }
37 }
38 // Save the number of input files for metrics/loadgen
39 job.getConfiguration().setLong(NUM_INPUT_FILES, files.size());
40 LOG.debug("Total # of splits: " splits.size());
41 returnsplits;
42 }从上面的代码可以看出，对文件进行切分其实很简单：获取文件在HDFS上的路径和Block信息，然后根据splitSize
对文件进行切分，splitSize = computeSplitSize(blockSize, minSize, maxSize);blockSize，minSize，maxSize都可以配置，默认splitSize 就等于blockSize的默认值（64m）。
FileInputFormat对文件的切分是严格按照偏移量来的，因此一行记录比较长的话，其可能被切分到不同的InputSplit。但这并不会对Map造成影响，尽管一行记录可能被拆分到不同的InputSplit，但是与FileInputFormat关联的RecordReader被设计的足够健壮，当一行记录跨InputSplit时，其能够到读取不同的InputSplit，直到把这一行记录读取完成，在Hadoop里，记录行形式的文本，通常采用默认的TextInputFormat，TextInputFormat关联的是LineRecordReader，下面我们来看看LineRecordReader的的nextKeyValue方法里读取文件的代码：
43 while(getFilePosition() <= end) {
44 newSize = in.readLine(value, maxLineLength,
45 Math.max(maxBytesToConsume(pos), maxLineLength));
46 if(newSize == 0) {
47 break;
48 }
其读取文件是通过LineReader（in就是一个LineReader实例）的readLine方法完成的：
[java]view plaincopy
49 publicintreadLine(Text str, intmaxLineLength,
50 intmaxBytesToConsume) throwsIOException {
51 if(this.recordDelimiterBytes != null) {
52 returnreadCustomLine(str, maxLineLength, maxBytesToConsume);
53 } else{
54 returnreadDefaultLine(str, maxLineLength, maxBytesToConsume);
55 }
56 }
57
58
61 privateintreadDefaultLine(Text str, intmaxLineLength, intmaxBytesToConsume)
62 throwsIOException {
63 str.clear();
64 inttxtLength = 0; //tracks str.getLength(), as an optimization
65 intnewlineLength = 0; //length of terminating newline
66 booleanprevCharCR = false; //true of prev char was CR
67 longbytesConsumed = 0;
68 do{
69 intstartPosn = bufferPosn; //starting from where we left off the last time
70 if(bufferPosn >= bufferLength) {
71 startPosn = bufferPosn = 0;
72 if(prevCharCR)
73 bytesConsumed; //account for CR from previous read
74 bufferLength = in.read(buffer);
75 if(bufferLength <= 0)
76 break; // EOF
77 }
78 for(; bufferPosn < bufferLength; bufferPosn) { //search for newline
79 if(buffer[bufferPosn] == LF) {
80 newlineLength = (prevCharCR) ? 2: 1;
81 bufferPosn; // at next invocation proceed from following byte
82 break;
83 }
84 if(prevCharCR) { //CR notLF, we are at notLF
85 newlineLength = 1;
86 break;
87 }
88 prevCharCR = (buffer[bufferPosn] == CR);
89 }
90 intreadLength = bufferPosn - startPosn;
91 if(prevCharCR && newlineLength == 0)
92 --readLength; //CR at the end of the buffer
93 bytesConsumed = readLength;
94 intappendLength = readLength - newlineLength;
95 if(appendLength > maxLineLength - txtLength) {
96 appendLength = maxLineLength - txtLength;
97 }
98 if(appendLength > 0) {
99 str.append(buffer, startPosn, appendLength);
100 txtLength = appendLength;
101 }
102 } while(newlineLength == 0&& bytesConsumed < maxBytesToConsume); "color: #ff0000;">//①
103
104 if(bytesConsumed > (long)Integer.MAX_VALUE)
105 thrownewIOException("Too many bytes before newline: " bytesConsumed);
106 return(int)bytesConsumed;
107 }我们分析下readDefaultLine方法，do-while循环体主要是读取文件，然后遍历读取的内容，找到默认的换行符就终止循环。前面说，对于跨InputSplit的行，LineRecordReader会自动跨InputSplit去读取。这就体现在上述代码的While循环的终止条件上：
while (newlineLength == 0 && bytesConsumed < maxBytesToConsume);
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方法。
108 publicbooleannextKeyValue() throwsIOException {
109 if(key == null) {
110 key = newLongWritable();
111 }
112 key.set(pos);
113 if(value == null) {
114 value = newText();
115 }
116 intnewSize = 0;
117 // We always read one extra line, which lies outside the upper
118 // split limit i.e. (end - 1)
119 while(getFilePosition() <= end) { "color: #ff0000;"> //②
120 newSize = in.readLine(value, maxLineLength,
121 Math.max(maxBytesToConsume(pos), maxLineLength));
122 if(newSize == 0) {
123 break;
124 }
125 pos = newSize;
126 inputByteCounter.increment(newSize);
127 if(newSize < maxLineLength) {
128 break;
129 }
130
131 // line too long. try again
132 LOG.info("Skipped line of size " newSize " at pos "
133 (pos - newSize));
134 }
135 if(newSize == 0) {
136 key = null;
137 value = null;
138 returnfalse;
139 } else{
140 returntrue;
141 }
142 }
通过代码②处得While条件，就保证了InputSplit读取边界的问题，如果存在跨InputSplit的记录，也只好跨InputSplit读取一次。
再来看LineRecordReader的initialize方法：
[java]view plaincopy
143 // If this is not the first split, we always throw away first record
144 // because we always (except the last split) read one extra line in
145 // next() method.
146 if(start != 0) {
147 start = in.readLine(newText(), 0, maxBytesToConsume(start));
148 }
149 this.pos = start;
