手頭那批同步任務(wù)終于可以重新選型了。過去兩年我把它們堆在一條比較重的實時鏈路上Flink CDC 從 MySQL 抓增量先進(jìn) Kafka再做幾層轉(zhuǎn)換落到數(shù)倉。數(shù)據(jù)量不算大但這套鏈路里光是常駐組件就有小十個大多數(shù)時候都在空轉(zhuǎn)。所以這次整理 2026 年這輪方案時我給自己定的標(biāo)準(zhǔn)很簡單能在單機(jī)或一兩個進(jìn)程內(nèi)跑完的就不上集群能用定時任務(wù)解決的就不用常駐服務(wù)能靠數(shù)據(jù)和位點恢復(fù)的就不依賴復(fù)雜運維面板。這篇主要是把“輕量級 CDC 與流處理”的選型思路記錄一下包括我實測下來比較順手的組合、國產(chǎn)數(shù)據(jù)庫環(huán)境的適配經(jīng)驗以及踩過幾次坑后總結(jié)出的判斷框架。如果你團(tuán)隊里沒有專職流平臺或者你只是想在業(yè)務(wù)代碼旁邊搭一條不喧賓奪主的增量同步管道這輪盤點會比較對胃口。1. 先把語境對齊同樣叫 CDC數(shù)據(jù)工程師和嵌入式工程師聊的不是一回事1.1 同名概念的“撞車”現(xiàn)場上個月我在即時通訊軟件里發(fā)了一條消息說“CDC 那邊延遲有點高”旁邊嵌入式組的同事立刻回了一句你們在做 USB Device當(dāng)時沉默了幾秒鐘然后兩個人才發(fā)現(xiàn)誰都沒聽懂誰。這個場景在 2026 年一點也不罕見。搜索框里敲 CDC返回結(jié)果至少有三個完全不同的技術(shù)語境數(shù)據(jù)工程語境Change Data Capture變更數(shù)據(jù)捕獲把數(shù)據(jù)庫的增刪改操作抓出來變成事件流。嵌入式/接口開發(fā)語境USB Communication Device Class通信設(shè)備類協(xié)議。那些搜“STM32F103 CDC 多串口編程”“STM32 HID CDC 復(fù)合設(shè)備 Cubemx”的工程師在做的是端點描述符和接口枚舉處理的是設(shè)備驅(qū)動與硬件通信。數(shù)字邏輯設(shè)計語境Clock Domain Crossing跨時鐘域。芯片工程師關(guān)心的是亞穩(wěn)態(tài)、同步器、FIFO 設(shè)計和數(shù)據(jù)表變更沒有關(guān)系。還有一個容易混淆的角落OpenCV 相關(guān)開發(fā)里會出現(xiàn)cdc::drawtext這樣的字符串視覺算法工程師理解的 CDC 可能是某個函數(shù)命名空間。人和人之間技術(shù)棧差距可以非常大但這幾個圈子不會同時出現(xiàn)在同一篇技術(shù)文檔里。1.2 數(shù)據(jù)工程語境下的 CDC 到底是什么收窄回數(shù)據(jù)同步這條線。Change Data Capture 的核心思路是不去頻繁全表掃描而是直接讀取數(shù)據(jù)庫日志或系統(tǒng)提供的變更接口把每一筆插入、更新、刪除翻譯成一條帶結(jié)構(gòu)信息的變更事件。不同數(shù)據(jù)庫提供的能力路徑不太一樣MySQL 走 binlog。最常用的是 row 格式binlog 里記錄每行變更前后的完整映象。PostgreSQL 走 WAL 與邏輯復(fù)制。發(fā)布訂閱機(jī)制可以把表的變更推給訂閱端。SQL Server 有內(nèi)置的 CDC 機(jī)制通過系統(tǒng)表記錄變更Oracle 則可以通過 LogMiner 或第三方解析日志。像達(dá)夢、人大金倉這類國內(nèi)數(shù)據(jù)庫環(huán)境適配邏輯就更需要先確認(rèn)日志接口和兼容模式后面我會單獨展開。所以當(dāng)我們在談“輕量級 CDC 與流處理”時真正談的是這樣一條鏈路源庫日志產(chǎn)生變更事件采集端解析事件中間可能做過濾和格式轉(zhuǎn)換最后進(jìn)入目標(biāo)庫或流處理端。采集只是起點后面每一步都可能成為坑。開始選型之前我建議做任何搜索時都養(yǎng)成一個習(xí)慣不要把 CDC 當(dāng)成獨立關(guān)鍵詞往前或往后加限定詞。找數(shù)據(jù)同步方案就寫“Debezium CDC”“Seatunnel 達(dá)夢 CDC”“Flink CDC 選型”找嵌入式內(nèi)容就寫“USB CDC 驅(qū)動”。搜索引擎不會替你判斷語境只有限定詞能幫你把不同圈子的內(nèi)容隔開。2. 輕量級不是“功能弱”而是把資源花在真正需要的地方2.1 先看看重量級方案是怎么變重的我過去維護(hù)的那套鏈路嚴(yán)格來說是從很樸素的需求長出來的MySQL 里的訂單表產(chǎn)生變化希望幾分鐘內(nèi)同步到分析庫。最初方案看起來也很簡單Canal 監(jiān)聽 binlog投遞到 Kafka再讓 Flink 消費?？墒堑冗@套東西真正跑起來日常需要照顧的組件變成了Kafka Broker 少說兩個節(jié)點算上 ZooKeeper 或 KRaft 模式下的控制器Canal 的 server 和 adapterFlink 集群的 JobManager 和 TaskManager外部化的狀態(tài)后端存儲用于監(jiān)控的 Prometheus、Grafana 和一堆告警規(guī)則。到了這一步哪怕原始需求只是同步幾十張表你已經(jīng)默認(rèn)背上了一個“小平臺”的運維負(fù)擔(dān)。而大部分時間這些組件的資源利用率都很低。2.2 輕量級方案的三種常見形態(tài)我理解中的輕量級不是把所有功能塞進(jìn)一個進(jìn)程而是砍掉與核心需求無關(guān)的組件讓復(fù)雜度降到一個人能扛住的程度。當(dāng)前生態(tài)里常見的輕量形態(tài)有三種第一種嵌入式引擎。典型代表是 Debezium 的 Embedded Engine。它把自己作為庫集成進(jìn)你的 Java 進(jìn)程應(yīng)用啟動時同步啟動源庫監(jiān)聽不需要部署 Kafka Connect 集群也不需要單獨管理 connector 的 REST API。適合的場景是業(yè)務(wù)服務(wù)里有一個明確的后臺任務(wù)比如訂單變更后同步到緩存或搜索索引。第二種批流一體的工具但只跑本地模式或單機(jī)模式。Seatunnel 這類工具給人的第一印象往往是“數(shù)據(jù)集成平臺”但它同樣可以只作為命令行任務(wù)運行啟動時讀取配置執(zhí)行完同步后進(jìn)程退出或者在一個常駐服務(wù)里按調(diào)度周期執(zhí)行 job。對大量“周期增量同步”的需求來說這遠(yuǎn)比維護(hù)一套常駐采集集群合適。第三種純輪詢或定時腳本。通過記錄源表更新時間戳或自增主鍵來抓增量。本質(zhì)上不是標(biāo)準(zhǔn)意義上的 CDC因為它讀不到被刪除的行但在某些無法開放日志權(quán)限的數(shù)據(jù)庫場景里這是最現(xiàn)實的手段。后面講達(dá)夢、人大金倉適配時會再提到它。2.3 什么情況才真正適合輕量級判斷該不該走輕量路線不要憑感覺可以先回答下面幾個問題數(shù)據(jù)量級單表日增百萬級以下還是千萬級以上延遲要求目標(biāo)是秒級延遲還是分鐘級甚至小時級容忍度下游復(fù)雜度只需要把變更落到另一張表還是需要做復(fù)雜窗口聚合、多流 join運維資源團(tuán)隊有沒有專職實時計算開發(fā)出問題時是否有人能在半小時內(nèi)定位如果答案偏向“日增可控、延遲要求不極端、下游是庫到庫同步”那輕量級方案通常完全夠用而且恢復(fù)起來比大集群快得多。真正不適合輕量級的場景也有比如需要支撐實時大屏的秒級指標(biāo)、需要跨多源做實時寬表 join、單表日變更量過千萬并伴隨超大事務(wù)。這類需求還是老老實實走集群化路線別為了省事把核心業(yè)務(wù)放到單機(jī)上賭運氣。3. 實測下來比較順手的幾套輕量級 CDC 與流處理組合3.1 Debezium Embedded Engine適合“寄生”在業(yè)務(wù)進(jìn)程里的采集方案我對 Debezium 嵌入式引擎的評價是如果你能接受 Java它是目前把“資源占用”壓到最低的成熟方案。它不需要獨立部署而是作為一個庫和你的業(yè)務(wù)應(yīng)用共存。一個最小化的思路大概是這樣通過DebeziumEngine構(gòu)建一個變更消費者傳入 MySQL 連接信息和需要監(jiān)聽的表在回調(diào)里把每一條SourceRecord轉(zhuǎn)換為目標(biāo)結(jié)構(gòu)再交給后續(xù)處理。啟動引擎后它會在內(nèi)部完成一致性快照和增量監(jiān)聽兩個階段。我把一個簡化骨架寫在這里幫助理解DebeziumEngineChangeEventString, String engine DebeziumEngine.create(ChangeEventFormat.of(Connect.class)) .using(props) // 包含連接信息、表白名單、offset存儲配置等 .notifying(record - { // record.value() 里可以拿到 before/after 結(jié)構(gòu) // 在這里做類型轉(zhuǎn)換、過濾然后寫到目標(biāo)端 }) .build(); // 建議用獨立線程啟動避免阻塞業(yè)務(wù)主流程 CompletableFuture.runAsync(engine);使用嵌入式方案時有幾個細(xì)節(jié)必須提前想明白引擎運行在業(yè)務(wù)進(jìn)程里如果業(yè)務(wù) JVM 因為 Full GC 停頓或重啟同步任務(wù)會跟著受影響。所以它適合作為后臺輔助任務(wù)不適合承載那種需要專門 SLA 的實時管道。offset 存儲需要顯式配置比如寫到本地文件或數(shù)據(jù)庫表否則重啟后會從頭開始或重復(fù)消費。下游寫入必須做冪等。至少要用目標(biāo)表主鍵做覆蓋更新避免重復(fù)事件造成臟數(shù)據(jù)。3.2 Seatunnel 本地模式庫到庫同步里的“輕騎兵”遇到“源庫到目標(biāo)庫搬運、不要常駐大集群”的需求我最近使用最多的是 Seatunnel 的本地運行模式。它的任務(wù)通常被定義成一個配置文件包含 source、transform、sink 三段。source 負(fù)責(zé)指定從哪里讀比如 MySQL 表或 JDBC 查詢transform 負(fù)責(zé)做字段映射或簡單清洗sink 指定目標(biāo)庫連接和寫入模式。以本地模式執(zhí)行時任務(wù)跑完進(jìn)程就退出也可以由調(diào)度系統(tǒng)按固定間隔拉起。對于真正的 CDC 增量同步場景Seatunnel 也支持從 binlog 或日志接口讀取變更但不同小版本的配置字段和連接器名稱會有差異所以我建議在搭建鏈路時先在測試環(huán)境打一個小版本快照確認(rèn)配置項再上生產(chǎn)。它吸引我的一點是任務(wù)終止后不會像常駐任務(wù)那樣留下一個“不知道狀態(tài)對不對”的進(jìn)程你可以隨時重新執(zhí)行從保存的位點恢復(fù)。需要提醒的是本地模式依然會占用運行節(jié)點的 CPU 和內(nèi)存。如果源表變更量很大又要求分鐘級同步建議給它配一個獨立的小規(guī)格實例不要和線上業(yè)務(wù)服務(wù)混部。否則一次大事務(wù)解析就可能把業(yè)務(wù) CPU 打滿。3.3 Flink CDC Local 模式只適合少數(shù)需要狀態(tài)計算的場景很多人問Flink CDC 能不能本地單機(jī)跑能但我不太建議為了單純同步去這么干。Flink 體系的真正價值在狀態(tài)管理和流式計算能力比如用窗口統(tǒng)計五分鐘內(nèi)的訂單量、把訂單流和商品流做實時 join。如果你的需求只是把 MySQL 的幾張表原樣搬到 PostgreSQL用 Flink 屬于拿大炮打蚊子部署、checkpoint、savepoint、資源隔離的成本比功能收益高得多。我會推薦使用 Flink CDC 的典型場景是同步進(jìn)來的數(shù)據(jù)不是直接入庫而是需要先清洗、關(guān)聯(lián)、聚合形成實時指標(biāo)后再寫下游。這個時候再考慮 Flink 的單機(jī)或集群模式才有意義。否則直接用嵌入式 Debezium 或者 Seatunnel 會更省心。3.4 輕量流處理側(cè)從流數(shù)據(jù)庫到單節(jié)點事件流在 CDC 事件落地之后另一個經(jīng)常被討論的問題是下游怎么對事件流做低延遲處理如果不想引入完整 Flink 集群可以關(guān)注兩類輕方案一類是支持單機(jī)部署的流數(shù)據(jù)庫比如 RisingWave。它能直接用 SQL 定義物化視圖消費來自 Kafka、PostgreSQL、MySQL 等源的事件流計算邏輯寫在標(biāo)準(zhǔn) SQL 里運維負(fù)擔(dān)比 Flink 小不少。單機(jī)跑一些中小規(guī)模實時指標(biāo)完全夠用。另一類是當(dāng)事件已經(jīng)進(jìn)到單一節(jié)點 Kafka 后用輕量流處理引擎做過濾和轉(zhuǎn)換比如 ksqlDB。它的部署形態(tài)相對簡單SQL 表達(dá)力也不錯適合“入 Kafka 后再洗一遍”的管道而不是從零開始設(shè)計一個流平臺。我做個簡單對比表格方便你快速判斷組合常駐資源外部依賴最適場景Debezium Embedded Engine 自定義代碼1 個 JVM 內(nèi)嵌源庫、offset 狀態(tài)存儲業(yè)務(wù)代碼后臺同步緩存/搜索索引更新Seatunnel 本地模式 調(diào)度任務(wù)結(jié)束進(jìn)程退出源庫、目標(biāo)庫庫到庫周期/增量同步批量數(shù)據(jù)搬運Flink CDC Local至少 1 個常駐 JVMcheckpoint 存儲需要狀態(tài)/窗口計算的實時邏輯單機(jī) Kafka ksqlDB / RisingWave2-3 個進(jìn)程消息隊列事件過濾、輕量流式計算、實時物化視圖4. 當(dāng)源庫換到達(dá)夢、人大金倉這類環(huán)境適配思路也跟著變4.1 現(xiàn)實環(huán)境比開源生態(tài)文檔殘酷得多近兩年企業(yè)內(nèi)部做數(shù)據(jù)庫替換的情況越來越多我接到過不少“Seatunnel 接達(dá)夢 CDC”“Kingbase 做增量同步”的咨詢。這類需求最大的特點不是技術(shù)本身有多難而是參考資料少、踩坑經(jīng)驗基本靠群里口口相傳。MySQL、PostgreSQL 的開源生態(tài)很成熟社區(qū)文檔、Issue、示例遍地都是。但到了達(dá)夢、人大金倉這些環(huán)境你會發(fā)現(xiàn)很多通用工具并沒有官方級別的 connector 支持。遇到這種情況第一步不是直接找工具鏈而是先搞清楚三件事這套數(shù)據(jù)庫的日志/變更捕獲接口是否對外開放文檔怎么描述它是否提供兼容模式比如某些產(chǎn)品線為了遷移便利支持兼容 Oracle 或 PostgreSQL 的日志接口這意味著你有可能復(fù)用對應(yīng)生態(tài)的解析工具。當(dāng)前賬號有沒有讀取日志或建立邏輯復(fù)制所需的權(quán)限把這三件事確認(rèn)完再決定技術(shù)路線能省掉后面大量無頭蒼蠅式排查。4.2 Seatunnel 接達(dá)夢這類場景的常用落地做法我沒有辦法在這里寫出一個放之四海皆準(zhǔn)的配置因為不同達(dá)夢版本、不同表結(jié)構(gòu)、不同權(quán)限配置都會影響最終寫法。但我可以分享一條我實測過多次、相對穩(wěn)妥的路線。如果目標(biāo)業(yè)務(wù)對實時性要求不高允許幾分鐘甚至更長延遲最穩(wěn)的組合是“JDBC 增量查詢 定時調(diào)度 位點記錄”。思路是表里如果有自增主鍵或最后更新時間字段把它們作為增量游標(biāo)每次任務(wù)啟動時從狀態(tài)表讀出上一次同步到的位置執(zhí)行查詢只取增量部分寫入目標(biāo)端后更新狀態(tài)表。這種做法的缺點是讀不到物理刪除業(yè)務(wù)上如果有刪除操作需要同步就得配合軟刪除標(biāo)記或者在源庫端建立刪除日志表由業(yè)務(wù)方在刪除時寫入一條標(biāo)記記錄。它雖然不優(yōu)雅但勝在可控、不依賴廠商日志格式的穩(wěn)定性。如果確實需要更實時、能感知刪除的日志級同步就要回到日志接口這條路。以我目前的經(jīng)驗這種場景非常依賴源庫版本與工具版本的匹配情況建議先用生產(chǎn)同版本搭建一個測試實例把日志歸檔開關(guān)打開再用你選中的工具鏈做一輪模擬寫入和刪除的驗證。不要直接在生產(chǎn)庫上試錯。4.3 人大金倉 Kingbase 的兼容性紅利與限制Kingbase 環(huán)境里我也被問到過很多次“能不能像 PostgreSQL 一樣做邏輯復(fù)制”。答案是看具體版本和授權(quán)形態(tài)。部分 KingbaseES 版本為了兼容 PostgreSQL 生態(tài)會提供類似邏輯解析的能力這讓 Debezium 的 PostgreSQL 連接器存在一定的復(fù)用可能。但從開源工具的角度看不能假設(shè)所有版本都開放了同樣的接口。部署前至少要做兩個檢查數(shù)據(jù)庫參數(shù)里有沒有開放邏輯復(fù)制所需配置以及賬號是否具備相應(yīng)角色權(quán)限。如果這兩項都滿足可以嘗試走 PostgreSQL 兼容鏈路如果有限制就退回 JDBC 增量輪詢方案。我的原則是在國產(chǎn)數(shù)據(jù)庫這類資料稀缺的環(huán)境里能用標(biāo)準(zhǔn) SQL 解決的問題就不要賭私有日志格式的穩(wěn)定性。你永遠(yuǎn)不希望同步任務(wù)在凌晨兩點掛掉然后發(fā)現(xiàn)沒人知道這個版本的日志解析行為。4.4 每次適配前先寫一份“環(huán)境確認(rèn)單”從踩過的坑里提煉出來的小建議做國產(chǎn)數(shù)據(jù)庫 CDC 適配之前先整理一份環(huán)境確認(rèn)單包含數(shù)據(jù)庫產(chǎn)品名、版本號、部署方式、日志相關(guān)開關(guān)、賬號權(quán)限清單、目標(biāo)端版本。不同人說的“達(dá)夢”可能完全是兩個形態(tài)沒有這份單子討論問題就是在猜謎。5. 位點、DDL、大事務(wù)輕量方案最常見的三個翻車現(xiàn)場5.1 增量位點管理是輕量方案的第一道生死線“輕量”帶來的最大錯覺是組件少了穩(wěn)定性自動就高了。實際上恰恰相反組件少了原本由框架幫你兜底的工作現(xiàn)在要自己負(fù)責(zé)了。最典型的就是增量位點管理。我見過不止一次這樣的場景一個人用 Debezium 嵌入式引擎寫了同步任務(wù)重啟后發(fā)現(xiàn)目標(biāo)庫多了一堆重復(fù)數(shù)據(jù)原因就是 offset 存儲配置沒落到持久化存儲上進(jìn)程重啟后只能從舊位點重新讀。還有一個相反的問題業(yè)務(wù)處理完但 offset 提交太早處理過程中崩潰重啟后位點已經(jīng)越過崩潰時的數(shù)據(jù)部分記錄永久丟失。這里最重要的是想清楚三件事offset 存哪里什么時候提交重啟后從哪里恢復(fù)不同框架的機(jī)制不完全一樣但只要你把這三個問題寫進(jìn)設(shè)計文檔把提交動作和數(shù)據(jù)處理動作的關(guān)系理順就不會出現(xiàn)最糟糕的“丟數(shù)據(jù)”或“爆量重復(fù)”。目標(biāo)端的寫入也應(yīng)盡量冪等。最通用的方法是用目標(biāo)表主鍵做 upsert這樣即使重啟導(dǎo)致少量重復(fù)消費結(jié)果依然正確。5.2 DDL 變更永遠(yuǎn)會打斷天真的同步邏輯另一個高頻事故是源表執(zhí)行了 DDL。比如業(yè)務(wù)給訂單表加了一個字段帶默認(rèn)值。如果下游表結(jié)構(gòu)沒有同步變更很多同步工具會直接報錯更隱蔽的是有些工具按列位置而不是按列名映射加了字段后整行數(shù)據(jù)的值全部錯位寫進(jìn)了錯誤的目標(biāo)列。這類問題的盤查鏈路通常是這樣先看同步任務(wù)日志里有沒有 schema 相關(guān)報錯再看任務(wù)內(nèi)部維護(hù)的 schema history 是不是和源庫結(jié)構(gòu)一致最后對比源表和目標(biāo)表的字段順序。很多工具會把 schema history 單獨記錄在一個狀態(tài)存儲里如果這個存儲被清理過就可能出現(xiàn)新舊結(jié)構(gòu)不一致。我目前的處理策略是源表結(jié)構(gòu)變更必須走變更流程先暫停同步任務(wù)、更新目標(biāo)表結(jié)構(gòu)、確認(rèn)字段映射、再恢復(fù)任務(wù)。依賴工具自動處理 DDL 的方案不是不能試但至少要在測試環(huán)境完整演練一遍而不是上了生產(chǎn)才去驗證。5.3 一個大事務(wù)就能讓同步延遲從秒級拖到半小時還有一種情況很讓人頭疼日常運行一切正常某天延遲突然飆升。排查到最后往往不是工具壞了而是源庫執(zhí)行了一個超大事務(wù)。舉個例子某項目的一次夜間批量腳本更新了三十萬行數(shù)據(jù)。因為 binlog 日志里這個事務(wù)是一個整體CDC 任務(wù)從日志中解析時必須把整個事務(wù)的事件按順序讀完并處理目標(biāo)端又是一個批次一個批次地提交處理這個超大事務(wù)期間后續(xù)所有變更全部堵在隊列里同步延遲瞬間從幾秒漲到幾十分鐘。等舊事務(wù)處理完延遲才慢慢回落。定位這類問題有個很實用的思路看到延遲突增不要只盯著消費端所在機(jī)器的 CPU 和流量先回到源庫查這段時間有沒有大事務(wù)、慢 SQL、大批量更新。找到責(zé)任事務(wù)后再決定是否需要對源庫側(cè)的大事務(wù)操作做拆分或者讓目標(biāo)端監(jiān)控在出現(xiàn)超大事務(wù)時自動調(diào)整批次大小。輕量方案下沒有調(diào)度中心幫你自動伸縮只能靠事前的任務(wù)設(shè)計和事后的監(jiān)控報警把影響控制在范圍內(nèi)。5.4 運維再輕也得保留最少四個監(jiān)控指標(biāo)輕量方案不需要完整可觀測平臺但至少保留下面幾個指標(biāo)否則出問題時會連方向都沒有監(jiān)控指標(biāo)來源建議關(guān)注點位點延遲源庫日志/復(fù)制位點與當(dāng)前消費位點差值延遲突然變大優(yōu)先查大事務(wù)和網(wǎng)絡(luò)消費失敗次數(shù)采集任務(wù)日志持續(xù)增長往往代表解析或下游寫入異常schema history 變化次數(shù)同步引擎狀態(tài)存儲排查 DDL 導(dǎo)致的問題時非常有用目標(biāo)端寫入耗時/成功率目標(biāo)庫連接池與寫入日志目標(biāo)庫慢查詢會反向拖垮同步任務(wù)這些指標(biāo)可以用很輕的方式實現(xiàn)寫日志、暴露 Prometheus 端點、或者定時發(fā)到內(nèi)部監(jiān)控系統(tǒng)不需要做一個大而全的平臺。但如果沒有它們位點偏移、事務(wù)堆積這類問題基本只能等業(yè)務(wù)方先發(fā)現(xiàn)那運維就被動了。6. 選型檢驗清單和一點長期有用的習(xí)慣6.1 把決策流程壓縮成三段自問我最后做決策時會走一個很簡化的流程分享出來當(dāng)作可直接參考的清單。第一問需要的是“庫到庫同步”還是“實時計算”“實時計算”是消耗資源的大戶。如果只是表結(jié)構(gòu)搬運、字段映射、格式變更那就不要輕易引入流計算引擎。第二問團(tuán)隊愿意常駐維護(hù)幾個進(jìn)程一個 Java 嵌入式引擎、一個單機(jī)任務(wù)進(jìn)程、還是一個單節(jié)點 Kafka把你能接受的常駐組件數(shù)量寫下來寫完之后你會發(fā)現(xiàn)很多“方案選項”會自動被排除。第三問源庫的日志接口和賬號權(quán)限是否可控如果不可控就不要強(qiáng)行追求日志級 CDC改用帶更新時間字段的增量輪詢方案?？煽啃圆灰欢ú钪攸c是邊界清晰不會在半夜收到“解析日志失敗”的告警?；谶@套自問我給出的粗略推薦是這樣的想在業(yè)務(wù)服務(wù)內(nèi)做后臺同步、更新緩存等優(yōu)先考慮 Debezium Embedded Engine需要庫到庫定時或周期同步優(yōu)先考慮 Seatunnel 本地模式加調(diào)度需要簡單流式過濾和物化視圖并且已有事件流入口可以評估 ksqlDB 或 RisingWave 之類的輕量流數(shù)據(jù)庫需要狀態(tài)窗口、復(fù)雜 join、實時指標(biāo)再上 Flink且別用“單機(jī)本地模式”自我安慰它仍然需要專業(yè)的運維約束源庫是非主流數(shù)據(jù)庫且資料極少優(yōu)先走 JDBC 增量輪詢加刪除標(biāo)記先把業(yè)務(wù)穩(wěn)定跑起來。6.2 長期有用的一項習(xí)慣是維護(hù)“表結(jié)構(gòu)基線”從這么多年的同步任務(wù)維護(hù)經(jīng)驗里如果要我選一個最值得長期堅持的習(xí)慣我會說為每個接入 CDC 的庫維護(hù)一份“表結(jié)構(gòu)基線”文檔。這份基線不需要多復(fù)雜包含每張表的源庫名稱、主鍵、需要的增量字段、目標(biāo)端連接信息、DDL 變更負(fù)責(zé)人就夠了。平時看起來不起眼但每次任務(wù)異常、每次新增同步表、每次數(shù)據(jù)庫版本升級它都能救場。很多工具本身也會記錄 schema history但你手頭那份文檔的價值在于它記錄的是你們業(yè)務(wù)側(cè)約定的語義不只是工具內(nèi)部的元數(shù)據(jù)。做輕量級方案這幾年我越來越傾向于一個觀點輕量不是把組件做得更少那么簡單而是把每個組件的作用、邊界、恢復(fù)手段都吃透讓系統(tǒng)的復(fù)雜度完全暴露在你能管理的范圍內(nèi)。數(shù)據(jù)庫日志級 CDC 很強(qiáng)大但如果你解釋不了它的位點文件里每一行含義那它就是不合適的JDBC 輪詢很土但如果它在你需要的時間窗口內(nèi)能穩(wěn)定完成任務(wù)那它就是好方案。希望這輪盤點能幫你少走一些我已經(jīng)走過的彎路。