HA（高可用）下的Spark集群工作原理，Spark内核架构笔记

一、HA实战：

ZooKeeper中包含的内容：Worker，Driver，Application
active级别的Master出错后，ZooKeeper会根据自身选举机制选取standby级别的Master转为active级别。只有从ZooKeeper中获取集群的状态信息，成功恢复集群的所有信息后，standby级别的Master才能转为active级别。
Master的切换不会影响到已有程序的运行。这是由于程序在运行前已经向Master申请了资源，此时Driver与Worker分配的Executor进行通信，一般不需要Master参与。
粗粒度分配资源：一次性分配资源，之后复用，不必关心资源分配。但是假设某Job有1000000个任务，有一个任务没有运行完，则分配给这1000000个任务的计算资源会闲置。实际工程中一般使用粗粒度的方式。
细粒度分配资源：需要时分配资源，运行结束立即释放资源。无法复用。
zookeeper安装配置：
下载zookeeper安装包，解压

root@master:/usr# tar -xvf zookeeper-3.4.6

配置环境变量

root@master:/usr# vim /etc/profile  //添加zookeeper路径

export ZOOKEEPER_HOME=/usr/zookeeper
export PATH=$ZOOKEEPER_HOME/bin:$PATH

root@master:/usr# source /etc/profile

进入/zookeeper文件夹，新建log和data目录，并进入/zookeeper/conf文件夹，复制zoo_sample.cfg文件，更改配置

root@master:/usr/zookeeper# mkdir log
root@master:/usr/zookeeper# mkdir data
root@master:/usr/zookeeper# cd conf
root@master:/usr/zookeeper/conf# ls
configuration.xsl  log4j.properties  zoo_sample.cfg
root@master:/usr/zookeeper/conf# vim zoo_sample.cfg
root@master:/usr/zookeeper/conf# cp zoo_sample.cfg zoo.cfg
root@master:/usr/zookeeper/conf# ls
configuration.xsl  log4j.properties  zoo.cfg  zoo_sample.cfg
root@master:/usr/zookeeper/conf# vim zoo.cfg

dataDir=/usr/zookeeper/data
dataLOgDir==/usr/zookeeper/log
server.0=master:2888:3888
server.1=slave1:2888:3888
server.2=slave2:2888:3888

进入data目录，配置机器ID信息

root@master:/usr/zookeeper/conf# cd ../data
root@master:/usr/zookeeper/data# echo 0>myid

root@master:/usr/zookeeper/data# vim myid
//配置为0
//其他机器分别配置为1，2

配置Spark，拷贝至其他机器：

root@master:~# cd /usr/spark/conf
root@master:/usr/spark/conf# vim spark-env.sh

export SPARK_DAEMON_JAVA_OPTS="-Dspark.depoly.recoverMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=master:2181,slave1:2182,slave2:2181 -Dspark.depoly.zookeeper.dir=/usr/spark"

zookeeper启动需要在各个机器分别进行启动： zkServer.sh start
二、Spark内核架构
Driver部分的代码：SparkConf+SparkContext

//以单词计数程序为例
//Driver部分
val conf = new SparkConf()
conf.setAppName("Name")
conf.setMaster("local")
val sc = new SparkContext(conf)
//Executor中的具体实现
//textFile,map,flatMap等RDD操作

Spark Cluster

Spark Application运行时不依赖于Cluster Manager。Spark应用程序在注册给Cluster Manager时，成功注册后就已经分配了资源，在程序运行过程中并不需要Cluster Manager的参与。
Worker管理当前Node(节点)的内存、CPU等计算资源，并接收Master分配资源的指令通过ExecutorRunner来分配具体的计算资源Executor（在新的进程中分配）。
Executor是运行在Worker所在节点上为当前应用程序运行所开启的进程中的对象，通过线程池并发执行和线程复用负责具体Task的运行。线程池中的每个线程运行一个任务，任务完成后线程被回收到线程池中，进行线程复用。
Worker不会向Master发送当前节点资源信息，发送的“心跳”只包含机器的ID信息，并不包含节点资源信息，这是因为在应用程序注册时，Master分配资源，在分配时就已经进行了记录。只有在出现故障时，会把信息汇报给Master。
一个Application可以包含多个Job，一般每个action操作都会触发一个Job。作业Job包含很多个Stage，每个Stage中又包含并行的Task。每个Stage内部计算逻辑完全一样，只是计算的数据不同。
任务本身就是计算数据分片，而一个Partition数据分片默认是128MB。但一个Partition并不会精确等于一个Block的大小，即128MB，因为最后一条记录一般会跨Block存储。
Spark程序的运行模式：Client和Cluster，一般使用Client模式。
Spark内核架构图：