Spark系列修炼---入门笔记14

核心内容：

1、如何搭建HA下的Spark集群模式

好了，进入本篇博客的正题，本篇博客主要内容为搭建HA下的Spark集群，在搭建之前，先看一下Spark的运行模式：



从运行模式上我们可以看出，我们需要先搭建Zookeeper集群，这里就不在详细叙述Zookeeper集群的的搭建过程了，但是要强调一下Zookeeper集群在安装的时候需要注意的3个方面：

①Zookeeper集群是单独安装的，Zookeeper的安装和我们的Hadoop、Spark的安装是没有任何关系的

②在Zk搭建的过程中，要指定Zk在Linux中存放数据的目录

③在Zk的配置过程中，要指定Zk集群中到底有几台机器。

Zk集群搭建完之后，我们查看一下相应的状态：

[root@hadoop44 ~]# zkServer.sh status
JMX enabled by default
Using config: /usr/local/zk/bin/../conf/zoo.cfg
Mode: follower

[root@hadoop55 ~]# zkServer.sh status
JMX enabled by default
Using config: /usr/local/zk/bin/../conf/zoo.cfg
Mode: leader

[root@hadoop66 ~]# zkServer.sh status
JMX enabled by default
Using config: /usr/local/zk/bin/../conf/zoo.cfg
Mode: follower

Zk集群搭建好之后，我们接下来就需要让Spark支持zk模式下的HA，而一般情况下Spark系统级别的配置都在spark-env.sh这个配置文件中，相应的配置文件内容如下所示(在非HA的spark模式下直接进行修改)：

spark-env.sh

export SCALA_HOME=/usr/local/scala
export JAVA_HOME=/home/hadoop/jdk1.7.0_25x64
export HADOOP_HOME=/usr/local/hadoop
#export SPARK_MASTER_IP=10.187.84.50
export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER
-Dspark.deploy.zookeeper.url=hadoop44:2181,hadoop55:2181,hadoop66:2181 -Dspark.deploy.zookeeper
.dir=/spark"
export SPARK_WORKER_MEMORY=1g
export HADOOP_CONF_DIR=/usr/local/hadoop/etc/hadoop

从配置文件中我们发现共修改了两处：

在配置文件中添加了:

export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER
-Dspark.deploy.zookeeper.url=hadoop44:2181,hadoop55:2181,hadoop66:2181    -Dspark.deploy.zookeeper
.dir=/spark"

第一个参数的含义：Spark整个集群状态的维护是通过zk来维护的，并且Spark整个集群状态的恢复也是通过zk来恢复的，假设我们用zk做了Spark的HA，如果Active级别的Master挂掉，Standby级别的Master如果想变成Active级别的，它首先需要通过zk来读取整个集群的状态信息，包括全部workers的状态信息，所有Drivers的状态信息，所有Applications的状态信息，而只有从Zk中获取到了整个集群的状态信息之后，Standby级别的Master才能正式的变为Active级别的Master，此时它才能对外继续提供服务(接受作业提交和资源申请的请求)。

第二个参数的含义：指定Spark所用Zk集群中节点的相关信息，端口号默认是2181。

第三个参数的含义：指定Spark在HDFS中存放数据的相关目录（但是现在具体用处还不确定）

同时正如上面所示，我们将:

#export SPARK_MASTER_IP=10.187.84.50

这行代码注释掉。

好的，修改完配置文件之后，我们启动HA下的Spark，注意:默认情况下先在哪个Master节点上启动，哪个Master节点就是Active状态的，而且其余的Master需要手动进行启动，在这里说一下，Standby级别的Master此时并没有获取到集群的相关状态信息。

我们看一下启动信息：







通过集群运行的状况,我们可以看到：我们的Spark集群再次启动的时候，首先需要从Zk集群中读取元数据信息进行状态恢复，此处所说的状态包括所有的workers、drivers、applications，而只有从Zk集群中获取到了整个集群的状态信息之后，此时它才能对外继续提供服务(接受作业提交和资源申请的请求)。

好的，此时我们画一下Spark集群HA下的框架图：



接下来我们测试一下Spark的HA性能，先启动整个集群：

spark-shell   --master spark://hadoop11:7077,hadoop22:7077

集群启动过程中的部分截图信息：



我们spark-shell程序在刚开始启动的时候，首先需要在我们的spark集群中的master进行注册，即知道有哪些的Master，所以程序在刚开始启动的时候要和我们的2台机器(hadoop11与hadoop22)进行连接，但是程序在最后的时候肯定只是跟Active级别的Master进行交互通信。

当然我们可以将hadoop11中的master进程杀掉进行进一步的测试，此处就不在详细写了。

好了，到这里我们HA下的Spark集群搭建方式已经指定好了，接下来总结一些概念性的知识：

1、Spark集群HA中的相关概念

Spark的体系结构是一个主从结构，我们平时所说的Master其实是负责整个集群资源的调度和分配的Master，Worker节点负责单个节点的资源状况，所谓资源主要指内存、CPU，而内存与CPU是计算的核心，由于主从结构存在单点故障，在Spark的生产环境中，采用最多的也是通过zk做HA，进而应对单点措施。

在HA中，一个Master是Active级别的、一个Master是Stanby级别的:所谓Active级别就是现在正在管理集群、并接受外界提交程序的（程序提交请求）和（资源分配请求）的Master，所谓Standby就是随时准备在Master挂掉之后自动切换成Active级别。

2、Standby级别的机器如果要变为Active级别的机器，它首先需要恢复集群的状态，那这台机器到哪里去寻找集群的状态信息呢？

Zk集群保管着Spark集群的所有元数据信息，集群的元数据信息包括：所有的worker(需要管理每台机器上的计算资源)、driver（代表正在运行的程序）、application（应用程序本身），而这些信息在整个集群运行的时候都会交给zk集群。

机器从Standy模式变为Active模式，做的最重要的一个步骤就是：从zk中来获取整个集群的状态信息，恢复整个集群的worker、driver、application所有的这些的信息，而只有恢复整个集群的状态这样才能接管整个集群的工作，才能对外继续提供服务（接受作业提交和资源申请的请求）。



3、HA模式下的Spark集群的一个注意事项

当我们Active级别的Master挂掉之后，在Standby级别的Master正式变为Active级别的Master之前的这一段时间，我们是不能向集群提交新的程序的，但是在这个时间，集群的运行还是正常的，比如说此时有一个程序正在运行，此时并会不会因为Master的切换而影响程序的继续运行。原因在于：程序在具体运行之前，已经向Master申请过资源了（这里讲的是Standbyalone模式-粗粒度），申请过资源之后，就是Driver与我们所有Worker分配的Excuters进行通信，这个过程一般不需要Master参与，除非我们的Excuters有故障。所以在Master出现故障进行切换的时候，并不影响已有作业的运行。

4、粗粒度和细粒度的相关概念

刚才已经说了,在Spark中并不会因为Master的切换而影响程序的继续运行,主要就是程序在运行之前，已经分配好资源了 ，而这种分配资源的方式就是一种粗粒度的分配方式。

粗粒度就是一次性分配好资源，后面就直接使用和复用资源，粗粒度的好处就是一次性分配好资源之后，不需要在关心资源的分配，在运行的过程中，只需要让Driver和Excuters进行交互通信，就可以完成整个作业和程序的运行。

弊端：如果说Job有100万个任务，其中只有一个任务没有运行完的话，那这个程序就没有运行完，此时为100个任务分配的资源都会闲置在那里。

所谓细粒度就是需要资源的时候在分配，使用完资源之后立即释放，细粒度就是你有计算资源的话，就立即分配给我们的计算任务，任务使用完计算之后，就立即释放，

弊端：任务启动非常慢，而且没有办法复用。

正常情况下做大数据处理需要粗粒度。

5、Spark中Driver和Excuter的相关概念

Spark程序在运行的时候分为两个层面：一个是Driver、一个是Excuter。Driver就是驱动整个程序运行的，Excuter就是具体算数据的。

程序在提交的时候，首先会先向我们的Master进行注册，注册之后，在我们的Driver完全启动之后，Master就开始分配资源。即Spark的程序是在注册的时候就完成计算资源的分配的(即在Woker上面启动Excuter、分配多少个Core这些东西），即分配资源都在是Spark程序启动初始化的过程中，而不是在程序具体工作的过程中完成的，即在注册的时候就已经完成了资源的分配。

6、Spark在内部已经封装了zk，让我想起了Hbase自带zk。

OK，明天继续努力！