从 SQL Server 到 MySQL （三）：愚公移山 - 开源力量

咱们用了两章文章 从 SQL Server 到 MySQL（一）：异构数据库迁移 / 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 介绍咱们遇到问题和解决方案。 不论是离线全量迁移仍是在线无缝迁移， 核心 ETL 工具就是 yugong。

Yugong 是一个成熟工具， 在阿里巴巴去 IOE 行动中起了重要做用， 它与 Otter / Canal 都是阿里中间件团队出品。 它们三者各有分工： Yugong 设计目标是异构数据库迁移； Canal 设计用来解决 MySQL binlog 订阅和消费问题； Otter 则是在 Canal 之上，以准实时标准解决数据库同步问题。 Otter 配备了相对 yugong 更健壮管理工具、分布式协调工具， 从而长期稳定运行。Yugong 设计目标则是一次性迁移工做，偏 Job 类型。 固然 yugong 自己质量不错，长期运行也没问题。 咱们有个产线小伙伴使用咱们魔改后 yugong， 用来将数据从管理平台同步数据到用户前台，已经稳定跑了半年多了。

yugong 系统结构

这里我不赘述如何使用 yugong，有需求同窗直接去 官方文档 查看使用文档。

我直接进入关键环节：解剖 yugong 核心模块。 Yugong 数据流是标准 ETL 流程，分别有 Extractor / Translator / Applier 这三个大类来实现 ETL 过程:

咱们依次来看看这三大类具体设计。

Extractor

• YuGongLifeCycle：Yugong 组件生命周期声明
• AbstractYuGongLifeCycle：Yugong 组件生命周期一些实现
• RecordExtractor：基础 Extractor Interface
• AbstractRecordExtractor：基础 Extractor 虚拟类，作了一部分实现
• AbstractOracleRecordExtractor：Oracle Extractor 虚拟类，作了一部分 Oracle 相关实现
• OracleOnceFullRecordExtractor：Oracle 基于特定 SQL 一次性 Extractor
• OracleFullRecordExtractor：Oracle 全量 Extractor
• OracleRecRecordExtractor：Oracle 记录 Extractor，用来建立物化视图
• OracleMaterializedIncRecordExtractor：基于（已有）物化视图 Oracle 增量 Extrator
• OracleAllRecordExtractor：Oracle 自动化 Extractor，先 Mark 再 Full，再 Inc

Exctractor 从 Source DB 读取数据写入内存， Yugong 官方提供 Extractor 抽象出 AbstractRecordExtractor 类， 其他类都是围绕 Oracle 实现。 另外 Yugong 设计了 YuGongLifeCycle 类实现了组件生命周期管理。

Translator

• DataTranslator：Translator 基类，为 Row 级别数据处理
• TableTranslator：Translator 基类，为 Table 级别提供处理（官方代码中没有使用）
• AbstractDataTranslator：Data Translator 虚拟类，作了部分实现
• EncodeDataTranslator：转换编码格式 Translator
• OracleIncreamentDataTranslator：为 Oracle 增量数据准备 Translator，会调整一些数据状态
• BackTableDataTranslator：Demo，容许在 Translator 中作回写数据操做
• BillOutDataTranslator：Demo，包含一些阿里业务逻辑 Translator
• MidBillOutDetailDataTranslator：Demo，包含一些阿里业务逻辑 Translator

Translator 读取内存中 RowData 而后变换， 大部分 Translator 作一些无状态操做，好比编码转换。 另外还有一小部分 Translator 作了业务逻辑操做，好比作一些数据回写。

Applier

• RecordApplier：基础 Applier Interface
• AbstractRecordApplier：基础 Applier 虚拟类，作了一部分实现
• CheckRecordRecordApplier：检查数据一致性 Applier，不作数据写入
• FullRecordRecordApplier：全量数据 Applier，使用 UPSERT 作数据更新
• IncreamentRecordApplier：增量 Applier，使用 Oracle 物化视图为数据源
• AllRecordRecordApplier：自动化 Applier，先使用全量数据 Applier，而后使用增量数据 Applier

Applier 将通过 Translator 处理过的数据写入 Target DB。 Yugong 提供了一致性检查、全量、增量 Applier。 比较特殊是 AllRecordRecordApplier 提供了全套自动化操做。

Others

除了 ETL 三个要素，yugong 还有一些重要类：控制类和工具类。

• SqlTemplate：提供 CRUD / UPSERT 等操做的基类 SQL 模板
• OracleSqlTemplate：基于 SqlTemplate 实现的 Oracle SQL 模板
• RecordDiffer：一致性检查 differ
• YugongController：应用控制器，控制整个应用数据流向
• YugongInstance：控制单个迁移任务实例，一张表对应一个 YugongInstance

老战士的问题

说 yugong 有问题会有些标题党，毕竟它是久经考验老战士了。 但对咱们来讲，开源版本 yugong 还有一些不足：

• 不支持 SQL Server 读取
• 不支持 SQL Server 写入（Rollback 须要写入 SQL Server）
• 不支持 MySQL 读取

除了数据库支持，Yugong 在工程上面却是也有一些改善空间。 咱们最后花费了很多时间，作了工程上改进。

• 抛弃默认打包方式（基于 maven-assembly-plugin 生成相似 LFS 结构 tar.gz 文件）， 改成使用 fat jar 模式打包，仅生成单文件可执行 jar 包
• 抛弃 ini 配置文件，使用 YAML 配置文件格式（已有老配置仍然使用 ini 文件，YAML 主要管理表结构变动）
• 改造 Plugin 模式，将 Java 运行时编译改成反射获取 Java 类
• 拆分 Unit Test / Integration Test，下降重构成本
• 重构 Oracle 继承结构，使其开放 SQL Server / MySQL 接口
• 支持 Canal Redis 格式数据做为 MySQL 在线增量数据源

改造以后结构

Extractor

• AbstractSqlServerExtractor：新增抽象 SqlServer Extractor
• AbstractMysqlExtractor：新增抽象 MySQL Extractor
• AbstractFullRecordExtractor：新增抽象 Full 模式 Extractor
• SqlServerCdcExtractor：新增 SQL Server CDC 增量模式 Extractor
• MysqlCanalExtractor：新增 MySQL Canal 格式增量消费 Extractor
• MysqlCanalRedisExtractor：新增 MySQL Canal 格式增量消费 Extractor，使用 Redis 作回溯
• MysqlFullExtractor：新增 MySQL 全量 Extractor
• SqlServerFullExtractor：新增 SQL Server 全量 Extractor

在抽象出三个抽象类以后，总体逻辑更为清晰，若是将来要增长新数据库格式支持，也更为简单。

Translator

• Sha1ShardingTranslator：根据 Sha1 Sharding Translator
• ModShardingTranslator：根据 Value Mode Sharding Translator
• RangeShardingTranslator：根据范围 Sharding Translator
• UserRouterMapShardingTranslator：特定业务使用， 用户分表 Sharding Translator
• UserRouterMapMobileShardingTranslator：特定业务使用， 用户分表 Sharding Translator
• ClassLearningNoteInfoShardingTranslator：特定业务使用自定义 Translator
• ClassLearningIsActiveReverseShardingTranslator：特定业务使用自定义 Translator
• ColumnFixDataTranslator：调整表结构 Translator
• NameStyleDataTranslator：调整表字段名 Translator，支持按风格对整个表自动转换
• CompositeIndexesDataTranslator：解决复合主键下惟一 PK 肯定问题的 Translator

新增了一系列 Translator。

Applier

• SqlServerIncreamentRecordApplier：新增 SQL Server 增量消费 Applier

Applier 结构调整挺小，主要是增长了 SQL Server 的支持。

二次开发心得

如何快速了解一个开源项目？不少同窗第一反应就是阅读源码。 看源码当然是有效果，可是性价比过低。 若是项目设计不合理，很快会迷失在代码细节之中。 个人经验是先阅读官方出品的一些 Slide 分享，而后阅读官方核心文档。 Slide 含金量高，在讲述核心中核心。

若是真要去了解细节去阅读源码，那我建议要善用工具， 好比使用 IntelliJ 的 Diagram 功能，抽象出核心类。 还有一些插件好比 SequencePluginReload 方便地生成函数之间调用，实为查看数据流利器。 我在此次开发过程当中，也根据生成类图发现了一些问题， 从而在进入 Coding 以前，先对框架继承结构重构。提升了总体开发效率

根据代码风格判断，Yugong 并不是是出自一我的之手。这多少会致使代码风格和设计上面不一致。 我本身也常年在业务线里面摸爬滚打，能想象到在快速推动项目中须要糙快猛。 但后人接受开发，多少会有些头疼。 因而我在进入开发以前，引入标准化 CheckStyle，用 Google Style 全局格式化， 使用 Sonar 扫描保证一个代码质量基线。 同时这也是一把双刃剑，格式化项目会致使大量 diff， 这也给我本身埋下了一个苦果，在后期给上游提交 PR 引入无尽问题。

开发过程当中我也犯了一些错误。最为头疼是没有在早期考虑到向开源社区贡献， 致使将来向上游合并困难重重，如今还在头疼合并代码中。 另外，因为总体项目时间紧，我贪图实现速度，没有作更详尽单元测试覆盖。 这里没有遵循开源软件的最佳实践。

通过我改造的 Yugong 版本开源地址是：https://github.com/alswl/yugong 。 我也提交了 Pull Request https://github.com/alibaba/yugong/pull/66 ， 正在与官方沟通如何将这部分提交并入上游。

---

原文连接: 从 SQL Server 到 MySQL （三）：愚公移山 - 开源力量 - Log4D

欢迎关注个人微信公众号：窥豹

3a1ff193cee606bd1e2ea554a16353ee