3. 集群架构与选型策略
在 Databricks 上，集群是计算资源的载体，也是成本产生的主要来源。同一段 Spark 作业，跑在不同类型、不同规模、不同伸缩策略的集群上，执行时间和账单金额可能相差数倍。因此，理解集群架构与选型逻辑，是性能优化与成本治理的第一道关口。本节围绕四个关键决策维度展开：集群用途（All-Purpose 还是 Job）、节点拓扑（单节点还是多节点）、伸缩方式（固定还是自动伸缩）、实例类型（Spot 还是按需），并给出可落地的权衡方法。
一、All-Purpose 集群与 Job 集群：用途决定成本模型
All-Purpose 集群（通用集群）面向交互式分析，支持多人共享、Notebook 交互、SQL 查询和探索性开发。它的特点是生命周期由人工控制，可以长期运行，支持多用户并发，但计费单价通常高于 Job 集群，且空闲时若未配置自动终止，会持续产生费用。Job 集群则专为自动化任务设计，由 Job 调度器在任务开始时创建、任务结束后自动销毁，计费单价更低，且天然避免了闲置浪费。
选型的核心判断是：这段计算是否需要人工交互？ 如果答案是“需要反复调试、查看中间结果、多人协作”，用 All-Purpose；如果答案是“已经定型、按计划自动运行、跑完即止”，用 Job 集群。实践中常见的浪费是：把生产 ETL 任务挂在长期运行的 All-Purpose 集群上，既支付了更高单价，又让集群在非任务时段空转。一个合理的做法是，开发阶段用 All-Purpose 集群调试，验证通过后将同一份代码提交为 Job，由 Job 集群执行。
需要补充的是，Job 集群的启动时间（冷启动）通常比复用已有 All-Purpose 集群更长，对于秒级、分钟级的短任务，冷启动开销可能占比过高。此时可以评估使用 Job 集群配合实例池（Instance Pool），让节点预先就绪，缩短启动时间。
二、单节点与多节点：并行度与开销的取舍
单节点集群只有一个 Driver 节点，Spark 以本地模式运行，没有分布式 shuffle 和网络通信开销。它适合数据量小、逻辑简单、以单机内存和 CPU 就能处理的任务，例如小规模数据清洗、配置生成、轻量级脚本。单节点的优势是启动快、无跨节点通信、成本低；劣势是无法水平扩展，受限于单机内存和核数。
多节点集群由一个 Driver 和若干 Worker 组成，任务被切分为分区并行执行，适合大数据量、需要 shuffle 的聚合与连接操作。多节点的关键参数是 Worker 数量与每节点规格。这里有一个常被忽视的权衡：少量大节点与多量小节点在总核数相同时，前者网络跳数少、单节点内存大，适合宽表连接和内存密集型任务；后者并行度高、故障影响面小，适合分区均匀、CPU 密集型的任务。选择时应结合数据倾斜程度和 shuffle 规模判断。
三、自动伸缩：让集群跟随负载变化
自动伸缩（Autoscaling）允许集群在最小和最大 Worker 数之间，根据待处理任务量动态增减节点。它的价值在于：负载高峰时扩容保证吞吐，负载低谷时缩容降低成本。配置时需要设定三个关键量：最小 Worker 数、最大 Worker 数和伸缩策略。
最小 Worker 数决定了集群的基线成本，设得过高会长期浪费，设得过低则高峰来临时扩容不及时。最大 Worker 数决定了成本上限和并行度上限，设得过高可能在数据倾斜时被少数大分区“骗”着扩到很大，反而拉长尾任务并推高成本。一个实用的经验是：先用固定规模跑一次代表性任务，观察各阶段的活跃任务数，再据此设定最小值和最大值，而不是凭感觉填写。
自动伸缩并非万能。对于 shuffle 量巨大、需要所有节点同时参与的任务，缩容可能导致中间数据重新计算；对于启动开销敏感的短任务，伸缩的响应延迟可能得不偿失。因此，自动伸缩更适合负载波动明显、任务持续时间较长的场景。
四、Spot 实例与按需实例：成本与中断风险的平衡
Spot 实例（抢占式实例）来自云厂商的闲置容量，价格通常仅为按需实例的一小部分，但可能被随时回收。Databricks 支持在集群中混合使用 Spot 和按需实例：Driver 节点建议使用按需实例以保证稳定性，Worker 节点可以大量使用 Spot 以降低成本。
使用 Spot 的核心风险是中断。当 Spot 节点被回收时，其上运行的任务需要重新调度，可能导致作业变慢甚至失败。降低风险的手段包括：为集群配置足够的 Spot 比例上限、开启“按需实例兜底”（当 Spot 不足时自动补充按需节点）、将 Driver 和关键状态放在按需节点上。对于可容忍重试的批处理任务，Spot 比例可以设得较高；对于时效性强的任务，应保留更多按需实例。
下面这张图把本节四个决策维度组织成一条选型判断链，从任务特征出发，依次经过用途、拓扑、伸缩和实例类型，最终落到成本与性能的权衡结果。
五、把四个维度落到一次具体选型
假设有一个每日凌晨运行的订单汇总任务，数据量约 800 GB，包含一次大表连接和一次聚合，要求 2 小时内完成，允许失败重试。按判断链走一遍：任务已定型、自动运行，选 Job 集群；数据量大、需要 shuffle，选多节点；负载在凌晨集中、白天无任务，选自动伸缩，最小 Worker 设为 2、最大设为 20；任务可重试，Worker 大量使用 Spot，Driver 用按需实例，Spot 比例上限设为 80%。这样既压低了单价，又用自动伸缩避免了任务结束后的空转。
反过来，如果是一个数据分析师白天反复查询的探索性 Notebook，则应选 All-Purpose 集群，配置自动终止时间为 45 分钟，Worker 数量按查询规模设定，不必强上 Spot，以免查询中途节点被回收打断交互体验。
总结来看，集群选型的本质是在单价、时长、利用率、中断风险四个变量之间寻找平衡点。All-Purpose 与 Job 决定单价与生命周期，单节点与多节点决定并行能力与开销，自动伸缩决定利用率，Spot 与按需决定单价与风险。把这四个维度按任务特征依次判断，再辅以实测数据校准，就能在保证性能的前提下，把集群成本控制在合理区间。