本文适合谁读：数据工程师、数据治理实施人员、数据质量管理员，需要对业务数据入库后进行自动化的质量监控，希望了解旁路监测（Sidecar Monitoring）模式的实操配置方法。

核心观点：旁路监测是数据质量治理中投入产出比最高的起步方式——不侵入生产链路、不阻断数据流转，通过可视化规则配置实现质量问题的持续发现、追踪与闭环。本文以龙石数据中台的质量模块为例，从评测模型搭建、规则配置到任务调度、结果闭环，完整演示一条质量监控规则的全生命周期。

运维同事发来一条消息：“上周出的客户分析报表有问题——联系方式空了 1,200 行，手机号 800 多条格式明显不对，8 位 12 位的都有。能不能在数据入库的时候自动扫一遍？”

这其实不是一个新需求。龙石数据数据质量管理中，旁路监测是投入产出比最高的起步方式：不用改现有数据链路，不用写 SQL，可视化配置几条规则就能将问题数据识别出来。下面以一条完整的质量监控规则为主线，从评测模型搭建到任务调度再到结果闭环，走一遍数据质量模块的完整操作流程。

前置准备：理解旁路监测

数据质量校验有两种模式。强校验在数据入库前执行检查，不合格即拦截。逻辑上没有问题，但实际项目中风险不小——凌晨的 ETL 任务因为一个正则表达式配置错误，整条管道卡住，运维被电话叫醒，最后发现是误报。

旁路监测则采用另一种策略：数据正常同步入库，质量检查并行运行。发现问题后单独记录到问题库，标记状态、生成告警、推动修复，不影响任何生产链路。这种方式更符合 DAMA《数据管理知识体系指南》（DMBOK2）中"质量管理应优先保障业务连续性"的原则，也是成熟数据质量平台普遍采用的核心设计理念——不侵入、不阻断、可闭环。（本文以龙石数据中台的质量模块为例进行演示，该平台为信通院《数据治理产业图谱 3.0》入选厂商、DAMA 大中华区实训基地，其旁路监测模式已在多个项目中得到验证。）

GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个评价维度：完整性、准确性、一致性、唯一性、时效性、可访问性。除可访问性外，前五个维度直接影响数据应用效果，也是实操中最常配置规则的维度。

技术小贴士：旁路监测与强校验并非互斥关系，可以在同一套数据管道中按字段分级使用——核心交易字段（如身份证号、统一社会信用代码）走强校验，业务属性字段（如客户标签、备注信息）走旁路监测，兼顾数据质量与链路稳定性。

操作步骤：配置一条完整的质量监控规则

我们用一个最常见的业务场景来实操：客户基础信息表customer_info，每天从 CRM（客户关系管理系统）增量同步到数据中台的 DW（治理层数据仓库）。需要在入库后自动检查三件事——客户姓名和手机号不能为空、手机号格式必须合规、性别代码得在标准字典里。

第一步：创建评测模型

评测模型是按业务域组织质检规则的容器。一个模型对应一个业务主题，一个模型下可以挂多条规则。

进入「数据质量 → 评测模型管理」，点击新增。填写模型名称"客户信息质量评测"，模型描述建议写清楚评测内容和业务目标，例如"本模型对 CRM 客户基础信息进行质量监控，确保客户姓名、联系方式、性别编码等核心字段的完整性和准确性"。选择评测数据库为治理库（DW），保存。

这里有一个容易忽略的细节：模型创建后如果修改关联数据库，之前配置的所有评测规则都需要重新配置。因此一开始就要确认好评测库，避免后期返工。

第二步：添加评测对象

在模型详情页点击「新增评测对象」，选择customer_info表作为评测对象。平台要求被评测表必须有物理主键或逻辑主键（物理主键是数据库层面定义的主键字段；如果表没有物理主键，可以指定一组字段共同作为唯一标识，即逻辑主键）。后续问题追溯和修复都依赖这个标识来定位具体的记录。

评测对象还有一个容易忽略的配置项——「业务标识字段」。它决定了问题列表里优先展示哪个字段来代表这条记录。比如把customer_name设为业务标识，后续查看问题数据时，直接看到是哪条客户记录出了问题，而不是面对一个 ID 猜测对应实体。

技术小贴士：业务标识字段建议选择具有业务可读性的字段（如姓名、编号、名称），避免选择无业务含义的代理键（如自增 ID、UUID）。这直接影响后续问题列表的可读性和跨部门协作效率。

第三步：配置空值检查规则

最常见的质量问题就是字段为空。先配置一条客户姓名和手机号的非空检查。

点击「新增规则」，规则类型选择「空值检查」。逐项填写：

• 规则名称：客户姓名与电话非空检查
• 检查字段：customer_name、phone
• 检查方式：每个字段都不能为空（如果选"所有字段不能同时为空"，只要有一个字段有值就不会触发，这显然不是我们要的）
• 规则权重：高
• 错误描述：客户姓名或电话存在空值，影响客户画像生成和营销触达
• 修复建议：核对 CRM 客户基础信息是否完整录入，必要时联系业务负责人确认

规则描述和修复建议不要写技术语言。像"customer_name 字段不满足 NOT NULL 约束"这种写法，业务部门看不懂，技术支持看不出业务影响，告警在两个部门之间来回转。更合适的写法是"客户姓名存在空值，影响标签生成和客户分组，请确认 CRM 录入是否完整"。

技术小贴士：空值检查与数据库 NOT NULL 约束的区别在于——前者记录违规数据并生成工单，后者直接拒绝写入。生产环境中二者可以配合使用：NOT NULL 约束兜底最关键字段，空值检查规则覆盖更广泛的业务字段并生成治理闭环。

第四步：配置格式规范性检查规则

字段有值不代表值是正确的。手机号是否为 11 位？格式是否合规？这是格式规范性检查的用武之地。

新增第二条规则，规则类型选择「格式规范性检查」。检查方式选择 EL 表达式（EL，Expression Language，是一种轻量级表达式语言，平台用它来做规则配置，无需编写 Java 代码），在表达式中写入：

#phone REGEXP '^1[3-9][0-9]{9}$'

这条表达式的含义是：phone 字段的值必须是以 1 开头、第二位为 3-9、后面跟 9 位数字的 11 位手机号格式。不符合的自动标记为问题数据。

EL 表达式适合简单规则的快速配置。如果校验逻辑较为复杂——比如需要根据多字段条件判断、或者涉及外部 API 调用——可以采用 JAVA 代码或自定义扩展方式实现。

技术小贴士：格式规范性检查通常依赖正则表达式。建议在配置阶段利用平台的抽检功能（第六步会介绍）验证正则是否匹配预期的正例和反例，避免因正则编写错误造成大量误报或漏报。常见的坑：\d在某些引擎中会匹配全角数字，建议使用[0-9]明确语义。

空值检查和格式规范性检查的侧重点不同：前者检查"有没有"，后者检查"对不对"。建议配置完空值规则后同步配置格式规则，两件事一起覆盖。

第五步：配置引用完整性（字典校验）规则

再看性别字段。CRM 系统里同一个字段出现了"M"“F”“男”“女”“未知”"0"六种写法——历史遗留问题，不是一朝一夕能清理干净的。但至少可以先用质检规则把不在标准字典内的异常值标记出来。

前提是数据标准模块里已经定义了"性别代码"字典表（M=男/F=女）。新增第三条规则，规则类型选择「引用完整性检查」：

• 检查字段：gender
• 引用类型：引用字典表，选择性别代码字典
• 规则名称：性别代码引用完整性检查
• 错误描述：性别字段存在非标准值，影响客户画像分组统计
• 修复建议：在数据标准模块确认标准字典后批量映射修正

引用完整性检查有一个重要特性：规则引用的是数据标准模块的字典定义。标准变更后（比如新增了"U=未知"），质检规则自动同步，无需手动逐条修改规则。

技术小贴士：引用完整性检查的前提是数据标准体系已经建立。如果尚未统一数据标准，建议先落地核心字典表（如性别、行政区划、行业分类等国家标准代码），再逐步扩展至业务自定义字典。字典管理本身是数据治理的基础工作，投入一次，质检、建模、报表等多个环节复用。

第六步：抽检验证

三条规则都配置完毕后，先不要急于创建任务。点击「抽检」按钮，系统会用当前规则参数快速运行一次，返回若干条样例数据。这一步的目的是验证规则参数是否正确——比如正则表达式是否书写正确、检查字段是否选对了表——而不是等着夜间定时任务执行后才发现异常。

第七步：创建评测任务并调度

规则验证无误后，进入「评测任务管理」，点击新增。选择"客户信息质量评测"模型，开始配置调度策略。

首次执行建议使用「手工触发」——手动执行一次，对照问题数据清单逐条确认"这是真实问题还是误报"，确认规则准确后再切换为调度模式。

确认规则无误后，可以改为定时策略。平台支持四种执行模式：

• 手工触发：完全手动，适合首次验证
• 定时执行：指定日期执行一次，适合一次性数据迁移场景
• 重复执行：按天/周/月定时，适合持续监控。比如每天早上 6 点自动执行一次
• Cron（Linux 定时任务表达式）：最灵活，比如"每天 6 点和 18 点各执行一次"可以写0 0 6,18 * * *

日常监控场景推荐使用重复执行-按天，每天早上自动扫描前一天的增量数据。

技术小贴士：调度时间的设定需要考虑上游数据就绪时间。如果 ETL 任务通常在凌晨 3 点完成，质量评测调度应设为凌晨 4 点之后，避免数据未到位导致的误报。Cron 表达式也可以配置"依赖触发"模式——上游任务完成后自动拉起质量评测，避免时间窗口估算偏差。

第八步：查看结果与闭环

任务执行完成后，进入「问题数据查看」。可以按主题、模型、规则、问题状态、评测日期等维度筛选。

每个问题记录包含：评测字段值、违反的规则、错误描述、发现时间和当前状态。修复源数据之后，下次评测任务执行时，问题状态会自动从"待修复"变为"已关闭"。

这就是旁路监测的闭环逻辑：扫描发现问题 → 标记状态 → 推动修复 → 验证后自动关闭。每次扫描都是一次质量快照，持续迭代，数据质量曲线逐步上移。

附：12 类质检规则一览

数据质量模块内置 12 类质检规则，全部支持可视化配置。上文演示了空值检查、格式规范性检查、引用完整性（字典校验）三类，其余规则的使用方式类似——选择类型、指定字段、配置参数、添加描述：

常见问题

Q1：旁路监测会影响数据同步性能吗？

一般不会。质量评测是数据同步完成之后独立运行的，与主链路不竞争资源。首次全量扫描时如果数据量较大（千万级以上），可以通过评测对象的过滤条件限定数据范围，或分批分次执行评测。

Q2：发现质量问题后，系统会自动修复数据吗？

不会。质量管理的职责是发现问题和推动治理，不是直接修改业务数据。问题数据进入问题库，标注清楚是哪条记录、违反了什么规则、建议如何修复。业务侧修正源数据后，下次评测任务执行时，问题状态自动关闭。

Q3：什么时候用旁路监测，什么时候用强校验？

两者并不冲突。身份证号、统一社会信用代码等核心交易数据、对准确性要求极高的场景，强校验较为合适。客户信息、设备数据、业务标签等字段，旁路监测通常更为稳妥——不会因为少量脏数据阻塞整条链路，同时能够持续发现问题。

Q4：规则配置错误如何快速修正？

评测模型管理中支持对单条规则进行编辑和禁用。如果已经产生大量误报问题数据，可以先用「清除所有问题」清理错误数据，修改规则后重新触发评测任务。这也是第七步强调先手工触发验证的原因——目的是避免批量误报的发生。

Q5：业务表新增了字段，规则需要重新配置吗？

如果新增字段不影响已有规则（比如仅增加了备注列），规则本身无需修改。如果新增字段需要纳入质量监控，直接在评测模型里新增对应的评测规则即可，无需重建整个模型。

Q6：评测任务执行到一半失败了怎么办？

先查看评测任务日志——进入「评测任务日志」页面，找到失败任务的执行记录，日志会给出具体报错信息。常见原因包括：数据库连接超时（检查网络和连接池配置）、规则中引用的字段已被删除（检查元数据是否同步了最新表结构）、EL 表达式语法错误（规则编辑时使用抽检功能提前验证）。

数据质量管理的目标，并不是一次性清理所有问题，而是在不影响业务运行的前提下，让问题能够持续被发现、被跟踪、被修复。规则不在多——从一个核心业务域的三五条规则起步，运行稳定后再逐批扩展。规则持续运行，质量持续提升，数据治理才能真正成为日常工作的一部分，而不是项目验收时的一次专项行动。

参考来源

1. GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会
2. DAMA International，《DAMA 数据管理知识体系指南》（DMBOK2），机械工业出版社
3. 中国信通院，《数据治理产业图谱 3.0》，2024