Spark 学习之 Spark 集群部署搭建（二）

Spark 运行模式介绍

本地模式

Spark单机运行，直接解压执行start-all.sh即可，一般用于开发测试。

Standalone 模式

构建一个由Master+Slave构成的Spark集群，Spark运行在集群中。

Spark on Yarn 模式

Spark客户端直接连接Yarn。不需要额外构建Spark集群。

Spark on Mesos 模式

Spark客户端直接连接Mesos。不需要额外构建Spark集群。

	|     Host     |   HostName  | Master | Slave |
	| 10.211.55.10 |    Spark1   |   √    |   √   |
	| 10.211.55.11 |    Spark2   |        |   √   |
	| 10.211.55.12 |    Spark3   |        |   √   |
	| 10.211.55.13 |    Spark4   |        |   √   |
	

详细步骤

环境设置

修改 4 台机器的 hostname 分别为 spark1、spark2、spark3、spark4,IP 和 hostname 参考上面的对应关系。
修改命令：

hostnamectl set-hostname sparkN

JDK 的安装：

全部机器都要安装 JDK，这里安装的版本的 JDK1.8。
JDK 下载地址：https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
解压 JDK 压缩包到:/usr/local/,重命名为 jdk1.8,jdk 的完整路径就是：/usr/local/jdk1.8。
配置环境变量：

vi /etc/profile

export JAVA_HOME=/usr/local/jdk1.8
export PATH=${JAVA_HOME}/bin:$PATH

source /etc/profile

Spark 的安装：

这里介绍的 Spark 版本是 Spark-2.4.0。

Spark 下载

下载地址：http://spark.apache.org/downloads.html

下载 Spark 后解压重命名到：/usr/local/spark-2.4.0。

修改 spark-env.sh 配置文件

cd spark-2.4.0/conf
cp spark-env.sh.template spark-env.sh
vi spark-env.sh


# 修改spark-env.sh配置文件，添加如下内容：

#设置JAVA_HOME
export JAVA_HOME=/usr/local/jdk1.8
#设置Master的主机名
export SPARK_MASTER_HOST=spark1
#提交Application的端口，默认就是7077，可以更改为其他端口
export SPARK_MASTER_PORT=7077
# 每一个Worker最多可以使用的cpu核个数
# 真实服务器如果有几个就可以设置几个
export SPARK_WORKER_CORES=1
# 每个Worker最多可以使用的内存，我的虚拟机就2g
# 真实服务器如果有128G，你可以设置为100G
export SPARK_WORKER_MEMORY=1g

修改 slaves 配置文件，添加 Worker 的主机列表

cp slaves.template slaves
vi slaves

# 里面的内容原来为localhost
spark1
spark2
spark3
spark4

到这里，Spark 的基本配置已完成，然后把 Spark-2.4.0 目录打包，发到其他 3 个机器上解压到 /usr/local/ 解压。
然后在所有节点都配置 SPARK_HOME 的环境变量：

vi /etc/profile

export SPARK_HOME=/usr/local/spark-2.4.0
export PATH=$SPARK_HOME/bin:$SPARK_HOME/sbin:$PATH

source /etc/profile

节点间互信操作

集群部署需要节点间互信才能启动所有节点的 Worker，互信的意思就是无需输入密码，只根据 hostname 就可以登录到其他节点上。
以下步骤需在所有节点执行一遍。

生成认证密钥：

ssh-keygen -t rsa

  一直回车,在/root/.ssh/会生成id_rsa和id_rsa.pub文件。

在节点执行以下命令，N就是各个节点的那个IP：

ssh-copy-id -i /root/.ssh/id_rsa.pub root@N

提示输入密码，输入对应IP的登录密码即可。
验证是否成功的话，命令：ssh spark2。能登录即说明互信操作成功了。

启动集群服务

回到服务器节点 10.211.55.10，这台用于启动 Master 和一个 Worker，在这台机启动集群

start-all.sh

启动后用命令看一下进程：

ps -ef | grep spark

上图就说明启动一个 Master 和一个 Slave 了，再到其他 Worker 节点查看是否都已启动 Worker 服务

ps -ef | grep spark

访问 http://10.211.55.10:8080

下面两种未试过，后续看时间允许再尝试实践一下，下面是参考网友的。
Spark On Yarn 模式：

参考：https://www.cnblogs.com/yuanyifei1/p/8474196.html

Spark On Mesos 模式：

参考：http://book.51cto.com/art/201708/549168.htm

总结：

1. Standalone 模式

即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统。从一定程度上说，该模式是其他两种的基础。借鉴 Spark 开发模式，我们可以得到一种开发新型计算框架的一般思路：先设计出它的 standalone 模式，为了快速开发，起初不需要考虑服务（比如 master/slave）的容错性，之后再开发相应的 wrapper，将 stanlone 模式下的服务原封不动的部署到资源管理系统 yarn 或者 mesos 上，由资源管理系统负责服务本身的容错。目前 Spark 在 standalone 模式下是没有任何单点故障问题的，这是借助 zookeeper 实现的，思想类似于 Hbase master 单点故障解决方案。将 Spark standalone 与 MapReduce 比较，会发现它们两个在架构上是完全一致的：

1. 都是由 master/slaves 服务组成的，且起初 master 均存在单点故障，后来均通过 zookeeper 解决（Apache MRv1 的 JobTracker 仍存在单点问题，但 CDH 版本得到了解决）；
2. 各个节点上的资源被抽象成粗粒度的 slot，有多少 slot 就能同时运行多少 task。不同的是，MapReduce 将 slot 分为 map slot 和 reduce slot，它们分别只能供 Map Task 和 Reduce Task 使用，而不能共享，这是 MapReduce 资源利率低效的原因之一，而 Spark 则更优化一些，它不区分 slot 类型，只有一种 slot，可以供各种类型的 Task 使用，这种方式可以提高资源利用率，但是不够灵活，不能为不同类型的 Task 定制 slot 资源。总之，这两种方式各有优缺点。

2. Spark On Mesos 模式

这是很多公司采用的模式，官方推荐这种模式（当然，原因之一是血缘关系）。正是由于 Spark 开发之初就考虑到支持 Mesos，因此，目前而言，Spark 运行在 Mesos 上会比运行在 YARN 上更加灵活，更加自然。目前在 Spark On Mesos 环境中，用户可选择两种调度模式之一运行自己的应用程序（可参考 Andrew Xia 的“Mesos Scheduling Mode on Spark”）：

1. 粗粒度模式（Coarse-grained Mode）：每个应用程序的运行环境由一个 Dirver 和若干个 Executor 组成，其中，每个 Executor 占用若干资源，内部可运行多个 Task（对应多少个“slot”）。应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。举个例子，比如你提交应用程序时，指定使用 5 个 executor 运行你的应用程序，每个 executor 占用 5GB 内存和 5 个 CPU，每个 executor 内部设置了 5 个 slot，则 Mesos 需要先为 executor 分配资源并启动它们，之后开始调度任务。另外，在程序运行过程中，mesos 的 master 和 slave 并不知道 executor 内部各个 task 的运行情况，executor 直接将任务状态通过内部的通信机制汇报给 Driver，从一定程度上可以认为，每个应用程序利用 mesos 搭建了一个虚拟集群自己使用。

2. 细粒度模式（Fine-grained Mode）：鉴于粗粒度模式会造成大量资源浪费，Spark On Mesos 还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算，思想是按需分配。与粗粒度模式一样，应用程序启动时，先会启动 executor，但每个 executor 占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos 会为每个 executor 动态分配资源，每分配一些，便可以运行一个新任务，单个 Task 运行完之后可以马上释放对应的资源。每个 Task 会汇报状态给 Mesos slave 和 Mesos Master，便于更加细粒度管理和容错，这种调度模式类似于 MapReduce 调度模式，每个 Task 完全独立，优点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。

3. Spark On YARN 模式

这是一种很有前景的部署模式。但限于 YARN 自身的发展，目前仅支持粗粒度模式（Coarse-grained Mode）。这是由于 YARN 上的 Container 资源是不可以动态伸缩的，一旦 Container 启动之后，可使用的资源不能再发生变化，不过这个已经在 YARN 计划中了。

spark on yarn 的支持两种模式：

1. yarn-cluster：适用于生产环境；
2. yarn-client：适用于交互、调试，希望立即看到 app 的输出

yarn-cluster 和 yarn-client 的区别在于 yarn appMaster，每个 yarn app 实例有一个 appMaster 进程，是为 app 启动的第一个 container；负责从 ResourceManager 请求资源，获取到资源后，告诉 NodeManager 为其启动 container。yarn-cluster 和 yarn-client 模式内部实现还是有很大的区别。如果你需要用于生产环境，那么请选择 yarn-cluster；而如果你仅仅是 Debug 程序，可以选择 yarn-client。

总结：

这三种分布式部署方式各有利弊，通常需要根据实际情况决定采用哪种方案。进行方案选择时，往往要考虑公司的技术路线（采用 Hadoop 生态系统还是其他生态系统）、相关技术人才储备等。上面涉及到 Spark 的许多部署模式，究竟哪种模式好这个很难说，需要根据你的需求，如果你只是测试 Spark Application，你可以选择 local 模式。而如果你数据量不是很多，Standalone 是个不错的选择。当你需要统一管理集群资源（Hadoop、Spark 等），那么你可以选择 Yarn 或者 mesos，但是这样维护成本就会变高。
· 从对比上看，mesos 似乎是 Spark 更好的选择，也是被官方推荐的
· 但如果你同时运行 hadoop 和 Spark,从兼容性上考虑，Yarn 是更好的选择。 · 如果你不仅运行了 hadoop，spark。还在资源管理上运行了 docker，Mesos 更加通用。
· Standalone 对于小规模计算集群更适合！