课程导入：学习目标、课程结构、性能调优的整体思路
欢迎来到《Spark与Iceberg读写性能调优实战》。在正式接触调优参数、执行计划分析和存储布局优化之前，我们需要先回答三个根本问题：这门课带你到达哪里？课程如何组织？以及面对一个性能问题时，正确的思考路径是什么？本章作为全课程的“导航图”，将为你建立一套可复用的调优方法论框架，避免后续陷入“盲目调参”的泥潭。
1.1 学习目标：从“能跑”到“跑得快且稳”
完成本课程后，你应当具备以下四项核心能力，它们分别对应调优工作的不同层次：
| 能力维度 | 具体表现 | 对应章节范围 |
|---|---|---|
| 定位瓶颈 | 能通过Spark UI、Event Log、CloudWatch等工具，在5分钟内定位CPU、内存、网络或磁盘I/O瓶颈 | 第2-5章 |
| 读写调优 | 能针对Parquet/ORC文件、分区策略、谓词下推、Shuffle分区数等给出具体优化方案 | 第6-15章 |
| Iceberg深度优化 | 理解Snapshot隔离、Manifest合并、Compaction策略对查询延迟的影响，并掌握数据布局优化技巧 | 第16-24章 |
| 实战调优 | 能独立完成从“现象描述→假设验证→方案实施→效果评估”的完整调优闭环 | 第25-30章 |
1.2 课程结构：四阶段递进式设计
30章内容按照“基础→读写→Iceberg→综合实战”的逻辑展开，每一阶段都建立在前一阶段的能力之上。下图展示了课程的整体架构与知识依赖关系：
这种递进设计的用意在于：先建立“诊断直觉”，再学习“优化手段”，然后深入“Iceberg特性”，最后通过综合实战将知识串联成技能。每一章都配有可运行的示例和可量化的性能对比，确保你不仅知道“怎么做”，更理解“为什么这样做”。
1.3 性能调优的整体思路：一个中心，两个基本点
面对任何Spark与Iceberg的性能问题，请始终围绕“减少数据扫描量”这一中心目标，同时把握“CPU效率”和“I/O效率”两个基本点。大量调优案例表明，80%的性能问题源于不必要的数据读取或低效的数据布局，而非计算本身。
调优决策应遵循以下优先级顺序：
- 架构层面（收益最大）：分区裁剪、文件格式、数据布局、Iceberg表属性。此层面优化往往能带来5-20倍性能提升。
- 执行层面（收益中等）：Shuffle分区数、广播阈值、内存分配、并行度设置。此层面优化通常带来1.5-3倍提升。
- 代码层面（收益局部）：避免UDF滥用、优化Join顺序、使用缓存。此层面优化提升幅度在10%-50%不等。
一个典型的调优案例：某数据团队反馈“按天过滤的查询需要40秒”。初步分析发现，虽然SQL中使用了WHERE event_date = '2024-05-20'，但Iceberg表未按日期分区，导致Spark扫描了全表所有数据文件。将表重建为按event_date分区后，查询时间降至3秒。整个调优过程没有修改任何Spark参数，仅通过数据布局优化就获得了13倍性能提升。
1.4 常见误区与复盘
在开始系统学习之前，先了解几个初学者最容易陷入的误区，这能帮助你避免在后续实践中走弯路：
| 误区 | 错误认知 | 正确理解 |
|---|---|---|
| 盲目增加Executor | 资源越多，任务越快 | 资源增加会加剧Shuffle和调度开销，需结合数据量测试最优并行度 |
| 忽略数据倾斜 | 集群资源充足就能处理 | 单个热点Task会拖垮整个Stage，需通过加盐、广播或重分区解决 |
| 过度依赖Spark缓存 | 缓存能解决所有重复查询 | 缓存占用内存可能导致GC频繁，需评估数据新鲜度和内存成本 |
| 忽视Iceberg快照管理 | 快照越多越安全 | 过多快照会膨胀元数据并拖慢查询规划，需定期执行expire_snapshots |
复盘提醒：性能调优不是一次性的活动，而是伴随数据增长和查询模式变化的持续过程。建议每次调优后记录：问题现象、假设原因、验证方法、改动参数、性能对比。当积累10个以上调优案例后，你会发现自己对Spark与Iceberg的理解将发生质的飞跃。