【转载】Map/Reduce hadoop 细节

zhaoke0727

Map/Reduce hadoop 细节



原文：http://www.iyunv.com/duguguiyu/archive/2009/02/28/1400278.html
分布式计算（Map/Reduce）分布式式计算，同样是一个宽泛的概念，在这里，它狭义的指代，按Google Map/Reduce框架所设计的分布式框架。在Hadoop中，分布式文件系统，很大程度上，是为各种分布式计算需求所服务的。我们说分布式文件系统就是加了分布式的文件系统，类似的定义推广到分布式计算上，我们可以将其视为增加了分布式支持的计算函数。 从计算的角度上看，Map/Reduce框架接受各种格式的键值对文件作为输入，读取计算后，最终生成自定义格式的输出文件。而从分布式的角度上看，分布 式计算的输入文件往往规模巨大，且分布在多个机器上，单机计算完全不可支撑且效率低下，因此Map/Reduce框架需要提供一套机制，将此计算扩展到无限规模的机器集群上进行。依照这样的定义，我们对整个Map/Reduce的理解，也可以分别沿着这两个流程去看。。。在Map/Reduce框架中，每一次计算请求，被称为作业。在分布式计算Map/Reduce框架中，为了完成这个作业，它进行两步走的战略，首先是将其拆分成若干个Map任务， 分配到不同的机器上去执行，每一个Map任务拿输入文件的一部分作为自己的输入，经过一些计算，生成某种格式的中间文件，这种格式，与最终所需的文件格式 完全一致，但是仅仅包含一部分数据。因此，等到所有Map任务完成后，它会进入下一个步骤，用以合并这些中间文件获得最后的输出文件。此时，系统会生成若 干个Reduce任务，同样也是分配到不同的机器去执行，它的目标，就是将若干个Map任务生成的中间文件为汇总到最后的输出文件中去。当然，这个汇总不总会像1 + 1 = 2那么直接了当，这也就是Reduce任务的价值所在。经过如上步骤，最终，作业完成，所需的目标文件生成。整个算法的关键，就在于增加了一个中间文件生成的流程，大大提高了灵活性，使其分布式扩展性得到了保证。。。I. 术语对照和分布式文件系统一样，Google、Hadoop和....我，各执一种方式表述统一概念，为了保证其统一性，特有下表。。。文中翻译 Hadoop术语 Google术语 相关解释 作业 Job Job 用户的每一个计算请求，就称为一个作业。 作业服务器 JobTracker Master 用户提交作业的服务器，同时，它还负责各个作业任务的分配，管理所有的任务服务器。 任务服务器 TaskTracker Worker 任劳任怨的工蜂，负责执行具体的任务。 任务 Task Task 每一个作业，都需要拆分开了，交由多个服务器来完成，拆分出来的执行单位，就称为任务。 备份任务 Speculative Task Buckup Task 每一个任务，都有可能执行失败或者缓慢，为了降低为此付出的代价，系统会未雨绸缪的实现在另外的任务服务器上执行同样一个任务，这就是备份任务。 II. 基本架构与分布式文件系统类似，Map/Reduce的集群，也由三类服务器构成。其中作业服务器，在Hadoop中称为Job Tracker，在Google论文中称为Master。前者告诉我们，作业服务器是负责管理运行在此框架下所有作业的，后者告诉我们，它也是为各个作业分配任务的核心。与HDFS的主控服务器类似，它也是作为单点存在的，简化了负责的同步流程。具体的负责执行用户定义操作的，是任务服务器，每一个作业被拆分成很多的任务，包括Map任务和Reduce任务等，任务是具体执行的基本单元，它们都需要分配到合适任务服务器上去执行，任务服务器一边执行一边向作业服务器汇报各个任务的状态，以此来帮助作业服务器了解作业执行的整体情况，分配新的任务等等。。。除了作业的管理者执行者，还需要有一个任务的提交者，这就是客户端。与分布式文件系统一样，客户端也不是一个单独的进程，而是一组API，用户需要自定义好自己需要的内容，经由客户端相关的代码，将作业及其相关内容和配置，提交到作业服务器去，并时刻监控执行的状况。。。同作为Hadoop的实现，与HDFS的通信机制相同，Hadoop Map/Reduce也是用了协议接口来进行服务器间的交流。实现者作为RPC服务器，调用者经由RPC的代理进行调用，如此，完成大部分的通信，具体服 务器的架构，和其中运行的各个协议状况，参见下图。从图中可以看到，与HDFS相比，相关的协议少了几个，客户端与任务服务器，任务服务器之间，都不再有 直接通信关系。这并不意味着客户端就不需要了解具体任务的执行状况，也不意味着，任务服务器之间不需要了解别家任务执行的情形，只不过，由于整个集群各机 器的联系比HDFS复杂的多，直接通信过于的难以维系，所以，都统一由作业服务器整理转发。另外，从这幅图可以看到，任务服务器不是一个人在战斗，它会像 孙悟空一样招出一群宝宝帮助其具体执行任务。这样做的好处，个人觉得，应该有安全性方面的考虑，毕竟，任务的代码是用户提交的，数据也是用户指定的，这质 量自然良莠不齐，万一碰上个搞破坏的，把整个任务服务器进程搞死了，就因小失大了。因此，放在单独的地盘进行，爱咋咋地，也算是权责明确了。。。与分布式文件系统相比，
的参数，通常它都有一个默认实现的类，用户如果不满意，则可自定义实现。。。III. 计算流程如果一切都按部就班的进行，那么整个作业的计算流程，应该是作业的提交 -> Map任务的分配和执行 -> Reduce任务的分配和执行 -> 作业的完成。而在每个任务的执行中，又包含输入的准备 -> 算法的执行 -> 输出的生成，三个子步骤。沿着这个流程，我们可以很快的整理清晰整个Map/Reduce框架下作业的执行。。。1、作业的提交一个作业，在提交之前，需要把所有应该配置的东西都配置好，因为一旦提交到了作业服务器上，就陷入了完全自动化的流程，用户除了观望，最多也就能起一个监督作用，惩治一些不好好工作的任务。。。基本上，用户在提交代码阶段，需要做的工作主要是这样的：首先，书写好所有自定的代码，最起码，需要有Map和Reduce的执行代码。在Hadoop中，Map需要派生自Mapper接口，Reduce需要派生自Reducer接口。这里都是用的泛型，用以支持不同的键值类型。这两个接口都仅有一个方法，一个是map，一个是reduce，这两个方法都直接受四个参数，前两个是输入的键和值相关的数据结构，第三个是作为输出相关的数据结构，最后一个，是一个Reporter类的实例，实现的时候可以利用它来统计一些计数。除了这两个接口，还有大量可以派生的接口，比如分割的Partitioner接口。。。然后，需要书写好主函数的代码，其中最主要的内容就是实例化一个JobConf类的对象，然后调用其丰富的setXXX接口，设定好所需的内容，包括输入输出的文件路径，Map和Reduce的类，甚至包括读取写入文件所需的格式支持类，等等。。。最后，调用JobClient的runJob方法，提交此JobConf对象。runJob方法会先行调用到JobSubmissionProtocol接口所定义的submitJob方法，将此作业，提交给作业服务器。接着，runJob开始循环，不停的调用JobSubmissionProtocol的getTaskCompletionEvents方法，获得TaskCompletionEvent类的对象实例，了解此作业各任务的执行状况。。。2、Map任务的分配当一个作业提交到了作业服务器上，作业服务器会生成若干个Map任务，每一个Map任务，负责将一部分的输入转换成格式与最终格式相同的中间文件。通常一个作业的输入都是基于分布式文件系统的文件（当然在单机环境下，文件系统单机的也可以...），因为，它可以很天然的和分布式的计算产生联系。而对于一个Map任务而言，它的输入往往是输入文件的一个数据块，或者是数据块的一部分，但通常，不跨数据块。因为，一旦跨了数据块，就可能涉及到多个服务器，带来了不必要的复杂性。当一个作业，从客户端提交到了作业服务器上，作业服务器会生成一个JobInProgress对象，作为与 之对应的标识，用于管理。作业被拆分成若干个Map任务后，会预先挂在作业服务器上的任务服务器拓扑树。这是依照分布式文件数据块的位置来划分的，比如一 个Map任务需要用某个数据块，这个数据块有三份备份，那么，在这三台服务器上都会挂上此任务，可以视为是一个预分配。关于任务管理和分配的大部分的真实功能和逻辑的实现，JobInProgress则依托JobInProgressListener和TaskScheduler的子类。TaskScheduler，顾名思义是用于任务分配的策略类（为了简化描述，用它代指所有TaskScheduler的子类...）。它会掌握好所有作业的任务信息，其assignTasks函数，接受一个TaskTrackerStatus作为参数，依照此任务服务器的状态和现有的任务状况，为其分配新的任务。而为了掌握所">

Map/Reduce框架的还有一个特点，就是可定制性强。文件系统中很多的算法， 都是很固定和直观的，不会由于所存储的内容不同而有太多的变化。而作为通用的计算框架，需要面对的问题则要复杂很多，在各种不同的问题、不同的输入、不同 的需求之间，很难有一种包治百病的药能够一招鲜吃遍天。作为Map/Reduce框架而言，一方面要尽可能的抽取出公共的一些需求，实现出来。更重要的， 是需要提供良好的可扩展机制，满足用户自定义各种算法的需求。Hadoop是由Java来实现的，因此通过反射来实现自定义的扩展，显得比较小菜一碟了。 在JobConf类中，定义了大量的接口，这基本上是Hadoop Map/Reduce框架所有可定制内容的一次集中展示。在JobConf中，有大量set接口接受一个Class