1、Spark 三种集群部署模式的比较目前 Apache Spark 支持三种分布式部署方式，分别是 standalone、spark on mesos 和 spark on YARN，其中，第一种类似于 MapReduce 1.0 所采用的模式，内部实现了容错性和资源管理，后两种则是未来发展的趋势，部分容错性和资源管理交由统一的资源管理系统完成：让 Spark 运行在一个通用的资源管理系统之上，这样可以与其他计算框架，比如 MapReduce，公用一个集群资源，最大的好处是降低运维成本和提高资源利用率（资源按需分配） 。本文将介绍这三种部署方式，并比较其优缺点。1. standalone 模式，
2、即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统。从一定程度上说，该模式是其他两种的基础。借鉴 Spark 开发模式，我们可以得到一种开发新型计算框架的一般思路：先设计出它的 standalone 模式，为了快速开发，起初不需要考虑服务（比如master/slave）的容错性，之后再开发相应的 wrapper，将 stanlone 模式下的服务原封不动的部署到资源管理系统 yarn 或者 mesos 上，由资源管理系统负责服务本身的容错。目前 Spark 在 standalone 模式下是没有任何单点故障问题的，这是借助 zookeeper 实现的，思想类似于
3、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
4、和 Reduce Task 使用，而不能共享，这是 MapReduce资源利率低效的原因之一，而 Spark 则更优化一些，它不区分 slot 类型，只有一种 slot，可以供各种类型的 Task 使用，这种方式可以提高资源利用率，但是不够灵活，不能为不同类型的 Task 定制 slot 资源。总之，这两种方式各有优缺点。2. Spark On Mesos 模式。这是很多公司采用的模式，官方推荐这种模式（当然，原因之一是血缘关系） 。正是由于 Spark 开发之初就考虑到支持 Mesos，因此，目前而言，Spark 运行在 Mesos 上会比运行在 YARN 上更加灵活，更加自然。目前在 Sp
5、ark On Mesos 环境中，用户可选择两种调度模式之一运行自己的应用程序（可参考 Andrew Xia 的“ Mesos Scheduling Mode on Spark”）：1) 粗粒度模式（Coarse-grained Mode）：每个应用程序的运行环境由一个 Dirver 和若干个 Executor 组成，其中，每个 Executor 占用若干资源，内部可运行多个 Task（对应多少个“slot”） 。应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。举个例子，比如你提交应用程序时，指定使用
6、 5 个 executor 运行你的应用程序，每个executor 占用 5GB 内存和 5 个 CPU，每个 executor 内部设置了 5 个 slot，则Mesos 需要先为 executor 分配资源并启动它们，之后开始调度任务。另外，在程序运行过程中，mesos 的 master 和 slave 并不知道 executor 内部各个task 的运行情况，executor 直接将任务状态通过内部的通信机制汇报给Driver，从一定程度上可以认为，每个应用程序利用 mesos 搭建了一个虚拟集群自己使用。2) 细粒度模式（Fine-grained Mode）：鉴于粗粒度模式会造成大量资
7、源浪费，Spark On Mesos 还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算，思想是按需分配。与粗粒度模式一样，应用程序启动时，先会启动 executor，但每个 executor 占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos 会为每个 executor动态分配资源，每分配一些，便可以运行一个新任务，单个 Task 运行完之后可以马上释放对应的资源。每个 Task 会汇报状态给 Mesos slave 和 Mesos Master，便于更加细粒度管理和容错，这种调度模式类似于 MapReduce 调度模式，每个 Task 完全独立，优
8、点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。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-c
9、lient 的区别在于 yarn appMaster，每个 yarn app 实例有一个 appMaster 进程，是为 app 启动的第一个 container；负责从ResourceManager 请求资源，获取到资源后，告诉 NodeManager 为其启动container。yarn-cluster 和 yarn-client 模式内部实现还是有很大的区别。如果你需要用于生产环境，那么请选择 yarn-cluster；而如果你仅仅是 Debug 程序，可以选择 yarn-client。总结：这三种分布式部署方式各有利弊，通常需要根据实际情况决定采用哪种方案。进行方案选择时，往往要考虑公
10、司的技术路线（采用 Hadoop 生态系统还是其他生态系统） 、相关技术人才储备等。上面涉及到 Spark 的许多部署模式，究竟哪种模式好这个很难说，需要根据你的需求，如果你只是测试 Spark Application，你可以选择 local 模式。而如果你数据量不是很多， Standalone 是个不错的选择。当你需要统一管理集群资源（Hadoop、Spark 等） ，那么你可以选择 Yarn 或者 mesos，但是这样维护成本就会变高。 从对比上看，mesos 似乎是 Spark 更好的选择，也是被官方推荐的 但如果你同时运行 hadoop 和 Spark,从兼容性上考虑，Yarn 是更好的选择。 如果你不仅运行了 hadoop，spark 。还在资源管理上运行了 docker，Mesos更加通用。 Standalone 对于小规模计算集群更适合！
