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