和HDFS一样,MapReduce也是采用Master/Slave的架构 MapReduce1包含4个部分:Client.JobTracker.TaskTracker和Task Client 将JAR文件.配置参数Configuration.计算分片.Distributed Cache 文件存储在HDFS 向 JobTracker 申请JobId JobTracker 负责资源监控和作业调度 监控所有TaskTracker 与job的健康状况,一旦发现失败,就将相应的任务转移到其他节点 跟踪任务

MapReduce作业可以细分为map task和reduce task,而MRAppMaster又将map task和reduce task分为四种状态: 1.pending:刚启动但尚未向resourcemanager发送资源请求: 2.scheduled:已经向resourceManager发送资源请求,但尚未分配到资源: 3.assigned:已经分配到了资源且正在运行: 4.completed:已经运行完成. map task的生命周期为:scheduled -> assigned -

上一节分析了Job由JobClient提交到JobTracker的流程,利用RPC机制,JobTracker接收到Job ID和Job所在HDFS的目录,够早了JobInProgress对象,丢入队列,另一个线程从队列中取出JobInProgress对象,并丢入线程池中执行,执行JobInProgress的initJob方法,我们逐步分析. public void initJob(JobInProgress job) { if (null == job) { LOG.info("Init on

近1年,偶尔发生应用系统启动时某些操作超时的问题,特别在使用4核心Surface以后.笔记本和台式机比较少遇到,服务器则基本上没有遇到过. 这些年,我写的应用都有一个习惯,就是启动时异步做很多准备工作.基本上确定这个问题跟它们有关. 最近两个月花了些时间分析线程池调度机制,有点绕,这里记录下来,防止以后忘了. (文章很长,时间不多的同学可以直接看最后!)  一.现象 这里以一个典型WinForm应用来分析.开发环境Surface Pro4,CPU=4 在vs中调试应用,可以明显感觉到启动时会卡3

v2版本的MapReduce作业中,作业JOB_SETUP_COMPLETED事件的发生,即作业SETUP阶段完成事件,会触发作业由SETUP状态转换到RUNNING状态,而作业状态转换中涉及作业信息的处理,是由SetupCompletedTransition来完成的,它主要做了四件事: 1.通过设置作业Job的成员变量setupProgress为1,标记作业setup已完成: 2.调度作业Job的Map Task: 3.调度作业的JobReduce Task: 4.如果没有task了,则生成J

话说在<Spark源码分析之五:Task调度(一)>一文中,我们对Task调度分析到了DriverEndpoint的makeOffers()方法.这个方法针对接收到的ReviveOffers事件进行处理.代码如下: // Make fake resource offers on all executors // 在所有的executors上提供假的资源(抽象的资源,也就是资源的对象信息,我是这么理解的) private def makeOffers() { // Filter out exec

在前四篇博文中,我们分析了Job提交运行总流程的第一阶段Stage划分与提交,它又被细化为三个分阶段: 1.Job的调度模型与运行反馈: 2.Stage划分: 3.Stage提交:对应TaskSet的生成. Stage划分与提交阶段主要是由DAGScheduler完成的,而DAGScheduler负责Job的逻辑调度,主要职责也即DAG图的分解,按照RDD间是否为shuffle dependency,将整个Job划分为一个个stage,并将每个stage转化为tasks的集合--TaskSet.

话说在<Spark源代码分析之五:Task调度(一)>一文中,我们对Task调度分析到了DriverEndpoint的makeOffers()方法.这种方法针对接收到的ReviveOffers事件进行处理.代码例如以下: // Make fake resource offers on all executors     // 在全部的executors上提供假的资源(抽象的资源.也就是资源的对象信息,我是这么理解的)     private def makeOffers() {       /

MapReduce五大过程已经分析过半了.上次分析完Map的过程,着实花费了我的非常多时间.只是收获非常大,值得了额,这次用相同的方法分析完了Reduce的过程,也算是彻底摸透了MapReduce思想的2个最最重要的思想了吧. 好,废话不多,切入正题,在学习Reduce过程分析的之前,我特意查了书籍上或网络上相关的资料.我发现非常大都是大同小异.缺乏对于源代码的參照分析.所以我个人觉得.我了能够在某些细节上讲得跟明确些,或许会比較好.由于Map和Reduce的过程的总体流程是非常相近的,假设你看

注意标题:Map Task数目的确定和Reduce Task数目的指定————自然得到结论,前者是后者决定的,后者是人为指定的.查看源码可以很容易看懂 1.MapReduce作业中Map Task数目的确定: 1)MapReduce从HDFS中分割读取Split文件,通过Inputformat交给Mapper来处理.Split是MapReduce中最小的计算单元,一个Split文件对应一个Map Task2)默认情况下HDFS种的一个block,对应一个Split.3)当执行Wordcount时

写了一个(不完整的)基于协程的task调度库 sample code如下 my_spawn( function () print('f: 1') local t1 = my_spawn( function () print('f: 3') task_yield_to_be_schedule() print('f: 4') end ) --task_yield_to_be_schedule() my_wait_task(t1) print('f: 2') end ) while my_run_on

早上发现一个任务有20个reduce,但是只有四个正常完成,剩余16个等待了8个小时才分配执行(集群槽位资源充足) 解决方法:查看了集群的log,发现有这种warn: -- ::, WARN org.apache.hadoop.mapred.JobInProgress: No room for reduce task. Node tracker_s lave028.hadoop.sjs.org:localhost/ has bytes free; but we expect red uce in

FAIR  调度策略的树结构如下图所示: FAIR 调度策略内存结构 FAIR 模式中有一个 rootPool 和多个子 Pool, 各个子 Pool 中存储着所有待分配的 TaskSetMagager . 在    FAIR   模 式 中 , 需 要 先 对 子    Pool  进 行 排 序 , 再 对 子    Pool  里 面 的 TaskSetMagager 进行排序,因为 Pool 和 TaskSetMagager 都继承了 Schedulable 特质, 因此使用相同的排序算

本节,已经能够利用我们眼下所学的知识做出一些有趣的东西.之前已经说过,CCNode类没有贴图,也就是说在屏幕上单独建立一个节点是没有不论什么效果的,可是能够通过这个"无形"的节点来控制屏幕上的节点.如今就開始吧!     1. 增加节点     新建一个项目,并在HelloWorldScene.cpp文件里的init函数中做如代码清单3-2的代码所看到的的改动.     代码清单3-2 增加节点 bool HelloWorld::init() { if ( !CCLayer::init

分块:Block HDFS存储系统中,引入了文件系统的分块概念(block),块是存储的最小单位,HDFS定义其大小为64MB.与单磁盘文件系统相似,存储在 HDFS上的文件均存储为多个块,不同的是,如果某文件大小没有到达64MB,该文件也不会占据整个块空间.在分布式的HDFS集群上,Hadoop系统保证一个块存储在一个datanode上. 把File划分成Block,这个是物理上真真实实的进行了划分,数据文件上传到HDFS里的时候,需要划分成一块一块,每块的大小由hadoop-default.

/* 线程合并:将指定的线程加入到当前线程,可以将两个交替执行的线程合并为顺序执行的线程,即单线程. 如在B线程中调用了A的join方法,则线程A执行完后,才会执行线程B. */ public class ThreadTest05 { public static void main(String[] args) throws Exception { Thread t = new Thread(new Processor()); t.setName("t"); t.start(); //

yield与sleep类似,只是不能指定暂停多长时间,并且只能让同优先级的线程有执行的机会,让位时间不固定. /* yield使用 */ public class ThreadTest04 { public static void main(String[] args) throws Exception { Thread t1 = new Thread(new Processor()); t1.setName("t1"); t1.start(); //主线程 for(int i=0;i

/* sleep,阻塞当前线程,腾出CPU,让给其他线程 单位是毫秒 静态方法 */ public class ThreadTest04 { public static void main(String[] args) { Thread t1 = new Processor(); t1.setName("t1"); t1.start(); } } class Processor extends Thread { //Thread的run方法不抛出异常,在run方法的声明位置上不能使用t

Compression and Input Splits   当我们使用压缩数据作为MapReduce的输入时,需要确认数据的压缩格式是否支持切片?   假设HDFS中有一个未经压缩的大小为1GB的文本文件,如果HDFS Block大小为128MB,那么这个文件会被HDFS存储为8个Block.当MapReduce Job使用这个文件作为输入时将会创建8个切片(默认每一个Block生成一个切片),每一个切片关联的数据都可以被一个Map Task独立地处理.   如果这个文本文件使用Gzip格式压

JobTracker和TaskTracker分别启动之后(JobTracker启动流程源码级分析,TaskTracker启动过程源码级分析),taskTracker会通过心跳与JobTracker通信,并获取分配它的任务.用户将作业提交到JobTracker之后,放入相应的数据结构中,静等被分配.mapreduce job提交流程源码级分析(三)这篇文章已经分析了用户提交作业的最后步骤,主要是构造作业对应的JobInProgress并加入jobs,告知所有的JobInProgressListen

1. 什么是Task? 在前面的章节里描写叙述过几个角色,Driver(Client),Master,Worker(Executor),Driver会提交Application到Master进行Worker上的Executor上的调度,显然这些都不是Task. Spark上的几个关系能够这样理解: Application: Application是Driver在构建SparkContent的上下文的时候创建的,就像申报员,如今要构建一个能完毕任务的集群,须要申报的是这次须要多少个Executor