Data Engineering Agent DQC 最佳实践
本文介绍如何为 Data Engineering Agent 的使用场景设计更稳妥的数据质量规则，重点是降低误报、便于验证和便于逐步上线。
先探索，再逐步加严
数据质量规则很容易一上来就配得过重。更稳的方式通常是：
- 先看当前有没有现成规则
- 先从简单规则和弱规则开始
- 先用测试规则或手动触发验证规则逻辑
- 验证通过后，再逐步升级到更强的阻塞策略
这类场景更适合探索式起手，例如：
- 帮我先看一下这张表当前有没有规则。
- 帮我先判断第一批最值得建的规则是什么。
- 帮我先判断这个规则更适合弱规则还是强规则。
从简单规则开始
刚开始建设 DQC 时，建议先从低争议、容易解释的规则开始：
- 行数大于 0
- 关键字段非空
- 主键或业务键去重
- 数值范围检查
不要一开始就上大量复杂 SQL 规则，否则用户会很难判断规则到底在检查什么。
先用弱规则
如果团队刚开始接触 DQC，建议优先使用：
- 弱规则
- 非阻塞级别
- 手动触发
这样可以先验证规则本身是否合理，再决定是否升级为会影响调度的强规则。
测试规则要有明显命名
测试规则建议采用明显的测试前缀，例如：
这样做的好处是：
- 一眼看出不是正式规则
- 验证完成后容易清理
- 不会和正式治理规则混淆
手动触发适合验证期
如果规则还在验证期，使用
REST- 一创建就影响调度
- 规则还未校准就阻塞生产任务
在规则成熟前，不建议直接把测试规则接入自动阻塞流程。
创建后一定复核
规则创建后，应确认：
- 规则类型是否正确
- 检查对象是否正确
- 阈值是否正确
- 强弱级别是否符合预期
- 触发方式是否符合预期
不要只看“已创建成功”。
验证完成后要清理测试规则
测试规则不是长期资产。验证完成后应：
- 删除测试规则
- 再次查询确认规则已清理
- 只保留正式规则
这样可以避免正式环境中混杂大量无效规则。
实际上最有价值的第一批规则
如果只能先做很少一批规则，建议优先：
- 表行数 > 0
- 关键业务字段非空
- 去重规则
这三类规则最容易解释，也最能让用户快速看到价值。
相关文档
联系我们