周一早上9点的"地震"
2026年5月，周一早上9点。推荐模型的训练Pipeline发现训练数据没到。数据团队说"上游数据管道延迟了"。3小时后，数据到了。但模型训练需要4小时。等模型训练完、评估完、部署完，已经是下午5点。推荐模型用旧数据跑了一天，CTR掉了12%。
这个事故的根源不是模型，不是部署，不是监控——而是数据管道。
金句：ML系统中的"垃圾进垃圾出"（Garbage In, Garbage Out）从来不是模型的问题，而是数据管道的问题。
数据管道的三个可靠性挑战
挑战一：数据延迟。 上游数据的到达时间不可预测。挑战二：数据质量。 数据可能包含空值、异常值、重复值、格式错误。挑战三：数据一致性。 训练数据和推理数据必须来自同一条数据管道。
数据管道可靠性设计
设计一：SLA和回退策略。 数据到达SLA：每天凌晨2:00前。如果2:00数据未到→告警。如果4:00数据未到→使用昨天的数据+实时数据补偿。如果8:00数据未到→使用上周同一天的数据（降级策略）。
设计二：数据质量检查。 用Great Expectations在数据管道中嵌入数据质量检查：expect_column_values_to_not_be_null("user_id")、expect_column_values_to_be_between("age", 0, 120)。如果质量检查失败，Pipeline停止。
设计三：数据版本化和回溯。 用DVC：dvc add data/training_data.parquet，每次数据变更都创建新版本。
设计四：数据管道监控。 监控：数据到达时间vs SLA、数据量vs历史基线、数据质量检查通过率、数据管道运行时长、空值率。
数据管道事故应急手册
- 数据延迟（< 2小时）：等待，Pipeline自动重试。2. 数据延迟（2-4小时）：使用昨天的数据+实时数据补偿。3. 数据延迟（> 4小时）：使用降级策略，人工介入。4. 数据质量异常：停止Pipeline，使用上一个有效版本。5. 数据管道故障：切换到备用管道。
结论：数据管道是ML系统的"地基"。 地基出了问题，再漂亮的模型也会倒塌。在MLOps中，数据管道的重要性被严重低估——直到它出问题的那一天。