hadoop mr的数据流程交互简单描述

dinggela

　　一、概述
　　文章可能会重新编辑，如果想浏览最新内容请访问原创博客：http://blog.iyunv.com/bxyz1203/article/details/8074248。由于作者个人知识面有限，如果描述有错误或者遗留之处敬请谅解，再欢迎指出，我们共同进步。
　　二、计算流程
　　MR计算框架发展到1.0.3左右，计算框架没有发展大的变化。在《hadoop  The Definitive Guide》中有张经典的图可以说明问题，如图1所示。

图1

图1大致说明了我们计算的任务流程，不过并没有深入内部讲述代码的一些细节。所有细节也非常繁细，我整理出一幅大致的数据流程图交互图来说明问题（此图主要我理清楚思路，可能有所欠缺及不完善，主要强调任务数据流转）。如图2:所示：

图2

图2简单说明：

大致分为上下两个部分：

上部分主要是JobTracker的一些内部数据结构。在JobTracker主要是JobInProgress的初始化，初始化的时候会确定每个JobInProgress会包含两个JobSetup、JobCleanup、一些map、及一些reduce任务。这些会合理地分配到taskTracker机器上面。上图主要给出的部分就是：setup及cleanup与map\reduce的调度是分开的。反馈部分图中没有涉及，此处就省去了。

下部分主要是taskTracker部分：

1、Action有两部分程序处理：taskTracker自己就能处理的是KillJobAction及KillTaskAction，这些action最后会把Child进程干掉（如果有child进程）。

交给Child处理的是LaunchTaskAction，因为这些都会涉及到用户自定义的代码（如：map\reduce 对于jobSetup及JobClean 最终调用的OutputCommitter，这些抽象类用户也是可以自定义的。），可能会造成进程挂掉。

2、可以看出对于slot，对于Map与Reduce是分开的。分别有两个TaskLauncher守护线程处理。

3、对于单个的Task，后在初始化过程中直接启动相关的LaunchTaskWorker来localizeJob，再启动TaskRunner来准备一些参数及启动一个Child进程。

4、 Child调用接口TaskUmbilicalProtocol，此可以获取任务的详细信息、反馈一些状态、最后报告任务完成。

三、思考

我们可以多想想作者为什么这么设计hadoop。此设计的hadoop即使是jobtracker是单点的，在5000左右的机器数目也能胜任，再往上，可能需要别的设计方案，如：Yarn。

1、由于是分布式的程序肯定会有网络不稳定等情况发生，所以对于处理异常情况是必不可少的。如：KillJobAction等

2、由于很多的模块用户可以自定义，为了保护守护进程，我们通常会重新启动一个进程来隔离。如：JobSetup都需要启动一个进程来处理。

3、由于我们需要拥塞控制及容量控制，我们就需要队列，最起码的是在接受到新任务需要一个有限的队列，不可能无限线程处理任务，或者一个线程处理任务。

4、一个很重要的原则是：简单很重要。如：我们为什么需要分开控制map reduce的个数，及为什么存在物理的jobtracker。这个话题其实具有时效性，目前Yarn的方案正在处理这个问题。简单也是有针对性的。物理单点可以解除或者压力小很多，map reduce slots可以合并。

5、分布式的线程之间需要同步状态及阻塞控制，那我们就需要强悍的工具。如：concurrent包。

6、对于一些软件的设计的一些基本思想，我们需要时常是回顾，勿忘根本。

等等。。。

         版权声明：本文为博主原创文章，未经博主允许不得转载。