摘要：本文整理自大健云倉(cāng)基礎(chǔ)架構(gòu)負(fù)責(zé)人、Flink CDC Maintainer 龔中強(qiáng)在 5 月 21 日 Flink CDC Meetup 的演講。主要內(nèi)容包括：

• 引入 Flink CDC 的背景
• 現(xiàn)今內(nèi)部落地的業(yè)務(wù)場(chǎng)景
• 未來(lái)內(nèi)部推廣及平臺(tái)化建設(shè)
• 社區(qū)合作

一、引入 Flink CDC 的背景

公司引入 CDC 技術(shù)，主要基于以下四個(gè)角色的需求：

• 物流科學(xué)家：需要庫(kù)存、銷(xiāo)售訂單、物流賬單等數(shù)據(jù)用于做分析。
• 開(kāi)發(fā)：需要同步其他業(yè)務(wù)系統(tǒng)的基本信息。
• 財(cái)務(wù)：希望財(cái)務(wù)數(shù)據(jù)能夠?qū)崟r(shí)傳送到財(cái)務(wù)系統(tǒng)，而不是月結(jié)前才能看到。
• 老板：需要數(shù)據(jù)大屏，通過(guò)大屏查看公司的業(yè)務(wù)和運(yùn)營(yíng)情況。

CDC 是數(shù)據(jù)捕獲變更的技術(shù)。廣義上來(lái)說(shuō)，但凡能夠捕獲數(shù)據(jù)變更的技術(shù)，都能被稱(chēng)為 CDC。但通常我們說(shuō)的 CDC 技術(shù)主要面向數(shù)據(jù)庫(kù)的變更。

CDC 的實(shí)現(xiàn)方式主要有兩種，分別是基于查詢和基于日志：

• 基于查詢：查詢后插入、更新到數(shù)據(jù)庫(kù)即可，無(wú)須數(shù)據(jù)庫(kù)的特殊配置以及賬號(hào)權(quán)限。它的實(shí)時(shí)性基于查詢頻率決定，只能通過(guò)提高查詢頻率來(lái)保證實(shí)時(shí)性，而這必然會(huì)對(duì) DB 造成巨大壓力。此外，因?yàn)槭腔诓樵儯运鼰o(wú)法捕獲兩次查詢之間數(shù)據(jù)的變更記錄，也就無(wú)法保證數(shù)據(jù)的一致性。
• 基于日志：通過(guò)實(shí)時(shí)消費(fèi)數(shù)據(jù)的變更日志實(shí)現(xiàn)，因此實(shí)時(shí)性很高。而且不會(huì)對(duì) DB 造成很大的影響，也能夠保證數(shù)據(jù)的一致性，因?yàn)閿?shù)據(jù)庫(kù)會(huì)將所有數(shù)據(jù)的變動(dòng)記錄在變更日志中。通過(guò)對(duì)日志的消費(fèi)，即可明確知道數(shù)據(jù)的變化過(guò)程。它的缺點(diǎn)是實(shí)現(xiàn)相對(duì)復(fù)雜，因?yàn)椴煌瑪?shù)據(jù)庫(kù)的變動(dòng)日志實(shí)現(xiàn)不一樣，格式、開(kāi)啟方式以及特殊權(quán)限都不一樣，需要針對(duì)每一種數(shù)據(jù)庫(kù)做相應(yīng)的適配開(kāi)發(fā)。

正如 Flink 的宣言 “實(shí)時(shí)即未來(lái)”，在如今的大背景下，實(shí)時(shí)性是亟待解決的重要問(wèn)題。因此，我們將主流 CDC 基于日志的技術(shù)做了對(duì)比，如上圖所示：

• 數(shù)據(jù)源：Flink CDC 除了對(duì)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)做到了很好的支持外，對(duì)文檔型、NewSQL（TiDB、OceanBase） 等當(dāng)下流行的數(shù)據(jù)庫(kù)都能夠支持；Debezium 對(duì)數(shù)據(jù)庫(kù)的支持相對(duì)沒(méi)有那么廣泛，但是對(duì)主流的關(guān)系型數(shù)據(jù)庫(kù)都做到了很好的支撐；Canal 和 OGG 只支持單一的數(shù)據(jù)源。
• 斷點(diǎn)續(xù)傳：四種技術(shù)都能夠支持。
• 同步模式：除了 Canal 只支持增量，其他技術(shù)均支持全量 + 增量的方式。而全量 + 增量的方式意味著第一次上線時(shí)全量到增量的切換過(guò)程全部可以通過(guò) CDC 技術(shù)實(shí)現(xiàn)，無(wú)須人為地通過(guò)全量的任務(wù)加上增量的 job 去實(shí)現(xiàn)全量 + 增量數(shù)據(jù)的讀取。
• 活躍度：Flink CDC 擁有非?；钴S的社區(qū)，資料豐富，官方也提供了詳盡的教程以及快速上手教程；Debezium 社區(qū)也相當(dāng)活躍，但資料大多是英文的；Canal 的用戶基數(shù)特別大，資料也相對(duì)較多，但社區(qū)活躍度一般；OGG 是 Oracle 的大數(shù)據(jù)套件，需要付費(fèi)，只有官方資料。
• 開(kāi)發(fā)難度：Flink CDC 依靠 Flink SQL 和 Flink DataStream 兩種開(kāi)發(fā)模式，尤其是 Flink SQL，通過(guò)非常簡(jiǎn)單的 SQL 即可完成數(shù)據(jù)同步任務(wù)的開(kāi)發(fā)，開(kāi)發(fā)上手尤為簡(jiǎn)單；Debezium 需要自己解析采集到的數(shù)據(jù)變更日志進(jìn)行單獨(dú)處理，Canal 亦是如此。
• 運(yùn)行環(huán)境依賴：Flink CDC 是以 Flink 作為引擎，Debezium通常是將 Kafka connector 作為運(yùn)行容器；而 Canal 和 OGG 都是單獨(dú)運(yùn)行。
• 下游豐富程度：Flink CDC 依靠 Flink 非?；钴S的周邊以及豐富的生態(tài)，能夠打通豐富的下游，對(duì)普通的關(guān)系型數(shù)據(jù)庫(kù)以及大數(shù)據(jù)存儲(chǔ)引擎 Iceberg、ClickHouse、Hudi 等都做了很好的支持；Debezium 有 Kafka JDBC connector， 支持 MySQL 、Oracle 、SqlServer；Canal 只能直接消費(fèi)數(shù)據(jù)或?qū)⑵漭敵龅?MQ 中進(jìn)行下游的消費(fèi)；OGG 因?yàn)槭枪俜教准?，下游豐富程度不佳。

二、現(xiàn)今內(nèi)部落地的業(yè)務(wù)場(chǎng)景

• 2018 年之前，大健云倉(cāng)數(shù)據(jù)同步的方式為：通過(guò)多數(shù)據(jù)應(yīng)用定時(shí)同步系統(tǒng)之間的數(shù)據(jù)。
• 2020 年之后，隨著跨境業(yè)務(wù)的飛速發(fā)展，多數(shù)據(jù)源應(yīng)用經(jīng)常打滿 DB 影響在線應(yīng)用，同時(shí)定時(shí)任務(wù)的執(zhí)行順序管理混亂。
• 因此， 2021 年我們開(kāi)始調(diào)研選型 CDC 技術(shù)，搭建了小型試驗(yàn)場(chǎng)景，進(jìn)行小規(guī)模的試驗(yàn)。
• 2022 年，上線了基于 Flink CDC 實(shí)現(xiàn)的 LDSS 系統(tǒng)庫(kù)存場(chǎng)景同步功能。
• 未來(lái)，我們希望依托 Flink CDC 打造數(shù)據(jù)同步平臺(tái)，通過(guò)界面的開(kāi)發(fā)和配置完成同步任務(wù)的開(kāi)發(fā)、測(cè)試和上線，能夠全程在線管理同步任務(wù)的整個(gè)生命周期。

LDSS 庫(kù)存管理的業(yè)務(wù)場(chǎng)景主要有以下四種：

• 倉(cāng)儲(chǔ)部門(mén)：要求倉(cāng)庫(kù)的庫(kù)存容量和商品品類(lèi)分布合理，庫(kù)存容量方面，需要留一些 buffer 以防突如其來(lái)的入庫(kù)單導(dǎo)致爆倉(cāng)；商品品類(lèi)方面，季節(jié)性的商品庫(kù)存分配不合理導(dǎo)致熱點(diǎn)問(wèn)題，這必將給倉(cāng)庫(kù)的管理帶來(lái)巨大挑戰(zhàn)。
• 平臺(tái)客戶：希望訂單處理及時(shí)，貨物能夠快速、精準(zhǔn)地交到客戶手上。
• 物流部門(mén)：希望能夠提升物流效率，降低物流成本，高效利用有限的運(yùn)力。
• 決策部門(mén)：希望 LDSS 系統(tǒng)能夠?qū)υ诤螘r(shí)何地新建倉(cāng)庫(kù)提供科學(xué)的建議。

上圖為 LDSS 庫(kù)存管理分單場(chǎng)景架構(gòu)圖。

首先，通過(guò)多數(shù)據(jù)源同步的應(yīng)用向下拉取倉(cāng)儲(chǔ)系統(tǒng)、平臺(tái)系統(tǒng)以及內(nèi)部 ERP 系統(tǒng)數(shù)據(jù)，將所需數(shù)據(jù)抽取到 LDSS 系統(tǒng)的數(shù)據(jù)庫(kù)中，以支撐 LDSS 系統(tǒng)訂單、庫(kù)存、物流三大模塊的業(yè)務(wù)功能。

其次，需要產(chǎn)品信息、訂單信息以及倉(cāng)庫(kù)信息才能進(jìn)行有效的分單決策。多數(shù)據(jù)源定時(shí)同步任務(wù)基于 JDBC 查詢，通過(guò)時(shí)間做篩選，同步變更的數(shù)據(jù)到 LDSS 系統(tǒng)中。LDSS 系統(tǒng)基于這些數(shù)據(jù)做分單決策，以獲得最優(yōu)解。

定時(shí)任務(wù)同步的代碼，首先需要定義定時(shí)任務(wù)、定義定時(shí)任務(wù)的類(lèi)、執(zhí)行方法以及執(zhí)行間隔。

上圖左側(cè)為定時(shí)任務(wù)的定義，右側(cè)是定時(shí)任務(wù)的邏輯開(kāi)發(fā)。首先，打開(kāi) Oracle 數(shù)據(jù)庫(kù)進(jìn)行查詢，然后 upsert 到 MySQL 數(shù)據(jù)庫(kù)，即完成了定時(shí)任務(wù)的開(kāi)發(fā)。此處以接近原生 JDBC 的查詢方式，將數(shù)據(jù)依次塞到對(duì)應(yīng)的數(shù)據(jù)庫(kù)表中，開(kāi)發(fā)邏輯十分繁瑣，也容易出現(xiàn) bug。

因此，我們基于 Flink CDC 對(duì)其進(jìn)行了改造。

上圖為基于 Flink CDC 實(shí)現(xiàn)的實(shí)時(shí)同步場(chǎng)景，唯一的變化是將此前的多數(shù)據(jù)源同步應(yīng)用程序換成了 Flink CDC 。

首先，通過(guò) SqlServer CDC、MySQL CDC、Oracle CDC 分別連接抽取對(duì)應(yīng)倉(cāng)儲(chǔ)平臺(tái)、 ERP 系統(tǒng)數(shù)據(jù)庫(kù)的表數(shù)據(jù)，然后通過(guò) Flink 提供的 JDBC connector 寫(xiě)入到 LDSS 系統(tǒng)的 MySQL 數(shù)據(jù)庫(kù)中。能夠通過(guò) SqlServer CDC、MySQL CDC、Oracle CDC 將異構(gòu)數(shù)據(jù)源轉(zhuǎn)化為統(tǒng)一的 Flink 內(nèi)部類(lèi)型，再往下游寫(xiě)。

此架構(gòu)相比于之前的架構(gòu)，對(duì)業(yè)務(wù)系統(tǒng)沒(méi)有侵入性，而且實(shí)現(xiàn)較為簡(jiǎn)單。

我們引入了 MySQL CDC 和 SqlServer CDC 分別連接 B2B 平臺(tái)的 MySQL 數(shù)據(jù)庫(kù)以及倉(cāng)儲(chǔ)系統(tǒng)的 SqlServer 數(shù)據(jù)庫(kù)，然后將抽取到的數(shù)據(jù)通過(guò) JDBC Connector 寫(xiě)入到 LDSS 系統(tǒng)的 MySQL 數(shù)據(jù)庫(kù)。

通過(guò)以上改造，得益于 Flink CDC 賦予其實(shí)時(shí)的能力，不需要管理繁雜的定時(shí)任務(wù)。

基于 Flink CDC 同步代碼的實(shí)現(xiàn)分為以下三步：

1. 第一步，定義源表 —— 需要同步的表；
2. 第二步，定義目標(biāo)表 —— 需要寫(xiě)入數(shù)據(jù)的目標(biāo)表；
3. 第三步，通過(guò) insert select 語(yǔ)句，即可完成 CDC 同步任務(wù)的開(kāi)發(fā)。

上述開(kāi)發(fā)模式非常簡(jiǎn)單，邏輯清晰。此外，依托 Flink CDC 的同步任務(wù)和 Flink 架構(gòu)，還獲得了失敗重試、分布式、高可用、全量增量一致性切換等特性。

三、未來(lái)內(nèi)部推廣及平臺(tái)化建設(shè)

上圖為平臺(tái)架構(gòu)圖。

左側(cè) source 是由 Flink CDC + Flink 提供的源端，能夠通過(guò)豐富的源端抽取數(shù)據(jù)，通過(guò)數(shù)據(jù)平臺(tái)上的開(kāi)發(fā)寫(xiě)入到目標(biāo)端。目標(biāo)端又依托于 Flink 的強(qiáng)大生態(tài)，能夠很好地支撐數(shù)據(jù)湖、關(guān)系型數(shù)據(jù)庫(kù)、MQ 等。

Flink 目前有兩種運(yùn)行方式，一種是國(guó)內(nèi)比較流行的 Flink on Yarn，另一種是 Flink on Kubernets。中間部分的數(shù)據(jù)平臺(tái)向下管理 Flink 集群，以向上支撐 SQL 在線開(kāi)發(fā)、任務(wù)開(kāi)發(fā)、血緣管理、任務(wù)提交、在線 Notebook 開(kāi)發(fā)、權(quán)限和配置以及對(duì)任務(wù)性能的監(jiān)控和告警，同時(shí)也能夠?qū)?shù)據(jù)源做到很好的管理。

數(shù)據(jù)同步的需求在公司內(nèi)部特別旺盛，需要通過(guò)平臺(tái)來(lái)提高開(kāi)發(fā)效率，加快交付速度。而且平臺(tái)化之后，可以統(tǒng)一公司內(nèi)部的數(shù)據(jù)同步技術(shù)，收攏同步技術(shù)棧，減少維護(hù)成本。

平臺(tái)化的目標(biāo)如下：

1. 能夠很好地管理數(shù)據(jù)源、表等元信息；
2. 任務(wù)的整個(gè)生命周期都可以在平臺(tái)上完成；
3. 實(shí)現(xiàn)任務(wù)的性能觀測(cè)以及告警；
4. 簡(jiǎn)化開(kāi)發(fā)，快速上手，業(yè)務(wù)開(kāi)發(fā)人員經(jīng)過(guò)簡(jiǎn)單培訓(xùn)即可上手開(kāi)發(fā)同步任務(wù)。

平臺(tái)化能帶來(lái)以下三個(gè)方面的收益：

1. 收攏數(shù)據(jù)同步任務(wù)，統(tǒng)一來(lái)管理；
2. 平臺(tái)管理維護(hù)同步任務(wù)的全生命周期；
3. 專(zhuān)門(mén)的團(tuán)隊(duì)負(fù)責(zé)，團(tuán)隊(duì)能夠?qū)Ｗ⑶把氐臄?shù)據(jù)集成技術(shù)。

有了平臺(tái)之后，即可快速落地應(yīng)用更多的業(yè)務(wù)場(chǎng)景。

• 實(shí)時(shí)數(shù)倉(cāng)：希望通過(guò) Flink CDC 以支持更多實(shí)時(shí)數(shù)倉(cāng)的業(yè)務(wù)場(chǎng)景，借助 Flink 強(qiáng)大的計(jì)算能力做一些數(shù)據(jù)庫(kù)的物化視圖。將計(jì)算從 DB 里解脫出來(lái)，通過(guò) Flink 的外部計(jì)算再重新寫(xiě)回?cái)?shù)據(jù)庫(kù)，以加速平臺(tái)應(yīng)用的報(bào)表、統(tǒng)計(jì)、分析等實(shí)時(shí)應(yīng)用場(chǎng)景。
• 實(shí)時(shí)應(yīng)用：Flink CDC 能夠從 DB 層捕獲變更，因此可以通過(guò) Flink CDC 實(shí)時(shí)更新搜索引擎中的內(nèi)容，實(shí)時(shí)向財(cái)務(wù)系統(tǒng)推送財(cái)務(wù)和核算數(shù)據(jù)。因?yàn)榇蟛糠重?cái)務(wù)系統(tǒng)的數(shù)據(jù)都需要業(yè)務(wù)系統(tǒng)通過(guò)跑定時(shí)任務(wù)以及經(jīng)過(guò)大量關(guān)聯(lián)、聚合、分組等操作才能計(jì)算出來(lái)，再推送到財(cái)務(wù)系統(tǒng)中。而借助 Flink CDC 強(qiáng)大的數(shù)據(jù)捕獲能力，再加上 Flink 的計(jì)算能力，將這些數(shù)據(jù)實(shí)時(shí)地推送到核算系統(tǒng)和財(cái)務(wù)系統(tǒng)，就能夠及時(shí)發(fā)現(xiàn)業(yè)務(wù)的問(wèn)題，減少公司的損失。
• 緩存：通過(guò) Flink CDC，能夠構(gòu)建一個(gè)脫離于傳統(tǒng)的應(yīng)用之外的實(shí)時(shí)緩存，對(duì)于在線應(yīng)用的性能有極大的提升。

有了平臺(tái)的助力，相信 Flink CDC 能夠在公司內(nèi)部更好地釋放它的能力。

上圖展示了 SqlServer CDC 的原理。

社區(qū)同學(xué)使用了當(dāng)前版本的 SqlServer CDC 后，主要反饋的問(wèn)題有以下三個(gè)：

1. 快照過(guò)程中鎖表：鎖表操作對(duì)于 DBA 和在線應(yīng)用都是不可忍受的， DBA 無(wú)法接受數(shù)據(jù)庫(kù)被夯住，同時(shí)也會(huì)影響在線應(yīng)用。
2. 快照過(guò)程中不能 checkpoint：不能 checkpoint 就意味著快照過(guò)程中一旦失敗，只能重新開(kāi)始跑快照過(guò)程，這對(duì)于大表非常不友好。
3. 快照過(guò)程只支持單并發(fā)：千萬(wàn)級(jí)、上億級(jí)的大表，在單并發(fā)的情況下需要同步十幾甚至幾十個(gè)小時(shí)，極大束縛了 SqlServer CDC 的應(yīng)用場(chǎng)景。

我們針對(duì)上述問(wèn)題做了實(shí)踐和改進(jìn)，參考社區(qū) 2.0 版本 MySQL CDC 并發(fā)無(wú)鎖算法的思想，對(duì) SqlServer CDC 進(jìn)行了優(yōu)化，最終實(shí)現(xiàn)了快照過(guò)程中無(wú)鎖，實(shí)現(xiàn)一致性快照；快照過(guò)程中支持 checkpoint ；快照過(guò)程中支持并發(fā)，加速快照過(guò)程。在大表同步的情況下，并發(fā)優(yōu)勢(shì)尤為明顯。

但是由于 2.2 版本社區(qū)將 MySQL 的并發(fā)無(wú)鎖思想抽象成了統(tǒng)一公共的框架，SqlServer CDC 需要重新適配這套通用框架后才能貢獻(xiàn)給社區(qū)。

提問(wèn)&解答

Q1需要開(kāi)啟 SqlServer 自己的 CDC 嗎？

是的，SqlServer CDC 的功能就是基于 SqlServer 數(shù)據(jù)庫(kù)自己的 CDC 特性實(shí)現(xiàn)的。

Q2物化視圖通過(guò)什么方式去刷新定時(shí)任務(wù)觸發(fā)器？

通過(guò) Flink CDC 將需要生成物化視圖的 SQL 放在 Flink 里運(yùn)行，通過(guò)原表的變動(dòng)觸發(fā)計(jì)算，然后同步到物化視圖表里。

Q3平臺(tái)化是怎么做的？

平臺(tái)化參考了社區(qū)眾多的開(kāi)源項(xiàng)目以及優(yōu)秀的開(kāi)源平臺(tái)，比如 StreamX、DLink 等優(yōu)秀的開(kāi)源項(xiàng)目。

Q4SqlServer CDC 在消費(fèi) transaction log 時(shí)有瓶頸嗎？

SqlServer 并沒(méi)有直接消費(fèi) log，其原理是 SqlServer capture process 去匹配 log 內(nèi)哪些表開(kāi)啟了 CDC ，然后將這些表從日志里撈到開(kāi)啟 CDC 表的變更數(shù)據(jù)，再轉(zhuǎn)插到 change table 里，最后通過(guò)開(kāi)啟 CDC 之后數(shù)據(jù)庫(kù)生成的 CDC query function 獲取到數(shù)據(jù)的變更。

Q5Flink CDC 高可用如何保障同步任務(wù)過(guò)多或密集處理方案？

Flink 的高可用依賴于 Flink 特性比如 checkpoint 等來(lái)保證。同步任務(wù)過(guò)多或處理方案密集的情況，建議使用多套 Flink 下游集群，然后根據(jù)同步的實(shí)時(shí)性區(qū)分對(duì)待，將任務(wù)發(fā)布到相應(yīng)的集群中。

Q6中間需要 Kafka 嗎？

取決于同步任務(wù)或數(shù)倉(cāng)架構(gòu)是否需要將中間數(shù)據(jù)做 Kafka 落地。

Q7一個(gè)數(shù)據(jù)庫(kù)中有多張表，可以放到一個(gè)任務(wù)里運(yùn)行嗎？

取決于開(kāi)發(fā)方式。如果是 SQL 的開(kāi)發(fā)方式，要實(shí)現(xiàn)一次性寫(xiě)多表只能通過(guò)多個(gè)任務(wù)。但 Flink CDC 提供了另外一種比較高階的開(kāi)發(fā)方式 DataStream ，可以將多表放到一個(gè)任務(wù)里運(yùn)行。

Q8Flink CDC 支持讀取 Oracle 從庫(kù)的日志嗎？

目前還無(wú)法實(shí)現(xiàn)。

Q9通過(guò) CDC 同步后兩個(gè)端的數(shù)據(jù)質(zhì)量如何監(jiān)控，如何比對(duì)？

目前只能通過(guò)定時(shí)抽樣來(lái)做數(shù)據(jù)質(zhì)量的檢查，數(shù)據(jù)質(zhì)量問(wèn)題一直是業(yè)內(nèi)比較棘手的問(wèn)題。

Q10大健云倉(cāng)用的什么調(diào)度系統(tǒng)？系統(tǒng)如何與 Flink CDC 集合？

使用 XXL Job 作為分布式的任務(wù)調(diào)度，CDC 沒(méi)有用到定時(shí)任務(wù)。

Q11如果采集增刪表，SqlServer CDC 需要重啟嗎？

SqlServer CDC 目前不支持動(dòng)態(tài)加表的功能。

Q12同步任務(wù)會(huì)影響系統(tǒng)性能嗎？

基于 CDC 做同步任務(wù)肯定會(huì)影響系統(tǒng)性能，尤其是快照過(guò)程對(duì)數(shù)據(jù)庫(kù)會(huì)有影響，進(jìn)而影響應(yīng)用系統(tǒng)。社區(qū)將來(lái)會(huì)做限流、對(duì)所有 connector 做并發(fā)無(wú)鎖的實(shí)現(xiàn)，都是為了擴(kuò)大 CDC 的應(yīng)用場(chǎng)景以及易用性。

Q13全量和增量的 savepoint 怎么處理？

（未通過(guò)并發(fā)無(wú)鎖框架實(shí)現(xiàn)的連接器）全量過(guò)程中不可以觸發(fā) savepoint，增量過(guò)程中如果需要停機(jī)發(fā)布，可通過(guò) savepoint 恢復(fù)任務(wù)。

Q14CDC 同步數(shù)據(jù)到 Kafka ，而 Kafka 里面存的是 Binlog ，如何保存歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)？

將 CDC 同步的數(shù)據(jù)全部 Sync 到 Kafka，保留的數(shù)據(jù)取決于 Kafka log 的清理策略，可以全部保留。

Q15CDC 會(huì)對(duì) Binlog 的日志操作類(lèi)型進(jìn)行過(guò)濾嗎？會(huì)影響效率嗎？

即使有過(guò)濾操作，對(duì)性能影響也不大。

Q16CDC 讀 MySQL 初始化快照階段，多個(gè)程序讀不同的表會(huì)有程序報(bào)錯(cuò)無(wú)法獲取鎖表的權(quán)限，這是什么原因？

建議先查看 MySQL CDC 是不是使用老的方式實(shí)現(xiàn)，可以嘗試新版本的并發(fā)無(wú)鎖實(shí)現(xiàn)。

Q17MySQL 上億大表全量和增量如何銜接？

建議閱讀雪盡老師在 2.0 的相關(guān)博客，非常簡(jiǎn)單清晰地介紹了并發(fā)無(wú)鎖如何實(shí)現(xiàn)一致性快照，完成全量和增量的切換。