Verity数据验证框架：从规则引擎到自动化数据质量监控

在数据平台和微服务架构里，一个经常被忽视但又绕不开的问题是：数据到底对不对。开发时看接口返回觉得没问题，测试环境数据量小也发现不了异常，等上了生产，业务方拿着报表问为什么对不上数，这个时候才意识到缺了一套数据验证机制。Verity 就是用来解决这个问题的——它是一套数据验证系统，核心职责是持续检查数据是否满足预期规则，并在不满足时及时暴露问题。这篇博客会从问题背景、核心机制、最小实现、参数配置到生产排错，完整梳理 Verity 在数据验证链路里到底做了什么，以及你自己如何搭建一个可用的验证框架。

1. 先理解 Verity 在数据链路里的定位

1.1 数据验证为什么不能靠人工抽查

很多团队对数据质量的把控方式，是上线前跑几条 SQL 看一眼，或者让测试人员手工核对几个关键字段。这种方式在数据量小、链路短、变更不频繁的场景下还能勉强工作，但一旦进入以下情况就会失效。

• 数据来源多，同一份数据经过采集、清洗、转换、聚合多个环节，每个环节都可能引入偏差。
• 数据量大，全量核对的时间和资源成本过高，抽样核对又无法覆盖全部异常。
• 变更频繁，表结构调整、口径修改、上游任务重跑、字段枚举值变化，都可能让历史验证规则失效。
• 发现问题滞后，人工核对通常在数据使用阶段才执行，异常已经影响下游报表或模型训练。

Verity 的定位就是把“随机核对”变成“规则化验证”。它用可配置的规则描述预期，以自动化的方式周期性执行，并输出结构化结果。只要数据发生变化，验证结果就能反映变化是否可接受。

1.2 Verity 是工具还是框架

在开源社区和搜索引擎里，Verity 这个名字并不唯一。它可能是某个公司内部的验证平台，也可能是一个针对特定引擎的校验组件。这里不纠结具体指代哪一个仓库，而是把它作为一类数据验证系统的统称来讨论。

一个合格的 Verity 系统至少包含三个部分。

• 规则管理：定义验证什么、怎么验证、阈值是多少。
• 执行引擎：按调度计划读取数据、执行规则、捕获异常。
• 结果输出：把验证通过或失败的结果落库、告警或回调给下游。

所以回答“verity 在干什么”，可以从三个层面理解：它是对数据质量做持续验证的工具，是把业务口径固化成可执行规则的执行器，也是数据异常时的第一道告警防线。

1.3 什么时候需要引入 Verity

不是所有项目都需要马上引入一套数据验证系统。需要先判断是否满足下面任一条件。

• 有多个上游系统写入同一份数据仓库，并且口径经常调整。
• 数据用于财务、风控、对账、报表等对准确性要求较高的场景。
• 数据链路长，单次任务失败不会立即报错，但最终结果明显不合理。
• 团队已经出现过线上数据质量问题，并且靠人工排查效率很低。

如果只做个人练习或单表简单查询，不需要引入完整验证框架，用几条 SQL 断言即可。但如果是在团队协作或多系统交互的环境里，Verity 这类工具的价值会随着链路复杂度快速放大。

2. 核心机制拆解：规则校验从定义到执行的完整链路

2.1 验证规则的本质是布尔断言

不管实现的复杂程度如何，任何数据验证规则最终都可以归结为一条布尔表达式：输入一批数据，判断它是否满足某个条件，输出 true 或 false。

例如验证订单金额不能为负数，本质是断言min(amount) >= 0。验证订单量不能波动超过 20%，本质是断言(today_total - yesterday_total) / yesterday_total <= 0.2。验证某张表记录数不为空，本质是断言count(*) > 0。

把规则抽象成断言有非常实际的好处：规则之间的表达方式统一，执行结果可以标准化，失败信息可以结构化。无论是简单边界检查还是复杂的跨表一致性校验，都可以纳入同一套执行机制。

Verity 在设计上会让用户通过配置文件或代码声明这些断言，而不是把逻辑硬编码在业务代码里。这样规则变更不需要重新发布整个服务。

2.2 规则执行的三个阶段

一次完整的验证任务可以拆成三个阶段。

第一阶段是数据获取。验证引擎需要连接数据源，拉取要校验的数据集。这里的数据源可能是数据库表、数据湖分区、消息队列中的批量消息，也可能是对象存储中的文件。数据获取阶段需要关注的是查询超时、数据量过大、分区是否已就绪。

第二阶段是规则执行。引擎读取规则配置，把规则翻译成可执行的校验逻辑。比如规则类型是column_not_null，引擎就生成对目标列的非空检查 SQL；规则类型是row_count_between，引擎就生成一张子查询并判断行数是否落在区间内。执行阶段最关键的指标是耗时和资源占用，要避免验证任务本身对生产数据库造成压力。

第三阶段是结果处理。每个规则执行后产生一个结果对象，包含规则 ID、执行时间、目标表、涉及指标、期望值、实际值、是否通过。Verity 再把这些结果写入结果表，按级别触发告警或阻断后续流程。

2.3 验证结果如何表达

一个规则执行完，只有“通过”和“未通过”两个状态是不够的。排错时最需要的三类信息是期望值、实际值和偏差方向。

例如某条规则希望表 A 的行数在 100000 到 200000 之间，实际运行结果是 0。这时如果只看到“校验失败”，无法判断是数据没写入还是查询条件有问题。只有同时输出 expectation=100000~200000，actual=0，才方便定位问题。

所以 Verity 的结果模型至少要有下面几个字段。

这套模型好处在于：可以按规则维度做历史趋势分析，查看某条规则的通过率变化；可以按表维度聚合，快速看到哪些数据表问题最多；可以按时间维度观察，判断异常是否和数据任务运行周期相关。

3. 从零实现一个最小可用的 Verity 验证服务

3.1 环境准备与项目结构

这里用一个 Spring Boot 工程来演示 Verity 的核心实现思路。为了便于复现，尽量少引入外部依赖。

环境建议：

创建项目时可以按下面的结构组织。

verity-demo/ ├── pom.xml ├── src/main/java/com/example/verity/ │ ├── VerityApplication.java │ ├── config/ │ │ └── QuartzConfig.java │ ├── controller/ │ │ └── VerifyController.java │ ├── entity/ │ │ ├── VerifyRule.java │ │ └── VerifyResult.java │ ├── mapper/ │ │ ├── VerifyRuleMapper.java │ │ └── VerifyResultMapper.java │ ├── service/ │ │ ├── RuleLoaderService.java │ │ ├── RuleExecutorService.java │ │ └── VerifySchedulerService.java │ └── job/ │ └── VerifyJob.java └── src/main/resources/ ├── application.yml └── schema.sql

这个结构的关键点是把规则加载、规则执行、结果写入分开，避免把所有逻辑堆在一个类里。实际项目中如果规则量大，还可以再加规则缓存和分布式锁。

3.2 规则表和结果表的建表设计

规则需要用数据库表存储，方便通过管理后台或 SQL 增改规则。下面是最小化的表设计。

CREATE TABLE verify_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_id VARCHAR(64) NOT NULL, rule_name VARCHAR(128) NOT NULL, target_table VARCHAR(128) NOT NULL, metric_type VARCHAR(32) NOT NULL, expectation VARCHAR(256) NOT NULL, severity VARCHAR(16) NOT NULL DEFAULT 'INFO', enabled TINYINT NOT NULL DEFAULT 1, cron_expr VARCHAR(64) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_rule_id (rule_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

结果表用于记录每次执行情况。这里要注意，结果表不要只写一条状态，尽量把实际数值、期望表达式和错误信息一起保存。

CREATE TABLE verify_result ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_id VARCHAR(64) NOT NULL, target_table VARCHAR(128) NOT NULL, metric_type VARCHAR(32) NOT NULL, actual_value VARCHAR(64) NOT NULL, expectation VARCHAR(256) NOT NULL, status VARCHAR(16) NOT NULL, error_message VARCHAR(512), executed_at DATETIME NOT NULL, cost_ms BIGINT NOT NULL DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建表时有几个细节值得注意。

• metric_type用字符串存储，是因为不同验证类型需要的参数不一样，枚举值可扩展性更好。
• expectation用字符串，是为了兼容多种表达式格式，比如gt:0、between:100,200、eq:success。
• 结果表保留error_message，即使校验失败也能看到具体原因，减少二次排查成本。
• 规则表建议加唯一索引，防止重复规则导致执行结果冲突。

3.3 Maven 依赖配置

pom.xml 中的核心依赖是 Spring Boot Starter Web、MyBatis、MySQL 驱动和 Quartz。

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

Quartz 的引入是为了让验证任务按 cron 表达式调度，而不是靠 Controller 手动触发。实际生产环境中，如果已经有统一的调度平台，也可以不做 Quartz 集成，只把验证逻辑封装成一个可被调度的服务。

3.4 规则加载器的实现

规则加载器的职责是从数据库读取启用的规则，并转换成内部对象。实际项目里，规则可能还会来自配置中心或 JSON 文件，但数据源统一成数据库后更容易管理。

@Service public class RuleLoaderService { @Resource private VerifyRuleMapper verifyRuleMapper; public List<VerifyRule> loadEnabledRules() { return verifyRuleMapper.selectEnabledRules(); } public Map<String, VerifyRule> loadAsMap() { return loadEnabledRules().stream() .collect(Collectors.toMap(VerifyRule::getRuleId, rule -> rule)); } }

这里要注意缓存问题。如果规则每分钟执行一次，而每次执行都查数据库，对数据库压力不大，但也没必要。更推荐的做法是启动时加载到本地缓存，然后通过监听数据库变更或定时刷新来更新缓存。

3.5 规则执行器的设计

执行器是 Verity 的核心。它的输入是一条规则和一批连接信息，输出是一个 VerifyResult 对象。

@Service public class RuleExecutorService { @Resource private VerifyRuleMapper verifyRuleMapper; @Resource private JdbcTemplate jdbcTemplate; public VerifyResult execute(VerifyRule rule) { long start = System.currentTimeMillis(); VerifyResult result = new VerifyResult(); result.setRuleId(rule.getRuleId()); result.setTargetTable(rule.getTargetTable()); result.setMetricType(rule.getMetricType()); result.setExpectation(rule.getExpectation()); try { String sql = buildSql(rule); String actualValue = queryActualValue(sql); result.setActualValue(actualValue); boolean pass = doAssert(rule.getMetricType(), actualValue, rule.getExpectation()); result.setStatus(pass ? "PASS" : "FAIL"); if (!pass) { result.setErrorMessage("metric check failed, actual=" + actualValue + ", expectation=" + rule.getExpectation()); } } catch (Exception e) { result.setStatus("ERROR"); result.setErrorMessage(e.getMessage()); } finally { result.setCostMs(System.currentTimeMillis() - start); } return result; } }

executor 里有几个值得讨论的细节。

• 异常必须捕获并按 ERROR 状态写入结果表，不能抛出去中断整个调度。否则一条规则的问题会导致所有规则不执行。
• SQL 拼接不要直接使用外部字符串，防止注入。规则表属于内部管理内容，风险相对低，但仍建议用白名单方式限制表名合法性。
• 实际值统一转成字符串，方便结果表存储，也在断言层做一次类型转换。

3.6 规则类型与 SQL 生成

不同 metric_type 对应不同 SQL 模板。常见的验证类型可以按下面表格拆分。

private String buildSql(VerifyRule rule) { String table = rule.getTargetTable(); String metricType = rule.getMetricType(); switch (metricType) { case "row_count_between": return "SELECT COUNT(*) FROM " + table; case "column_not_null": return "SELECT COUNT(*) FROM " + table + " WHERE " + rule.getColumnName() + " IS NULL"; case "column_min_gt": return "SELECT MIN(" + rule.getColumnName() + ") FROM " + table; case "duplicate_check": return "SELECT COUNT(*) - COUNT(DISTINCT " + rule.getColumnName() + ") FROM " + table; default: throw new IllegalArgumentException("unsupported metric type: " + metricType); } }

这个设计大大简化了规则扩展方式。新增一个 metric_type 时，只需要在 SQL 构建和断言判断两处扩展，不需要改动调度和结果写入逻辑。

3.7 断言判断：把期望表达式解析成比较逻辑

规则表的 expectation 字段存的是字符串，需要一套解析规则把它转成可执行的比较。推荐用“类型前缀 + 冒号 + 值”的结构。

private boolean doAssert(String metricType, String actualValue, String expectation) { if (expectation.startsWith("gt:")) { double expect = Double.parseDouble(expectation.substring(3)); return Double.parseDouble(actualValue) > expect; } if (expectation.startsWith("ge:")) { double expect = Double.parseDouble(expectation.substring(3)); return Double.parseDouble(actualValue) >= expect; } if (expectation.startsWith("lt:")) { double expect = Double.parseDouble(expectation.substring(3)); return Double.parseDouble(actualValue) < expect; } if (expectation.startsWith("eq:")) { return actualValue.trim().equals(expectation.substring(3).trim()); } if (expectation.startsWith("between:")) { String[] parts = expectation.substring(8).split(","); double expectLow = Double.parseDouble(parts[0]); double expectHigh = Double.parseDouble(parts[1]); double actual = Double.parseDouble(actualValue); return actual >= expectLow && actual <= expectHigh; } throw new IllegalArgumentException("unsupported expectation: " + expectation); }

选择这种格式的原因是配置语义清晰，且方便在规则管理页面上做表单校验。业务人员不需要写复杂代码，只要会填表达式。

3.8 调度任务与结果落库

调度任务负责定时触发 execute 逻辑。这里用 Quartz 的 Job 来实现。

@Component public class VerifyJob extends QuartzJobBean { @Resource private RuleLoaderService ruleLoaderService; @Resource private RuleExecutorService ruleExecutorService; @Resource private VerifyResultMapper verifyResultMapper; @Override protected void executeInternal(JobExecutionContext context) { List<VerifyRule> rules = ruleLoaderService.loadEnabledRules(); for (VerifyRule rule : rules) { VerifyResult result = ruleExecutorService.execute(rule); verifyResultMapper.insert(result); } } }

这里存在一个常见问题：如果规则多，串行执行耗时长，后续规则会推迟。生产环境可以按目标表拆分线程池，或者按规则优先级分为不同的调度组。

4. 参数说明与配置策略

4.1 规则参数如何配置才合理

编写规则时，最常踩的坑是阈值设得太严或太松。阈值太严，数据正常波动也会频繁告警，团队会逐渐忽略告警；阈值太松，真实问题被掩盖。没有通用的固定值，只能根据业务历史数据设置。

推荐的做法是每天观察指标分布，取过去 7 天或 30 天的平均数作为基准，再结合标准差设置波动范围。比如订单量的基数在 100000 左右，标准差约 5000，那么between:85000,115000就是相对合理的区间。等运行一段时间后再根据误报率调整。

4.2 调度周期的影响

调度周期决定发现异常的速度，也决定对数据源的压力。

短周期适合验证实时性要求高的指标，比如接口成功率和今日订单总额。但如果底层表还在同步过程中，执行得太早会把中间状态当成最终状态，产生大量误报。长周期适合验证离线数仓的全量表，比如 T+1 的汇总指标。

一个折中策略是把规则分成“准实时”和“离线批处理”两组。准实时规则每 5 分钟执行一次，只校验实时表的关键指标；离线规则每天凌晨 2 点后执行，等所有 ETL 任务跑完再校验。

4.3 告警阈值和分级

规则表里有severity字段，用来表达规则严重程度。一般分为 INFO、WARNING、ERROR 三级。

• INFO：校验失败只记录，不打扰。适合观察类指标。
• WARNING：校验失败触发告警，但下游流程继续。适合一般质量指标。
• ERROR：校验失败阻断下游任务，或者立即通知值班人员。适合对账类核心指标。

分级的意义在于避免所有失败都走同一条告警路径。如果每条失败都发短信或打电话，运维很快会疲劳。只有对核心规则保持实时响应，才能让告警真正被处理。

5. 运行验证与预期结果

5.1 准备测试数据

下面用一个简单的订单表做演示。先造一张test_order表，插入几条订单数据。

CREATE TABLE test_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, amount DECIMAL(12,2) NOT NULL, status VARCHAR(16) NOT NULL, created_at DATETIME NOT NULL ); INSERT INTO test_order (order_no, amount, status, created_at) VALUES ('A001', 88.50, 'PAID', NOW()), ('A002', 120.00, 'PAID', NOW()), ('A003', 6.00, 'CANCELLED', NOW()), ('A004', 39.90, 'PAID', NOW()), ('A005', 0.00, 'PAID', NOW());

这张表里有几个适合验证的点：存在 amount=0 的订单、有 CANCELLED 状态、行数为 5。可以根据这些特征设计规则。

5.2 往规则表里配置验证规则

INSERT INTO verify_rule (rule_id, rule_name, target_table, metric_type, expectation, severity, enabled, cron_expr) VALUES ('order_row_count', '订单表行数检查', 'test_order', 'row_count_between', 'between:5,10', 'WARNING', 1, '0 * * * * ?'), ('order_amount_min', '订单金额最小值检查', 'test_order', 'column_min_gt', 'gt:0', 'ERROR', 1, '0 * * * * ?'), ('order_dup_no', '订单号重复检查', 'test_order', 'duplicate_check', 'eq:0', 'WARNING', 1, '0 * * * * ?');

注意第二条规则order_amount_min期望金额大于 0，但测试数据里有一条 amount=0 的订单，因此这条规则会校验失败。这正是用来演示 FAIL 状态的好例子。

5.3 启动服务并观察结果

启动 Spring Boot 应用后，验证任务会按照 cron 配置每分钟执行一次。查询结果表可以看到每次执行的状态。

SELECT rule_id, actual_value, expectation, status, error_message, executed_at FROM verify_result ORDER BY executed_at DESC;

预期结果：

这条结果说明 Verity 的系统行为完全正常：规则能执行，结果能落库，失败规则有详细的 error_message。接下来就可以接告警、接可视化，或者扩展更多规则。

如果结果表没有数据，优先检查三项：Quartz 调度是否启动、规则表里 enabled 是否为 1、执行 SQL 是否报错。这三个原因占了大部分“规则没执行”的情况。

6. 常见问题与排查路径

6.1 规则不执行

现象：verify_result 表一直没新增数据。

排查顺序：

1. 检查规则表 enabled 字段是否为 1。
2. 检查应用日志有没有 Quartz 调度日志。
3. 检查 cron 表达式是否合法。
4. 检查 RuleLoaderService 里查询语句是否正常。
5. 如果是多实例部署，检查是否有分布式锁，避免多个实例重复执行或互相阻塞。

常见原因是规则表里 cron_expr 写错。比如0 * * * * ?表示每分钟第 0 秒执行，写成了0 0 * * * ?就变成每天 0 点执行一次。

6.2 校验结果一直 FAIL，但数据看起来正常

现象：规则持续报 FAIL，人工核对却发现表数据没有异常。

这种问题绝大多数不是系统坏了，而是规则本身有问题。重点检查：

• expectation 是否写反，比如把lt:100写成了gt:100。
• 当数据为空时聚合函数的行为。比如SELECT MIN(amount) FROM test_order，如果表为空，结果不是 0 而是 NULL，字符串化的 actual 是null，转 double 会抛异常，最终被捕获后标记为 ERROR。
• 检查目标数据是否在验证时还没有同步完成。

建议在规则执行前，先手动跑一遍生成的 SQL，确认返回结果，再核对 expectation 是否与业务预期一致。

6.3 实际值发生变化但结果总是 PASS

现象：数据明显有问题，结果表却全部是 PASS。

可能原因有两个。第一，expectation 区间设置得太大，异常值落在正常范围内。第二，SQL 里用错了列，校验的不是真正关心的字段。

排查时先把这条规则最近几天的 actual_value 拉出来，看数值分布是否合理。

SELECT rule_id, actual_value, executed_at FROM verify_result WHERE rule_id = 'order_amount_min' ORDER BY executed_at DESC LIMIT 20;

如果实际值一直稳定在 0，说明被测数据本身就存在异常，规则没起作用的真正原因是 expectation 写错或规则没生效，而不是系统没检查。

6.4 执行任务对数据库造成压力

现象：验证任务执行期间，生产库 CPU 上升，慢查询增多。

原因通常是验证 SQL 扫了全表，或者同时执行的规则太多。

处理方式：

• 只在只读从库上执行验证，不要把验证任务打到主库。
• 大表验证优先使用采样或分区裁剪，不要全表扫描。
• 控制同一时刻并发执行的规则数量，避免高峰期集中触发。
• 对复杂验证可以先用日汇总表，而不是每次都扫描明细表。

6.5 重复告警导致疲劳

现象：一个规则持续失败，告警一直发，最后团队直接把告警关了。

解决方式是把告警升级策略做成衰减式：同一规则连续失败 N 次后，降低告警频率，并且只有恢复后才重置计数。这样既不会漏掉持续性问题，也不会一直刷屏。

7. 最佳实践与生产落地建议

7.1 规则治理要先于规则建设

很多团队一开始热情很高，连续配置几十条规则，但两周后就开始发现大量误报，最后规则被禁用一半。问题不是 Verity 不好用，而是缺少规则治理流程。

建议新增一个规则时先回答三个问题：

• 这个指标用哪个字段计算，统计口径是什么。
• 正常值范围是多少，依据是哪段历史数据。
• 校验失败后，谁负责排查，怎么通知，期望恢复时间是多少。

没有这三个答案的规则，建议先不要上线，而是放进待评审列表。

7.2 把验证结果接入运维体系

验证结果不应该是孤立数据。结果表里保存的 PASS/FAIL 记录，经过一段时间后就能反映数据质量趋势。

• 按天聚合规则通过率，能看到哪类表最容易出错。
• 按规则 ID 聚合失败次数，可以找出“总是坏”的规则。
• 按执行时间分布分析，可以判断哪些任务经常延迟，延迟是否引发后续问题。

有了这些数据，验证系统就不再只是查错工具，而是数据质量改进的度量工具。

7.3 把规则配置模板化

如果团队有多个业务域，每个域都有订单、用户、流水等相似的验证需求，可以沉淀一套模板。例如“订单表基础检查”模板包含行数区间、金额最小值、订单号唯一性三个规则。新表接入时只需要替换表名和阈值，不用从零编写规则。

这样做的直接收益是降低配置成本，间接收益是让不同域之间的质量口径保持一致，对比报表时更有意义。

7.4 学习环境与生产环境差异

在本地学习时，可以用内存数据库如 H2 替代 MySQL，把 Quartz 调度周期调短，方便快速验证结果。生产环境至少还要补上以下几块。

• 配置外置化：把数据库连接、调度开关、规则刷新间隔放到配置中心。
• 权限控制：不是所有人都能在生产环境新增、修改、禁用规则。
• 日志监控：验证任务本身的执行耗时、失败率、队列堆积情况需要监控。
• 回滚能力：批量修改规则后，如果出现大面积误报，要能快速回滚到上一版本。

7.5 关于 Verity 的扩展方向

当前实现是基础的规则验证模型，可以继续扩展的方向包括：

• 跨表一致性校验，支持同一批数据中两张表的行数或金额总和相等。
• 数据血缘集成，把验证规则绑定到数据地图，方便看到某个字段曾被哪些规则覆盖。
• 指标画像功能，自动学习历史数据分布，推荐合理的 expectation，减少人工配阈值的工作。
• 异步执行队列，把规则提交到消息队列，通过多个 worker 消费，解决大批量规则执行慢的问题。

8. 结尾

Verity 类数据验证系统的核心价值，是让数据校验从“上线前临时查一查”变成“周期性自动化执行并留痕”。它的工作流程并不复杂：定义规则、周期执行、输出结果、失败告警。但真正让它发挥作用的，是规则是否贴合业务、阈值是否合理、失败后是否有人能沿着结构化结果快速排查。

搭建最小实现时，建议先跑通“规则表 + 执行器 + 结果表”这条最简链路，确认结果能落库，再逐步加入调度、告警、可视化和管理后台。生产环境则要额外关注只读数据源、分布式锁、规则治理和告警降噪。

如果团队的数据质量问题经常要花大量时间追问“这个数为什么不对”，那么 Verity 这类验证框架值得认真引入一次。配置若干条核心规则后，你可能会发现大量此前从未被注意的隐性数据问题。