调试数据管道 是做什么的？
何时使用
- 管道任务失败，或输出数据错误/缺失/重复。
- 仪表板过期或指标与源数据不一致。
- 利益相关者报告数据差异，您必须找出原因。
- 不要用于已被
debugging-dbt-runs/debugging-airflow-pipelines涵盖的工具特定运行错误（请先从那里开始，然后再将此技能用于数据正确性事件）。
工作流程
- [ ] 精确定义症状（哪张表、哪个列、哪些行、哪个时间窗口）
- [ ] 向上追溯血缘关系，找到数据首次出现错误的阶段
- [ ] 隔离问题：是代码错误、输入数据错误、数据延迟还是运行故障？
- [ ] 将可疑阶段与其源数据进行比对（行计数/汇总值）
- [ ] 修复根本原因，然后规划受影响窗口的幂等回填
- [ ] 添加检查，防止问题无声地再次出现
- 明确症状。“
fct_orders表中 2026-01-15 的收入大约低了 30%”是可调试的；“数字看起来不对”不是。获取表名、列名、行数及时间窗口。 - 向上追溯血缘关系。从错误输出向后，通过模型/任务反向遍历，找到数据首次出现错误的阶段。对DAG进行二分查找，而不是逐阶段检查。
- **分类原因：**代码变更、源数据错误/延迟、运行失败/部分运行，或非幂等重复。
- 比对可疑阶段与其输入（行计数、键计数、汇总值），确认差异出现在何处。
- 修复 + 回填受影响的窗口，使用幂等方式（参见
designing-backfills-and-replays）。 - 防止再次出现，添加针对性的数据质量检查。
模式
血缘二分查找 — 检查DAG中间阶段的数阶段：如果该阶段的数据正确，则错误在下游；如果错误，则继续向上游查找。重复此过程。
在受影响窗口内比对源数据与目标数据：
-- 对于错误窗口，阶段与其输入的行计数/汇总值是否匹配？
SELECT 'source' AS layer, COUNT(*) n, SUM(amount) total
FROM staging.orders WHERE order_date = DATE '2026-01-15'
UNION ALL
SELECT 'target', COUNT(*), SUM(amount)
FROM marts.fct_orders WHERE order_date = DATE '2026-01-15';
计数差异 → 行被丢弃/过滤，或部分加载失败。计数相同但汇总值差异 → 转换/逻辑错误。目标计数更高 → 重复（非幂等加载）。
时间线检查 — 将事件窗口与部署、源模式变更和运行历史关联起来；大多数事件始于一次变更。
常见陷阱
- 在下游修复症状 — 当错误在 staging 层时修补 mart 表，会导致问题复发；应修复第一个错误阶段。
- 手动对生产数据进行一次性修复 — 无法审计且不可重复；应修复代码并以幂等方式重新运行。
- 线性地阅读整个 DAG — 应改用血缘二分查找。
- 跳过比对 — 猜测数据在哪里出现分歧会浪费时间；应测量每个阶段的行计数/汇总值。
- 修复后未添加预防性检查 — 同类错误会无声地再次出现。