T+1 任务突然变成 T+2——你怎么查的？
本文目录
先说结论
T+1 变 T+2 的四大常见原因：上游数据到达延迟、单个慢 SQL 拖累链路、下游资源队列排队、数据倾斜导致某个 task 跑飞。
排查从链路入手：看关键路径（Critical Path）——哪个节点拖了整条链路，不是看所有节点。
跨时区是最隐蔽的 T+1 到 T+2——看起来任务按时跑完了，但数据不在『业务方预期的那一天』，本质是 ETL 切日逻辑的问题。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
本来每天早上 8 点就能看的看板，某天突然早上 10 点还没出来——T+1 的任务变成了 T+2。这是生产问题里第二常见的场景。面试官问这道题想考你对『任务链路时效性』的理解：延迟发生在哪里、数据到齐没到齐、重跑要不要动下游、怎么防止再发生。能把这几层讲清楚，这题就过了。
业务场景：某短剧出海公司的跨时区延迟事故
我在某短剧出海公司处理过一次最痛的 T+1 变 T+2 事故。业务方说『美国昨天的数据今天没出』，我一查任务都跑完了——但当天美东的数据被归到了『明天』的分区里。这不是任务延迟，是切日逻辑错了。
-- 原始切日逻辑（错的）：
-- 我们服务器在 UTC+8，bizdate 是 UTC+8 的日期
-- 3/15 UTC+8 0:00 = 3/14 UTC-5 美东 11:00
-- 美东用户 3/14 整个白天的事件被切到 3/14 UTC+8 分区（正确）
-- 美东用户 3/14 晚上 23:00 的事件呢？
-- 那时候 UTC+8 已经是 3/15 12:00，事件被切到 3/15 分区（错！）
-- 正确做法：按用户时区切日
SELECT
CONVERT_TZ(event_ts, 'UTC', user_tz) AS local_ts,
DATE(CONVERT_TZ(event_ts, 'UTC', user_tz)) AS user_local_date,
-- 这是用户所在时区的 '业务日期'
...
FROM ods_event
JOIN dim_user USING (uid);
-- 然后按 user_local_date 分区，而不是按服务器日期修复过程花了 3 天，回刷了 40 多个下游任务。教训：出海业务的切日逻辑必须在最早的 DWD 层就明确——究竟是『按服务器 UTC+8』还是『按用户本地时区』，两套口径不能混用。
段落一：原因一——上游数据延迟到达
最常见的 T+1 变 T+2 原因是上游数据没按时到。上游可能是 Binlog 订阅、埋点回传、第三方数据回流。每一类都有自己的延迟模式。
| 上游类型 | 典型延迟模式 | 诊断方法 |
|---|---|---|
| Binlog 订阅 | 大事务、主从延迟 | 看 Canal / Debezium 的 lag 监控 |
| 埋点回传 | 客户端离线缓存、网络抖动 | 看 Kafka 消息的 event_time 分布 |
| 广告回传 | 第三方批量小时级/日级 | 对方约定时间 + buffer |
| 跨云同步 | 带宽瓶颈、时区切换 | 看同步工具的传输进度 |
排查手法：在 DataWorks 或 Airflow 里看任务依赖图，找最慢的那个节点。90% 的延迟都能看出来是某一个上游节点没按时就绪。
段落二：原因二——关键路径上的慢 SQL
调度依赖图 = DAG，其中『完成时间最晚的路径』叫关键路径（Critical Path）。关键路径上任何一个节点变慢，整条链路就延迟。关键路径之外的节点变慢不影响。
Plain
简化的数仓依赖链：
ODS_A → DWD_A ─┐
├─ DWS → ADS → 看板（8:00 截止）
ODS_B → DWD_B ─┘
正常时间：
ODS_A 2:00 到，DWD_A 4:00 完成
ODS_B 3:00 到，DWD_B 5:00 完成 ← 关键路径
DWS 5:30 完成，ADS 7:00 完成，看板 8:00
某天 DWD_B 开始变慢，6:30 才完成：
DWS 7:00 完成，ADS 8:30 完成
看板延迟 30 分钟 → 业务方投诉
排查：看每个任务的执行时长曲线，DWD_B 从 2 小时涨到 3.5 小时
进一步：那个 SQL 的 Spark UI 看 stage 时长分布
根因：数据倾斜（上一题 06 讲过）段落三：原因三——资源队列排队
凌晨高峰期（2-5 点）所有公司的 ETL 都在跑，资源队列排队是常事。表现是任务状态是『提交』但迟迟不开始执行。
看哪些指标：MaxCompute / Spark 的队列排队时长、YARN 的 Pending Applications 数量、集群的 CPU/内存使用率。如果发现是队列问题，解决手段：（1）核心链路独立资源队列；（2）错峰调度（非核心任务避开 2-5 点）；（3）扩容（最后手段）。
段落四：原因四——重跑策略引发的连锁延迟
一个隐蔽的 T+1 变 T+2 原因：某个任务失败自动重试 3 次，每次间隔 10 分钟，总共多花了 30 分钟。如果这个任务在关键路径上，直接拖累整条链路。
解决方案：（1）核心链路失败立即告警而不是默认重试（让人判断是否真的要重试）；（2）重试间隔缩短；（3）对偶发性失败（OOM / 网络抖动）可以自动重试，对确定性失败（SQL 错误）立即告警。这个也是第 3 篇调度讲的告警分级的延伸。
段落五：防御——SLA 分级和预警
Plain
我的 SLA 分级体系（某短剧出海公司实操）：
P0 核心链路：
SLA：T+1 08:00 前完成
预警：07:00 未完成 → 电话告警
降级：若关键路径慢 → 自动跳过非必要节点
P1 常规链路：
SLA：T+1 10:00 前完成
预警：09:30 未完成 → 企微告警
P2 非紧急：
SLA：T+1 18:00 前完成
预警：17:00 未完成 → 日报记录
关键指标：'就绪时间 - SLA 时间' 的分布，
平均 buffer < 30 分钟的链路要警惕。面试高频追问
追问一：关键路径是个什么概念？你怎么知道哪条是关键路径？
关键路径是 DAG 里『完成时间最晚』的那条路径。判断方法：在 DataWorks / Airflow 里看任务运行甘特图，找『最后一个完成、且它的上游完成时间最接近它开始时间』的链条。实操里用一个简单办法：看每个任务的 lag（就绪到完成的时间差），lag 最长的几个任务基本就在关键路径上。核心链路上我们会专门监控关键路径的总时长。
追问二：如果上游 A 延迟 2 小时，你下游任务会等吗？
看场景。如果是核心链路（财务、广告 ROI），必须等——宁可看板晚出也不能用缺失数据出错误结论。如果是探索性任务或弱依赖，用『依赖过期降级』策略：超过阈值后自动跳过，用前一天的替代，但在看板打标记提醒用户。我在某短剧出海公司的跨时区链路里设计过这套——海外某个市场延迟 4 小时自动降级，企微同时报警。
追问三：重跑一个失败任务，下游要不要一起重跑？
看下游是否已经跑过。如果下游还没跑，只重跑当前节点即可，下游会因为依赖自动等；如果下游已经用错误数据跑过（比如 SQL 跑出空结果但没报错），必须带下游重跑——DataWorks 和 Airflow 都支持『重跑并带下游』。我们团队的规矩：带下游重跑核心任务必须两人对齐 + 企微通知，因为会影响已经出的看板。
实战踩坑：数据迟到 + 重跑错位
我在某元宇宙社交应用遇到过一次组合拳：上游 Kafka 消息因为客户端离线累积，3/15 的事件到了 3/17 才重新上报。我们的 ETL 按 process_time 分区，结果这批 3/15 的事件被塞到了 3/17 的分区里，历史数据永远拉不回来。
解决方案：所有事实表的分区键从 process_time 改成 event_time，ETL 按事件发生时间分区。代价是要支持『回写历史分区』——当天可能写 3/15、3/16、3/17 三个分区（迟到事件往回追）。但业务口径从此正确。这个改造涉及 30 多张表，花了一个月。
-- ❌ 按处理时间分区（ETL 时间，会漏迟到数据）
INSERT OVERWRITE TABLE dwd_event PARTITION (dt='${bizdate}')
SELECT * FROM ods_event WHERE dt = '${bizdate}';
-- ✅ 按事件时间分区（允许回写历史）
INSERT OVERWRITE TABLE dwd_event PARTITION (event_date)
SELECT *, DATE(event_ts) AS event_date
FROM ods_event
WHERE process_dt = '${bizdate}';
-- 动态分区，迟到事件自动写回历史分区总结
T+1 变 T+2 排查题的上限是能讲出四种原因（上游延迟 / 慢 SQL / 队列排队 / 重试连锁）+ 关键路径的概念 + SLA 分级 + 至少一个真实的跨时区或数据迟到故事。能把这几块串起来，这题就是 9 分水平。
下一篇：『上游 Schema 变更了没通知你——怎么防御？』——生产问题第三道，最容易炸的协作问题。
你们团队有没有试过『某天任务没挂但数据不对』的恐怖场景？查了多久？
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长