国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

DataX的限速與調優

不知名網友 / 4069人閱讀
DataX的限速與調優

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！

一

前 言

眾所周知，當一個程序需要傳輸數據的時候，它肯定會想盡辦法占用掉設備的資源，但是，隨著對DataX深入使用可以發現，DataX并不會全力吃掉資源，所以究竟DataX是如何做到限速的？傳輸緩慢到底是限速原因還是其他原因？本文來一起探討下。

二

限 速

我們知道是在core.json文件里面的speed方法里面限速DataX的，可以通過record記錄數和byte字節數來限速。
這個配置在CoreConstant類里面定義了:
選中常量復制并查找，可以看到有兩個地方調用了這個值：
分別是初始化、求最大通道數的時候。
接下來，看看這兩個配置在Channel類如何實現限速的。

Channel類里實現限速：

從下圖，可以看到在Channel初始化時，順帶初始化了限速的記錄數(recordSpeed)以及字節數(byteSpeed) ，接下來Control+F看看recordSpeed在哪里調用了。
可以看到在statPush方法里面用到了：

statPush整個流程的描述：

  • 判斷byteSpeed（bps）和recordSpeed（tps）是否都大于0？如果不是，則退出；
  • 根據當前的byteSpeed和設定的byteSpeed對比，求出睡眠時間（公式：currentByteSpeed * interval / this.byteSpeed- interval;）
  • 根據當前的recordSpeed和設定的recordSpeed對比，求出睡眠時間（公式：currentRecordSpeed * interval / this.recordSpeed - interval;）
  • 取休眠時間最大值；
  • Thread.sleep(sleepTime)來休眠；
  • 實現限速。
下面貼上statPush的完整代碼：

三

調 優

首先我們知道，傳輸受兩個因素影響：

  • 網絡本身的帶寬等硬件因素造成的影響；
  • DataX本身的參數。
即當覺得DataX傳輸速度慢時，需要從上述兩個個方面著手開始排查。

3.1 網絡本身的帶寬等硬件因素造成的影響

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

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

3.2 DataX本身的參數

1）全局

全局：提升每個channel的速度**
在DataX內部對每個Channel會有嚴格的速度控制，分兩種，一種是控制每秒同步的記錄數，另外一種是每秒同步的字節數，默認的速度限制是1MB/s，可以根據具體硬件情況設置這個byte速度或者record速度，一般設置byte速度，比如：我們可以把單個Channel的速度上限配置為5MB，舉例：
Json：
{
   "core":{
        "transport":{
            "channel":{
                "speed":{
                  "channel": 2, 此處為數據導入的并發度，建議根據服務器硬件進行調優
                  "record":-1,此處解除對讀取行數的限制
                  "byte":-1,此處解除對字節的限制
                  "batchSize":204每次讀取batch的大小
                }
            }
        }
    },
    "job":{
            ...
        }
    }

2）局部

局部：提升DataX Job內Channel并發數**
并發數=taskGroup的數量每一個TaskGroup并發執行的Task數 (默認單個任務組的并發數量為5)。

提升job內Channel并發有三種配置方式：

  • 配置全局Byte限速以及單Channel Byte限速，Channel個數 = 全局Byte限速 / 單Channel Byte限速。
  • 配置全局Record限速以及單Channel Record限速，Channel個數 = 全局Record限速 / 單Channel Record限速。
  • 直接配置Channel個數。

配置含義：

  • job.setting.speed.channel : channel并發數；
  • job.setting.speed.record : 全局配置channel的record限速；
  • job.setting.speed.byte：全局配置channel的byte限速。
  • core.transport.channel.speed.record：單channel的record限速；
  • core.transport.channel.speed.byte：單channel的byte限速。
舉例：
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)

注意事項：

此處根據服務器配置進行調優，切記不可太大！否則直接Exception。以上為調優，應該是可以針對每個json文件都可以進行調優。

當提升DataX Job內Channel并發數時，調整JVM堆參數，原因如下：

  • 當一個Job內Channel數變多后，內存的占用會顯著增加，因為DataX作為數據交換通道，在內存中會緩存較多的數據。
  • 例如Channel中會有一個Buffer，作為臨時的數據交換的緩沖區，而在部分Reader和Writer的中，也會存在一些Buffer，為了防止jvm報內存溢出等錯誤，調大jvm的堆參數。
  • 通常我們建議將內存設置為4G或者8G，這個也可以根據實際情況來調整。
  • 調整JVM xms xmx參數的兩種方式：一種是直接更改datax.py；另一種是在啟動的時候，加上對應的參數，如下：python datax/bin/datax.py --jvm="-Xms8G -Xmx8G" XXX.json。

Channel個數并不是越多越好，原因如下：

  • Channel個數的增加，帶來的是更多的CPU消耗以及內存消耗。
  • 如果Channel并發配置過高導致JVM內存不夠用，會出現的情況是發生頻繁的Full GC，導出速度會驟降，適得其反。

備注：

MysqlReader進行數據抽取時，如果指定splitPk，表示用戶希望使用splitPk代表的字段進行數據分片，DataX因此會啟動并發任務進行數據同步，這樣可以大大提供數據同步的效能，splitPk不填寫，包括不提供splitPk或者splitPk值為空，DataX視作使用單通道同步該表數據。

結語：

學習之路沒有固定的，先了解原理，再根據原理及執行過程開始研究，DataX是開源軟件，能直接看到開發者的思路，更能對其進行研究和修改，使其更適合我們的工作。


本文作者：孫振興(上海新炬中北團隊）

本文來源：“IT那活兒”公眾號

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129097.html

相關文章

  • DataPipeline |《Apache Kafka實戰》作者胡夕：Apache Kafka監控與

    摘要：主機監控個人認為對于主機的監控是最重要的。在實際監控時可以有意識地驗證這一點。另外還有兩個線程池空閑使用率小關注，最好確保它們的值都不要低于，否則說明已經非常的繁忙。此時需要調整線程池線程數。 showImg(https://segmentfault.com/img/bVbgpkO?w=1280&h=720); 胡夕，《Apache Kafka實戰》作者，北航計算機碩士畢業，現任某互金...

    lvzishen 評論0 收藏0

  • DataX在有贊大數據平臺的實踐

    摘要：與大數據體系交互上報運行統計數據自帶了運行結果的統計數據，我們希望把這些統計數據上報到元數據系統，作為的過程元數據存儲下來。基于我們的開發策略，不要把有贊元數據系統的嵌入源碼，而是在之外獲取，截取出打印的統計信息再上報。一、需求 有贊大數據技術應用的早期，我們使用 Sqoop 作為數據同步工具，滿足了 MySQL 與 Hive 之間數據同步的日常開發需求。 隨著公司業務發展，數據同步的場景越...

    JerryWangSAP 評論0 收藏0

發表評論

0條評論

不知名網友

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<