Expert guidance on non-obvious…

# Airflow 周四全量重跑丢数排查思路

一、先确认“丢数”的真相

• 区分少写还是少读：对比 MySQL 源表 count 与 Redshift 目标表 count，再对比下游 agg 表。可能数据在 Redshift 里没问题，而是 agg 汇总时丢的（如 JOIN 条件、去重逻辑把数据排掉）。
• 锁定时间范围：对比是“当天增量”少了，还是历史全量对不上。全量重跑一般靠 WHERE ds = ... 分区，检查分区条件是否正确。

二、周四特殊性的常见嫌疑

• 任务依赖链冲突：周四可能有其他 DAG 也在跑（如每周任务、数据回溯），抢占 Redshift 资源或写入中间表，导致读到中间状态。
• 源库周四有批量写入：查 MySQL binlog / 业务侧，周四是否有大促、报表日之类的批量导入，同步启动时刻（凌晨2点）源表还在写入，造成快照不一致。
• DAG 历史回填：全量重跑是否用 backfill 或 clear 触发，execution_date 与实际数据日期偏移一天，导致拉错数据窗口。

三、同步机制本身的问题

• 无幂等/先删后插的窗口竞态：如果流程是“删旧数据→插入新数据”，中途失败会留下残缺数据；检查任务重试日志。
• 增量水位线问题：若按 update_time >= 上次执行时间 增量，全量重跑时水位线可能被覆盖或错位，漏掉某段数据。
• 分页/分片导出遗漏：MySQL 导出若用 LIMIT 分页且无稳定排序，写入期间数据偏移会丢行；检查是否有 ORDER BY 主键。

四、下游 agg 环节

• agg 是否依赖了错误的调度参数：周四重跑时 agg 读的是当天分区还是最新分区？
• JOIN 丢数：LEFT JOIN 被写成 INNER JOIN、聚合键含 NULL 被过滤。
• Redshift 特有：目标表无主键约束，重复或 DELETE + INSERT 竞态；检查 STL_LOAD_ERRORS、SVL_QUERY_SUMMARY 排查加载报错。

五、建议的落地动作

1. 选一个丢数的周四，逐层 count：MySQL 源 → 中间落地文件/staging → Redshift 明细表 → agg 表，定位断点在哪一环。

2. 拉取当次任务日志（Airflow UI + Redshift STL 表），看有无告警、重试、部分失败。

3. 对比周四与正常周日的数据差异明细，找出丢失记录的共性（如集中在某时间段/某状态值）。

4. 长期方案：给全量重跑加数据校验节点（源/目标 count 对比 + 抽样校验），不通过则告警或阻断下游。

排查顺序建议：先做第1步的逐层 count 对比，能最快把问题收敛到某一层。