首先由Spark图表理解Worker于Spark中的作用和地位:

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYW56aHNvZnQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="" />

Worker所起的作用有下面几个:

1. 接受Master的指令,启动或者杀掉Executor

2. 接受Master的指令,启动或者杀掉Driver

3. 报告Executor/Driver的状态到Master

4. 心跳到Master。心跳超时则Master觉得Worker已经挂了不能工作了

5. 向GUI报告Worker的状态

说白了,Worker就是整个集群真正干活的。首先看一下Worker重要的数据结构:

  val executors = new HashMap[String, ExecutorRunner]
val finishedExecutors = new HashMap[String, ExecutorRunner]
val drivers = new HashMap[String, DriverRunner]
val finishedDrivers = new HashMap[String, DriverRunner]

这些Hash Map存储了名字和实体时间的相应关系,方便通过名字直接找到实体进行调用。

看一下怎样启动Executor:

case LaunchExecutor(masterUrl, appId, execId, appDesc, cores_, memory_) =>
if (masterUrl != activeMasterUrl) {
logWarning("Invalid Master (" + masterUrl + ") attempted to launch executor.")
} else {
try {
logInfo("Asked to launch executor %s/%d for %s".format(appId, execId, appDesc.name))
val manager = new ExecutorRunner(appId, execId, appDesc, cores_, memory_,
self, workerId, host,
appDesc.sparkHome.map(userSparkHome => new File(userSparkHome)).getOrElse(sparkHome),
workDir, akkaUrl, ExecutorState.RUNNING)
executors(appId + "/" + execId) = manager
manager.start()
coresUsed += cores_
memoryUsed += memory_
masterLock.synchronized {
master ! ExecutorStateChanged(appId, execId, manager.state, None, None)
}
} catch {
case e: Exception => {
logError("Failed to launch executor %s/%d for %s".format(appId, execId, appDesc.name))
if (executors.contains(appId + "/" + execId)) {
executors(appId + "/" + execId).kill()
executors -= appId + "/" + execId
}
masterLock.synchronized {
master ! ExecutorStateChanged(appId, execId, ExecutorState.FAILED, None, None)
}
}
}

1行到3行是验证该命令是否发自一个合法的Master。7到10行定义了一个ExecutorRunner,实际上系统并没有一个类叫做Executor。我们所说的Executor实际上是由ExecutorRunner实现的,这个名字起得也比較贴切。11行将新建的executor放到上面提到的Hash Map中。

然后12行启动这个Executor。13行和14行将如今已经使用的core和memory进行的统计。15到17行实际上是向Master报告Executor的状态。这里须要加锁。

假设在这过程中有异常抛出,那么须要check是否是executor已经加到Hash Map中,假设有则首先停止它。然后从Hash Map中删除它。而且向Master report Executor是FAILED的。Master会又一次启动新的Executor。

接下来看一下Driver的Hash Map的使用。通过KillDriver:

    case KillDriver(driverId) => {
logInfo(s"Asked to kill driver $driverId")
drivers.get(driverId) match {
case Some(runner) =>
runner.kill()
case None =>
logError(s"Asked to kill unknown driver $driverId")
}
}

这个KillDirver的命令实际上由Master发出的。而Master实际上接收了Client的kill driver的命令。这个也能够看出Scala语言的简洁性。

版权声明:本文博主原创文章,博客,未经同意不得转载。

Spark里边:Worker源代码分析和架构的更多相关文章

  1. Spark SQL Catalyst源代码分析之TreeNode Library

    /** Spark SQL源代码分析系列文章*/ 前几篇文章介绍了Spark SQL的Catalyst的核心执行流程.SqlParser,和Analyzer,本来打算直接写Optimizer的,可是发 ...

  2. Spark SQL Catalyst源代码分析Optimizer

    /** Spark SQL源代码分析系列*/ 前几篇文章介绍了Spark SQL的Catalyst的核心运行流程.SqlParser,和Analyzer 以及核心类库TreeNode,本文将具体解说S ...

  3. Spark SQL Catalyst源代码分析之UDF

    /** Spark SQL源代码分析系列文章*/ 在SQL的世界里,除了官方提供的经常使用的处理函数之外.一般都会提供可扩展的对外自己定义函数接口,这已经成为一种事实的标准. 在前面Spark SQL ...

  4. Spark SQL Catalyst源代码分析之Analyzer

    /** Spark SQL源代码分析系列文章*/ 前面几篇文章解说了Spark SQL的核心运行流程和Spark SQL的Catalyst框架的Sql Parser是如何接受用户输入sql,经过解析生 ...

  5. 小记--------spark的worker原理分析及源码分析

     

  6. Spark大师之路:广播变量(Broadcast)源代码分析

    概述 近期工作上忙死了--广播变量这一块事实上早就看过了,一直没有贴出来. 本文基于Spark 1.0源代码分析,主要探讨广播变量的初始化.创建.读取以及清除. 类关系 BroadcastManage ...

  7. Spark SQL 源代码分析系列

    从决定写Spark SQL文章的源代码分析,到现在一个月的时间,一个又一个几乎相同的结束很快,在这里也做了一个综合指数,方便阅读,下面是读取顺序 :) 第一章 Spark SQL源代码分析之核心流程 ...

  8. Spark2.3(三十五)Spark Structured Streaming源代码剖析(从CSDN和Github中看到别人分析的源代码的文章值得收藏)

    从CSDN中读取到关于spark structured streaming源代码分析不错的几篇文章 spark源码分析--事件总线LiveListenerBus spark事件总线的核心是LiveLi ...

  9. Spark SQL 源代码分析之Physical Plan 到 RDD的详细实现

    /** Spark SQL源代码分析系列文章*/ 接上一篇文章Spark SQL Catalyst源代码分析之Physical Plan.本文将介绍Physical Plan的toRDD的详细实现细节 ...

随机推荐

  1. spring web.xml配置服务启动后执行文件

    <bean id="readXmlService" class="com.xxx.xxx.readXmlServiceImpl" init-method= ...

  2. spring原拦截器配置与新命名空间mvc:interceptors配置拦截器对照与注意事项

    原先,我们是这么配置拦截器的 <bean id="openSessionInViewInterceptor"class="org.springframework.o ...

  3. surfaceflinger中各个layer的排序

    surfaceflinger的主要工作就是负责把上层传递下来的各个不同的layer进行composition. 这里,我们来讨论一下各个layer在surfaceflinger中的上下排序关系和相关的 ...

  4. HDOJ 5276 YJC tricks time multimap

    multimap的使用 YJC tricks time Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 524288/262144 K ...

  5. 一百万数据索引实例測试--mysql

    推荐书籍:http://pan.baidu.com/s/1sjJIyRV 任务描写叙述: 如果一高频查询例如以下  SELECT * FROM user WHERE area='amoy' AND s ...

  6. POJ 2182 Lost Cows(牛排序,线段树)

    Language: Default Lost Cows Time Limit: 1000MS   Memory Limit: 65536K Total Submissions: 9207   Acce ...

  7. VS2010 TFS

    在本文的两个部分中,我将介绍Team Foundation Server的一些核心特征,重点介绍在本产品的日常应用中是怎样将这些特性结合在一起使用的. 作为一名软件开发者,在我的职业生涯中,我常常会用 ...

  8. Android涉及到的设计模式(转)

    1.适配器模式:ListView或GridView的Adapter 简介:不同的数据提供者使用一个适配器来向一个相同的客户提供服务. 2.建造者模式:AlertDialog.Builder 简介:可以 ...

  9. 【ArcGIS 10.2新特性】ArcGIS 10.2 for Desktop 新特性(一)

    ArcGIS 10.2 for Desktop是在10.1的成功基础上进行的改进,它的改进包括:性能提升.附加的安全性.40多个新的分析工具.3D功能提高.栅格增强.新的地理数据管理能力以及其它更多的 ...

  10. 【安德鲁斯】基于脚本的数据库&quot;增量更新&quot;,如果不改变,每次更新java代码、!

    思维: 1.当然,它是基于SQLiteOpenHelper.onCreate(第一个呼叫建立).onUpdate(当所谓的升级计划) 2.用"脚本"(脚本制作详细方法问度娘)做数据 ...