如果你们团队正在做数据库迁移或者同步链路的验收大概率会遇到一个看起来简单、实际很难回答的问题两边数据到底一不一样我们在一次国产数据库环境替换项目中就被这个问题卡了很久。手工导数据、逐表数行数短期还能应付数据量一上来就完全顶不住。于是内部搭了一套轻量级的数据对比工具VERI专门用于国产数据库本文以DMS系列数据库为例源端与目标端的一致性校验。这篇内容就完整记录这个工具从需求、设计、部署到实战排查的全过程给同样被数据比对折磨的同学一个参考。VERI能做的事包括表结构对比、行数对比、数据指纹对比、差异行定位最后自动输出一份差异报告整个过程基本不需要人工干预。1. 为什么需要数据对比工具迁移与同步场景下的硬需求1.1 迁移验收不能只数行数数据库迁移项目的验收环节最常听到的一句话就是“两边行数都对上了”。但行数对上不代表数据一致。同一张表源库和目标库各有100万行可能是同一批数据也可能是每边各自缺了不同的记录凑巧数量相同。更麻烦的是字段值不一致时间精度被截断、小数位被四舍五入、字符集转码导致中文乱码这些都不会影响总数却直接影响业务。行数比对只是第一层。真正可靠的验收要做内容级比对。VERI的设计目标就是把这层内容比对自动化源库一个查询、目标库一个查询两边对hash值不一致就落到差异表再让运维去处理。1.2 三类典型场景一次性迁移、双轨巡检、同步链路监控我们做VERI时明确了对三类场景的支持。第一类是一次性迁移验收。业务系统从一个数据库整体搬到另一个数据库迁移工具跑完后需要证明“搬干净了、没搬错”。这种情况下要求做全量比对所有用户表、索引、约束、数据都要过一遍。第二类是双轨运行期间的日常巡检。业务在切换过程中会有一段时间两边同时写入应用层通过中间件做双写。双写最容易出现单边成功、单边失败的问题所以需要每天定时跑一遍对比发现差异马上报警。第三类是同步链路监控。比如主库通过日志解析把数据同步到查询库或者通过数据集成工具做准实时同步同步链路偶尔会中断、会丢消息。VERI每周做一次抽样比对能及时发现同步链路的隐性故障。1.3 手工比对的痛点和工具解决思路在没有VERI之前我们尝试过几种手工方案都不理想。第一种是导出再对比。用数据库工具把表导出成文本文件再写脚本逐行比对。小表没问题大表导出耗时很长而且导出中途资源占用过高影响生产库性能。第二种是写一次性SQL。用两边的SQL把数据拼成字符串然后全表聚合取MD5人工对比结果。操作繁琐而且每张表都要手写SQL字段几十个的时候SQL写出来一大串维护成本非常高。第三种是只抽样。随机抽几千行比对效率高但漏检率高适合有把握的环境不适合迁移验收这种关键场景。VERI的思路是把这些手工步骤变成标准化流程自动读取表清单自动生成对比SQL自动并发执行自动汇总差异。人只需要看报告做决策。2. 搭建前的方案选型与整体设计2.1 分层对比策略设计VERI时我们没有一上来就做“最完整”的逐行全量比对而是采用了分层策略先粗后细逐层缩小范围。第一层是元数据比对。对比两边表名、字段名、字段类型、字段长度、是否非空、默认值。这一层解决的问题是“表结构是否对应”。结构不对后面数据对比没有意义。第二层是行数比对。对比每张表的记录数快速找出明显差异。如果一张表源库是100万行目标库是90万行那就不用继续往下比了先查同步链路。第三层是数据指纹比对。对整张表或分片数据计算聚合校验值比如CRC32、MD5两边对比校验值。一致则大概率数据一致不一致则说明存在差异进入下一层。第四层是差异行定位。对指纹不一致的分片拉取具体数据行进行逐行比对定位到主键级别的差异记录生成明细报告。这种分层设计的核心价值是省钱。全表逐行比对是O(N)成本指纹比对通常能把需要逐行检查的数据量缩小到全表的百分之几甚至千分之一尤其是数据基本一致的场景收益非常明显。2.2 VERI的工具架构与模块划分VERI整体分为六个模块。配置管理模块负责读取连接配置、比对规则、忽略清单。连接管理模块负责维护源库和目标库的连接池避免频繁建立连接。任务调度模块负责把表清单拆分成多个任务交给并发线程池执行。比对引擎是核心模块负责生成对比SQL、执行查询、计算校验值、判定结果。差异存储模块把有差异的分片和行主键写入本地差异库方便后续查询。报告输出模块最后生成CSV和HTML两种格式的报告。模块划分遵循了一个原则比对引擎不关心数据来自哪张表只关心“怎么比”任务调度不关心比什么只关心“怎么分配”。这样后续如果要新增对比规则只需要改比对引擎不会动其他模块。2.3 关键设计决策与取舍在工具选型上我们内部讨论过用现成的商业比对工具也考虑过基于ETL工具二次开发。最后都放弃了。商业工具功能强但是在这个环境里适配成本高而且我们需要把差异结果跟自己的工单系统打通商业工具的黑盒逻辑不太好扩展。ETL工具侧重重数据搬运对比能力相对弱我们只需要比对不需要搬数引入整套ETL太重了。最终选择了基于Python自研轻量工具。原因有几个一是Python在数据类工具生态成熟连接数据库的驱动齐全二是开发效率高核心逻辑几百行代码就能跑通三是部署简单一台Linux跳板机装好Python环境就能运行不需要额外安装中间件。开发语言选定之后最关键的架构决策是“计算下推”。把聚合校验值的计算放到数据库端执行而不是把数据拉到工具内存里算。比如分片内的数据在数据库端做字符串拼接、做哈希聚合工具只需要拿到一个哈希值。这样可以大幅降低网络传输量和内存占用。2.4 部署环境与依赖清单在实际部署时我们准备了一个最小的环境。调度机是一台普通的Linux虚拟机2核4GB内存Python 3.8安装了数据库驱动和OpenPyXL。源库和目标库是两套独立的DMS数据库实例应用账号只需要授予对比表的SELECT权限。网络层面要求调度机能同时访问两个库的数据库服务端口两边数据库不需要互相访问这个条件在大多数网络隔离场景下都能满足。驱动安装有一点要注意国内数据库产品对应的Python驱动有时分的版本比较多要确认驱动版本和数据库服务端版本兼容。我们在测试环境遇到过驱动版本过旧导致浮点数读取精度丢失的问题排查了很久才发现是驱动版本不匹配。3. 核心实现配置、分片与对比逻辑3.1 配置文件设计与关键参数VERI使用YAML格式的配置文件来管理所有参数。配置文件分为三块连接信息、比对规则、执行参数。连接信息块内容如下source: host: 192.168.10.11 port: 5236 username: cmp_user password: enc_placeholder database: app_src target: host: 192.168.10.22 port: 5236 username: cmp_user password: enc_placeholder database: app_dst这里要对密码做占位处理真实的密码通过环境变量或密钥文件注入避免明文放配置文件里。数据库对比工具通常需要较高的权限密钥管理一定不能省。执行参数块是调优重点execution: concurrency: 4 commit_batch: 500 query_timeout: 300 hash_algorithm: md5 sample_rate: 1.0concurrency表示并发线程数不是越大越好后面会专门说。hash_algorithm支持md5和crc32MD5碰撞概率极低推荐用于正式验收CRC32计算更快适合抽查场景。sample_rate是采样率默认1.0表示全量日常巡检可以设0.1只比对10%的数据分片提高效率。3.2 表清单发现与忽略规则对比前需要确定“比哪些表”。VERI支持两种模式手动指定表清单或者自动发现表清单。自动发现模式下工具查询数据库元数据表获取所有用户表然后应用忽略规则。忽略规则配置如下rules: ignore_tables: - TMP_* - *_BAK - SYS_LOG_* ignore_columns: - last_update_time忽略规则非常实用。比如日志类表数据量大、时效性强同步过程中可能一直在写入对比它们没有意义还耽误时间。临时表和备份表也应该跳过。ignore_columns用于忽略强波动字段比如最后更新时间这类字段在源库和目标库天然不一致放进对比里只会制造噪音。表清单发现后VERI还会做一次结构映射。因为源库和目标库的表名可能不同比如源库叫ORDER_INFO目标库叫ORDER工具通过配置里的表映射关系把它们对应起来。3.3 分片比对原理与并发控制全表一次性做哈希比对在数据量小的场景可行数据量一大就非常危险。一次扫描几千万行数据库端需要临时表空间拼接所有字段工具端长时间等待一个SQL返回任何一端出问题整个任务就卡死。VERI的分片思路是按主键或唯一键把表拆成N个范围每个范围作为一个独立比对单元。用户表通常有主键可以直接用主键分片。没有主键的表按行号ROWID切分。伪代码实现如下def build_slices(conn, table, slice_col, total_rows, slice_size): min_val conn.query(SELECT MIN(%s) FROM %s % (slice_col, table)) max_val conn.query(SELECT MAX(%s) FROM %s % (slice_col, table)) step (max_val - min_val) / slice_size slices [] for i in range(slice_size): low min_val i * step high min_val (i 1) * step slices.append((low, high)) return slices这个写法针对整型主键比较直观但要注意主键分布不均匀的问题。如果主键不是均匀自增按范围切分会产生大小差异很大的分片。更稳妥的做法是先查主键分布或者按主键值列表分批处理。我们后期改成了按主键排序后均匀抽样取边界值每个分片行数基本一致避免出现“一个分片占了全表90%数据”的情况。并发数设置我们踩过坑。一开始图快把并发数调到12结果源库和目标库的CPU直接飙到90%以上对比任务本身影响了生产业务。后来把并发数控制在4到6同时对数据库连接池做限流每个线程最多持有2个连接整体资源占用就会可控很多。3.4 聚合校验值哈希的实现分片确定后每个分片会在数据库端计算一个聚合校验值。核心SQL逻辑如下SELECT MD5(STRING_AGG(md5_part, )) FROM ( SELECT MD5( COALESCE(CAST(id AS VARCHAR(100)), ) || | || COALESCE(CAST(name AS VARCHAR(200)), ) || | || COALESCE(CAST(amount AS VARCHAR(50)), ) ) AS md5_part FROM order_info WHERE id BETWEEN :low AND :high ) t;这段SQL的思路是先把每一行数据的所有字段拼接成一个字符串计算行的MD5再把分片内所有行的MD5串接起来计算分片级MD5。工具只需要把源库分片MD5和目标库分片MD5拿出来对比就能快速判断这个分片是否一致。这里有个很关键的细节拼接字段时必须把NULL值统一处理成固定标记比如空字符串。因为源库的空字符串和目标库的NULL在业务语义上可能等价但在数据库内部存储和输出上不一样。如果不统一处理会产生大量误报。我们统一约定NULL和空字符串都归一化成同一个标记。另一个细节是字段类型转换。数字类型建议明确转成字符串并固定格式防止小数位的展示差异影响MD5。时间类型建议统一转成带毫秒精度的字符串格式或者统一转成时间戳数字再拼接。这些细节不做VERI跑出来的差异报告会非常不可信。3.5 差异结果落库与报告输出分片MD5不一致时VERI不会立即断定数据有问题而是进入差异行定位阶段。它会把这个分片的源库数据行和目标库数据行都拉出来按主键做关联逐字段对比。差异结果落库到差异明细表结构大致这样CREATE TABLE veri_diff_detail ( check_time TIMESTAMP, table_name VARCHAR(200), pk_value VARCHAR(500), column_name VARCHAR(200), source_value VARCHAR(2000), target_value VARCHAR(2000), diff_type VARCHAR(50) );diff_type记录差异类型MISSING表示源库有目标库没有EXTRA表示目标库多出来的VALUE表示两行主键相同但字段值不同。报告输出模块读取差异明细表生成CSV和HTML报告。HTML报告包含总体摘要一共比了多少张表、多少张表一致、多少张表有差异、总差异行数差异明细按表分组展示。这样验收人员打开报告第一眼就能下结论不需要自己再写SQL查。4. 实操过程一次完整比对跑通4.1 构造业务场景为了说明完整流程这里用一个模拟场景。某业务系统要从存量数据库迁移到新的DMS数据库核心表包括用户表user_profile、订单表order_info、账户流水表account_flow。数据量分别为80万、300万、1200万。迁移工具跑完后我们用VERI做正式验收。配置好连接信息后执行VERI的第一步—预检查python veri.py --config config_cmp.yaml --check-meta这一步对比表结构。输出显示user_profile表有一个字段在目标库多了默认值account_flow表有一个索引遗漏了。这些结构差异先由DBA处理处理完后重新跑元数据对比直到通过。4.2 运行数据行数比对元数据通过后执行python veri.py --config config_cmp.yaml --check-count执行结果如下表名源库行数目标库行数结果user_profile800000800000通过order_info30000003000000通过account_flow1200000011999980有差异account_flow表目标库少了20行。这个差异很可能来自同步任务漏数。我们暂停对比让数据同步团队先补数补完再跑行数。行数比对全部通过后再做内容层比对。4.3 运行数据指纹比对执行python veri.py --config config_cmp.yaml --check-dataVERI对每张表分片并发计算MD5汇总后输出user_profile48个分片全部一致order_info120个分片116个一致4个不一致account_flow200个分片全部一致order_info的4个不一致分片进入差异定位。定位结果显示一共有37行数据和源库不一致差异字段集中在order_time。查看明细后发现源库的order_time是datetime类型带毫秒2025-06-01 12:30:45.123目标库建表时字段定义成了datetime不带毫秒数据写入时毫秒部分被截断。这是典型的字段精度不一致问题。4.4 差异修复与复跑定位到问题后我们跟开发确认业务上是否需要毫秒精度。订单系统的时间精度确实需要毫秒于是修改目标表字段类型把截断的数据重新从源库抽过来然后只针对order_info表重新执行比对python veri.py --config config_cmp.yaml --check-data --tables order_info这次全部120个分片一致。VERI支持指定表复跑不需要把三张表重新跑一遍节省了大量时间。全部通过后生成的HTML报告归档到验收文档中。4.5 执行性能复盘这次正式比对中account_flow表1200万行分片200个4并发执行总耗时约22分钟。性能瓶颈主要在源库端MD5计算目标库端反而是秒级返回。如果希望提速可以把并发数提升到6或者采用CRC32算法减少哈希计算开销但要注意CRC32碰撞概率更高适合巡检不适合最终验收。5. 常见问题与排查技巧实录5.1 驱动与连接问题最常遇到的是“连不上库”。先检查网络策略确认调度机到数据库服务端口连通再检查账号权限对比账号需要能够查询元数据表只给业务表SELECT权限会导致表清单发现失败最后检查驱动版本数据库产品大版本升级后老驱动往往表现出异常行为连接时好时坏甚至返回乱码。5.2 大表全量比对性能差大表比对的性能瓶颈通常不在工具本身而在SQL设计。分片键如果选择不当会出现数据倾斜。举个例子用状态字段做分片键如果状态只有3个值分片等于只有3个根本起不到并行效果。应该选择高选择性的主键或唯一键。没有主键的表处理比较麻烦。DMS数据库支持物理行号ROWID可以用它做分片。但注意ROWID在数据发生更新或表重组后可能变化所以只适合静态数据表的比对频繁更新的表不建议用。另外临时表空间也可能爆掉。分片内拼接全字段的SQL在字段特别多且包含大字段时会产生大量临时排序空间。解决办法是控制分片大小、排除大字段列先做粗比对发现差异再补查大字段。5.3 误报问题类型、精度与字符集误报是比对工具口碑崩塌的主要原因。最常见的是数字精度问题。源库某字段是NUMBER(18,6)目标库是DECIMAL(10,2)两边存的值其实来自同一业务但展示和存储精度不同MD5拼接结果就不同。这类问题不是数据错误而是模型不一致。处理方式有两种一是先做结构统一再比数据二是把精度差异配置到字段映射规则中允许目标库做格式化。字符集问题在迁移场景中同样高发。源库字符集是GBK目标库是UTF-8中文内容本身没变但字节序列变了拼接后哈希值必然不同。我们在每个库端计算MD5之前先统一对字符串内容做一次转换归一比如都转成UTF-8编码后再拼装这样能有效减少字符集层面的误报。NULL值和空字符串的差异前面已经说过这里是所有误报里占比最高的。实现层面务必在拼接字段前统一用COALESCE和默认值归一化。5.4 超大字段与二进制数据的处理文本大字段CLOB和二进制大字段BLOB直接参与字符串拼接会产生大量临时空间也影响MD5计算性能。我们的做法是第一轮指纹对比不带大字段只比对普通字段大字段单独抽出来做样本比对比如按主键随机抽1000行用哈希摘要比对完整内容。这样既保证了主要数据的可比对性又避免了大字段拖垮整个任务。5.5 工具自身健壮性数据对比工具经常要跑几个小时工具的健壮性不能忽视。VERI加了断点续跑机制每个分片完成状态记录到本地表任务中断后重启会跳过已完成分片只执行剩余分片。这个机制在一次凌晨跑批被运维重启机器后发挥了关键作用原本以为要从头再来结果几分钟就恢复执行了。还有一个经验对比过程中的日志一定要记录每个分片的开始时间和结束时间。出现性能问题时通过日志能快速定位是哪个分片慢、是不是所有慢分片都集中在某个键值范围从而反向判断数据分布是否存在问题。说到最后我自己的一个体会是数据对比工具的价值不在于堆功能而在于让结果可信。一个误报频频的工具用几次就没人信了一个能把差异分片收敛到具体主键、让业务人员一眼看懂报告的工具才能在日常运维里真正站住脚。VERI这版实践下来最大的收获不是那些代码而是我们总结出的分层比对思路和对各种“假差异”的甄别经验。这些经验比工具本身更值得沉淀后续如果要做定时巡检和告警联动也只是在这个底座上再加一层调度罢了。 
长河君 · 2026/10/11 3:00:48 · 阅读 1.2k 数据库迁移数据一致性校验：VERI轻量级对比工具实战
如果你们团队正在做数据库迁移或者同步链路的验收大概率会遇到一个看起来简单、实际很难回答的问题两边数据到底一不一样我们在一次国产数据库环境替换项目中就被这个问题卡了很久。手工导数据、逐表数行数短期还能应付数据量一上来就完全顶不住。于是内部搭了一套轻量级的数据对比工具VERI专门用于国产数据库本文以DMS系列数据库为例源端与目标端的一致性校验。这篇内容就完整记录这个工具从需求、设计、部署到实战排查的全过程给同样被数据比对折磨的同学一个参考。VERI能做的事包括表结构对比、行数对比、数据指纹对比、差异行定位最后自动输出一份差异报告整个过程基本不需要人工干预。1. 为什么需要数据对比工具迁移与同步场景下的硬需求1.1 迁移验收不能只数行数数据库迁移项目的验收环节最常听到的一句话就是“两边行数都对上了”。但行数对上不代表数据一致。同一张表源库和目标库各有100万行可能是同一批数据也可能是每边各自缺了不同的记录凑巧数量相同。更麻烦的是字段值不一致时间精度被截断、小数位被四舍五入、字符集转码导致中文乱码这些都不会影响总数却直接影响业务。行数比对只是第一层。真正可靠的验收要做内容级比对。VERI的设计目标就是把这层内容比对自动化源库一个查询、目标库一个查询两边对hash值不一致就落到差异表再让运维去处理。1.2 三类典型场景一次性迁移、双轨巡检、同步链路监控我们做VERI时明确了对三类场景的支持。第一类是一次性迁移验收。业务系统从一个数据库整体搬到另一个数据库迁移工具跑完后需要证明“搬干净了、没搬错”。这种情况下要求做全量比对所有用户表、索引、约束、数据都要过一遍。第二类是双轨运行期间的日常巡检。业务在切换过程中会有一段时间两边同时写入应用层通过中间件做双写。双写最容易出现单边成功、单边失败的问题所以需要每天定时跑一遍对比发现差异马上报警。第三类是同步链路监控。比如主库通过日志解析把数据同步到查询库或者通过数据集成工具做准实时同步同步链路偶尔会中断、会丢消息。VERI每周做一次抽样比对能及时发现同步链路的隐性故障。1.3 手工比对的痛点和工具解决思路在没有VERI之前我们尝试过几种手工方案都不理想。第一种是导出再对比。用数据库工具把表导出成文本文件再写脚本逐行比对。小表没问题大表导出耗时很长而且导出中途资源占用过高影响生产库性能。第二种是写一次性SQL。用两边的SQL把数据拼成字符串然后全表聚合取MD5人工对比结果。操作繁琐而且每张表都要手写SQL字段几十个的时候SQL写出来一大串维护成本非常高。第三种是只抽样。随机抽几千行比对效率高但漏检率高适合有把握的环境不适合迁移验收这种关键场景。VERI的思路是把这些手工步骤变成标准化流程自动读取表清单自动生成对比SQL自动并发执行自动汇总差异。人只需要看报告做决策。2. 搭建前的方案选型与整体设计2.1 分层对比策略设计VERI时我们没有一上来就做“最完整”的逐行全量比对而是采用了分层策略先粗后细逐层缩小范围。第一层是元数据比对。对比两边表名、字段名、字段类型、字段长度、是否非空、默认值。这一层解决的问题是“表结构是否对应”。结构不对后面数据对比没有意义。第二层是行数比对。对比每张表的记录数快速找出明显差异。如果一张表源库是100万行目标库是90万行那就不用继续往下比了先查同步链路。第三层是数据指纹比对。对整张表或分片数据计算聚合校验值比如CRC32、MD5两边对比校验值。一致则大概率数据一致不一致则说明存在差异进入下一层。第四层是差异行定位。对指纹不一致的分片拉取具体数据行进行逐行比对定位到主键级别的差异记录生成明细报告。这种分层设计的核心价值是省钱。全表逐行比对是O(N)成本指纹比对通常能把需要逐行检查的数据量缩小到全表的百分之几甚至千分之一尤其是数据基本一致的场景收益非常明显。2.2 VERI的工具架构与模块划分VERI整体分为六个模块。配置管理模块负责读取连接配置、比对规则、忽略清单。连接管理模块负责维护源库和目标库的连接池避免频繁建立连接。任务调度模块负责把表清单拆分成多个任务交给并发线程池执行。比对引擎是核心模块负责生成对比SQL、执行查询、计算校验值、判定结果。差异存储模块把有差异的分片和行主键写入本地差异库方便后续查询。报告输出模块最后生成CSV和HTML两种格式的报告。模块划分遵循了一个原则比对引擎不关心数据来自哪张表只关心“怎么比”任务调度不关心比什么只关心“怎么分配”。这样后续如果要新增对比规则只需要改比对引擎不会动其他模块。2.3 关键设计决策与取舍在工具选型上我们内部讨论过用现成的商业比对工具也考虑过基于ETL工具二次开发。最后都放弃了。商业工具功能强但是在这个环境里适配成本高而且我们需要把差异结果跟自己的工单系统打通商业工具的黑盒逻辑不太好扩展。ETL工具侧重重数据搬运对比能力相对弱我们只需要比对不需要搬数引入整套ETL太重了。最终选择了基于Python自研轻量工具。原因有几个一是Python在数据类工具生态成熟连接数据库的驱动齐全二是开发效率高核心逻辑几百行代码就能跑通三是部署简单一台Linux跳板机装好Python环境就能运行不需要额外安装中间件。开发语言选定之后最关键的架构决策是“计算下推”。把聚合校验值的计算放到数据库端执行而不是把数据拉到工具内存里算。比如分片内的数据在数据库端做字符串拼接、做哈希聚合工具只需要拿到一个哈希值。这样可以大幅降低网络传输量和内存占用。2.4 部署环境与依赖清单在实际部署时我们准备了一个最小的环境。调度机是一台普通的Linux虚拟机2核4GB内存Python 3.8安装了数据库驱动和OpenPyXL。源库和目标库是两套独立的DMS数据库实例应用账号只需要授予对比表的SELECT权限。网络层面要求调度机能同时访问两个库的数据库服务端口两边数据库不需要互相访问这个条件在大多数网络隔离场景下都能满足。驱动安装有一点要注意国内数据库产品对应的Python驱动有时分的版本比较多要确认驱动版本和数据库服务端版本兼容。我们在测试环境遇到过驱动版本过旧导致浮点数读取精度丢失的问题排查了很久才发现是驱动版本不匹配。3. 核心实现配置、分片与对比逻辑3.1 配置文件设计与关键参数VERI使用YAML格式的配置文件来管理所有参数。配置文件分为三块连接信息、比对规则、执行参数。连接信息块内容如下source: host: 192.168.10.11 port: 5236 username: cmp_user password: enc_placeholder database: app_src target: host: 192.168.10.22 port: 5236 username: cmp_user password: enc_placeholder database: app_dst这里要对密码做占位处理真实的密码通过环境变量或密钥文件注入避免明文放配置文件里。数据库对比工具通常需要较高的权限密钥管理一定不能省。执行参数块是调优重点execution: concurrency: 4 commit_batch: 500 query_timeout: 300 hash_algorithm: md5 sample_rate: 1.0concurrency表示并发线程数不是越大越好后面会专门说。hash_algorithm支持md5和crc32MD5碰撞概率极低推荐用于正式验收CRC32计算更快适合抽查场景。sample_rate是采样率默认1.0表示全量日常巡检可以设0.1只比对10%的数据分片提高效率。3.2 表清单发现与忽略规则对比前需要确定“比哪些表”。VERI支持两种模式手动指定表清单或者自动发现表清单。自动发现模式下工具查询数据库元数据表获取所有用户表然后应用忽略规则。忽略规则配置如下rules: ignore_tables: - TMP_* - *_BAK - SYS_LOG_* ignore_columns: - last_update_time忽略规则非常实用。比如日志类表数据量大、时效性强同步过程中可能一直在写入对比它们没有意义还耽误时间。临时表和备份表也应该跳过。ignore_columns用于忽略强波动字段比如最后更新时间这类字段在源库和目标库天然不一致放进对比里只会制造噪音。表清单发现后VERI还会做一次结构映射。因为源库和目标库的表名可能不同比如源库叫ORDER_INFO目标库叫ORDER工具通过配置里的表映射关系把它们对应起来。3.3 分片比对原理与并发控制全表一次性做哈希比对在数据量小的场景可行数据量一大就非常危险。一次扫描几千万行数据库端需要临时表空间拼接所有字段工具端长时间等待一个SQL返回任何一端出问题整个任务就卡死。VERI的分片思路是按主键或唯一键把表拆成N个范围每个范围作为一个独立比对单元。用户表通常有主键可以直接用主键分片。没有主键的表按行号ROWID切分。伪代码实现如下def build_slices(conn, table, slice_col, total_rows, slice_size): min_val conn.query(SELECT MIN(%s) FROM %s % (slice_col, table)) max_val conn.query(SELECT MAX(%s) FROM %s % (slice_col, table)) step (max_val - min_val) / slice_size slices [] for i in range(slice_size): low min_val i * step high min_val (i 1) * step slices.append((low, high)) return slices这个写法针对整型主键比较直观但要注意主键分布不均匀的问题。如果主键不是均匀自增按范围切分会产生大小差异很大的分片。更稳妥的做法是先查主键分布或者按主键值列表分批处理。我们后期改成了按主键排序后均匀抽样取边界值每个分片行数基本一致避免出现“一个分片占了全表90%数据”的情况。并发数设置我们踩过坑。一开始图快把并发数调到12结果源库和目标库的CPU直接飙到90%以上对比任务本身影响了生产业务。后来把并发数控制在4到6同时对数据库连接池做限流每个线程最多持有2个连接整体资源占用就会可控很多。3.4 聚合校验值哈希的实现分片确定后每个分片会在数据库端计算一个聚合校验值。核心SQL逻辑如下SELECT MD5(STRING_AGG(md5_part, )) FROM ( SELECT MD5( COALESCE(CAST(id AS VARCHAR(100)), ) || | || COALESCE(CAST(name AS VARCHAR(200)), ) || | || COALESCE(CAST(amount AS VARCHAR(50)), ) ) AS md5_part FROM order_info WHERE id BETWEEN :low AND :high ) t;这段SQL的思路是先把每一行数据的所有字段拼接成一个字符串计算行的MD5再把分片内所有行的MD5串接起来计算分片级MD5。工具只需要把源库分片MD5和目标库分片MD5拿出来对比就能快速判断这个分片是否一致。这里有个很关键的细节拼接字段时必须把NULL值统一处理成固定标记比如空字符串。因为源库的空字符串和目标库的NULL在业务语义上可能等价但在数据库内部存储和输出上不一样。如果不统一处理会产生大量误报。我们统一约定NULL和空字符串都归一化成同一个标记。另一个细节是字段类型转换。数字类型建议明确转成字符串并固定格式防止小数位的展示差异影响MD5。时间类型建议统一转成带毫秒精度的字符串格式或者统一转成时间戳数字再拼接。这些细节不做VERI跑出来的差异报告会非常不可信。3.5 差异结果落库与报告输出分片MD5不一致时VERI不会立即断定数据有问题而是进入差异行定位阶段。它会把这个分片的源库数据行和目标库数据行都拉出来按主键做关联逐字段对比。差异结果落库到差异明细表结构大致这样CREATE TABLE veri_diff_detail ( check_time TIMESTAMP, table_name VARCHAR(200), pk_value VARCHAR(500), column_name VARCHAR(200), source_value VARCHAR(2000), target_value VARCHAR(2000), diff_type VARCHAR(50) );diff_type记录差异类型MISSING表示源库有目标库没有EXTRA表示目标库多出来的VALUE表示两行主键相同但字段值不同。报告输出模块读取差异明细表生成CSV和HTML报告。HTML报告包含总体摘要一共比了多少张表、多少张表一致、多少张表有差异、总差异行数差异明细按表分组展示。这样验收人员打开报告第一眼就能下结论不需要自己再写SQL查。4. 实操过程一次完整比对跑通4.1 构造业务场景为了说明完整流程这里用一个模拟场景。某业务系统要从存量数据库迁移到新的DMS数据库核心表包括用户表user_profile、订单表order_info、账户流水表account_flow。数据量分别为80万、300万、1200万。迁移工具跑完后我们用VERI做正式验收。配置好连接信息后执行VERI的第一步—预检查python veri.py --config config_cmp.yaml --check-meta这一步对比表结构。输出显示user_profile表有一个字段在目标库多了默认值account_flow表有一个索引遗漏了。这些结构差异先由DBA处理处理完后重新跑元数据对比直到通过。4.2 运行数据行数比对元数据通过后执行python veri.py --config config_cmp.yaml --check-count执行结果如下表名源库行数目标库行数结果user_profile800000800000通过order_info30000003000000通过account_flow1200000011999980有差异account_flow表目标库少了20行。这个差异很可能来自同步任务漏数。我们暂停对比让数据同步团队先补数补完再跑行数。行数比对全部通过后再做内容层比对。4.3 运行数据指纹比对执行python veri.py --config config_cmp.yaml --check-dataVERI对每张表分片并发计算MD5汇总后输出user_profile48个分片全部一致order_info120个分片116个一致4个不一致account_flow200个分片全部一致order_info的4个不一致分片进入差异定位。定位结果显示一共有37行数据和源库不一致差异字段集中在order_time。查看明细后发现源库的order_time是datetime类型带毫秒2025-06-01 12:30:45.123目标库建表时字段定义成了datetime不带毫秒数据写入时毫秒部分被截断。这是典型的字段精度不一致问题。4.4 差异修复与复跑定位到问题后我们跟开发确认业务上是否需要毫秒精度。订单系统的时间精度确实需要毫秒于是修改目标表字段类型把截断的数据重新从源库抽过来然后只针对order_info表重新执行比对python veri.py --config config_cmp.yaml --check-data --tables order_info这次全部120个分片一致。VERI支持指定表复跑不需要把三张表重新跑一遍节省了大量时间。全部通过后生成的HTML报告归档到验收文档中。4.5 执行性能复盘这次正式比对中account_flow表1200万行分片200个4并发执行总耗时约22分钟。性能瓶颈主要在源库端MD5计算目标库端反而是秒级返回。如果希望提速可以把并发数提升到6或者采用CRC32算法减少哈希计算开销但要注意CRC32碰撞概率更高适合巡检不适合最终验收。5. 常见问题与排查技巧实录5.1 驱动与连接问题最常遇到的是“连不上库”。先检查网络策略确认调度机到数据库服务端口连通再检查账号权限对比账号需要能够查询元数据表只给业务表SELECT权限会导致表清单发现失败最后检查驱动版本数据库产品大版本升级后老驱动往往表现出异常行为连接时好时坏甚至返回乱码。5.2 大表全量比对性能差大表比对的性能瓶颈通常不在工具本身而在SQL设计。分片键如果选择不当会出现数据倾斜。举个例子用状态字段做分片键如果状态只有3个值分片等于只有3个根本起不到并行效果。应该选择高选择性的主键或唯一键。没有主键的表处理比较麻烦。DMS数据库支持物理行号ROWID可以用它做分片。但注意ROWID在数据发生更新或表重组后可能变化所以只适合静态数据表的比对频繁更新的表不建议用。另外临时表空间也可能爆掉。分片内拼接全字段的SQL在字段特别多且包含大字段时会产生大量临时排序空间。解决办法是控制分片大小、排除大字段列先做粗比对发现差异再补查大字段。5.3 误报问题类型、精度与字符集误报是比对工具口碑崩塌的主要原因。最常见的是数字精度问题。源库某字段是NUMBER(18,6)目标库是DECIMAL(10,2)两边存的值其实来自同一业务但展示和存储精度不同MD5拼接结果就不同。这类问题不是数据错误而是模型不一致。处理方式有两种一是先做结构统一再比数据二是把精度差异配置到字段映射规则中允许目标库做格式化。字符集问题在迁移场景中同样高发。源库字符集是GBK目标库是UTF-8中文内容本身没变但字节序列变了拼接后哈希值必然不同。我们在每个库端计算MD5之前先统一对字符串内容做一次转换归一比如都转成UTF-8编码后再拼装这样能有效减少字符集层面的误报。NULL值和空字符串的差异前面已经说过这里是所有误报里占比最高的。实现层面务必在拼接字段前统一用COALESCE和默认值归一化。5.4 超大字段与二进制数据的处理文本大字段CLOB和二进制大字段BLOB直接参与字符串拼接会产生大量临时空间也影响MD5计算性能。我们的做法是第一轮指纹对比不带大字段只比对普通字段大字段单独抽出来做样本比对比如按主键随机抽1000行用哈希摘要比对完整内容。这样既保证了主要数据的可比对性又避免了大字段拖垮整个任务。5.5 工具自身健壮性数据对比工具经常要跑几个小时工具的健壮性不能忽视。VERI加了断点续跑机制每个分片完成状态记录到本地表任务中断后重启会跳过已完成分片只执行剩余分片。这个机制在一次凌晨跑批被运维重启机器后发挥了关键作用原本以为要从头再来结果几分钟就恢复执行了。还有一个经验对比过程中的日志一定要记录每个分片的开始时间和结束时间。出现性能问题时通过日志能快速定位是哪个分片慢、是不是所有慢分片都集中在某个键值范围从而反向判断数据分布是否存在问题。说到最后我自己的一个体会是数据对比工具的价值不在于堆功能而在于让结果可信。一个误报频频的工具用几次就没人信了一个能把差异分片收敛到具体主键、让业务人员一眼看懂报告的工具才能在日常运维里真正站住脚。VERI这版实践下来最大的收获不是那些代码而是我们总结出的分层比对思路和对各种“假差异”的甄别经验。这些经验比工具本身更值得沉淀后续如果要做定时巡检和告警联动也只是在这个底座上再加一层调度罢了。