hadoop学习笔记：MapReduce原理

首先 hadoop1.0主要的组成部分分别为HDFS和MapReduce。其中，HDFS是hadoop的文件系统，MapReduce是hadoop的计算框架，上一篇博文，根据paper对其hdfs进行了介绍，学习了框架及执行流程等。这篇博文将对hadoop的计算框架MapReduce进行一下梳理，这里主要还是梳理MapReduce1.0，虽然有些过时，但对于学习后面的新版本也具有十分重要的意义。

为什么需要MapReduce框架？

(1) 大量或者海量数据在单机上处理运行，在有限的硬件资源范围内处理，需要超级长的时间，无法实现快速处理；
(2) 如果粗暴的将单机版程序扩展到集群进行分布式运行，需要极为复杂的程序逻辑，增加了开发难度；

什么是MapReduce框架？

MapReduce是一种编程模型，是处理和生成大型数据集的实现。用户指定一个map函数，该函数处理一个键/值对以生成一组中间结果键/值对，以及一个reduce函数，该函数合并与中间结果中键关联的所有中间值。Mapreduce 核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序，并发运行在一个 hadoop 集群上。
MapReduce的核心思想就是”分而治之“，将大的数据分割成小的数据块，分别在多台机器上进行小任务运行（这就是map操作），小任务执行完后，在进行集中的合并操作（这就是reduce操作），最终获得整个结果。这样可以大大的提高海量数据的运行效率。

MapReduce执行框架：

MapReduce框架属于master/slave框架，包含三种角色，client， jobTracker和TaskTracker；
Client ： 每一个 job 都会在用户端通过 Client 类将应用程序以及配置参数打包成 jar 文件存储到 HDFS 中，并把路径提交给 JobTracker，然后由 JobTracker 创建每个 task，并将它们分发到各个 tasktracker 服务中去执行。
jobtracker：它是一个 Master 服务，负责调度 job 的每个 task 运行于 tasktracker 之上，并监控它们，如果发现有失败的 task，就重新启动它。一般应将 tasktracker 部署在单独的机器上。它包含一个 job 队列来跟踪和调度所有 job。
tasktracker：它是运行在多个节点上的 slaver 服务，负责直接执行每个 task。tasktracker 都需要运行在 HDFS 的 datanode 上。

MapReduce执行流程：

MapReduce在执行过程中，首先读取HDFS文件系统中的文件块，然后，根据需要再进行split，每一个maptask执行一个map作业，执行结果会被分为reduce作业对应的个数的份数，例如我们需要n个reduce，那么每个map会根据key把中间结果分为n类（一般使用hash取模）。然后在把每个map的结果，中每一类的中间结果，shuffle到对应的reduceTask机器上。shuffle过程是需要跨机器传输的，所以相对费时，所以在编程过程中，都会尽量较少shuffle的操作。最后，reduce作业会把结果写入的文件（一般都是分part，也可以合并操作）

示例分析：
1.分布式grep：如果map函数的输入与提供的模式匹配，则输出一个中间结果。reduce函数是一个标识函数，它将map提供的中间结果输出。
2.URL访问频率计数：map函数处理网页请求日志，并输出的。reduce函数将同一个URL的所有值相加，并发出一个对结果。
3.单词数量统计：map函数将输入的文本行，切割为单个单词，并得中间计算结果， reduce函数则将相同的word的pair所对应的值累加在一起，输出结果。

MapReduce的容错机制 ：

1. 任务出错情况，JobTask会周期监控task任务节点，如果节点失联，怎会在其他可用节点（一般优先有备份数据的节点）上重启相同任务同时会尝试重复执行该任务。
2. 任务备份机制，JobTask如果发现某一个TaskTracker计算过程中很慢，有异于其他Task的状态时（paper中叫做“straggler”），系统会重新启动一个TaskTracker做同样的事情，则保证整个系统不会因为一个Task的异常而导致整个系统性能的下降或错误。

MapReduce的资源管理：

参考来源：https://www.cnblogs.com/sammyliu/p/4396142.html
MapReduce1.0本身除了数据计算功能之外，还负责资源管理功能。
Hadoop 1.0 资源管理由两部分组成：资源表示模型和资源分配模型，其中，资源表示模型用于描述资源的组织方式，Hadoop 1.0采用“槽位”（slot）组织各节点上的资源，而资源分配模型则决定如何将资源分配给各个作业/任务，在Hadoop中，这一部分由一个插拔式的调度器完成。
Hadoop引入了“slot”概念表示各个节点上的计算资源。为了简化资源管理，Hadoop将各个节点上的资源（CPU、内存和磁盘等）等量切分成若干份，每一份用一个slot表示，同时规定一个task可根据实际需要占用多个slot 。通过引入“slot“这一概念，Hadoop将多维度资源抽象简化成一种资源（即slot），从而大大简化了资源管理问题。
更进一步说，slot相当于任务运行“许可证”，一个任务只有得到该“许可证”后，才能够获得运行的机会，这也意味着，每个节点上的slot数目决定了该节点上的最大允许的任务并发度。为了区分Map Task和Reduce Task所用资源量的差异，slot又被分为Map slot和Reduce slot两种，它们分别只能被Map Task和Reduce Task使用。Hadoop集群管理员可根据各个节点硬件配置和应用特点为它们分配不同的map slot数（由参数mapred.tasktracker.map.tasks.maximum指定）和reduce slot数（由参数mapred.tasktrackerreduce.tasks.maximum指定）。

Hadoop 1.0中的资源管理存在以下几个缺点：

（1）静态资源配置。采用了静态资源设置策略，即每个节点实现配置好可用的slot总数，这些slot数目一旦启动后无法再动态修改。
（2）资源无法共享。Hadoop 1.0将slot分为Map slot和Reduce slot两种，且不允许共享。对于一个作业，刚开始运行时，Map slot资源紧缺而Reduce slot空闲，当Map Task全部运行完成后，Reduce slot紧缺而Map slot空闲。很明显，这种区分slot类别的资源管理方案在一定程度上降低了slot的利用率。
（3） 资源划分粒度过大。这种基于无类别slot的资源划分方法的划分粒度仍过于粗糙，往往会造成节点资源利用率过高或者过低 ，比如，管理员事先规划好一个slot代表2GB内存和1个CPU，如果一个应用程序的任务只需要1GB内存，则会产生“资源碎片”，从而降低集群资源的利用率，同样，如果一个应用程序的任务需要3GB内存，则会隐式地抢占其他任务的资源，从而产生资源抢占现象，可能导致集群利用率过高。
（4） 没引入有效的资源隔离机制。Hadoop 1.0仅采用了基于jvm的资源隔离机制，这种方式仍过于粗糙，很多资源，比如CPU，无法进行隔离，这会造成同一个节点上的任务之间干扰严重。

总结：

MapReduce是一个分布式的主从计算框架，使用简单的Map函数，和reduce函数实现了分布式计算。但是1.0版本也存在缺陷，所以2.0版本时，hadoop将MapReduce进行了简化，将资源管理和调度任务分离出来一个yarn（Yet Another Resource Negotiator）资源管理器模块，来全局管理整个集群的计算资源的分配和任务的调度协调工作。
hadoop 1.0 任务执行框架图：
NameNode和dataNode是HDFS的两种节点，JobTracker和taskTracker是MapReduce的两种Tracker，整体可以理解二者的关系。HDFS是文件数据，MapReduce是数据计算。

注：图片来源互联网