数据质量平台发出一条告警：“订单表行数校验失败，实际 980 万，期望大于 1000 万。”收到的人通常还要追问：检查的是哪个分区，数据任务跑完了吗，规则什么时候改过，这次是补数还是正常调度？

如果这些信息不在结果里，一条 FAIL 只是现象。甚至同一条规则重跑后变成 PASS，也无法判断数据被修复了，还是第二次读取了另一批数据。

Great Expectations 0.14.2 把一次验证拆成 Batch、Expectation Suite、RunIdentifier、Validation Result 和后续 Action。这个结构很值得数据平台参考：规则不是悬空执行，结果也不能只保存布尔值。一次质量结论必须能回答“用哪版规则，在什么时候，对哪批数据，算出了什么”。

DataX 任务想容忍少量脏数据，通常会在 job.setting.errorLimit 里同时写条数和比例：小表不超过 10 条，大表不超过万分之一。这个意图很合理，但 2020 年底这版 DataX 并不会同时检查两条规则。

只要配置了 record，ErrorRecordChecker 就把 percentageLimit 设成 null。两个参数都写时，真正生效的只有条数。

另一个容易混淆的配置是 core.statistics.collector.plugin.maxDirtyNumber。它限制的是控制台最多打印多少条脏数据，不是任务能够容忍多少条。把这两个 max 当成同一个阈值，会得到一条“日志看起来不多，任务却突然失败”或“日志只打印几条，任务居然成功”的链路。

这篇笔记仍然使用 DataX 提交 5485fb3，提交时间是 2020 年 12 月 17 日。