数据质量如何接入数据管道：校验、阻断与回溯

数据质量最稳妥的接入方式，不是给任务末尾加一个“检查脚本”，而是把校验结果定义成管道状态的一部分：在数据进入下一层之前执行与风险匹配的检查，按失败等级决定继续、隔离还是阻断，同时保存批次、运行、规则和观测值。这样，质量问题才会从“发现异常”变成“控制发布、定位来源、可重放恢复”的工程闭环。

先决定校验放在哪个边界

同一条规则不必在每个环节重复执行。先按数据生命周期拆成三个边界。

第一是接入边界，检查文件、消息或源表是否满足基本契约，例如必需字段是否存在、主键是否为空、时间戳是否能解析。这一层的目标是尽快拒绝明显损坏的数据，避免坏数据进入共享存储。它适合低成本、确定性强的规则，不适合依赖完整业务上下文的跨表一致性检查。

第二是加工边界，检查转换后的结果是否符合业务口径，例如订单金额不能为负、状态值必须来自允许集合、明细行数与汇总结果在误差范围内。这里的信息最完整，但任务已经消耗了计算资源，因此应优先放置会影响下游决策的高风险规则。

第三是服务边界，检查准备被报表、接口或模型消费的数据是否及时、可用和完整。服务边界不一定要再次扫描全量数据，可以检查分区是否到齐、最近成功批次是否在时限内，以及关键指标是否突然越过阈值。

一个实用判断是：规则失败后，错误数据是否还能被安全消费？如果不能，就把规则放在消费前并设置阻断；如果可以暂时使用旧分区或降级结果，则可在服务边界告警而不阻断；如果错误只影响少数记录，则应考虑隔离坏批次或坏行，而不是让整条管道停摆。

把质量规则变成可执行契约

在写检测函数之前，先为每条规则补齐五个字段。

一是对象，明确检查哪个数据集、分区或批次，不要只写一个模糊的表名。二是规则，说明条件和计算口径，例如“支付成功订单的金额总和与结算明细差异不超过千分之三”。三是阈值，区分固定阈值、相对历史基线和允许缺失值。四是等级，至少分为阻断、告警和记录三种处置级别。五是责任与恢复动作，说明谁处理、是否允许重跑、需要从哪个时间窗口回放。

质量结果还要带稳定的运行标识。建议把 dataset_id、batch_id、run_id、规则标识、检查时间、期望值、实际值、状态和错误信息作为最小结果。batch_id 可以是业务日期和分区，run_id 必须区分同一批次的重试。否则第一次失败和第二次成功会被覆盖，回溯时无法回答“哪一次运行产出了这份结果”。

以每日订单为例，接入检查可以包含：订单编号非空且唯一，支付状态属于固定枚举，金额大于等于零，业务日期等于分区日期，分区行数不低于过去七天基线的某个比例。前两条通常是阻断候选；行数异常更适合先告警，因为促销日和节假日可能带来合理波动。阈值不应直接照搬示例，必须由业务对错误成本和漏报成本作出选择。

用 Checkpoint 连接校验与动作

以 Great Expectations Core 为例，Checkpoint 会执行一个或多个 Validation Definition，再根据返回的 Validation Results 执行 Actions。这个模型很适合放在调度任务与下游发布之间：任务产生待检批次，Checkpoint 绑定该批次，结果再驱动更新文档、通知或自定义处置。运行时还可以通过 batch_parameters 指定要检查的批次，通过 expectation_parameters 注入本次运行的阈值。

接入时建议按下面顺序实现：

1. 先让管道生成不可变的批次标识，并把它传给校验步骤。不要让校验器自行猜测“最新分区”，因为重跑和延迟到达会改变最新值。
2. 把阻断规则和观察规则放进同一次检查，但让结果包含各自的严重级别。检查失败不等于任务一定失败，必须由门禁策略解释失败的后果。
3. 将 Checkpoint 的返回结果转换为管道能识别的状态，例如 quality_pass、quality_warn、quality_blocked。不要只依赖日志文本判断成功与否。
4. 在动作阶段保存完整结果或可定位的结果地址，包括失败规则、期望值、实际值和批次参数。通知只负责唤起处理，不能成为唯一证据。
5. 下游任务只消费门禁明确放行的批次。若使用旧版本数据降级，要把降级状态显式写入服务元数据，避免“任务成功”被误解成“最新数据已通过”。

阻断、隔离和告警怎样取舍

阻断适合不可逆或高风险错误，例如主键重复会造成重复结算，字段类型变化会让下游解析失败。它的代价是放大上游延迟，因而必须同时准备重跑入口、超时策略和人工豁免记录。没有恢复路径的阻断，最终会变成无人处理的排队。

隔离适合少量坏数据或可以分批修复的场景。可以把未通过的记录写入隔离区，合格记录继续向下游流动，但要保证隔离区具有原始批次、规则版本和重放条件。隔离不能只是把错误行丢进一个没有保留期限的目录，否则问题被隐藏而不是解决。

告警适合趋势性、非致命和需要观察的异常，例如行数相对历史基线下降。告警不应降低证据质量：仍需记录失败状态、阈值和实际值。尤其要区分“检查未通过”和“检查没有执行”，后者可能意味着数据源不可用或规则配置错误。

用运行和血缘完成回溯

质量结果只有和生产运行、输入输出数据集关联起来，才具备回溯价值。一次加工运行应能回答：用了哪些输入分区，生成了哪些输出分区，执行了哪一版代码和规则，哪些检查通过或失败。对于同一批次的重试，要保留多个运行，而不是只留下最后一次状态。

当异常发生时，可按“服务指标—输出批次—生产运行—输入批次—规则结果”的方向回查。先确认是数据真的异常，还是检查使用了错误批次；再确认该批次由哪次运行生成；最后追到输入分区和上游规则版本。若质量结果没有批次和运行键，只能重新扫描数据，无法证明当时的发布决策依据。

常见失败模式与落地顺序

最常见的失败是把所有规则都设置为阻断，导致偶发波动让整条链路停摆。解决办法是先按错误成本分级，并给每个阻断规则设计可验证的恢复动作。第二个失败是只保存通过或失败，不保存实际值和批次参数，导致值班人员只能重新运行检查。第三个失败是重跑覆盖原结果，失去失败前后的对照。第四个失败是质量步骤与任务状态分离，调度显示成功，但下游实际拿到了未通过数据。

建议按三步上线：先在不影响发布的观察模式收集规则命中和误报；再对少数高风险规则启用阻断，并验证重跑、隔离和豁免；最后把质量状态、运行标识和输入输出关系纳入统一检索。验收标准不是“规则数量够多”，而是出现一次真实失败时，团队能在同一条链路中看到失败规则、受影响批次、责任运行和可执行的恢复动作。