1、结构安排v1.现状及意义v2.MapReduce工作机制简述v3.MapReduce作业工作原理v4.MapReduce在短作业上的优化v4.实验设计及分析v5.总结现状及意义vMapReduce是Google公司于2004年提出的用于并行解决大规模数据处理的计算框架。由于MapReduce拥有诸多良好特性，如负载平衡、高可扩展性以及容错等。它已成为当前工业界和学术界最有效的大规模数据处理问题并行解决方案之一。v虽然HadoopMapReduce是目前面向大规模数据批处理应用的最有效方案之一，但是现在它也经常被应用于短作业的处理，尤其是在线查询和分析类应用。显然，如果能够提升它对于短作业的执行
2、效率，那么这些工具以及Hadoop本身都能更好地支持这些在线查询应用这篇文章就是研究如何提升短作业的执行效率。MapReduce工作机制简述v当一个作业被提交给Hadoop系统时，该作业的输入数据会被划分成很多等长的数据块，每个数据块都会对应于一个map任务这些map任务会同时执行，并行化地处理数据map任务的输出数据会被排序，然后被系统分发给reduce任务以作进一步的处理在作业执行的整个过程中，主节点会对所有任务进行管理：重复执行失败的任务，更改作业的执行状态。v总体上可以把作业的运行分为个阶段：准备阶段（Prep）、运行阶段（Running）和结束阶段（Finished）。MapRedu
3、ce作业工作原理v当一个作业提交到Hadoop系统时，主节点对作业进行初始化，作业内的任务（TaskInProgress）被全部创建好，等待从节点来请求任务。v准备阶段：v（1）分配setup 任务，经过一个心跳周期（3s），主节点收到从节点的任务请求，分发setup任务。v（2）setup任务完成从节点执行setup任务，完成后通过心跳信息向主节点报告完成信息，这是第2次心跳通信。v（3）主节点为作业创建作业内的任务（TaskInProgress);此时task处于UnAssigned状态。v（4）从节点 经过一个心跳周期后向主节点发送一次心跳消息（heart beat），请求分配任务，主节
4、点 收到请求后分配 个作业内的任务（TaskInProgress)给从节点这是第3次心跳通信。v（5）从节点收到任务后创建一个对应的TaskTracker.TaskInProgress对象，并启动独立的Child进程去执行该任务。此时，从节点已将任务状态更新为Running。v运行阶段：运行阶段：v（6）又经过一个心跳周期，从节点 向主节点报告任务状态的改变，主节点也将任务状态更新为Running这是第4次心跳通信。v（7）经过一定时间，任务在Child进程内执行完成，Child进程向从节点进程发出通知，任务状态变为Commit_Pending（任务在执行期间从节点还会周期性地向主节点发送心跳
5、信息）。v（8）从节点再次向主节点发送心跳信息，报告任务状态的改变，主节点收到消息后也将任务状态更新为Commit_Pending，并返回确认消息，允许提交。v（9）从节点收到确认可以提交的消息后，将结果提交，并把任务的状态更新为Succeeded。v（10）一个心跳周期后从节点再次发送心跳消息，主节点收到消息后也更新任务的状态为Succeeded。此时，另一个特殊的任务（job clean up任务）被启动，清理作业的运行环境。与setup类似，job clean up至少也需要两个心跳周期。v结束阶段：v（11）清理任务完成后，作业最终到达成功状态Succeeded，至此，整个作业的生命周
6、期结束。MapReduce在短作业上的优化v优化1：setup/clean up任务优化v在标准Hadoop中执行作业的setup任务仅仅是为了创建一个临时输出目录，而clean up任务则仅仅是删除该目录（此时已为空）这些任务执行的内容本身并没有太大的时间开销，而真正的时间都花费在主节点为了分配该任务而与从节点的心跳等待中。例如，对于一个时间消耗为min左右的短作业而言，这两个操作12s占到左右的百分比如果我们缩短乃至消除这部分时间开销，系统性能将获得较大的提升。v因此，这篇文章设计了一种新的执行方式：setup，cleanup任务将直接在主节点本地执行，而不是分配给从节点执行。v也就是说，
7、一个作业在初始化完成时，该作业的setup任务会直接在主节点上执行；类似地，在该作业所有的MapReduce任务执行完毕之后，clean up任务会同样地直接在主节点上执行。从而消除这两个任务通信上不必要的开销，进一步提高效率。v优化2：任务分配从“拉”模式改为“推”模式v在标准的Hadoop中，主节点不会主动地向从节点发起通信，因此在作业被提交之后，该作业并不会立即被分发到从节点开始执行，而是必须在从节点发起基于周期性心跳的请求之后才会被分发，这样，在作业被用户提交之后需要有一个心跳左右的时间等待期才能真正被安排执行，这个等待期延缓了作业的启动。v因此，这篇文章设计了一种新的方式，在作业初始
8、化完成之后，主节点会根据自己负载情况，尝试主动地立即向所有拥有该作业输入数据的从节点发送信息，告诉他们来“取任务”。这种模式与从节点“拉”模式相反，由主节点向从节点来“推送”任务。v优化3：任务控制信息从心跳通信机制中分离v主节点和从节点之间的通信基于心跳通信机制，这些心跳信息包含有节点信息、任务执行信息等为了提高任务调度效率。v为了将重要的任务控制信息从心跳通信机制中分离出来，因此采用一种即时的消息传递机制。当重要事件发生时它们会立刻被发送出去，而不必等待心跳周期。值得注意的是除了这些任务控制相关信息之外，必要的集群控制信息等依然通过心跳通信机制来推送，以避免造成主节点的瓶颈效应另外，为了限
9、制网络开销和进一步保护主节点，可以适当地延长集群的心跳周期，降低主节点接受和处理那些不重要消息的频率。实验设计及分析v实验平台为一个拥有19个节点的集群，测试系统的算法为Blast（basic local alignment search tool）算法程序Blast是一个基因序列比对算法代表了一种典型的具有实时性要求的查询应用，而且具有典型的多作业类型的特征。实验所用序列数据库为美国国家生物技术信息中心官方的 序列数据库（它是一个核酸序列库）。其文件原始大小为32GB，编码压缩后约为16.44GB，共有1400多万条标注过的序列，整个文件以Hadoop SequenceFile文件格式存储于
10、HDFS。实验分别对比标准HadoopMapReduce系统和优化后的HadoopMapReduce系统。实验对比总结v文章主要致力于对MapReduce执行短作业性能的优化研究通过对作业环境准备和清理的优化，改变任务首轮分配模式以及提供一种新的即时消息传递机制，有效地实现了MapReduce作业执行性能优化实验结果表明，对本文给出的Blast 测试应用，优化后的Hadoop MapReduce比标准Hadoop MapReduce获得平均23执行性能的提升。同时，本文设计的优化版Hadoop MapReduce继承了标准Hadoop的所有特性，包括编程接口、容错性、扩展性等等，从而允许已有的应用程序不必进行任何修改即可在优化后的系统上运行。
