业务部门的运营同事对着BI报表犯了难：上周出的客户分析报表，不同页面展示的客户数量对不上，营销部门据此做的短信推送要么发给了空号，要么漏掉了关键客户。追溯原因后发现，CRM（客户关系管理系统，Customer Relationship Management）同步过来的客户信息表中，联系方式字段空了1,200多行，手机号有800多条格式明显异常——有的8位、有的12位，还有的夹杂着座机号码。业务负责人直说："这数据谁敢用？能不能在数据入库的时候自动扫一遍，把有问题的找出来？"
这不是个别现象。企业数据中台每天汇聚多个业务系统的数据，源系统的录入规范、历史数据质量、接口传输稳定性，任何一个环节都可能引入脏数据。如果每一批数据都要靠人工写SQL去排查，效率低、覆盖面窄，而且查完这批下批又来了。更务实的做法是建立一套自动化的旁路监测机制——数据正常入库，质量检查并行扫描，发现问题的同时不阻断业务链路。配好几条规则，系统就能每天自动把问题数据标记出来。
二、前置准备：理解旁路监测
在动手配置规则之前，有必要厘清一个关键概念：旁路监测与强校验的本质区别。强校验模式在数据入库前执行检查，不合格的数据被拦截、无法写入。这种模式逻辑上没有问题，但在实际项目中风险很大——凌晨的ETL（数据抽取、转换、加载，Extract-Transform-Load）任务可能因为一条正则表达式配错而卡住整条数据管道，导致所有下游报表和业务系统当日无数据可用。旁路监测则采用不同的策略：数据正常完成入库，质量评测任务在入库后独立并行运行，扫描结果生成问题清单、触发告警或工单，但不阻断数据流转。这一设计符合DAMA（国际数据管理协会）DMBOK2（《数据管理知识体系指南》第二版）中"质量管理应优先保障业务连续性"的原则。
龙石数据中台的质量管理模块采用旁路监测模式——不侵入现有数据链路、不阻断数据入库、支持从发现到修复再到验证的完整闭环。龙石是DAMA大中华区实训基地，也是中国信通院《数据治理产业图谱3.0》入选厂商。
在确定监测模式之后，还需要一个衡量"什么叫高质量数据"的标准框架。GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个评价维度：完整性、准确性、一致性、规范性、时效性、可访问性。其中，除可访问性外，其余五个维度直接影响数据在业务中的应用效果，也是日常质量监控中最常配置规则的维度。下文的操作演示将依次覆盖完整性（字段是否为空）、规范性/准确性（手机号格式是否合规）、一致性（性别编码是否在标准字典范围内）三个核心维度。
三、操作步骤：配置一条完整的质量监控规则
以下配置以CRM客户信息表customer_info为例。该表每天从CRM系统增量同步到DW（治理层数据仓库，Data Warehouse治理层）中，业务要求自动检查三件事：客户姓名和手机号不能为空、手机号格式符合中国大陆手机号规范、性别代码必须在标准字典规定的取值范围内。以下八个步骤均可在龙石数据中台的「数据质量」模块中独立完成。
第一步：创建评测模型
评测模型是按业务域组织质检规则的容器，一个模型对应一个评测库，内部可挂载多个评测对象和若干条规则。进入「数据质量 → 评测模型管理」页面，点击"新增模型"，模型名称填写"客户信息质量评测"，评测库选择治理库（DW）。评测库的选择决定了后续规则扫描的数据范围，模型创建后若修改关联评测库，已配置的规则需要重新绑定——因此建议在创建之初就确认好评测库，避免后期返工。
第二步：添加评测对象
在新建的评测模型中新增评测对象，选择customer_info表作为被评测的数据表。被评测的表必须具备物理主键或逻辑主键。逻辑主键是指业务层面能够唯一标识一条记录的字段组合，例如客户编号、合同编号等——当数据库表中没有设置物理主键时，可以通过指定逻辑主键来确保每条问题数据可被精确定位。此外，还需要设置业务标识字段，指定一个业务含义明确的字段（如customer_name），这样在后续的问题数据列表中，每条记录会优先展示客户姓名，而不是难以辨认的技术ID，方便业务人员快速识别是哪条客户记录出了问题。
第三步：配置空值检查规则（覆盖完整性维度）
在评测对象下新增规则，规则类型选择「空值检查」，检查字段勾选customer_name和phone，检查方式选择"每个字段都不能为空"。这种规则解决的是"数据有没有"的问题——确保核心业务字段不缺失。配置规则参数时，有三项内容需要认真填写：
| 配置项 | 填写内容 | 说明 |
|---|---|---|
| 规则权重 | 高 | 客户姓名和手机号是营销触达的核心字段，缺失直接影响业务效果 |
| 错误描述 | 客户姓名或联系电话存在空值，影响客户画像生成、营销分组和短信触达 | 用业务语言说明什么问题、影响什么场景 |
| 修复建议 | 请核对CRM系统中对应客户的基础信息是否完整录入，补全后重新同步 | 给出可操作的具体步骤，而非仅描述状态 |
错误描述的撰写有一个实用原则：回答三个问题——什么数据出了什么问题（用业务语言而非技术字段名）、影响了下游哪个业务环节、应该怎么修。这条原则适用于所有规则类型的错误描述撰写。
第四步：配置格式规范性检查规则（覆盖规范性/准确性维度）
规则类型选择「格式规范性检查」，检查字段选择phone。格式规范性检查与空值检查的区别在于：空值检查回答"有没有"，格式规范性检查回答"对不对"。这里使用EL表达式（Expression Language，一种简单的表达式语言，用于在平台上进行轻量级规则配置，无需编写Java代码）来定义手机号的校验规则。在表达式输入框中填入：
#phone REGEXP '^1[3-9][0-9]{9}$'
这条表达式的含义是：phone字段的值必须是以1开头、第二位为3到9之间的数字、后面跟随9位数字的11位手机号格式。EL表达式支持直接复制使用，配置完成后可先在页面上点击「表达式测试」输入几个样例值验证逻辑是否正确。规则权重设为"高"，错误描述写为"客户手机号格式不符合中国大陆手机号规范，影响短信触达和客户回访"，修复建议写为"请核对CRM源系统中客户手机号的录入格式，按11位手机号规范修正后重新同步"。
第五步：配置引用完整性检查规则（覆盖一致性维度）
规则类型选择「引用完整性检查」，检查字段选择gender（性别）。引用完整性检查又称字典校验，用于验证字段的取值是否在预先定义的标准字典范围之内。前提是数据标准模块中已经定义了"性别代码"标准字典：M代表男、F代表女。在规则配置中关联该字典后，系统会自动比对customer_info表中gender字段的每一个值是否在{M, F}的合法范围内。引用完整性检查的一个关键特性是：当数据标准模块中的字典定义发生变更时（如新增了"U=未知"的取值），所有引用该字典的质检规则会自动同步更新，不需要逐条手动修改。规则权重设为"中"，错误描述写为"客户性别编码不在标准字典范围内，影响客户分群和画像标签的准确性"，修复建议写为"请核对CRM源系统中对应客户的性别信息，按标准字典（M=男/F=女）修正后重新同步"。
第六步：抽检验证
三条规则配置完毕后，不要急于创建正式评测任务。先在评测模型页面点击「抽检」功能，系统会在评测表中随机抽取少量数据进行规则试跑，快速验证各项规则的参数配置是否正确。抽检结果会即时展示匹配到的问题数据数量和明细，如果发现误报（如格式正确的手机号被判定为异常），可以当场调整EL表达式或规则参数。这一步骤虽然简单，但能有效避免将规则错误留到正式评测时才发现。
第七步：创建评测任务并调度
确认抽检结果无误后，进入「评测任务管理」页面创建评测任务，关联刚配置的"客户信息质量评测"模型。首次执行必须选择手工触发——手动跑一次全量评测，逐条查看结果，判断是真实质量问题还是规则配置导致的误报。确认问题清单合理之后，再将执行策略切换为定时模式。平台支持四种执行策略：手工触发、定时执行（指定一个具体时间点）、重复执行（按固定间隔周期性运行）、Cron表达式（一种Linux系统中的定时任务表达式，支持灵活定义执行时间规则，如"0 6 * * *"表示每天早上6点执行）。日常运维推荐采用重复执行-按天策略，设置在每天早上6点自动扫描前一天的增量数据，与业务使用数据的时间窗口错开。
第八步：查看结果与问题闭环
评测任务执行完成后，进入「问题数据查看」页面，可以按评测主题、评测模型、规则类型、问题状态、发现日期等多个维度进行筛选和查看。每条问题数据会展示违规字段、违反的规则、当前实际值、发现时间、状态等信息。问题闭环的完整流程是：系统扫描发现问题数据→自动标记为"待处理"状态→数据责任人认领并推动源系统修复→修复后下次评测任务自动重新扫描→验证通过后状态自动关闭。整个闭环过程中，问题的产生、分配、修复、验证都有记录可追溯。
四、执行与结果
以上述三条规则对某客户数据仓库中的86万条customer_info记录执行首次全量评测，实际产出结果如下：手机号缺失4,200条（占比0.49%），客户名称缺失1,200条（占比0.14%），手机号格式异常800条（占比0.09%），性别编码不在标准字典范围3,500条（占比0.41%），四项合计问题数据9,700条，整体问题率约1.03%。这个结果说明即便在运行多年的业务系统中，数据质量问题也并非个例——百分之一的异常率在百万级数据量下就是近万条需要处理的问题记录。
每条问题数据都可以点开查看详情：哪个字段违反了哪条规则、当前的实际值是什么、问题发现于何时。修复完成后，下一次评测任务会自动重新扫描对应记录，验证通过后问题状态自动关闭。这种"发现-标记-修复-验证-关闭"的闭环机制，让数据质量治理从一次性的人工排查变成了持续运转的日常机制。
五、项目实战中的四个常见坑
坑一：规则越多越好——认为质量监控就是要把能想到的检查项全部配上。 这个假设忽略了一个基本事实：告警的价值取决于被关注和处理的程度。实际项目中常见的情况是，团队第一次使用质量模块时热情高涨，一口气配置了三四十条规则，覆盖了几乎所有字段。第二天早上打开系统，几千条告警扑面而来，团队花了两天时间也只处理了不到三分之一。到第二周，通知被静音，第三周，质量模块实质上已被弃用。正确的做法是：先选择一到两个核心业务域，配置三到五条覆盖面广、业务影响大的高价值规则（如客户姓名空值、手机号格式、订单金额范围），跑通"发现→认领→修复→验证"的完整闭环，团队适应了节奏之后再逐批扩展规则覆盖范围。
坑二：把低价值字段等同于核心字段——没有区分"应该检查的"和"值得检查的"。 并非所有字段的缺失或异常都会对业务产生同等影响。手机号缺失直接阻断营销触达，确实值得告警；但备注字段（remark）为空，本身就是一个可空的自由文本字段，对其配置空值检查只会制造噪音。区分方法很简单：面对一个候选字段，问一句"这个字段的值出错了，下游哪个具体的业务环节会受影响？"回答不上来的字段，大概率不值得配置监控规则。
坑三：规则刚建好就设定时任务——主观认为抽检验证通过就等于规则完美。 抽检只覆盖少量样本，无法完全暴露规则在大规模数据下的表现。假设团队周五下午配置了五条规则并完成抽检，顺手设定了"每天晚上0点自动执行"的定时策略，然后下班。周末两天，系统每天凌晨定时触发评测，产生数百条误报告警堆积在系统中，周一早上团队面临的是需要逐条甄别的混乱局面。正确的流程是：规则配置完成后，第一步手工触发全量评测，第二步逐条确认问题数据的真实性，第三步剔除误报并调整规则参数，第四步确认问题清单无异常后再切换为定时策略。
坑四：错误描述用技术语言写——认为"phone字段不满足EL表达式REGEXP"这样的描述足够清楚。 技术团队可能看得懂"phone字段不满足NOT NULL约束"，但业务部门看到这样的描述完全无法判断问题的严重性和处理优先级。即便是技术团队，也很难从"不满足REGEXP"中看出这条数据对业务的具体影响。正确的写法是用业务语言回答三个问题：是什么问题（"客户手机号格式不符合11位手机号规范"）、影响什么（"导致短信触达失败，客户无法收到营销通知"）、怎么修（"请核对CRM源系统中客户手机号的录入格式，按11位标准修正"）。好的错误描述应该让业务人员一眼看懂问题严重性，让技术人员立刻知道去哪里修。
六、小反转：真正难的，不是发现问题
按照上述步骤配置三五条规则，几十分钟就能让系统自动扫描出近万条问题数据。但真正棘手的事情在扫描完成之后才浮出水面。你标记了4,200条手机号缺失、3,500条性别编码异常，这些数据谁来补？客服部门说"这些历史数据是前任同事录的，跟我没关系"，IT部门说"源系统的录入校验我们加不了，那是业务系统厂商的事"，而业务部门说"数据质量问题不解决，我们的报表永远不准"。
大部分数据质量问题并非系统故障导致的，而是业务过程的产物——录入时图省事跳过了非必填字段、历史数据迁移时未做清洗、不同系统的编码规则长期不统一。质量监控规则能扫描出来的，往往只是冰山浮在水面的一角，水面之下还沉积着大量历史遗留的脏数据。
旁路监测的真正价值并不在于发现问题的能力——配几条规则就能做到的事，门槛很低。它的价值在于提供了一套持续推动问题修复的抓手：每周生成按来源系统分类的问题清单，明确"哪个系统产生的数据出了什么问题、影响范围多大、建议谁来修复"；用数据说话——"本季度CRM系统产生的质量问题占全量的67%，主要集中在客户联系方式缺失"——这比任何口头的"数据质量很重要"都更有推动力。质量管理最终要解决的，不是一次性的数据清洗，而是建立一种让问题能够回到业务源头并得到修复的能力。
七、附：十二类质检规则一览
上文以客户信息表为例，演示了空值检查、格式规范性检查、引用完整性检查（字典校验）三类质检规则的配置方法。龙石数据质量模块共内置十二类质检规则，全部支持可视化配置，无需编写SQL或代码。其余规则的使用方式类似——选择规则类型、指定检查字段、配置校验参数、填写业务化的错误描述与修复建议：
| 规则类型 | 用途 | 典型场景 |
|---|---|---|
| 空值检查 | 校验必填字段是否存在空值 | 客户姓名、手机号不能为空 |
| 数据缺失检查 | 检测数据归集或共享过程中的数据丢失 | 源库1,000条记录，目标库仅950条 |
| 唯一性检查 | 检测是否存在重复数据记录 | 同一个学号在表中出现两次 |
| 值域检查 | 校验字段取值是否在合理范围内 | 交易金额必须大于0、年龄在0-120之间 |
| 格式规范性检查 | 校验字段格式是否符合规范 | 手机号、身份证号、邮箱格式 |
| 引用完整性检查 | 校验字段值是否在标准字典范围内 | 性别只能是男/女、省份代码在行政区划字典内 |
| 一致性检查 | 跨表比对数据是否一致 | CRM与订单系统的客户信息保持一致 |
| 逻辑检查 | 验证多字段之间的逻辑关系 | 毛利率是否等于（收入-成本）/收入 |
| 交叉比对检查 | 多表联合验证数据一致性 | 订单状态、出库记录、物流信息三方校验 |
| SQL检查 | 通过自定义SQL实现深度验证 | 已发货订单的承诺送达日期是否逾期 |
| 关联关系检查 | 验证表间的引用关系完整性 | 每个员工有且仅有一张工卡记录 |
| 自定义扩展 | 对接外部API服务进行专项校验 | 调用第三方地址校验接口验证地址有效性 |
八、常见问题 Q&A
Q1：旁路监测会影响数据同步的性能吗？
通常不会。质量评测任务在数据同步任务完成后独立运行，与数据同步链路不争抢计算资源。对于千万级以上的首次全量扫描，建议使用过滤条件（如按日期范围或分区字段）限定评测范围，或采用分批评测的方式降低单次负载。后续的增量评测只扫描当日新增数据，性能压力远小于首次全量。
Q2：系统发现质量问题后，会自动修复数据吗？
不会。质量管理模块的职责是发现问题和推动治理，而不是直接修改业务数据——擅自修改源数据可能引入更严重的业务风险。问题数据被扫描出来后，进入问题库并标注所属规则、当前值和修复建议。业务侧在源系统中完成数据修正并重新同步后，下一次评测任务会自动重新扫描对应记录，验证通过后问题状态自动关闭。
Q3：什么时候用旁路监测，什么时候用强校验？
两者并不冲突，适用于不同场景。身份证号、统一社会信用代码等对数据准确性要求极高、且错误可能引发合规风险的核心字段，适合在入库环节采用强校验。客户信息、设备日志、业务标签等数据量大、更新频繁、个别脏数据不影响核心业务的场景，更适合旁路监测——既不让少数问题数据卡住整条数据链路，又能持续发现并推动修复。
Q4：规则配错了导致大量误报，怎么快速修正？
评测模型管理页面支持对已有规则进行编辑和禁用操作。如果已经产生了大量误报告警，建议先使用「清除所有问题」功能清理垃圾数据，然后修改规则参数（如调整EL表达式或放宽值域范围），修改完成后重新手工触发全量评测进行验证。这也是第七步强调"首次执行必须手工触发"的原因——给规则留出验证和调整的窗口。
Q5：业务表新增了字段，已有规则需要重新配置吗？
如果新增字段与已有规则无关，不需要任何改动。如果新增字段需要纳入质量监控，直接在对应的评测模型中新增一条规则即可，不需要重建评测模型或修改已有规则。评测模型的规则之间相互独立，支持按需灵活增减。
Q6：评测任务执行到一半失败了怎么办？
在评测任务管理页面查看失败任务的执行日志，定位具体失败原因。常见的三种情况：一是数据库连接超时，检查网络连通性和数据库连接池配置；二是规则中引用的字段在表中已被删除或重命名，需要同步更新元数据中的表结构信息，然后修正规则中引用的字段名；三是EL表达式存在语法错误，回到规则编辑页面使用抽检功能提前验证表达式的正确性。
九、方法论收尾
数据质量管理的目标，并不是一次性把所有问题都清理干净——这在企业数据环境中几乎不可能做到。更务实的目标是：在不影响业务正常运行的前提下，让数据质量问题能够持续被发现、被跟踪、被修复。规则不在多，从一个核心业务域的三到五条高价值规则起步，跑通闭环之后再逐批扩展。这一思路体现了数据治理的核心理念：不是项目验收时的一次专项行动，而是融入日常运营的持续性工作。
龙石数据中台的质量管理模块正是围绕这一理念设计——旁路监测保障业务连续性、可视化配置降低使用门槛、闭环追踪推动持续改进。在实际落地中，江苏某大数据中心通过这套机制沉淀了超过5,000条质量规则，累计评测超10亿条数据，问题修复率达到95%；华东某数据局沉淀了1,000余条监测规则，问题修复率超过93%，数据目录合格率从6.34%提升至94.74%。
规则持续运行，质量持续提升——数据治理才能真正成为日常工作的一部分。
十、参考来源
GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会
DAMA International，《DAMA数据管理知识体系指南》（DMBOK2），机械工业出版社
