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的優勢非常明顯：
- 首先，部署非常簡單，無論是在物理機上或者虛擬機上，只要網絡通暢，便可進行數據同步，給實施人員帶來了極大的便利，不受標準數據同步產品部署的條框限制；
- 再者，它是開源產品，幾乎沒有成本；
但是，它的缺點也是顯而易見的：
- 開源工具更多的是提供基礎能力，并不具備任務管理，進度跟蹤、校驗等等一系列的功能，只能使用者自己通過腳本或者表格記錄，目前暫無白屏；因此注定了它只能作為臨時性質的數據同步工具去使用；
所以，業務上有一些規范化管理或者標準化運維的需求時，或者有頻繁的、持續的使用數據同步調度的需求時，安全生產是非常重要的，還是推薦大家使用阿里云官方的產品。
3. 寫在最后
本期給大家介紹了Datax的相關概念，分享了兩個案例供大家參考，但是在實際的數據同步過程中仍有非常多的困難和問題，需要對整個數據傳輸的鏈路做分析和優化，操作較為繁雜。后續會給大家介紹案例二中的性能瓶頸分析和優化。
所以，下一期見咯。
參考文檔
[1] Datax的git地址：https://github.com/alibaba/DataX/
我們是阿里云智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用云、基于云構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上云、用好云，讓客戶云上業務運行更加穩定可靠的技術。
原文鏈接：https://developer.aliyun.com/article/781761?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的DataX在数据迁移中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 压测场景下的 TIME_WAIT 处理
- 下一篇： Arthas 使用的四种方式