spark的容错分析..docxVIP

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.shstep 2: 启动worker./bin/spark-class org.apache.spark.deploy.worker.Worker spark://localhost:7077worker启动之后，会做两件事情将自己注册到Master, RegisterWorker定期发送心跳消息给Master任务提交过程step 1: 提交application利用如下指令来启动spark-shellMASTER=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: 启动ExecutorWorker在收到LaunchExecutor指令之后，会启动Executor进程step 4: 注册Executor启动的Executor进程会根据启动时的入参，将自己注册到Driver中的SchedulerBackend日志位置： executor的运行日志在$SPARK_HOME/work目录下step 5: 运行TaskSchedulerBackend收到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哪个先启动，无所谓但driver提交的job只有在有相应的worker注册到Master之后才可以被真正的执行异常场景分析?上面说明