Mapreduce的原理

详细在reduce端的操作：

在上图中，从map端得到数据文件，写入内存，当写满1G的70%的66%的时候，先进行封锁排序，（这个排序如果大于数据块的大小，第一个不用排序，第二个需要排序，因为跟下一个数据块的数据合在一起了），排序完毕进行溢写操作，溢写成一个一个的磁盘小文件，然后进行合并排序，生成一个大文件，此时的大文件是一个按照key排序好的文件，然后进行分组，形成一个一个的分组文件，一个分组文件调用一次reduce方法产生一个结果文件，下一个分组产生另一个结果文件，追加在第一个结果文件的后部，即一个reducetask只产生一个结果大文件。

在上图中，有详细的流程以及个部分进行的操作：
所以进行补充：
在第四步中的磁盘小文件数并不是根据前面切片的多少来决定的，而是根据溢写大小来决定，即如果前面的切片没有80M或者大于80M，buffer当到达80M时进行聚合，此次聚合是将切片中相同分区的数据进行聚合，聚合后根据key值进行排序，得到一个磁盘小文件。

shuffle write阶段，当把数据进行分区完后往buffer中写时，一旦写满80M，则会把这80M进行封锁，封锁的目的是为了能进行有效的排序，如果不封锁进行排序，排序的结果是不对的。当进行封锁以后，buffer留出了20M的内存，防止操作的阻塞。
相同的问题在shuffler read阶段，相同的分区的数据往内存中写入时，此时内存的大小为1G的70%，当数据写满66%时，则会进行封锁排序，留下的4%与上面的功能是一样的。

关于MapReduce的流程中，有4次排序：
1.Buffer写满以后进行溢写前，会根据分区号进行分区，分区完毕进行根绝key进行排序，产生一个有序的磁盘小文件
2.在小磁盘文件合并成大文件时，会进行合并排序，根据分区key进行聚合排序
3.拉取map端数据进行写入内存时，写满1G的70%的66%时将进行溢写操作，溢写前进行排序
4.磁盘小文件合并成大文件时，进行合并排序，产生一个有序的大文件。

hadoop1.x

Mapreduce自带的资源调度器：

以上为基本运行流程：
其中存在的问题：
1.如果现在还有一个计算框架想运行在JobTracker的架构中是不行的，它需要自己再实现一套资源任务调度机制，因为Jobtracker是Mapreduce自带的。

当它自己实现了一套机制时，会出现与MapReduce的资源抢夺和资源隔离的问题
2.

---

Hadoop2.x

为解决上面的问题，在2.x版本开发了单独的资源调度框架：yarn，yarn只负责资源的调度，任务调度需要计算框架自己来实现