1. 课程导入与性能治理全景
在 Databricks 平台上，性能优化与容量治理并不是两个独立话题，而是同一套工程体系的两面：性能决定单位计算资源能产出多少有效结果，容量治理决定这些资源是否被合理分配、持续可用且成本可控。很多团队在 Lakehouse 上遇到的第一类问题往往表现为“作业变慢”，但真正的原因可能来自数据布局、计算资源配置、并发争抢、Shuffle 膨胀、缓存策略、集群生命周期或权限与配额限制。若只盯着某一条 SQL 或某一个 Spark 参数，很容易陷入局部优化，甚至把瓶颈从计算层推到存储层或调度层。
本课程的核心目标可以概括为三条主线：第一，建立从“症状”到“根因”的定位能力，能够区分是数据问题、计算问题、调度问题还是资源治理问题；第二，掌握可落地的优化手段，包括分区与文件布局、Join 与聚合策略、AQE 与自适应执行、Photon 与运行时选择、缓存与物化、集群规格与自动伸缩；第三，把优化结果纳入容量治理闭环，用指标、配额、成本与 SLA 共同约束，避免“优化一次、退化很快”。
一个典型教学示例：某团队在 Databricks 上运行每日销售汇总作业，输入表 fact_sales 约 8 TB，按 dt 分区，但每个分区内存在大量小文件。作业原本 40 分钟完成，近期逐步退化到 2 小时以上。初步观察：Executor CPU 利用率不高，但 Shuffle Read 很大，且任务数远高于预期。此时若直接扩容集群，成本上升但耗时改善有限；更合理的路径是先检查文件数量与分区裁剪，再评估 Join 策略与 AQE 是否生效，最后才调整集群规格与并发。
为了把这类问题讲清楚，本课程采用“分层治理”的方法论。最上层是业务目标与 SLA，中间是作业与查询的执行特征，底层是存储布局与计算资源。每一层都有对应的观测指标和干预手段。下图给出整体方法论与学习路径的关系：从症状观测出发，经过分层定位，进入具体优化手段，最终回到容量治理与持续监控。
上图把课程结构映射为四层治理模型。需要强调的是，这四层不是严格的瀑布顺序，而是迭代循环：当你在执行特征层发现 Shuffle 过大时，可能需要回到存储布局层调整分区或聚类；当容量治理层发现成本异常时，也可能需要重新审视 SLA 是否合理。真正的优化能力体现在“知道当前该看哪一层、该动哪一层”。
关键挑战：为什么性能问题难以一次解决
Databricks 的性能挑战具有几个典型特征。第一，症状与根因跨层：一个“查询变慢”可能由小文件、数据倾斜、错误的 Join 策略、集群规格不足或并发争抢共同导致。第二，动态性：数据量、用户数、并发作业每天都在变化，今天的优化参数明天可能不再适用。第三，成本与性能的权衡：增加集群规格可以缩短耗时，但 DBU 成本上升；过度分区可以提升裁剪率，但小文件问题会加剧。第四，可观测性依赖：没有 Spark UI、Query Profile、集群指标和成本标签，优化只能靠猜。
建议的入门检查顺序：先看 Query Profile 或 Spark UI 中耗时最长的 Stage，判断是 Shuffle、IO 还是 CPU 瓶颈；再检查输入表的文件数量与分区裁剪情况；然后确认 AQE、Photon、缓存等运行时特性是否按预期生效；最后才考虑调整集群规格或并发配额。这个顺序可以避免“先扩容、后发现问题不在资源”的常见浪费。
整体方法论：观测、定位、干预、固化
本课程贯穿的方法论可以概括为四步。第一步是观测：建立基线，记录作业耗时、DBU 消耗、Shuffle 量、Spill 量、任务倾斜度等指标。第二步是定位：利用 Spark UI 的 Stage/Task 视图、Query Profile 的算子级耗时、以及表级统计信息，把瓶颈缩小到具体算子或数据分区。第三步是干预：选择最小必要手段，例如调整分区数、改写 Join、启用 AQE 倾斜处理、优化文件布局或调整集群策略。第四步是固化：把有效配置写入作业模板、集群策略或表属性，并设置回归监控，防止优化效果随时间退化。
为了便于后续章节对照，这里给出一个简化的治理闭环示例。假设某作业的 SLA 是 60 分钟内完成，当前耗时 95 分钟，DBU 成本 120。通过 Query Profile 发现一个 Stage 的 Shuffle Read 达到 2.1 TB，且存在明显倾斜。干预措施包括：对 Join 键进行加盐处理、启用 AQE 倾斜 Join、将输出分区数从 200 调整为 800。调整后耗时降至 52 分钟，DBU 成本降至 85。此时需要把分区数、AQE 配置和加盐逻辑固化到作业代码与集群策略中，并设置每日耗时与成本告警。这个示例中的数值为教学假设，用于说明判断逻辑，不代表真实实测结果。