DataX系列10-DataX優化

一. DataX優化概述

當覺得DataX傳輸速度慢時，需要從上述四個方面着手開始排查。

1. 網絡本身的帶寬等硬件因素造成的影響；
2. DataX本身的參數；
3. 從源端到任務機；
4. 從任務機到目的端；

1.1 網絡帶寬等硬件因素困擾

  此部分主要需要了解網絡本身的情況，即從源端到目的端的帶寬是多少（實際帶寬計算公式），平時使用量和繁忙程度的情況，從而分析是否是本部分造成的速度緩慢。

以下提供幾個思路。

1. 可使用從源端到目的端scp，python http,nethogs等觀察實際網絡及網卡速度；
2. 結合監控觀察任務運行時間段時，網絡整體的繁忙情況，來判斷是否應將任務避開網絡高峯運行；
3. 觀察任務機的負載情況，尤其是網絡和磁盤IO，觀察其是否成爲瓶頸，影響了速度；

1.2 DataX本身的參數調優

1.2.1 全局

datax 安裝目錄的conf 目錄下的 core.json 文件。

{
   "core":{
        "transport":{
            "channel":{
                "speed":{
                    "channel": 2, ## 此處爲數據導入的併發度，建議根據服務器硬件進行調優
                    "record":-1, ##此處解除對讀取行數的限制
                    "byte":-1, ##此處解除對字節的限制
                    "batchSize":2048 ##每次讀取batch的大小
                }
            }
        }
    },
    "job":{
            ...
        }
    }

1.2.2 局部

實際運行每個人物的json配置文件

"setting": {
            "speed": {
                "channel": 2,
                "record":-1,
                "byte":-1,
                "batchSize":2048
            }
        }
    }
}

channel增大，爲防止OOM，需要修改datax工具的datax.py文件。
如下所示，可根據任務機的實際配置，提升-Xms與-Xmx，來防止OOM。
tunnel並不是越大越好，過分大反而會影響宿主機的性能。
DEFAULT_JVM = "-Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=%s/log" % (DATAX_HOME)

1.2.3 Jvm 調優

python datax.py  --jvm="-Xms3G -Xmx3G" ../job/test.json

-Xms3G 表示JVM的初始值爲3G
-Xmx3G 表示JVM可使用的最大值爲3G

這樣做的好處是給定一個大的內存，讓同步數據處理起來更快。
也可以避免內存的抖動。

二.DataX優化案例

2.1 mysql表切分

如果源端是mysql的話，可以使用mysql的切分，並行處理。

{
                "reader": {
                    "name": "mysqlreader",
                    "parameter": {
                        "username": "root",
                        "password": "abc123",
                        "column": [
                            "id",
                            "sale_date",
                            "prod_name",
                            "sale_nums"
                        ],
                        "splitPk": "id",
                        "connection": [
                            {
                                "table": [
                                    "fact_sale"
                                ],
                                "jdbcUrl": [
     "jdbc:mysql://10.31.1.122:3306/test"
                                ]
                            }
                        ]
                    }
                },

可以看到日誌裏面根據spilit進行切分了

[15:14:00] 2021-11-24 15:14:08.179 [job-0] INFO  JobContainer - jobContainer starts to do split ...
[15:14:00] 2021-11-24 15:14:08.179 [job-0] INFO  JobContainer - Job set Channel-Number to 2 channels.
[15:14:00] 2021-11-24 15:14:08.194 [job-0] INFO  SingleTableSplitUtil - split pk [sql=SELECT MIN(id),MAX(id) FROM fact_sale] is running... 
[15:14:00] 2021-11-24 15:14:08.219 [job-0] INFO  SingleTableSplitUtil - After split(), allQuerySql=[
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (1 <= id AND id < 78762161) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (78762161 <= id AND id < 157524321) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (157524321 <= id AND id < 236286481) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (236286481 <= id AND id < 315048641) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (315048641 <= id AND id < 393810801) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (393810801 <= id AND id < 472572961) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (472572961 <= id AND id < 551335120) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (551335120 <= id AND id < 630097279) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (630097279 <= id AND id < 708859438) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  (708859438 <= id AND id <= 787621597) 
[15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale  where  id IS NULL
[15:14:00] ].

參考:

1. https://www.cnblogs.com/hit-zb/p/10940849.html