任务变慢了，我们先看哪里？

把一次 T+1 运行拆成阶段，用证据定位瓶颈，再验证一个可以被复测的假设。

性能诊断ScanStage / Task

T+1 反欺诈特征任务开始变慢

这条离线 T+1 任务每天读取 Transaction（账户交易），加工客户与交易对手特征。一次运行的教学模拟记录已经从几分钟变成 68 min；现在要做的第一件事，是找到时间到底花在哪里。

主案例Transaction账户交易事实，一行一笔交易事件

业务问题客户交易对手特征历史累计、首次出现、最近 30 天

本次记录68 minrelative simulation / 教学模拟值

如果只知道任务变慢了，下一步应该先加资源，还是先找出最慢的阶段？

核心概念

性能诊断：先定位，再改变计算

性能诊断是一个可复核的过程：从症状出发拆执行阶段，收集证据，提出假设，实施小范围修改，重新测量，并检查副作用。

这次加工的业务日期是 2026-09-16。Transaction 以 txn_date 作为业务日期字段；counterparty_id 只在本章作为分析标识和特征键，不新增一个交易对手业务实体。

一次运行的阶段记录是 Scan 41 min、Join 6 min、Shuffle 15 min、Aggregate 5 min、Write 1 min。它们加起来是 68 min 的教学模拟值，但分布式任务还要另外观察最长 Task，不能只拿总时间或平均时间做结论。

症状：T+1 结果变慢，业务窗口开始有风险。
阶段：先分开看 Scan、Join、Shuffle、Aggregate 和 Write。
证据：Query Plan、Stage、Task、Scan Bytes、Shuffle Bytes 是真实系统中常见的观测入口；本节不教授某个引擎的执行计划语法。

11-1 · Stage / Task 诊断

点击阶段查看对应证据。选对首要阶段后，执行一次只改变 Scan 假设的验证性测量；如果选的是候选阶段，也要保留“证据还不够”的判断。

正在加载交互实验…

存储与执行层先回答“哪些数据被读了、文件怎样被读、哪个 Task 拖住了整体”。本节看到 Scan 41 min，因此优先调查分区命中、文件数量和 Task 证据。

如果读取范围已经合理，再看计算方案层：是否提前过滤、提前聚合，是否让 Join 或 Shuffle 传输了不必要的数据。最后才回到业务语义层，问“是不是每天都需要重新计算完整历史”。三层可能相互影响，但不能用一个模糊的“调优”代替定位。