3. Spark部署模式：Local模式、Standalone模式、YARN模式、Mesos模式、Kubernetes模式
聊到Spark部署模式，我脑子里第一个蹦出来的念头就是——别选错了。
我自己刚接触Spark那会儿，觉得部署模式不就是个启动参数嘛，随便选一个就行。结果呢？在测试环境跑得好好的，上了生产就各种资源争抢、任务排队、节点失联……说白了，部署模式决定了Spark怎么跟底层集群打交道，选错了，后面全是坑。
3.1 Local模式：本地调试的“瑞士军刀”
Local模式，就是Spark在单机上跑。所有Executor、Driver都挤在一个JVM进程里。
你可能会问：这玩意儿有啥用？
嗯，我个人的习惯是：写代码阶段，先用Local模式快速验证逻辑。比如你写了个DataFrame的join操作，直接本地跑一下，几秒钟出结果，比提交到集群快多了。
启动方式：
# 本地1个线程
spark-shell --master local
# 本地4个线程
spark-shell --master local[4]
# 尽可能多的线程
spark-shell --master local[*]我的经验：local[*] 在开发机上很实用。它会自动检测CPU核数，把资源用满。但注意，别在生产环境用这个模式——我见过有人把local模式部署到服务器上，结果内存爆了，整个节点都挂了。
3.2 Standalone模式：Spark自带的“小集群”
Standalone模式，说白了就是Spark自己管自己。它自带Master和Worker进程，不需要依赖Hadoop、YARN这些外部资源调度器。
我记得第一次搭Standalone集群时，觉得特别爽——解压、配置、启动，三步搞定。对于小团队或者实验环境，这模式简直不要太方便。
架构示意：
Master节点：负责资源调度
└── Worker节点1：启动Executor
└── Worker节点2：启动Executor
└── Worker节点3：启动Executor但Standalone有个硬伤：没有高可用。Master挂了，整个集群就瘫了。我曾经在项目中吃过这个亏——凌晨三点，Master节点宕机，所有任务中断，爬起来手动重启……
避坑指南：如果你要用Standalone模式，一定要配置ZooKeeper实现Master高可用。别问我怎么知道的，问就是血的教训。
3.3 YARN模式：企业级“标配”
YARN模式，是目前生产环境最常用的部署方式。它把Spark任务提交到Hadoop YARN集群上，由YARN负责资源分配和调度。
为什么大家都爱用YARN？原因很简单：资源共享。你想想看，公司里既有MapReduce任务，又有Spark任务，还有Flink任务，如果每个框架都自己管资源，那不乱套了？YARN就像一个“资源大管家”，谁要用资源，找它申请就行。
两种运行模式：
| 模式 | Driver位置 | 适用场景 |
|---|---|---|
| yarn-client | 客户端（提交任务的机器） | 调试、交互式分析 |
| yarn-cluster | YARN集群内部 | 生产环境、离线批处理 |
我个人习惯是：调试用yarn-client，上线用yarn-cluster。为什么？yarn-client模式下，Driver在客户端，你可以直接看到日志，方便排查问题。但生产环境如果还用yarn-client，客户端一断连，任务就挂了——这坑我踩过。
小技巧：提交任务时，记得设置 --num-executors、--executor-cores、--executor-memory 这三个参数。我见过太多人只设一个，结果资源分配不合理，任务跑得比蜗牛还慢。
3.4 Mesos模式：曾经的“资源调度王者”
Mesos模式，现在用得少了，但我觉得还是值得提一嘴。Mesos是一个通用的资源调度框架，Spark可以跑在它上面。
Mesos有两个调度模式：
- 粗粒度模式：Spark提前申请好资源，用完了再释放。跟YARN类似。
- 细粒度模式：Spark按需申请资源，用完立刻释放。资源利用率更高，但调度开销也大。
说实话，我在项目中只用过一次Mesos。那时候公司已经有现成的Mesos集群，想着“拿来就用”呗。结果呢？配置复杂、社区活跃度下降、文档不全，折腾了两周才跑通。后来还是切回了YARN。
我的建议：除非你公司已经有成熟的Mesos集群，否则别轻易尝试。现在Kubernetes这么火，Mesos基本被边缘化了。
3.5 Kubernetes模式：云原生的“新宠”
Kubernetes模式，是Spark 2.3之后引入的。它让Spark任务可以像容器一样，在K8s集群上运行。
为什么K8s模式这么火？说白了，云原生是大趋势。你想想看，现在大家都在搞容器化、微服务，如果Spark还依赖YARN，那跟整个技术栈就脱节了。
K8s模式的优势：
- 资源隔离：每个Executor跑在独立的Pod里，互不干扰
- 弹性伸缩：可以根据负载自动扩缩容
- 统一管理：跟其他微服务共享K8s集群，运维成本低
我记得第一次在K8s上跑Spark任务时，遇到一个坑：Driver Pod挂了，任务直接失败。后来才发现，需要配置 spark.kubernetes.allocation.driver.podTemplateFile 来设置重启策略。嗯，这些细节，文档里写得不够清楚，得自己踩一遍才知道。
我的经验：K8s模式适合“云原生”场景，比如你已经在用K8s管理微服务，那Spark也跑在K8s上，运维会非常统一。但如果你公司还是传统的Hadoop集群，那YARN模式更稳妥。
3.6 如何选择？一张表说清楚
好了，五种模式都讲完了。你可能会问：那我到底该选哪个？
我整理了一张对比表，你一看就明白：
| 模式 | 适用场景 | 资源管理 | 高可用 | 推荐指数 |
|---|---|---|---|---|
| Local | 本地开发、单元测试 | 单机 | 无 | ⭐⭐⭐ |
| Standalone | 小集群、实验环境 | Spark自带 | 需配置ZooKeeper | ⭐⭐⭐ |
| YARN | 生产环境、大数据平台 | YARN | 原生支持 | ⭐⭐⭐⭐⭐ |
| Mesos | 已有Mesos集群 | Mesos | 原生支持 | ⭐⭐ |
| Kubernetes | 云原生、容器化 | K8s | 原生支持 | ⭐⭐⭐⭐ |
我个人建议：新手先从Local模式开始学，生产环境首选YARN模式。如果你公司已经在搞云原生，那K8s模式值得投入精力去研究。
好了，这一章就聊到这儿。下一章我们讲讲Spark作业提交流程——说白了，就是你的代码是怎么从本地跑到集群上的。到时候我会分享一些“提交任务时容易踩的坑”，敬请期待。