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

先介紹一下DataX，DataX是阿里巴巴集團內被廣泛使用的離線數據同步工具/平臺。特點是實現了眾多異構數據源之間高效的數據同步功能。

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

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

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

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

如圖所示：

Reader：Reader為數據采集模塊，負責采集數據源的數據，將數據發送給Framework。

Writer：Writer為數據寫入模塊，負責不斷向Framework取數據，并將數據寫入到目的端。

Framework：Framework用于連接reader和writer，作為兩者的數據傳輸通道，并處理緩沖，流控，并發，數據轉換等核心技術問題。

當前DataX支持的Reader插件和Writer非常多，從官網上可以看到，主流的關系型數據庫都支持。

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

表的大小接近75G。

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

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

而且該Ora2PG配置參數也是經過優化，設置了以下參數：

-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腳本調用起來了。

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

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

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

JobContainer- Scheduler starts [7] taskGroups.

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

[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

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

那么這161個任務他們是怎么樣取數的呢？通過日志我們可以發現，它在做任務之前，執行了下面的SQL，對數據進行了分片。

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中執行，發現數據查出來是160個Page_ID的值。

再繼續看程序日志，你會發現每個任務對應的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

每一片數據都是這個where條件。

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

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

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

當整個任務完成之后，會顯示速度，讀出的記錄數，失敗的記錄數。

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