多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

遗留系统数据迁移实战(八):WalkBy 抄表业务迁移里的表关系和脏数据处理

遗留系统数据迁移实战(八):WalkBy 抄表业务迁移里的表关系和脏数据处理 WalkBy 迁移为什么复杂主档迁移通常比较直观一块表对应一个设备。WalkBy 抄表业务不一样。它至少涉及抄表计划抄表册抄表任务当前抄表记录历史抄表记录发布记录计划和册子的关系任务和册子的关系发布记录和历史记录的关系册子和区域的关系任何一张表没迁完整都可能导致新系统页面打不开、任务看不到、发布记录断链。典型表关系可以用下面这张关系图理解rm_plan - rm_rela_book_plan - rm_book - rm_rela_task_book - rm_task - rm_record rm_record_hi - rm_rela_pub_record - rm_pub_record rm_book - rm_rela_book_region其中rm_plan是抄表计划rm_book是抄表册rm_task是某次实际抄表任务rm_record是当前任务下的抄表记录rm_record_hi是历史抄表记录rm_pub_record是发布批次rm_rela_*是业务关系表迁移边界怎么定迁移时不能简单按dept_code把所有表都搬过来。更稳妥的边界是以客户表具范围为核心 只迁与这些表具抄表记录相关的任务、册子、计划和发布记录也就是说任务是否迁移不只看任务表本身还要看它下面有没有目标表具的rm_record。为什么只迁有 record 的 task正常业务逻辑下生成抄表任务时会生成对应的抄表记录。如果一个任务没有任何相关rm_record通常说明历史残留被中途删除过生成失败数据被人工改过与当前迁移范围无关这类任务迁过去反而可能造成新系统里出现没有意义的空任务。所以更合理的策略是只迁移存在目标表具抄表记录的任务为什么源库任务数可能比目标库多迁移验证时常见现象是源库按简单 SQL 查出 21 个任务 目标库迁移后只有 16 个任务这时不能马上判断漏迁。要进一步按业务唯一维度分析例如计划 执行人 抄表方式 任务日期如果同一天、同计划、同执行人出现多个任务而业务上只应该有一个就可能是历史重复任务。目标库按唯一键幂等合并后数量少一些是合理的。如何向业务解释可以这样解释迁移不是机械搬所有历史脏数据而是按照正常业务可使用的数据结构迁移。 正常生成任务会生成对应抄表记录。 没有记录的任务、重复任务、跨范围关系属于历史脏数据或无效数据。 目标系统保留可使用的任务和记录避免把脏关系带入新系统。如何证明重复任务可以用类似 SQL 找出重复任务selectt.rm_plan_id,t.oper_id,t.rm_type_code,t.task_begin_date,count(distinctt.task_id)astask_count,group_concat(distinctt.task_idorderbyt.task_id)astask_ids,count(r.rm_record_id)asrecord_countfromrm_task tjoinrm_record ronr.task_idt.task_idjoinas_meter monm.meter_coder.meter_codewherem.dept_code目标部门编码andm.rm_type_codein(01,03)andr.rm_type_codein(01,03)groupbyt.rm_plan_id,t.oper_id,t.rm_type_code,t.task_begin_datehavingcount(distinctt.task_id)1orderbyt.task_begin_date;这个 SQL 的目的不是迁移而是给业务解释同一业务维度下确实存在多个历史任务。发布记录为什么也会不一致发布记录也可能存在类似情况。源库的发布记录可能按操作批次存了多条但真正和目标表具历史抄表记录有关的只有一部分。迁移时应该以rm_record_hi和rm_rela_pub_record的关系为准只迁能关联到目标历史记录的发布记录。总结WalkBy 迁移最重要的不是“把所有表 count 对齐”而是保证业务链路可用计划能看到 册子能看到 任务能看到 记录能打开 历史能追溯 发布记录不断链 区域能补偿历史脏数据不应该原样带入新系统。迁移的目标是保留可解释、可使用、可验收的数据结构。
返回列表