DataX在數(shù)據(jù)遷移中的應(yīng)用是怎樣的

本篇文章給大家分享的是有關(guān)DataX在數(shù)據(jù)遷移中的應(yīng)用是怎樣的，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

1. DataX定義

首先簡單介紹下datax是什么。
DataX是阿里巴巴集團(tuán)內(nèi)被廣泛使用的離線數(shù)據(jù)同步工具/平臺，實現(xiàn)包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各種異構(gòu)數(shù)據(jù)源之間高效的數(shù)據(jù)同步功能。

2. DataX 商業(yè)版本

阿里云DataWorks數(shù)據(jù)集成是DataX團(tuán)隊在阿里云上的商業(yè)化產(chǎn)品，致力于提供復(fù)雜網(wǎng)絡(luò)環(huán)境下、豐富的異構(gòu)數(shù)據(jù)源之間高速穩(wěn)定的數(shù)據(jù)移動能力，以及繁雜業(yè)務(wù)背景下的數(shù)據(jù)同步解決方案。目前已經(jīng)支持云上近3000家客戶，單日同步數(shù)據(jù)超過3萬億條。DataWorks數(shù)據(jù)集成目前支持離線50+種數(shù)據(jù)源，可以進(jìn)行整庫遷移、批量上云、增量同步、分庫分表等各類同步解決方案。2020年更新實時同步能力，支持10+種數(shù)據(jù)源的讀寫任意組合。提供MySQL，Oracle等多種數(shù)據(jù)源到阿里云MaxCompute，Hologres等大數(shù)據(jù)引擎的一鍵全增量同步解決方案。
關(guān)于datax的git地址，可參考文后資料了解詳情[1]。

2.1 應(yīng)用案例

接下來介紹下我們在兩個項目上的應(yīng)用案例。

2.1.1 案例一 通過datax協(xié)助分析數(shù)據(jù)同步鏈路

客戶某oracle數(shù)據(jù)庫在遷移上云過程中，使用了某封裝好的產(chǎn)品，但是傳輸效率一直很低，只有6M/s?？蛻粢恢睉岩墒窃苾?nèi)vpc網(wǎng)絡(luò)瓶頸或rds數(shù)據(jù)庫瓶頸導(dǎo)致，但是實際上，云內(nèi)網(wǎng)絡(luò)以及數(shù)據(jù)庫整體處于非常低的負(fù)載狀態(tài)。
由于客戶側(cè)的傳輸工具我們不方便直接拿來測試，所以在ecs上臨時部署了datax，來做分析和對照測試；
測試結(jié)果如下圖所示。

圖1：測試結(jié)果

常用的優(yōu)化參數(shù)介紹如下：
1.通道（channel）--并發(fā)

• 通過測試可知，channel的設(shè)置對傳輸效率的影響較為明顯，上述實驗中，所有設(shè)置為1的，即沒有并發(fā)的情況下，同步速度均為8.9M/s；將該設(shè)置調(diào)高之后，速率明顯倍增，但增大到一定程度后，瓶頸點就轉(zhuǎn)到其他配置了；

2.切片（splitpk）
Git官方介紹如下：

• 描述：MysqlReader進(jìn)行數(shù)據(jù)抽取時，如果指定splitPk，表示用戶希望使用splitPk代表的字段進(jìn)行數(shù)據(jù)分片，Datax因此會啟動并發(fā)任務(wù)進(jìn)行數(shù)據(jù)同步，這樣可以大大提高數(shù)據(jù)同步的效能。

• 推薦splitPk用戶使用表主鍵，因為表主鍵通常情況下比較均勻，因此切分出來的分片也不容易出現(xiàn)數(shù)據(jù)熱點。
  目前splitPk僅支持整形數(shù)據(jù)切分，不支持浮點、字符串、日期等其他類型。如果用戶指定其他非支持類型，MysqlReader將報錯。
  如果splitPk不填寫，包括不提供splitPk或者splitPk值為空，DataX視作使用單通道同步該表數(shù)據(jù)。

• 必選：否

• 默認(rèn)值：空

實際上，由測試結(jié)果可知，切片是要配合channel來使用的，如果只開了splitpk，但是channel的配置為1，同樣不會有并發(fā)的效果；
3.Batchsize
Git官方介紹如下：

• 描述：一次性批量提交的記錄數(shù)大小，該值可以極大減少DataX與Mysql的網(wǎng)絡(luò)交互次數(shù)，并提升整體吞吐量。但是該值設(shè)置過大可能會造成DataX運行進(jìn)程OOM情況。

• 必選：否

• 默認(rèn)值：1024

現(xiàn)場的實際測試效果不明顯，主要原因是數(shù)據(jù)量較小，1c1g配置時，適當(dāng)提高batch可以提升同步速度。
其他還有很多參數(shù)，有待小伙伴們?nèi)ブ鹨话l(fā)掘，或者下次我們用到再給大家分享；
由測試結(jié)果可知，項目使用的工具只能同步6m的速率，肯定是遠(yuǎn)遠(yuǎn)不足的，性能瓶頸既不在網(wǎng)絡(luò)上，也不在數(shù)據(jù)庫上，我們只做了部分測試，就發(fā)現(xiàn)4c16g的數(shù)據(jù)庫輕輕松松就能達(dá)到27M的同步速率。

2.1.2 案例二 datax在數(shù)據(jù)同步實戰(zhàn)中的應(yīng)用

該案例是客戶兩朵云之間的數(shù)據(jù)遷移，客戶新建了一朵云，需要把前一朵云上的數(shù)據(jù)遷移過去；
方案如下：

圖2：方案

2.2 部署方式

Datax本身無自動集群化部署，需要逐臺手工部署；
15臺v2的物理機(jī)，空余內(nèi)存均在150G左右。（因為V2集群即將下線，上述產(chǎn)品無業(yè)務(wù)，所以利用了閑置的物理機(jī)，在物理條件不具備時，可以采用ecs或其他虛擬機(jī)。)
機(jī)器要求：同步任務(wù)啟動會占用較多內(nèi)存，測試平均1個任務(wù)占用10G內(nèi)存（大表）；
單臺150G內(nèi)存可以支持15個并發(fā)任務(wù)；

2.3 同步方式

2.3.1 數(shù)據(jù)特點

分類項目數(shù)總數(shù)據(jù)量1T以上project7個97T1T以下project77個15T

• 歷史記錄表：歷史數(shù)據(jù)，項目數(shù)不多，但占用了80%以上的空間；

• 維表+臨時表：項目數(shù)多，表較小，占用空間占比小；

• 數(shù)據(jù)特點：客戶幾十個部門分析報表，小表分區(qū)比較多，大表相對少一些；

2.3.2 同步順序

先同步大表，然后再同步小表；
業(yè)務(wù)沒有同步順序要求，小表易變，大表穩(wěn)定，因此優(yōu)先同步大表；
大表同步需要的手動配置少，也適合前期做好調(diào)試；（正式啟動同步前的測試不要選太大的表，建議10G-50G，可以測出效率和壓力。）

• 優(yōu)點：機(jī)器多，并發(fā)高，可以快速壓到瓶頸，提升整體同步效率；

• 缺點：Datax為原生的遷移工具，不具備自動化能力，需要人工大量的配置同步任務(wù)；

注：建議預(yù)留幾臺機(jī)器專門用于多分區(qū)小表的同步，剩余其他機(jī)器同步大表。

2.4 總結(jié)

綜上所述，Datax的優(yōu)勢非常明顯：

• 首先，部署非常簡單，無論是在物理機(jī)上或者虛擬機(jī)上，只要網(wǎng)絡(luò)通暢，便可進(jìn)行數(shù)據(jù)同步，給實施人員帶來了極大的便利，不受標(biāo)準(zhǔn)數(shù)據(jù)同步產(chǎn)品部署的條框限制；

• 再者，它是開源產(chǎn)品，幾乎沒有成本；

但是，它的缺點也是顯而易見的：

• 開源工具更多的是提供基礎(chǔ)能力，并不具備任務(wù)管理，進(jìn)度跟蹤、校驗等等一系列的功能，只能使用者自己通過腳本或者表格記錄，目前暫無白屏；因此注定了它只能作為臨時性質(zhì)的數(shù)據(jù)同步工具去使用；

所以，業(yè)務(wù)上有一些規(guī)范化管理或者標(biāo)準(zhǔn)化運維的需求時，或者有頻繁的、持續(xù)的使用數(shù)據(jù)同步調(diào)度的需求時，安全生產(chǎn)是非常重要的，還是推薦大家使用阿里云官方的產(chǎn)品。

以上就是DataX在數(shù)據(jù)遷移中的應(yīng)用是怎樣的，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。