用途
该技能面向超出单机处理能力、需要分布式执行规范的批处理工作负载。它帮助智能体在以下场景中做出合理判断：构建或修改 Spark 作业；在 Spark、Glue、EMR 或更小的引擎之间做选择；调试代价高昂的连接、数据倾斜、shuffle 或内存问题；为大型文件或分区表设计批处理管道；针对 Iceberg、Delta、Hudi 等湖仓表实现转换。
不适用于可轻松放入单个进程的轻量级本地转换。
工作流程
-
确认是否确实需要分布式执行。需检查：输入数据量、延迟预期、转换复杂度、文件大小与分区数量、与更简单引擎相比的成本。
-
有意选择运行时：Spark 提供直接控制和广泛生态支持；Glue 是 AWS 原生的托管 Spark 执行；EMR 提供对 Spark 及相关引擎更广泛的集群控制；短生命周期或无服务器 Spark（Lambda、无服务器 Glue、硬性超时上限）应加载 spark-serverless-reliability-and-state-management。
-
设计物理计划而不仅是逻辑计划。需考虑：分区与文件布局、高 shuffle 的连接、倾斜键、检查点或中间持久化、写入模式与幂等行为。
-
在边界处保持数据契约可见。在昂贵执行前验证输入假设，在发布前验证输出契约。
-
使回填与重跑安全。历史批量重算应明确定义覆盖、合并或追加语义。
常见合理化借口
- “Spark 会替我们处理优化。”——引擎优化有帮助，但糟糕的分区、倾斜和写入策略仍会导致失败或巨额成本。
- “我们直接扩集群就行。”——扩容常掩盖糟糕的物理设计，且仍可能因倾斜或错误的 shuffle 而失败。
- “托管 Spark 意味着不需要做运行时设计。”——Glue 和 EMR 仍需要有意的分区、重试和存储策略。
危险信号
- 没有规模或延迟理由就选择 Spark
- 分区和写入策略未定义
- 连接忽略倾斜的业务键
- 历史加载的重跑行为不清晰
- 在更小引擎更简单、更便宜的地方使用分布式计算
验证清单
- 运行时选择相对于工作负载需求有正当理由
- 分区、连接策略和写入语义明确
- 输入和输出边界存在契约与质量检查
- 分布式作业的回填与重试行为有文档记录