spark的容错解析.docx

Standalone部署的节点组成 介绍Spark的资料中对于RDD这个概念涉及的比较多，但对于RDD如何运行起来，如何对应到进程和线程的，着墨的不是很多。 在实际的生产环境中，Spark总是会以集群的方式进行运行的，其中standalone的部署方式是所有集群方式中最为精简的一种，另外是Mesos和YARN，要理解其内部运行机理，显然要花更多的时间才能了解清楚。 standalone cluster的组成 standalone集群由三个不同级别的节点组成，分别是 Master?主控节点，可以类比为董事长或总舵主，在整个集群之中，最多只有一个Master处在Active状态 Worker?工作节点 ，这个是manager,是分舵主， 在整个集群中，可以有多个worker，如果worker为零，什么事也做不了 Executor?干苦力活的，直接受worker掌控，一个worker可以启动多个executor,启动的个数受限于机器中的cpu核数 这三种不同类型的节点各自运行于自己的JVM进程之中。 Driver Application 提交到standalone集群的应用程序称之为Driver Applicaton。 Standalone集群启动及任务提交过程详解 ? 上图总结了正常情况下Standalone集群的启动以及应用提交时，各节点之间有哪些消息交互。下面分集群启动和应用提交两个过程来作详细说明。 集群启动过程 正常启动过程如下所述 step 1: 启动master $SPARK_HOME/sbin/start-master.sh step 2: 启动worker ./bin/spark-class org.apache.spark.deploy.worker.Worker spark://localhost:7077 worker启动之后，会做两件事情 将自己注册到Master, RegisterWorker 定期发送心跳消息给Master 任务提交过程 step 1: 提交application 利用如下指令来启动spark-shell MASTER=spark://127.0.0.1:7077 $SPARK_HOME/bin/spark-shell 运行spark-shell时，会向Master发送RegisterApplication请求 日志位置：?master运行产生的日志在$SPARK_HOME/logs目录下 step 2: Master处理RegisterApplication的请求之后 收到RegisterApplication请求之后，Mastet会做如下处理 如果有worker已经注册上来，发送LaunchExecutor指令给相应worker 如果没有，则什么事也不做 step 3: 启动Executor Worker在收到LaunchExecutor指令之后，会启动Executor进程 step 4: 注册Executor 启动的Executor进程会根据启动时的入参，将自己注册到Driver中的SchedulerBackend 日志位置： executor的运行日志在$SPARK_HOME/work目录下 step 5: 运行Task SchedulerBackend收到Executor的注册消息之后，会将提交到的Spark Job分解为多个具体的Task，然后通过LaunchTask指令将这些Task分散到各个Executor上真正的运行 如果在调用runJob的时候，没有任何的Executor注册到SchedulerBackend，相应的处理逻辑是什么呢？ SchedulerBackend会将Task存储在TaskManager中 一旦有Executor注册上来，就将TaskManager管理的尚未运行的task提交到executor中 如果有多个job处于pending状态，默认调度策略是FIFO，即先提交的先运行 测试步骤 启动Master 启动spark-shell 执行 sc.textFile(README.md).count 启动worker 注意worker启动之后，spark-shell中打印出来的日志消息 Job执行结束 任务运行结束时，会将相应的Executor停掉。 可以做如下的试验 停止spark-shell 利用ps -ef|grep -i java查看java进程，可以发现CoarseGrainedExecutorBackend进程已经退出 小结 通过上面的控制消息原语之间的先后顺序可以看出 Master和worker进程必须显式启动 executor是被worker隐式的带起 集群的启动顺序 Master必须先于其它节点启动 worker和driver哪个先启动