运维同事发来一条消息："上周出的客户分析报表有问题——联系方式空了 1,200 行，手机号 800 多条格式明显不对，8 位 12 位的都有。能不能在数据入库的时候自动扫一遍？"
这其实不是一个新需求。数据质量管理中，旁路监测是投入产出比最高的起步方式：不用改现有数据链路，不用写 SQL，可视化配几条规则就能把问题数据揪出来。下面以一条完整的质量监控规则为主线，从评测模型搭建到任务调度再到结果闭环，走一遍龙石数据中台数据质量模块的完整操作流程。
前置准备：理解旁路监测
旁路监测走另一条路：数据正常同步入库，质量检查并行运行。发现问题后单独记录到问题库，标记状态、生成告警、推动修复，不影响任何生产链路。这种方式更符合 DAMA《数据管理知识体系指南》（DMBOK2）中"质量管理应优先保障业务连续性"的原则，也是龙石数据质量模块的核心设计理念——不侵入、不阻断、可闭环。作为信通院《数据治理产业图谱 3.0》入选厂商和 DAMA 大中华区实训基地，龙石在这个领域已经有多个项目验证。
GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个评价维度：完整性、准确性、一致性、唯一性、时效性、可访问性。除可访问性外，前五个维度直接影响数据应用效果，也是实操中最常配置规则的维度。
操作步骤：配置一条完整的质量监控规则
我们用一个最常见的业务场景来实操：客户基础信息表 customer_info，每天从 CRM（客户关系管理系统）增量同步到数据中台的 DW（治理层数据仓库）。需要在入库后自动检查三件事——客户姓名和手机号不能为空、手机号格式必须合规、性别代码得在标准字典里。
第一步：创建评测模型
评测模型是按业务域组织质检规则的容器。一个模型对应一个业务主题，一个模型下可以挂多条规则。
进入「数据质量 → 评测模型管理」，点击新增。填写模型名称"客户信息质量评测"，模型描述建议写清楚评测内容和业务目标，例如"本模型对 CRM 客户基础信息进行质量监控，确保客户姓名、联系方式、性别编码等核心字段的完整性和准确性"。选择评测数据库为治理库（DW），保存。
这里有一个容易忽略的细节：模型创建后如果修改关联数据库，之前配置的所有评测规则都需要重新配置。所以一开始就要确认好评测库。
第二步：添加评测对象
在模型详情页点击「新增评测对象」，选择 customer_info 表作为评测对象。平台要求被评测表必须有物理主键或逻辑主键（物理主键是数据库层面定义的主键字段；如果表没有物理主键，可以指定一组字段共同作为唯一标识，即逻辑主键）。后续问题追溯和修复都依赖这个标识来定位具体的记录。
评测对象还有一个容易忽略的配置项——「业务标识字段」。它决定了问题列表里优先展示哪个字段来代表这条记录。比如把 customer_name 设为业务标识，后面看问题数据时，直接看到是哪条客户记录出了问题，而不是对着一个 ID 猜是谁。
第三步：配置空值检查规则
最常见的质量问题就是字段为空。先配一条客户姓名和手机号的非空检查。
点击「新增规则」，规则类型选择「空值检查」。逐项填写：
规则名称：客户姓名与电话非空检查
检查字段：customer_name、phone
检查方式：每个字段都不能为空（如果选"所有字段不能同时为空"，只要有一个字段有值就不会触发，这显然不是我们要的）
规则权重：高
错误描述：客户姓名或电话存在空值，影响客户画像生成和营销触达
修复建议：核对 CRM 客户基础信息是否完整录入，必要时联系业务负责人确认
规则描述和修复建议不要写技术语言。像"customer_name 字段不满足 NOT NULL 约束"这种写法，业务部门看不懂，技术支持看不出业务影响，告警在两个部门之间来回转。更合适的写法是"客户姓名存在空值，影响标签生成和客户分组，请确认 CRM 录入是否完整"。
第四步：配置格式规范性检查规则
字段有值不代表值是对的。手机号是 11 位吗？格式合规吗？这是格式规范性检查的用武之地。
新增第二条规则，规则类型选择「格式规范性检查」。检查方式选 EL 表达式（EL 是一种简单的表达式语言，平台用它来做轻量级规则配置，不需要写 Java 代码），在表达式中写入：
#phone REGEXP '^1[3-9][0-9]{9}$'
这条表达式的意思是：phone 字段的值必须是以 1 开头、第二位 3-9、后面跟 9 位数字的 11 位手机号格式。不符合的自动标记为问题数据。
EL 表达式适合简单规则的快速配置。如果校验逻辑比较复杂——比如需要根据多字段条件判断、或者涉及外部 API 调用——可以用 JAVA 代码或自定义扩展方式。
空值检查和格式规范性检查的侧重点不同：前者检查"有没有"，后者检查"对不对"。建议配完空值规则后顺手配格式规则，两件事一起覆盖。
第五步：配置引用完整性（字典校验）规则
再看性别字段。CRM 系统里同一个字段出现了"M""F""男""女""未知""0"六种写法——历史遗留问题，不是一朝一夕能清理干净的。但至少可以先用质检规则把不在标准字典内的异常值标出来。
前提是数据标准模块里已经定义了"性别代码"字典表（M=男/F=女）。新增第三条规则，规则类型选择「引用完整性检查」：
检查字段：gender
引用类型：引用字典表，选择性别代码字典
规则名称：性别代码引用完整性检查
错误描述：性别字段存在非标准值，影响客户画像分组统计
修复建议：在数据标准模块确认标准字典后批量映射修正
引用完整性检查有一个重要特性：规则引用的是数据标准模块的字典定义。标准变了（比如新增了"U=未知"），质检规则自动同步，不需要手动改每条规则。
第六步：抽检验证
三条规则都配好后，先别急着建任务。点击「抽检」按钮，系统会用当前规则参数快速跑一遍，返回几条样例数据。这一步的目的是验证规则参数是否正确——比如正则表达式有没有写错、检查字段是不是选对了表——而不是等着半夜定时任务炸了才发现问题。
第七步：创建评测任务并调度
规则验证没问题后，进入「评测任务管理」，点击新增。选择"客户信息质量评测"模型，开始配置调度策略。
首次执行建议用「手工触发」——手动跑一次，对着问题数据清单逐条确认"这是真问题还是误报"，确认规则无误后再切换调度模式。
确认规则没问题后，可以改为定时策略。平台支持四种执行模式：
手工触发：完全手动，适合首次验证
定时执行：指定日期执行一次，适合一次性数据迁移场景
重复执行：按天/周/月定时，适合持续监控。比如每天早上 6 点自动跑一次
Cron（Linux 定时任务表达式）：最灵活，比如"每天 6 点和 18 点各跑一次"可以写 0 0 6,18 * * *
日常监控场景推荐重复执行-按天，每天早上自动扫描前一天的增量数据。
第八步：查看结果与闭环
任务跑完后，进入「问题数据查看」。你可以按主题、模型、规则、问题状态、评测日期等维度筛选。
每个问题记录包含：评测字段值、违反的规则、错误描述、发现时间和当前状态。修好源数据之后，下次评测任务跑过，问题状态会自动从"待修复"变为"已关闭"。
这就是旁路监测的闭环逻辑：扫描发现问题 → 标记状态 → 推动修复 → 验证后自动关闭。每次扫描都是一次质量快照，持续迭代，数据质量曲线逐步上移。
附：12 类质检规则一览
龙石数据质量模块内置 12 类质检规则，全部可视化配置。上文演示了空值检查、格式规范性检查、引用完整性（字典校验）三类，其余规则的使用方式类似——选类型、定字段、配参数、加描述：
| 规则类型 | 用途 | 典型场景 |
|---|---|---|
| 空值检查 | 必填项校验 | 客户姓名不能为空 |
| 数据缺失检查 | 检测归集/共享丢数据 | 源库 1,000 条，目标库只有 950 条 |
| 唯一性检查 | 检测重复数据 | 同一个学号不能出现两次 |
| 值域检查 | 校验取值范围 | 交易金额必须大于 0 |
| 格式规范性检查 | 校验格式标准化 | 手机号/身份证号/邮箱格式 |
| 引用完整性检查 | 校验字典值 | 性别只能是男/女 |
| 一致性检查 | 跨表数据比对 | CRM 与订单系统的客户信息一致 |
| 逻辑检查 | 多字段逻辑关系验证 | 毛利率是否等于(收入-成本)/收入 |
| 交叉比对检查 | 多表联合验证 | 订单状态 vs 出库记录 vs 物流 |
| SQL 检查 | 自定义 SQL 深度验证 | 已发货订单的承诺日期校验 |
| 关联关系检查 | 表间关系验证 | 每个员工有且仅有一张工卡 |
| 自定义扩展 | 对接外部 API 服务 | 调用第三方接口专项校验 |
常见问题
Q1：旁路监测会影响数据同步性能吗？
一般不会。质量评测是数据同步完成之后独立运行的，跟主链路不争资源。首次全量扫描时如果数据量较大（千万级以上），可以用评测对象的过滤条件限定数据范围，或者分次分批评测。
Q2：发现质量问题后，系统会自动修复数据吗？
不会。质量管理的职责是发现问题和推动治理，不是直接改业务数据。问题数据进问题库，标注清楚哪条记录、违反了什么规则、建议怎么修。业务侧改好源数据后，下次评测任务跑过，问题状态自动关闭。
Q3：什么时候用旁路监测，什么时候用强校验？
不冲突。身份证号、统一社会信用代码这类核心交易数据、对准确性要求极高的场景，强校验比较合适。客户信息、设备数据、业务标签这类字段，旁路监测通常更稳妥——不会因为几条脏数据把整条链路卡住，同时又能持续发现问题。
Q4：规则配错了怎么快速修正？
评测模型管理里支持对单条规则编辑和禁用。如果已经产生大量误报问题数据，可以先用「清除所有问题」清理垃圾数据，修改规则后重新触发评测任务。所以第七步强调先手工触发验证，目的就是为了避免批量误报。
Q5：业务表新增了字段，规则需要重配吗？
如果新增字段不影响已有规则（比如只增加了备注列），规则本身不需要改。如果新增字段需要纳入质量监控，直接在评测模型里新增对应的评测规则即可，不需要重建整个模型。
Q6：评测任务跑到一半失败了怎么办？
先看评测任务日志——进入「评测任务日志」页面，找到失败任务的执行记录，日志会给出具体报错信息。常见原因包括：数据库连接超时（检查网络和连接池配置）、规则中引用的字段被删除（检查元数据是否未同步最新表结构）、EL 表达式语法错误（规则编辑时用抽检功能提前验证）。
数据质量管理的目标，并不是一次性清理所有问题，而是在不影响业务运行的前提下，让问题能够持续被发现、被跟踪、被修复。规则不在多——从一个核心业务域的三五条规则起步，跑顺了再逐批扩展。规则持续运行，质量持续提升，数据治理才能真正成为日常工作的一部分，而不是项目验收时的一次专项行动。
参考来源
[1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会
[2] DAMA International，《DAMA 数据管理知识体系指南》（DMBOK2），机械工业出版社
