Spark 任务跑了 3 个小时。
屏幕上进度条不动，监控里红一块绿一块，群里已经有人问：“今天这批数什么时候能出来？”
这时候最容易做的一件事，是打开 AI，问一句：
“Spark 任务太慢，怎么调优？”
它会很快给你一堆建议。加 executor，调 shuffle partition，广播小表，检查数据倾斜，开启 AQE。每一句都像对的。
问题是，你的任务到底慢在哪里，它不知道。
慢任务不是一种病
做数据开发的人都知道，Spark 慢起来有很多原因。
可能是扫描了太多历史分区，可能是 join 键倾斜，可能是小文件太多，可能是 UDF 拖慢，可能是某个上游字段突然膨胀，也可能只是资源被别人抢走了。
这些问题最后都叫“慢”，但处理方式完全不同。
如果不先定位原因，调参就像在黑屋子里拧螺丝。拧对了算运气，拧错了还会把问题藏得更深。
Expedia Group 最近写了一篇文章，讲他们用 LLM 分析 Spark SQL Plans，辅助排查长时间运行的任务。这个方向值得看，但重点不是“AI 会调参了”。
重点是：他们先把 Spark SQL Plan 这样的中间证据拿出来，再让模型分析。
这和随口问 AI 差别很大。
第一份证据：执行计划
执行计划是 Spark 告诉你的“我准备怎么干活”。
它会暴露很多事情：有没有全表扫描，有没有大范围 shuffle，有没有奇怪的 join 顺序，有没有过滤条件没下推，有没有本该广播的小表被当成大表处理。
如果你只问 AI “任务慢怎么办”，它只能背通用答案。
如果你把执行计划给它，它至少开始面对你的真实任务。
不过这里要注意一件事：不要把执行计划当神谕。
执行计划是线索，不是结论。你还要结合数据量、运行时间、资源使用和业务逻辑一起看。否则很容易看到一个 shuffle 就激动，看到一个 scan 就焦虑。
真正该问的是：这一步为什么发生？它处理了多少数据？它是不是符合业务预期？
第二份证据：运行指标
执行计划说明“准备怎么做”，运行指标说明“实际卡在哪”。
你至少要看几个东西：
- 哪个 stage 时间最长；
- 哪个 task 明显拖后腿；
- shuffle read / write 是否异常；
- 输入数据量是不是突然变大；
- executor 是否频繁 GC 或失败重试。
这些指标可以帮你区分两类问题。
一类是逻辑问题：SQL 写法、join 顺序、分区裁剪、过滤条件、聚合方式。
另一类是资源问题：集群资源不足、并发任务太多、内存不够、磁盘或网络压力。
这两类问题不能混着治。
逻辑问题靠加资源，往往只是把浪费放大。资源问题靠改 SQL，有时候又是在折磨自己。
第三份证据：业务上下文
这是最容易被忽略的一份证据。
AI 很可能告诉你：这个 join 可以改，这个字段可以提前过滤，这个窗口可以简化，这个聚合可以挪位置。
技术上可能对。
业务上不一定。
比如一个订单表里有取消订单、退款订单、补录订单。某个字段看起来可以过滤掉，但它恰好是财务对账要看的异常样本。再比如一个日期字段看起来可以按天分区，实际业务却按结算周期看。
如果没有业务上下文，AI 的优化建议有时会把慢任务变成快错任务。
快错最危险。
慢任务至少有人盯着，快错会安静地流进报表。
所以你在让 AI 看慢任务之前，最好补一句：这张表在业务里干什么，这个指标不能改哪些口径，哪些字段看起来没用但实际不能删。
一个实用的排查顺序
下次 Spark 任务跑慢，可以先别急着问“怎么调参”。
按这个顺序走一遍：
- 先确认是不是数据量变了：输入分区、行数、文件数有没有异常。
- 再看执行计划：有没有大 shuffle、无效 scan、奇怪 join。
- 再看运行指标：最长 stage、最慢 task、重试和资源使用。
- 最后带着业务边界问 AI：这些优化建议会不会改变结果。
这个顺序不酷。
但它能救你少走很多弯路。
真正专业的数据开发，不是每个参数都背得很熟，而是在一堆看似合理的建议里，知道哪一条适合当前任务，哪一条会把结果改坏。
AI 可以帮你看线索。
判断还得你来做。
我叫石头，在数据行业里摸爬滚打了十几年，最怕的不是慢任务，而是没人知道它为什么慢。这里写的，就是这些教训——我觉得值得说出来的那部分。
