`
cloudeagle
  • 浏览: 102871 次
  • 性别: Icon_minigender_1
  • 来自: 合肥
社区版块
存档分类
最新评论

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

 
阅读更多

http://blog.csdn.net/bxyz1203/article/details/8074248

一、概述

文章可能会重新编辑,如果想浏览最新内容请访问原创博客:http://blog.csdn.net/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、对于一些软件的设计的一些基本思想,我们需要时常是回顾,勿忘根本。

等等。。。

一、概述

文章可能会重新编辑,如果想浏览最新内容请访问原创博客:http://blog.csdn.net/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、对于一些软件的设计的一些基本思想,我们需要时常是回顾,勿忘根本。

等等。。。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics