從 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