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、对于一些软件的设计的一些基本思想,我们需要时常是回顾,勿忘根本。
等等。。。