背景

公司开发数据开发平台，进行数据迁移处理。涉及到两套系统的数据迁移，一套：古老的调度系统，主要使用人群：数据开发和数据分析人员；另一套，新开发的元数据管理平台，实现元数据的开发管理。目前，也是负责这一系统的开发维护。在实现数据迁移中，踩了不少坑。也是心中的痛。

实施

目的

实现任务信息的迁移

平台设计分析

老的调度系统（以下称为系统s），设计表结构和新的元数据平台（以下称系统w）存在较大差异。这也给数据迁移带来了不少麻烦。

典型表对比分析

系统s
任务表Task以及从属的配置表，分开设计。
系统w
任务和配置信息完全由task一张表承担。其中有一个字段task_def，以json记录相关配置关系。设计初衷是实现任务版本对比时的便利。直接进行单表操作获取即可，减少了多表操作。

方案

sql语句迁移数据主体数据

结构复杂，相关的信息需要建立零时表处理。

考虑到以上因素，决定配合程序实现相关处理。

遇到的坑

迁移数据不全

迁移过程中，出现迁移数据不全的问题。这个问题也是早有预料。但是问题是什么？

由于线上环境日志记录不完善，迁出线上数据进行模式也未曾发现问题。最后，根本原因是某些字段的类型太短。这个早模拟时也出现过，针对系统s，系统w也做不少的modify操作。而就是那个task_def字段没有想到。系统w中task_def数据库定义为text(65535(2^16-1)个字符)，本以为这个长度已经够了，没想到还是超，超，超…

引申

TINYBLOB TINYTEXT

一个BLOB或TEXT列，最大长度为255(2^8-1)个字符。

BLOB TEXT

一个BLOB或TEXT列，最大长度为65535(2^16-1)个字符。

MEDIUMBLOB MEDIUMTEXT

一个BLOB或TEXT列，最大长度为16777215(2^24-1)个字符。

LONGBLOB LONGTEXT

一个BLOB或TEXT列，最大长度为4294967295(2^32-1)个字符。

ENUM(‘value1’,’value2’,…)
枚举。一个仅有一个值的字符串对象，这个值式选自与值列表’value1’、’value2’, …,或NULL。一个ENUM最多能有65535不同的值。

SET(‘value1’,’value2’,…)
一个集合。能有零个或多个值的一个字符串对象，其中每一个必须从值列表’value1’, ‘value2’, …选出。一个SET最多能有64个。

业务扩展不便

由于业务变更，导致迁移来的数据部分表结果不满足业务流程。那么只好扩展表结构。

做法

对相关表，增加外键关联（关联其他业务表）。不推荐
使用关联依赖表，进行过渡。推荐
数据唯一性全部以id自增的Integer值。弊端：分步实现，多应用下，导致数据唯一性不足，建议：使用uuid标识唯一性

坑

不久后，部门架构调整。导致，前期迁移过来的数据还得还原回去（也是醉了）。s系统要承接多个平台的调度处理。实现任务同意管理的中枢。那么，问题来了。之前设计的w系统为了业务扩展，进行了表结构的调整。如果系统数据再迁移回去。s承接另外的系统，业务不同于w。致使部分表数据出现冗余字段（出现了特征化数据）。

总结

平台迁移不够平滑

目前数据不支持两个平台的互通，导致数据迁移过来，来系统s就无法同步数据，系统不能使用。这是在这个迁移中不足的地方。切换系统期间不够平滑，导致无论是数据开发人员还是系统本身都是一个考验。

系统设计不完善

系统w设计初期没有做好评估，没有考虑对系统s的兼容。导致数据迁移时十分蛋痛。各种数据格式不一致，各种转换。

缺少对数据迁移的测试资源

缺少系统的数据迁移测试环境，整个过程完全是由研发自导自演 缺少测试的接入。同事，缺少线上真实环境的模拟，导致真正迁移线上数据时，出现很多类型不一匹配的问题。