图解spark-local模式运行原理

local部署模式

首先spark运行时有4个角色,如下:

在这里插入图片描述

Driver:应用驱动程序, 是spark集群的客户
Master:Spark的主控节点,是spark集群的老板
Worker:Spark的工作节点,是集群的各个节点主管
Executor:Spark的工作进程,由worker监管,负责具体任务的执行

简单local模式运行流程(无集群)

我们先看下启动任务前, driver和executor之间,简单发生了什么(注意local模式下,executor是在driverApp里面的):

在这里插入图片描述

localBackend可以理解成1个客户端
localActore可以理解成1个消息处理器,在这里处理消息并调用对应对象的方法

可以看到启动前,需要先向集群中心申请资源,足够的时候才调用executor的launTask启动任务。

看下任务启动后,发生了什么:

在这里插入图片描述

可以看到executor会不断更新当前的任务运行状态,并发送出去做状态更新。

local-custer运行流程

和简单local相比,有如下区别:

在这里插入图片描述

多了master角色和worker角色。
看一下master的创建流程:

在这里插入图片描述


可以看到首先进行了master注册,即告知启动了一个master。
从图中可以看到几个关键点:

  1. 为了可靠性,master要选举出主备
  2. 为了主备能顺利切换,会做信息持久化。
  3. actorSystem会定期发消息通知master做检测。
    即检测的定时器是在actorSytem中启动的,而不是master自身启动的。 (为什么呢,如果as挂了,不是所有的心跳检测都无法进行了吗?)

master对worker的离线检测机制

看一下master的离线检测机制:

在这里插入图片描述


在这里插入图片描述


可以看到是确认离线后,会设置worker状态为dead,并清理内存。
如果离线时的worker已经是dead状态,则会过一段时间才从检测列表中移除。
几个疑问点:

  1. 为什么发现worker状态为已DEAD时,要过几个周期才把worker从检测列表移除?(个人理解是防止worker恢复?但非dead离线的worker为什么是直接移除)
  2. 发现非DEAD的worker离线时,为什么是要告知driver。(个人理解是告知driver有worker异常,需要等待新的worker注册

worker挂掉后具体发生了什么,等后面的容错机制会介绍。

worker的启动过程

在这里插入图片描述


可以看到以下几点:

  1. 每个worker有一个独立的工作目录,用于缓存数据等
  2. 启动后同样需要反过来注册到master。
  3. 会通过metricsSystem定期上报自己的状态给master

worker如何注册到master

在这里插入图片描述


里面黄色标签可以看到自己当时的疑问
为什么worker要先给自己发心跳,然后再转发给master。
书里没说,个人理解是为了自身能确认心跳线程是否因为异常情况导致中断,所以要先发给自己来确认心跳情况。

在这里插入图片描述


针对这个问题, 其实就是之前提到的, 如果超时了,master会把worker清除, 但后来又收到了心跳,则说明worker没挂,可能只是网络异常,此时会需要worker发送连接请求,重新注册到master

master和worker启动之后

在这里插入图片描述


可以看到master和worker启动完成后, 会启动一个客户端专门和application通信。

master如何处理regsiterapplication

在这里插入图片描述


关键点在于:

  1. 注册过程是为了在master这绑定appid和appadress的关系(local-clster是本地集群的,但如果是真实的集群,则会有多个appid,所以需要这个诸恶过程)

完整流程图

在这里插入图片描述

相关文章

1.SparkStreaming是什么?SparkStreaming是SparkCore的扩展A...
本篇内容介绍了“Spark通讯录相似度计算怎么实现”的有关知识...
本篇文章给大家分享的是有关如何进行Spark数据分析,小编觉得...
本篇内容主要讲解“Spark Shuffle和Hadoop Shuffle有哪些区别...
这篇文章主要介绍“TSDB的数据怎么利用Hadoop/spark集群做数...
本篇内容介绍了“Hadoop与Spark性能原理是什么”的有关知识,...