基于HDFS的MapReduce计算框架

         学习MapReduce的原理(https://blog.csdn.net/Chris_MZJ/article/details/83099262)之后，我们来看看MapReduce是如何在HDFS集群上实现的。分布式计算框架的思想一般都是计算找数据，这样能减少数据传输中的网络IO开销，可以将一个计算线程比作一个伐木工人，数据就是山上的树木，工人工作肯定是携带工具上山伐木的，而不能把山搬到工人的家中来。
先来介绍Hadoop1.x版本的MapReduce实现：

首先程序员自己写好MapReduce计算框架的map部分和reduce部分代码，shuffle过程由MapReduce框架实现。现在有一个MapReduce程序，我们将它打包成一个Application jar包，光有这个jar包肯定是不能运行的，首先我们得向资源调度器申请点资源(CPU,内存，磁盘空间),得到运行Application的资源后还得进行任务调度，因为一个MapReduce程序有多个map task和reduce task，然后再进行分布式并行计算。

          如上图所示，首先客户端将MapReduce程序打包成Application jar包，发送给JobTracker，JobTracker拿到jar包后分析MapReduce程序要操作哪些数据，并汇报给NameNode节点，NameNode返回要操作的数据都是哪些DataNode上，接着，JobTrakcer将appllication中的map task和reduce task 分发给对应的TaskTracker(哪个DataNode有数据哪个节点就是一个TaskTracker，当由数据的节点资源不足时，TaskTracker也会是其他节点)，TaskTracker收到JobTracker的消息后分配一部分资源用来运行map task任务，map task任务输出数据后reduce tracker把数据拿走，进行Reduce task任务，输出结果。在这整个过程中，JobTracker既是任务调度的主节点，又是资源调度的主节点，负荷大，任务量多时容易崩，JobTracker一旦崩了整个计算框架就不能用了。还有一个潜在的问题是：当有另外一个计算框架也要在HDFS集群在工作时，可能会造成资源抢夺问题，详见上图。由此，Hadoop1.x版本是不稳定的。由此我们引出Hadoop的2.x版本:

          同样地，首先客户端将MapReduce程序打包成Application jar包，向NameNode汇报，然后生成一个数据报表，这个报表的意义是：我们假设要处理的文件在HDFS上只有两个block，对于block1：数据在node01~node3上面，那么最好是在这三个节点的任意一个启动map task计算，如果这三个节点资源不足，那么就在同机架的一个节点启动map task，如果同机架的节点资源不足，随机找一个节点启动。

         与NameNode通信生成数据报表后，client会向资源调度器发起请求，请求启动一个application master，RM收到client的请求后在NodeManager启动一个Application Master进程，接着，Application Master会从client拿到数据报表，根据数据报表向RM申请资源，RM收到请求后开始分配资源，拿到资源的NodeManager节点创建一个container容器，容器包括cpu，内存，磁盘空间等资源，接着Application Master向各个获得资源的NodeManager派发任务执行，这就是整个计算框架的运算过程。其中启动RM,Application Master,NodeManager等工作都是由hadoop的yarn框架完成的，当有其他的计算框架如sparks想运行在HDFS集群上时，只需要继承yarn的接口就行，因为这两个框架都是继承yarn的接口执行的，资源调度均有yarn完成，所以就不会存在Hadoop1.x版本的资源抢夺问题。而且，在运行过程中，如果Application Master挂掉，RM会重新启动一个Application Master来执行任务，如果RM挂掉，zookeeper会切换到备用的RM来进行资源调度管理，这就比Hadoop1.x版本强大稳定得多了。