1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 為什么選擇 DataX 而不是其他同步工具我一直在做數(shù)據(jù)平臺的活兒日常打交道最多的就是各種數(shù)據(jù)遷移、離線同步、倉庫存取。最開始那幾年同步數(shù)據(jù)基本靠寫Shell腳本加SQL導(dǎo)出導(dǎo)入或者用Sqoop這種老牌工具。但用著用著就發(fā)現(xiàn)問題了腳本一多維護(hù)成本直線上升跑掛了沒人發(fā)現(xiàn)數(shù)據(jù)類型稍微復(fù)雜一點(diǎn)就開始鬧脾氣而且不同數(shù)據(jù)源之間的同步方式完全不統(tǒng)一每接一個(gè)新源就要重寫一套邏輯。后來接觸到DataX最大的感受就是這玩意兒把“數(shù)據(jù)同步”這件事抽象得特別干凈。它不需要你部署服務(wù)端就是一個(gè)獨(dú)立運(yùn)行的進(jìn)程你給它一個(gè)JSON格式的作業(yè)配置它就能把數(shù)據(jù)從源頭拉到目的地。不像有些同步工具要裝Agent、要搭管理端DataX本身就是個(gè)“跑完即走”的命令行工具特別適合那種不想引入太重基礎(chǔ)設(shè)施的場景。我選擇DataX還有幾個(gè)很現(xiàn)實(shí)的原因第一它支持的數(shù)據(jù)源特別全MySQL、Oracle、SQL Server、HDFS、Hive、HBase、MongoDB、Elasticsearch、ClickHouse這些常見的都覆蓋到了而且還在持續(xù)更新。第二它的運(yùn)行機(jī)制是“讀取-緩沖-寫入”三段式理論上任意兩個(gè)數(shù)據(jù)源之間都能通過配置組合實(shí)現(xiàn)同步。第三它是純Java寫的跨平臺跑沒問題扔到服務(wù)器上就能用。如果你只是偶爾同步幾張表或者需要在不穩(wěn)定的網(wǎng)絡(luò)環(huán)境下做斷點(diǎn)重跑DataX這種輕量級工具其實(shí)比調(diào)度平臺自帶的同步組件更靈活因?yàn)樗鼘\(yùn)行環(huán)境的要求極低——只要有JDK有Python執(zhí)行入口腳本用就能跑起來。1.2 一次同步任務(wù)的基本運(yùn)行邏輯很多人第一次接觸DataX時(shí)會被它的目錄結(jié)構(gòu)嚇到其實(shí)拆開看就兩件事寫配置、跑命令。一個(gè)完整的DataX同步任務(wù)本質(zhì)上是定義了一條數(shù)據(jù)流轉(zhuǎn)管道。你的核心工作就是寫好一個(gè)JSON文件里面描述清楚三件事數(shù)據(jù)從哪來reader、數(shù)據(jù)寫到哪去writer、以什么速率跑channel。DataX會解析這個(gè)JSON啟動一個(gè)調(diào)度進(jìn)程把任務(wù)拆分成多個(gè)并發(fā)線程通過內(nèi)存緩沖區(qū)把數(shù)據(jù)從源頭搬運(yùn)到目標(biāo)端。跑任務(wù)的命令也特別簡單python datax.py job.json就這一行沒有了。所有復(fù)雜的連接信息、字段映射、并發(fā)控制全部沉淀在JSON配置里。這也意味著你的所有“功力”都在于怎么把JSON寫好、寫對。我自己第一次跑通DataX時(shí)花了不少時(shí)間在“JSON怎么寫才合法”上面。它有一套固定的結(jié)構(gòu)比如最外層是jobjob下面是contentcontent里面是一個(gè)數(shù)組每個(gè)元素包含reader、writer、setting。這個(gè)結(jié)構(gòu)看起來簡單但嵌套層級一旦多起來少個(gè)括號、多個(gè)逗號任務(wù)就直接報(bào)錯(cuò)。所以后來我習(xí)慣了寫完之后用Python的json.tool先校驗(yàn)一遍再做真實(shí)執(zhí)行。2. 環(huán)境準(zhǔn)備與安裝部署2.1 最小化環(huán)境依賴DataX對運(yùn)行環(huán)境的要求確實(shí)很低但“低”不代表“不用準(zhǔn)備”。我實(shí)踐下來的最小環(huán)境是JDK 1.8及以上版本推薦直接裝OpenJDK。Python 2.7或3.x用來啟動datax.py腳本。實(shí)測Python 3.6以上也沒問題。目標(biāo)數(shù)據(jù)源和源數(shù)據(jù)源各自的連接權(quán)限、賬號信息、網(wǎng)絡(luò)連通性。有足夠的磁盤空間DataX會使用臨時(shí)目錄存放運(yùn)行時(shí)產(chǎn)生的中間文件。安裝就更簡單了把DataX壓縮包扔到服務(wù)器上解壓之后目錄結(jié)構(gòu)長這樣datax/ bin/ datax.py conf/ core.json logback.xml job/ job.json lib/ datax-core-xxx.jar datax-common-xxx.jar ... 各種數(shù)據(jù)源插件jar包 plugin/ reader/ mysqlreader/ hdfsreader/ ... writer/ mysqlwriter/ hdfswriter/ ... tmp/ log/plugin目錄才是DataX的靈魂。每個(gè)數(shù)據(jù)源插件都是獨(dú)立打包的互不干擾。如果你只需要MySQL到HDFS的同步甚至可以把不需要的插件刪掉體積能瘦身不少啟動速度也會快一點(diǎn)。不過新手不建議亂刪等完全理解了每個(gè)插件的依賴關(guān)系之后再做精簡。2.2 環(huán)境變量配置與啟動驗(yàn)證解壓之后推薦把DataX的目錄配到PATH里。但我一般不愛改全局環(huán)境變量因?yàn)榉?wù)器上可能有多個(gè)版本共存的情況。我習(xí)慣在需要執(zhí)行任務(wù)的用戶目錄下的.bashrc文件里寫export DATAX_HOME/opt/datax export PATH$PATH:$DATAX_HOME/bin這樣在任何目錄下都能直接敲datax.py命令。配置完成之后先跑一下自帶的自檢腳本確認(rèn)基礎(chǔ)環(huán)境沒問題python $DATAX_HOME/bin/datax.py $DATAX_HOME/job/job.json如果能看到“任務(wù)啟動時(shí)刻”“任務(wù)結(jié)束時(shí)刻”“任務(wù)總計(jì)耗時(shí)”“平均流量”這些信息輸出說明安裝成功可以開始正式寫任務(wù)了。提示如果你的服務(wù)器是內(nèi)網(wǎng)環(huán)境沒有外網(wǎng)那就不能使用在線安裝的方式只能先把安裝包傳到服務(wù)器上解壓。注意確認(rèn)JDK的位數(shù)和版本出現(xiàn)過不少因?yàn)镴DK版本太高導(dǎo)致部分插件加載不了的情況保守點(diǎn)直接用JDK 8最穩(wěn)。3. 核心配置解析與JSON結(jié)構(gòu)拆解3.1 一個(gè)標(biāo)準(zhǔn)任務(wù)JSON的完整框架先給一個(gè)我日常用得最多的模板MySQL同步到MySQL{ job: { content: [ { reader: { name: mysqlreader, parameter: { username: root, password: 123456, column: [*], connection: [ { table: [t_user], jdbcUrl: [jdbc:mysql://localhost:3306/test?useSSLfalsecharacterEncodingutf8] } ] } }, writer: { name: mysqlwriter, parameter: { username: root, password: 123456, writeMode: insert, column: [*], connection: [ { table: [t_user_bak], jdbcUrl: jdbc:mysql://localhost:3306/test?useSSLfalsecharacterEncodingutf8 } ] } } } ], setting: { speed: { channel: 3, byte: 1048576 } } } }這個(gè)JSON是理解所有DataX配置的鑰匙。不管你后面用多少個(gè)Reader、多少個(gè)Writer底層表達(dá)方式完全一致。你只需要替換name字段和parameter里各個(gè)數(shù)據(jù)源專屬的連接參數(shù)其他框架完全不用動。3.2 Reader和Writer的參數(shù)細(xì)節(jié)Reader部分的重點(diǎn)在三個(gè)地方怎么連接源端、讀哪些列、以及并發(fā)切片機(jī)制。column字段既可以是通配符*也可以寫具體的列名列表。我建議生產(chǎn)環(huán)境永遠(yuǎn)不要用*要顯式列出列名。一方面防止源端表結(jié)構(gòu)變更導(dǎo)致同步出錯(cuò)另一方面DataX在做字段映射時(shí)按名稱匹配比按位置匹配更穩(wěn)。connection下的table支持?jǐn)?shù)組意味著你可以一次配置多張表。但要小心多表配置時(shí)DataX會按表順序逐個(gè)讀取如果各表結(jié)構(gòu)不一致很可能報(bào)錯(cuò)。我習(xí)慣一次只同步一張表多張表就多寫幾個(gè)JSON配合調(diào)度平臺并行跑。Writer部分的重點(diǎn)在writeMode。以mysqlwriter為例主要有三個(gè)取值insert直接插入、update按主鍵更新、replace存在則替換不存在則插入。這個(gè)選擇直接決定了同步的冪等性策略。如果你做的是全量覆蓋同步推薦用replace配合JobId能實(shí)現(xiàn)類似“按批次清理數(shù)據(jù)”的效果。如果是增量同步就用insert。還有一點(diǎn)容易被忽略Writer的jdbcUrl字段值是一個(gè)字符串而Reader的jdbcUrl字段值是一個(gè)數(shù)組。這個(gè)差異官方文檔里寫得很隱晦我當(dāng)初調(diào)試了半天才發(fā)現(xiàn)是類型不匹配的問題。DataX的多個(gè)Reader插件和Writer插件之間參數(shù)格式并不完全對稱寧可先看官方示例再改。3.3 Channel參數(shù)如何決定同步速率setting.speed.channel是控制并發(fā)度的核心參數(shù)。它是怎么運(yùn)作的呢DataX會把Reader讀到的數(shù)據(jù)放進(jìn)內(nèi)存隊(duì)列Writer從隊(duì)列里取數(shù)據(jù)寫入目標(biāo)端。channel的數(shù)量相當(dāng)于同時(shí)跑了多少條讀寫管道。channel越多并行度越高同步速度越快但同時(shí)也意味著更高的內(nèi)存消耗、更大的源端和目的端壓力。我整理過一組實(shí)際經(jīng)驗(yàn)值供你參考場景channel數(shù)說明小表幾十萬行以內(nèi)1避免頻繁建連夠用即可中等規(guī)模千萬級3-5兼顧速度和穩(wěn)定性大表億級5-10需要壓測確認(rèn)源端扛得住極端快速導(dǎo)入15以上只建議在內(nèi)網(wǎng)高帶寬場景使用另外channel到底是多少不能只看數(shù)據(jù)量還要看源端數(shù)據(jù)庫的負(fù)載。我遇到過把channel調(diào)到10之后直接把源端MySQL的CPU打滿的情況。那是一個(gè)業(yè)務(wù)核心庫差點(diǎn)出事。所以我現(xiàn)在調(diào)并發(fā)時(shí)會遵循“逐步遞增”的原則先用channel1跑一遍記錄耗時(shí)和流量再把channel翻倍觀察數(shù)據(jù)庫監(jiān)控指標(biāo)穩(wěn)定之后再繼續(xù)往上加直到性能不再提升反而下降的那個(gè)點(diǎn)取上一個(gè)值作為最終配置。setting.speed.byte參數(shù)是流控用的如果不設(shè)置DataX會盡可能跑滿帶寬。對于生產(chǎn)任務(wù)建議設(shè)置一個(gè)合理的上限防止同步任務(wù)占滿網(wǎng)絡(luò)帶寬影響線上業(yè)務(wù)。比如設(shè)置1048576單位是字節(jié)就是每秒最多1MB加上channel機(jī)制實(shí)際上最終速率是兩者取較小值這個(gè)不要搞混了。4. 實(shí)操過程從零跑通一個(gè)同步任務(wù)4.1 場景設(shè)定MySQL數(shù)據(jù)同步到HDFS為了把一個(gè)完整的實(shí)操過程講清楚我拿一個(gè)真實(shí)場景舉例把業(yè)務(wù)庫MySQL里的用戶訂單表同步到HDFS上按天分區(qū)存放做離線數(shù)倉的原始數(shù)據(jù)層。目標(biāo)源表業(yè)務(wù)庫testdb下的t_order目標(biāo)HDFS路徑 /warehouse/ods/t_order/dt20250115文件格式TextFile字段分隔符設(shè)為\t同步方式當(dāng)天全量快照先看一下最終的job.json長什么樣{ job: { content: [ { reader: { name: mysqlreader, parameter: { username: readonly, password: xxxx, column: [ order_id, user_id, product_id, order_amount, order_status, create_time ], splitPk: order_id, connection: [ { table: [t_order], jdbcUrl: [jdbc:mysql://10.0.0.x:3306/testdb?useSSLfalsecharacterEncodingutf8zeroDateTimeBehaviorconvertToNull] } ] } }, writer: { name: hdfswriter, parameter: { defaultFS: hdfs://10.0.0.y:9000, fileType: text, path: /warehouse/ods/t_order/dt20250115, fileName: t_order_, column: [ { name: order_id, type: long }, { name: user_id, type: long }, { name: product_id, type: long }, { name: order_amount, type: double }, { name: order_status, type: string }, { name: create_time, type: string } ], writeMode: append, fieldDelimiter: \t, compress: gzip } } } ], setting: { speed: { channel: 4, byte: 52428800 }, errorLimit: { record: 0, percentage: 0 } } } }4.2 關(guān)鍵參數(shù)的設(shè)計(jì)邏輯splitPk這個(gè)參數(shù)很關(guān)鍵。它告訴DataX用哪個(gè)字段作為分片鍵來切分并發(fā)任務(wù)。如果設(shè)置了splitPkDataX會在底層把一張表的數(shù)據(jù)按照這個(gè)字段的范圍切成多段讓多個(gè)channel并行讀取。不設(shè)置的話即使channel配置了多個(gè)也只會在數(shù)據(jù)源層面做JDBC連接復(fù)用沒法真正并行拉取。splitPk通常選擇主鍵或數(shù)字類型的字段。因?yàn)镈ataX底層是用類似于between and的條件去分段讀取數(shù)據(jù)varchar類型也可以但需要確認(rèn)數(shù)據(jù)庫端能做范圍查詢優(yōu)化。我實(shí)測下來用自增主鍵效果最好切分均勻查詢計(jì)劃也穩(wěn)定。hdfswriter的path路徑我寫的是具體到日期的分區(qū)路徑。這跟Hive數(shù)倉的分區(qū)表結(jié)構(gòu)是對應(yīng)的后續(xù)如果要用Hive查數(shù)據(jù)直接通過分區(qū)路徑就能映射到分區(qū)字段。還有一點(diǎn)要說明DataX在寫入HDFS時(shí)不會自動創(chuàng)建多級目錄所以你需要提前用hdfs dfs -mkdir -p把目錄建好或者依賴調(diào)度平臺在跑任務(wù)前執(zhí)行建目錄操作。writeModeappend表示追加寫入不覆蓋已有文件。對于每天同步的場景這個(gè)模式是安全的因?yàn)槊刻斓哪夸浭仟?dú)立的不存在覆蓋問題。如果同步的是業(yè)務(wù)上要覆蓋的維度表可以考慮用truncate模式它會先清空目錄再寫入。4.3 從執(zhí)行到驗(yàn)證的完整流程寫好JSON后先校驗(yàn)格式python -m json.tool job.json沒有報(bào)錯(cuò)說明語法沒問題再執(zhí)行python /opt/datax/bin/datax.py job.json執(zhí)行過程中會實(shí)時(shí)輸出每個(gè)channel的讀取速度、寫入速度、流量信息。我習(xí)慣盯著兩個(gè)指標(biāo)看讀取記錄總數(shù)確認(rèn)跟源表行數(shù)一致?？梢栽谠磶炫芤粭lcount(*)兩邊核對。運(yùn)行速度是否達(dá)到預(yù)期如果長時(shí)間在幾十KB/s徘徊多半是數(shù)據(jù)庫端慢查詢或者網(wǎng)絡(luò)有瓶頸。跑完之后的輸出片段大致是這樣任務(wù)啟動時(shí)刻: 2025-01-15 01:00:00 任務(wù)結(jié)束時(shí)刻: 2025-01-15 01:08:32 任務(wù)總計(jì)耗時(shí): 512s 任務(wù)平均流量: 18.67MB/s 記錄寫入速度: 32,500rec/s 讀出記錄總數(shù): 16,658,432 讀寫失敗總數(shù): 0看到讀寫失敗總數(shù)為0就可以收工了。下一步是去HDFS上看一眼文件是否正常生成hdfs dfs -ls /warehouse/ods/t_order/dt20250115/ hdfs dfs -cat /warehouse/ods/t_order/dt20250115/* | head -10我一般還會順手跑一下文件行數(shù)統(tǒng)計(jì)用wc -l或者Hive里的count對比一下源表的行數(shù)確保兩邊一致。這一步看似多余但在真實(shí)生產(chǎn)里確實(shí)抓到過幾次數(shù)據(jù)條數(shù)對不上的問題原因都是源端表在同步過程中有并發(fā)寫入。5. 常見問題與排查技巧實(shí)錄5.1 連接超時(shí)與連接被拒最常見的坑就是數(shù)據(jù)源連不上。報(bào)錯(cuò)信息一般長這樣Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure我的排查順序是固定的先在本機(jī)用mysql命令測試一下能不能連上目標(biāo)庫排除網(wǎng)絡(luò)問題。檢查jdbcUrl里的IP和端口是否真的開放了。很多時(shí)候是安全組策略沒放行這個(gè)在云上環(huán)境尤其常見。確認(rèn)賬號權(quán)限沒有問題。DataX連接數(shù)據(jù)庫的賬號需要有SELECT權(quán)限寫端還要有INSERT、UPDATE、DELETE、CREATE等權(quán)限缺一不可。檢查數(shù)據(jù)庫的max_connections有沒有打滿。如果數(shù)據(jù)庫連接池已經(jīng)被占滿DataX的連接就會被拒。還有一個(gè)容易忽視的細(xì)節(jié)MySQL連接串里要帶useSSLfalse。內(nèi)網(wǎng)數(shù)據(jù)庫一般都沒開SSL如果這里不寫連接初始化階段會花很長時(shí)間甚至直接hang住。5.2 數(shù)據(jù)格式容忍度問題有一段時(shí)間我同步MySQL的數(shù)據(jù)到HDFS時(shí)老報(bào)錯(cuò)日志提示java.lang.NumberFormatException: For input string: abc排查發(fā)現(xiàn)源表某個(gè)int字段里混入了臟數(shù)據(jù)出現(xiàn)了字符串類型的值。DataX默認(rèn)遇到類型轉(zhuǎn)換失敗就會報(bào)錯(cuò)除非在setting里配置errorLimit。errorLimit有record和percentage兩個(gè)字段含義分別是可以容忍的錯(cuò)誤條數(shù)和錯(cuò)誤比例。生產(chǎn)環(huán)境我一般不設(shè)容忍度因?yàn)榕K數(shù)據(jù)意味著數(shù)據(jù)質(zhì)量有問題寧可同步失敗暴露出來也不要靜默丟掉。但在做一次性數(shù)據(jù)遷移時(shí)我會把errorLimit的percentage設(shè)為5先保證任務(wù)能跑完拿到絕大部分?jǐn)?shù)據(jù)再回頭單獨(dú)清洗臟數(shù)據(jù)。5.3 HDFS權(quán)限與文件格式坑HDFS寫入報(bào)錯(cuò)最常見的原因是權(quán)限不足。DataX進(jìn)程以什么系統(tǒng)用戶啟動HDFS上對應(yīng)的就是什么身份。如果目標(biāo)目錄的owner和權(quán)限沒有針對這個(gè)用戶放通就會遇到Permission denied。解決辦法有幾個(gè)給目標(biāo)目錄設(shè)置遞歸權(quán)限hdfs dfs -chmod -R 777 /warehouse/ods或者把DataX進(jìn)程的啟動用戶切換到HDFS的超級用戶或者用Kerberos認(rèn)證企業(yè)集群場景我在測試環(huán)境一般用第一種生產(chǎn)環(huán)境會專門創(chuàng)建一個(gè)數(shù)據(jù)同步賬戶配置好它的讀寫權(quán)限避免用hdfs超級用戶跑所有任務(wù)。fileType這個(gè)參數(shù)也經(jīng)常出錯(cuò)。hdfswriter支持text和orc兩種格式。text格式就是普通文本文件調(diào)試方便任何工具都能讀。orc格式是列式存儲壓縮率高、查詢性能好適合數(shù)據(jù)量很大的場景。但如果你的下游是Spark或Presto建議直接用orc省掉后續(xù)轉(zhuǎn)換的麻煩。不過要注意orc格式對字段類型要求更嚴(yán)格string和varchar不要混用否則會出現(xiàn)讀出來類型不匹配的問題。5.4 同步速度遠(yuǎn)低于預(yù)期這個(gè)是群里被問得最多的一個(gè)問題。明明channel配了8結(jié)果速度只有幾十KB/s。我總結(jié)下來主要因素不外乎這幾個(gè)splitPk沒設(shè)置導(dǎo)致并行讀根本沒生效。源庫是主從架構(gòu)同步賬號連接到了只讀節(jié)點(diǎn)只讀節(jié)點(diǎn)的負(fù)載太高查詢性能大幅下降。目標(biāo)端HDFS的DataNode磁盤IO打滿了。JDBC連接串里少了rewriteBatchedStatementstrue導(dǎo)致批量寫入沒有生效。這個(gè)參數(shù)對MySQL寫入性能影響巨大加上它之后寫入速度能提升好幾倍。實(shí)測過一組對比同樣的表同樣的channel數(shù)加上rewriteBatchedStatementstrue之后寫入速度從3萬條/秒提升到12萬條/秒。這個(gè)參數(shù)對于MySQL寫入場景幾乎是必選項(xiàng)。提示MySQL連接串中建議同時(shí)使用rewriteBatchedStatementstrue和useCompressiontrue前者優(yōu)化批量寫入后者在數(shù)據(jù)量大的時(shí)候減少網(wǎng)絡(luò)傳輸開銷。5.5 多表同步時(shí)的類型映射不同數(shù)據(jù)源之間的類型映射是另一個(gè)大坑。DataX有一套自己的類型體系比如long、double、string、date、bytes、boolean它在讀取階段會把源端類型轉(zhuǎn)換成自己的類型在寫入階段再把內(nèi)部類型轉(zhuǎn)換成目標(biāo)端類型。問題是這種轉(zhuǎn)換規(guī)則在不同插件里并不完全一致。比如MySQL的datetime類型在mysqlreader里會轉(zhuǎn)成date但hdfswriter的date類型和string類型的處理方式不同。如果不小心同步過去之后時(shí)間字段會變成一串?dāng)?shù)字或者格式不對。我的避坑方法是在writer的column里顯式指定目標(biāo)端類型不要依賴自動推斷。尤其是時(shí)間類型目標(biāo)端要指定成string并在讀端就做好格式轉(zhuǎn)換?？梢栽赟QL里直接寫date_format(create_time, %Y-%m-%d %H:%i:%s) as create_time這樣源頭輸出就是標(biāo)準(zhǔn)格式字符串寫端直接按string處理完全避開類型轉(zhuǎn)換的坑。5.6 常見錯(cuò)誤速查表現(xiàn)象可能原因解決思路任務(wù)啟動即報(bào)ClassNotFoundlib目錄缺插件jar包重新完整解壓DataX檢查plugin目錄讀取速度極慢未設(shè)置splitPk按主鍵設(shè)置splitPk寫入速度極慢缺少rewriteBatchedStatementsMySQL連接串加上該參數(shù)JSON解析報(bào)錯(cuò)字段類型寫錯(cuò)或缺少逗號用python -m json.tool校驗(yàn)?zāi)繕?biāo)端重復(fù)數(shù)據(jù)writeMode用錯(cuò)更新MySQL寫模式為replaceHDFS路徑不存在未提前建目錄調(diào)度流程里加mkdir步驟內(nèi)存溢出channel數(shù)量過多或byte限制過大降低channel設(shè)置byte流控6. 一些心得體會用了DataX這么久最大的體會是它的定位很精準(zhǔn)它不搞服務(wù)化不做Web界面不負(fù)責(zé)調(diào)度只專注做一件事——把數(shù)據(jù)穩(wěn)定地從A搬到B。這種“單點(diǎn)做好”的思路反而讓我在排障時(shí)特別舒服因?yàn)槊總€(gè)環(huán)節(jié)都單一、透明出問題就能快速定位。我現(xiàn)在的做法是把所有同步任務(wù)按業(yè)務(wù)線組織成獨(dú)立目錄每個(gè)任務(wù)一個(gè)JSON。在調(diào)度平臺里按天觸發(fā)跑完自動記錄日志。長期運(yùn)行下來非常穩(wěn)定基本不需要人為干預(yù)。DataX的另一個(gè)好用之處是它的插件機(jī)制。如果現(xiàn)有插件滿足不了需求你甚至可以自己寫一個(gè)插件只要繼承它提供的接口打包放進(jìn)plugin目錄就能被識別。有一次我需要從一個(gè)內(nèi)部自研的存儲系統(tǒng)同步數(shù)據(jù)就是照著官方插件的代碼結(jié)構(gòu)自己寫了個(gè)reader整個(gè)過程大概花了一天時(shí)間這種自由度是很多商業(yè)同步工具給不了的。最后分享一個(gè)小技巧DataX在跑任務(wù)的時(shí)候日志里會打印每個(gè)channel的實(shí)時(shí)流量如果發(fā)現(xiàn)某個(gè)channel長期沒有輸出大概率是數(shù)據(jù)傾斜了。這時(shí)候可以用splitPk配合一個(gè)更均勻的字段比如把字符串主鍵換成自增主鍵或者增加多個(gè)字段拼接成切分鍵基本能解決。如果你是剛接觸DataX建議先從最簡單的MySQL到MySQL開始跑通了再往上疊加HDFS、Hive這些復(fù)雜目標(biāo)端。每一步都確認(rèn)數(shù)據(jù)一致之后再擴(kuò)展場景就不會在踩坑中浪費(fèi)時(shí)間。