我們在遷移Oracle到PostgreSQL的過程中，遇到了一些不小的挑戰(zhàn)。使用Ora2PG工具遷移數(shù)據(jù)遇到的小問題比較多，同時在遷移LOB字段的時候，性能表現(xiàn)不夠理想，于是我們采用了DataX來做數(shù)據(jù)遷移。

先介紹一下DataX，DataX是阿里巴巴集團內(nèi)被廣泛使用的離線數(shù)據(jù)同步工具/平臺。特點是實現(xiàn)了眾多異構(gòu)數(shù)據(jù)源之間高效的數(shù)據(jù)同步功能。

我們當(dāng)前使用ogg軟件來實現(xiàn)異構(gòu)數(shù)據(jù)源同步的問題，從左圖可見其鏈路及其復(fù)雜，這給后續(xù)運維工作帶來了很多不可控因素，一旦數(shù)據(jù)庫多起來，對維護人員來說不僅僅是工作量的增加，錯綜復(fù)雜的邏輯關(guān)系都是潛在的天坑。

而DataX則采用了星型數(shù)據(jù)鏈路來實現(xiàn)，運維人員只要管理中間的DataX服務(wù)器即可完成。當(dāng)需要新增加一個數(shù)據(jù)源時，只需要接進來就可以完成數(shù)據(jù)同步工作。

當(dāng)然缺點也顯而易見，一旦宕機，將會影響其上所有同步的數(shù)據(jù)源。同時性能上也受制于DataX主機網(wǎng)卡的性能。一旦該網(wǎng)卡流量打滿，則會導(dǎo)致同步速度達到天花板。

DataX作為離線數(shù)據(jù)同步框架，采用Framework+ plugin架構(gòu)構(gòu)建。將數(shù)據(jù)源讀取和寫入抽象成為Reader/Writer插件，納入到整個同步框架中。

如圖所示：

Reader：Reader為數(shù)據(jù)采集模塊，負責(zé)采集數(shù)據(jù)源的數(shù)據(jù)，將數(shù)據(jù)發(fā)送給Framework。

Writer：Writer為數(shù)據(jù)寫入模塊，負責(zé)不斷向Framework取數(shù)據(jù)，并將數(shù)據(jù)寫入到目的端。

Framework：Framework用于連接reader和writer，作為兩者的數(shù)據(jù)傳輸通道，并處理緩沖，流控，并發(fā)，數(shù)據(jù)轉(zhuǎn)換等核心技術(shù)問題。

當(dāng)前DataX支持的Reader插件和Writer非常多，從官網(wǎng)上可以看到，主流的關(guān)系型數(shù)據(jù)庫都支持。

了解了基本概念和架構(gòu)之后，來看看如何使用。先看看我們的表。這是一張Oracle中的表，包含BLOB字段。表上沒有主鍵，也沒有索引。

表的大小接近75G。

我們先看下Ora2PG遷移這張表的速度

可以看到速度非常慢，只能達到700行/秒，這張表的數(shù)據(jù)量大概是6000多萬。而在遷移其他小表或者字段沒有LOB的表的時候，性能最高是可以達到20萬行/秒。

而且該Ora2PG配置參數(shù)也是經(jīng)過優(yōu)化，設(shè)置了以下參數(shù)：

-P| --parallel num: Number of parallel tables to extract at the sametime.

-j| --jobs num : Number of parallel process to send data to PostgreSQL.

-J| --copies num : Number of parallel connections to extract data fromOracle.

BLOB_LIMIT    5000

由此可見，使用Ora2PG遷移帶有LOB的大表，速度不理想。

測試DataX。DataX軟件安裝非常簡單，直接下載軟件包，解壓到指定的目錄，建議是速度快的硬盤上。

然后到datax/bin目錄下，先要配置一個json文件。

具體可以參考官方給出的示例：

Oracle讀取

https://github.com/alibaba/DataX/blob/master/oraclereader/doc/oraclereader.md

PostgreSQL寫入

https://github.com/alibaba/DataX/blob/master/postgresqlwriter/doc/postgresqlwriter.md

按照官方文檔配置的JSON文件如下：

配置好后，就可以使用python腳本調(diào)用起來了。

nohuppython datax.py a1.json > a1.log &

然后我們可以通過日志來觀察。執(zhí)行速度。還有是否出錯。

可以看到，我的Channel配置為32，且使用了"splitPk":"id"。它在后臺自動開了7個任務(wù)組。

JobContainer- Scheduler starts [7] taskGroups.

7個TaskGroup，每個下面又包含了23個task任務(wù)。

[taskGroup-0]INFO  TaskGroupContainer - taskGroupId=[0] start [5] channels for[23] tasks.

[taskGroup-2]INFO  TaskGroupContainer - taskGroupId=[2] start [5] channels for[23] tasks.

[taskGroup-1]INFO  TaskGroupContainer - taskGroupId=[1] start [5] channels for[23] tasks.

[taskGroup-3]INFO  TaskGroupContainer - taskGroupId=[3] start [5] channels for[23] tasks

[taskGroup-4]INFO  TaskGroupContainer - taskGroupId=[4] start [4] channels for[23] tasks

[taskGroup-5]INFO  TaskGroupContainer - taskGroupId=[5] start [4] channels for[23] tasks

[taskGroup-6]INFO  TaskGroupContainer - taskGroupId=[6] start [4] channels for[23] tasks

我們仔細觀察，可以發(fā)現(xiàn)每個TaskGroup開啟了channel數(shù)量不太一樣，有的開啟了5個，有的開啟了4個，但是他們的任務(wù)都是23個。所以總共是161個任務(wù)。

那么這161個任務(wù)他們是怎么樣取數(shù)的呢？通過日志我們可以發(fā)現(xiàn)，它在做任務(wù)之前，執(zhí)行了下面的SQL，對數(shù)據(jù)進行了分片。

SingleTableSplitUtil- split pk [sql=SELECT * FROM ( SELECT PAGE_ID FROMhb_e2e.E2E_BUSI_ACCEPT SAMPLE (0.1)  WHERE (PAGE_ID IS NOT NULL) ORDER BY DBMS_RANDOM.VALUE) WHERE ROWNUM <= 160 ORDER by PAGE_IDASC] is running

我們把這個SQL拿到Oracle中執(zhí)行，發(fā)現(xiàn)數(shù)據(jù)查出來是160個Page_ID的值。

再繼續(xù)看程序日志，你會發(fā)現(xiàn)每個任務(wù)對應(yīng)的SQL語句如下。

[taskGroup-1]INFO  TaskGroupContainer - taskGroup[1] taskId[155] attemptCount[1]is started

INFO CommonRdbmsReader$Task - Begin to read record by Sql: [selectarea_code,system_code,session_id,virtual_order_id,page_id,staff_id,cust_order_nbr,channel_nbr,cust_id,cust_cert_nbr,cust_cert_type,order_flow_code,oper_code,step_code,evt_time,server_time,event_type,id,name,json_data,create_datefrom hb_e2e.E2E_BUSI_ACCEPT  where (f3f9ec73-4e88-2f7d-ab51-cfde34852856 <= PAGE_ID AND PAGE_ID

每一片數(shù)據(jù)都是這個where條件。

f3f9ec73-4e88-2f7d-ab51-cfde34852856<= PAGE_ID AND PAGE_ID < f4c81a28-7088-91a2-fe91-305ec26d6624

至此數(shù)據(jù)被分成了160份，然后160個任務(wù)有條不紊的并行運行，所以速度自然會提上來。

我們可以看到每秒大概能每秒能復(fù)制35000行記錄。大概復(fù)制的速度是30.64多MB/S。

當(dāng)整個任務(wù)完成之后，會顯示速度，讀出的記錄數(shù)，失敗的記錄數(shù)。

最后不得不吐槽一句，雖然DataX工具好用，速度也很快，但是每一個表都需要配置一個json文件，配置工作比較繁瑣。所以需要自行開發(fā)腳本來批量生成json文件，目前我們在開發(fā)類似的腳本。