簡介： DataX在數據遷移中的應用
1. DataX定義
首先簡單介紹下datax是什麼。
DataX是阿里巴巴集團內被廣泛使用的離線數據同步工具/平臺，實現包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各種異構數據源之間高效的數據同步功能。
2. DataX 商業版本
阿里雲DataWorks數據集成是DataX團隊在阿里雲上的商業化產品，致力於提供複雜網絡環境下、豐富的異構數據源之間高速穩定的數據移動能力，以及繁雜業務背景下的數據同步解決方案。目前已經支持雲上近3000家客戶，單日同步數據超過3萬億條。DataWorks數據集成目前支持離線50+種數據源，可以進行整庫遷移、批量上雲、增量同步、分庫分表等各類同步解決方案。2020年更新實時同步能力，支持10+種數據源的讀寫任意組合。提供MySQL，Oracle等多種數據源到阿里雲MaxCompute，Hologres等大數據引擎的一鍵全增量同步解決方案。
關於datax的git地址，可參考文後資料瞭解詳情[1]。
2.1 應用案例
接下來介紹下我們在兩個項目上的應用案例。
2.1.1 案例一 通過datax協助分析數據同步鏈路
客戶某oracle數據庫在遷移上雲過程中，使用了某封裝好的產品，但是傳輸效率一直很低，只有6M/s。客戶一直懷疑是雲內vpc網絡瓶頸或rds數據庫瓶頸導致，但是實際上，雲內網絡以及數據庫整體處於非常低的負載狀態。
由於客戶側的傳輸工具我們不方便直接拿來測試，所以在ecs上臨時部署了datax，來做分析和對照測試；
測試結果如下圖所示。
圖1：測試結果
常用的優化參數介紹如下：
1.通道（channel）--併發
- 通過測試可知，channel的設置對傳輸效率的影響較爲明顯，上述實驗中，所有設置爲1的，即沒有併發的情況下，同步速度均爲8.9M/s；將該設置調高之後，速率明顯倍增，但增大到一定程度後，瓶頸點就轉到其他配置了；
2.切片（splitpk）
Git官方介紹如下：
- 描述：MysqlReader進行數據抽取時，如果指定splitPk，表示用戶希望使用splitPk代表的字段進行數據分片，Datax因此會啓動併發任務進行數據同步，這樣可以大大提高數據同步的效能。
推薦splitPk用戶使用表主鍵，因爲表主鍵通常情況下比較均勻，因此切分出來的分片也不容易出現數據熱點。
目前splitPk僅支持整形數據切分，不支持浮點、字符串、日期等其他類型。如果用戶指定其他非支持類型，MysqlReader將報錯。
如果splitPk不填寫，包括不提供splitPk或者splitPk值爲空，DataX視作使用單通道同步該表數據。 - 必選：否
- 默認值：空
實際上，由測試結果可知，切片是要配合channel來使用的，如果只開了splitpk，但是channel的配置爲1，同樣不會有併發的效果；
3.Batchsize
Git官方介紹如下：
- 描述：一次性批量提交的記錄數大小，該值可以極大減少DataX與Mysql的網絡交互次數，並提升整體吞吐量。但是該值設置過大可能會造成DataX運行進程OOM情況。
- 必選：否
- 默認值：1024
現場的實際測試效果不明顯，主要原因是數據量較小，1c1g配置時，適當提高batch可以提升同步速度。
其他還有很多參數，有待小夥伴們去逐一發掘，或者下次我們用到再給大家分享；
由測試結果可知，項目使用的工具只能同步6m的速率，肯定是遠遠不足的，性能瓶頸既不在網絡上，也不在數據庫上，我們只做了部分測試，就發現4c16g的數據庫輕輕鬆鬆就能達到27M的同步速率。
2.1.2 案例二 datax在數據同步實戰中的應用
該案例是客戶兩朵雲之間的數據遷移，客戶新建了一朵雲，需要把前一朵雲上的數據遷移過去；
方案如下：
圖2：方案
2.2 部署方式
Datax本身無自動集羣化部署，需要逐臺手工部署；
15臺v2的物理機，空餘內存均在150G左右。（因爲V2集羣即將下線，上述產品無業務，所以利用了閒置的物理機，在物理條件不具備時，可以採用ecs或其他虛擬機。)
機器要求：同步任務啓動會佔用較多內存，測試平均1個任務佔用10G內存（大表）；
單臺150G內存可以支持15個併發任務；
2.3 同步方式
2.3.1 數據特點
| 分類 | 項目數 | 總數據量 |
|---|---|---|
| 1T以上project | 7個 | 97T |
| 1T以下project | 77個 | 15T |
- 歷史記錄表：歷史數據，項目數不多，但佔用了80%以上的空間；
- 維表+臨時表：項目數多，表較小，佔用空間佔比小；
- 數據特點：客戶幾十個部門分析報表，小表分區比較多，大表相對少一些；
2.3.2 同步順序
先同步大表，然後再同步小表；
業務沒有同步順序要求，小表易變，大表穩定，因此優先同步大表；
大表同步需要的手動配置少，也適合前期做好調試；（正式啓動同步前的測試不要選太大的表，建議10G-50G，可以測出效率和壓力。）
- 優點：機器多，併發高，可以快速壓到瓶頸，提升整體同步效率；
- 缺點：Datax爲原生的遷移工具，不具備自動化能力，需要人工大量的配置同步任務；
注：建議預留幾臺機器專門用於多分區小表的同步，剩餘其他機器同步大表。
2.4 總結
綜上所述，Datax的優勢非常明顯：
- 首先，部署非常簡單，無論是在物理機上或者虛擬機上，只要網絡通暢，便可進行數據同步，給實施人員帶來了極大的便利，不受標準數據同步產品部署的條框限制；
- 再者，它是開源產品，幾乎沒有成本；
但是，它的缺點也是顯而易見的：
- 開源工具更多的是提供基礎能力，並不具備任務管理，進度跟蹤、校驗等等一系列的功能，只能使用者自己通過腳本或者表格記錄，目前暫無白屏；因此註定了它只能作爲臨時性質的數據同步工具去使用；
所以，業務上有一些規範化管理或者標準化運維的需求時，或者有頻繁的、持續的使用數據同步調度的需求時，安全生產是非常重要的，還是推薦大家使用阿里雲官方的產品。z
3. 寫在最後
本期給大家介紹了Datax的相關概念，分享了兩個案例供大家參考，但是在實際的數據同步過程中仍有非常多的困難和問題，需要對整個數據傳輸的鏈路做分析和優化，操作較爲繁雜。後續會給大家介紹案例二中的性能瓶頸分析和優化。
作者：陳樹昌
本文爲阿里雲原創內容，未經允許不得轉載