在 ETL 作业中，Spark SQL 的性能优化通常有哪些处理办法？请给出若干常用的调优技巧。
考察说明
考查对 Spark SQL 在 ETL 场景下的性能优化手段的理解和实际应用能力。
回答思路
- 【回答框架 1】ETL 性能瓶颈常见于数据倾斜、小文件过多、Shuffle 开销大、资源利用不足等。调优先从诊断入手：通过 Spark UI 观察 Stage 耗时、Shuffle 读写量、Executor 负载，定位瓶颈是 CPU、内存、IO 还是网络。
- 【回答框架 2】针对数据倾斜，可用加盐（salting）或广播小表（broadcast join）缓解。加盐将热点 key 随机拆分，聚合时二次去重；广播小表避免大表 join 小表时的 Shuffle，需控制小表大小并开启自动广播阈值参数。
- 【回答框架 3】资源优化：合理设置 Executor 内存（如 spark.executor.memory）、并行度（spark.sql.shuffle.partitions）和动态资源分配。ETL 作业通常 IO 密集，可适当增加并行度但需避免过多小任务导致调度开销。
- 【回答框架 4】文件优化：使用 coalesce 或 repartition 控制输出分区数，避免小文件过多；开启自适应查询执行（AQE）可自动合并小分区、优化 Join 策略。
- 【回答框架 5】代码层面：避免不必要的列和行，尽早过滤（filter pushdown）、使用恰当的数据格式（如 Parquet）并启用压缩；减少重复计算，复用 DataFrame 或使用缓存（cache）仅当复用明确。
- 【关键点 1】调优前先基于 Spark UI 定位瓶颈，而非盲目设置参数。
- 【关键点 2】数据倾斜可用加盐或广播 join 缓解，广播 join 需小表且开启自动广播阈值。
- 【关键点 3】合理设置 Executor 内存、shuffle 分区数与并行度，并结合 AQE 自适应优化。
- 【关键点 4】控制输出分区数减少小文件，使用列式存储和过滤下推提升性能。
- 【关键点 5】ETL 作业应平衡资源与延迟，最终以压测和实际资源为准。
- 【易错点 1】不当增加并行度可能导致小任务过多，反而增加调度开销。
- 【易错点 2】广播小表若不限制大小或数据更新频繁，可能造成内存压力或数据不一致。
- 【易错点 3】cache 并非总是提升性能，仅当数据被多次复用且内存足够时才应使用。