MapReduce 不仅仅是一个工具，更是一个框架。我们必须拿问题解决方案去适配框架的 map 和 reduce 过程
很多情况下，需要关注 MapReduce 作业所需要的系统资源，尤其是集群内部网络资源的使用情况。这是MapReduce 框架在设计上的取舍，是在需要考虑并发、容错、扩展性以及其他挑战与只关注数据的分布式处理之间的平衡。但是，独特的系统加上独特的问题使解决方案产生了独特的设计模式。
我们不仅要关注代码的简洁和可维护性，同时还要考虑到任务会在数百台机器的共享集群上处理 TB 级甚至 PB 级的数据，任务性能也需要格外地重视。同时，该作业与共享集群的机器上数以百计的任务存在竞争关系。 一个好的设计可以带来几个数量级的性能提升，因此选择正确的设计来实现 MapReduce 算法就显得尤为重要。
随着 pig、hive 的发展，他们更将能解决 90% 以上的业务场景。 但是那10% 将是他们无法解决的。 这种情况编写MR 就是最好的解决方案。 就像有些时候依然必须用 汇编语言一样。
HDFS 分块 - MapReduce 分析
HDFS 数据划分 ： 文件上传之后，第一件事就是数据划分，是按照配置文件的块大小进行的物理分块。
Hadoop 数据划分 ： 现在版本是 JobClient 去进行划分分析 split.file 写入 HDFS 中，到时候 JobTracker 端读这个文件。计算一个文件 有多少个 Block是由 getSplits这个函数计算的单位是Block个数.
MapTask任务分配 ： map 的个数是由 splits 长度决定。 一个 splits 不会包含两个 File 的块，不会跨越 File 边界。 splits 和 Block 关系式一对多关系，默认是一对一。
Reduce 任务 ： Shuffle, 也是 Copy 阶段，Reduce Task 从各个 MapTask 上远程拷贝数据，并针对某一片数据，如果其大小超过一定阈值，则写到磁盘上，否则直接放在内存中。
很多情况下 Reduce 执行时需要跨节点拉取其他节点的 map task 结果。 如果集群正在运行的 job 有很多， 那么 task 的正常执行对集群内部的网络资源消耗会很严重。 这种网络小号是正常的。 不能加以限制，能做的就是最大化的减少不必要的消耗。还有在节点内，相比于内存，磁盘 IO 对 job 完成任务影响是很客观的。
Shuffer ： 完整的拉取 map 节点数据。 减少对带宽不必要的消耗。 减少磁盘IO对 task 的执行影响。（主要是尽量使用内存而非磁盘。）
FileSplit 类：
(1)数据切分：按照某个策略将输入数据切分成若干个split，以便确定MapTask个数以及对应的split；
(2)为Mapper提供输入数据：读取给定的split的数据，解析成一个个的key/value对，供mapper使用。
InputFormat有两个比较重要的方法：(1)List<InputSplit> getSplits(JobContext job)；(2)RecordReader<LongWritable, Text> createRecordReader(InputSplit split,TaskAttemptContext context)。