簡(jiǎn)介：Flink CDC 2.0.0 版本于 8 月 10 日正式發(fā)布，點(diǎn)擊了解詳情～ 本文由社區(qū)志愿者陳政羽整理，內(nèi)容來(lái)源自阿里巴巴高級(jí)開(kāi)發(fā)工程師徐榜江 (雪盡) 7 月 10 日在北京站 Flink Meetup 分享的《詳解 Flink-CDC》。深入講解了最新發(fā)布的 Flink CDC 2.0.0 版本帶來(lái)的核心特性，包括：全量數(shù)據(jù)的并發(fā)讀取、checkpoint、無(wú)鎖讀取等重大改進(jìn)。

GitHub 地址：
https://github.com/ververica/flink-cdc-connectors

一、CDC 概述

CDC 的全稱(chēng)是 Change Data Capture ，在廣義的概念上，只要是能捕獲數(shù)據(jù)變更的技術(shù)，我們都可以稱(chēng)之為 CDC 。目前通常描述的 CDC 技術(shù)主要面向數(shù)據(jù)庫(kù)的變更，是一種用于捕獲數(shù)據(jù)庫(kù)中數(shù)據(jù)變更的技術(shù)。CDC 技術(shù)的應(yīng)用場(chǎng)景非常廣泛：

• 數(shù)據(jù)同步：用于備份，容災(zāi)；
• 數(shù)據(jù)分發(fā)：一個(gè)數(shù)據(jù)源分發(fā)給多個(gè)下游系統(tǒng)；
• 數(shù)據(jù)采集：面向數(shù)據(jù)倉(cāng)庫(kù) / 數(shù)據(jù)湖的 ETL 數(shù)據(jù)集成，是非常重要的數(shù)據(jù)源。

CDC 的技術(shù)方案非常多，目前業(yè)界主流的實(shí)現(xiàn)機(jī)制可以分為兩種：

• 基于查詢(xún)的 CDC：

  • 離線(xiàn)調(diào)度查詢(xún)作業(yè)，批處理。把一張表同步到其他系統(tǒng)，每次通過(guò)查詢(xún)?nèi)カ@取表中最新的數(shù)據(jù)；
  • 無(wú)法保障數(shù)據(jù)一致性，查的過(guò)程中有可能數(shù)據(jù)已經(jīng)發(fā)生了多次變更；
  • 不保障實(shí)時(shí)性，基于離線(xiàn)調(diào)度存在天然的延遲。

• 基于日志的 CDC：

  • 實(shí)時(shí)消費(fèi)日志，流處理，例如 MySQL 的 binlog 日志完整記錄了數(shù)據(jù)庫(kù)中的變更，可以把 binlog 文件當(dāng)作流的數(shù)據(jù)源；
  • 保障數(shù)據(jù)一致性，因?yàn)?binlog 文件包含了所有歷史變更明細(xì)；
  • 保障實(shí)時(shí)性，因?yàn)轭?lèi)似 binlog 的日志文件是可以流式消費(fèi)的，提供的是實(shí)時(shí)數(shù)據(jù)。

對(duì)比常見(jiàn)的開(kāi)源 CDC 方案，我們可以發(fā)現(xiàn)：

• 對(duì)比增量同步能力，

  • 基于日志的方式，可以很好的做到增量同步；
  • 而基于查詢(xún)的方式是很難做到增量同步的。
• 對(duì)比全量同步能力，基于查詢(xún)或者日志的 CDC 方案基本都支持，除了 Canal。
• 而對(duì)比全量 + 增量同步的能力，只有 Flink CDC、Debezium、Oracle Goldengate 支持較好。
• 從架構(gòu)角度去看，該表將架構(gòu)分為單機(jī)和分布式，這里的分布式架構(gòu)不單純體現(xiàn)在數(shù)據(jù)讀取能力的水平擴(kuò)展上，更重要的是在大數(shù)據(jù)場(chǎng)景下分布式系統(tǒng)接入能力。例如 Flink CDC 的數(shù)據(jù)入湖或者入倉(cāng)的時(shí)候，下游通常是分布式的系統(tǒng)，如 Hive、HDFS、Iceberg、Hudi 等，那么從對(duì)接入分布式系統(tǒng)能力上看，Flink CDC 的架構(gòu)能夠很好地接入此類(lèi)系統(tǒng)。

• 在數(shù)據(jù)轉(zhuǎn)換 / 數(shù)據(jù)清洗能力上，當(dāng)數(shù)據(jù)進(jìn)入到 CDC 工具的時(shí)候是否能較方便的對(duì)數(shù)據(jù)做一些過(guò)濾或者清洗，甚至聚合？

  • 在 Flink CDC 上操作相當(dāng)簡(jiǎn)單，可以通過(guò) Flink SQL 去操作這些數(shù)據(jù)；
  • 但是像 DataX、Debezium 等則需要通過(guò)腳本或者模板去做，所以用戶(hù)的使用門(mén)檻會(huì)比較高。
• 另外，在生態(tài)方面，這里指的是下游的一些數(shù)據(jù)庫(kù)或者數(shù)據(jù)源的支持。Flink CDC 下游有豐富的 Connector，例如寫(xiě)入到 TiDB、MySQL、Pg、HBase、Kafka、ClickHouse 等常見(jiàn)的一些系統(tǒng)，也支持各種自定義 connector。

二、Flink CDC 項(xiàng)目

講到這里，先帶大家回顧下開(kāi)發(fā) Flink CDC 項(xiàng)目的動(dòng)機(jī)。

1. Dynamic Table & ChangeLog Stream

大家都知道 Flink 有兩個(gè)基礎(chǔ)概念：Dynamic Table 和 Changelog Stream。

• Dynamic Table 就是 Flink SQL 定義的動(dòng)態(tài)表，動(dòng)態(tài)表和流的概念是對(duì)等的。參照上圖，流可以轉(zhuǎn)換成動(dòng)態(tài)表，動(dòng)態(tài)表也可以轉(zhuǎn)換成流。
• 在 Flink SQL中，數(shù)據(jù)在從一個(gè)算子流向另外一個(gè)算子時(shí)都是以 Changelog Stream 的形式，任意時(shí)刻的 Changelog Stream 可以翻譯為一個(gè)表，也可以翻譯為一個(gè)流。

聯(lián)想下 MySQL 中的表和 binlog 日志，就會(huì)發(fā)現(xiàn)：MySQL 數(shù)據(jù)庫(kù)的一張表所有的變更都記錄在 binlog 日志中，如果一直對(duì)表進(jìn)行更新，binlog 日志流也一直會(huì)追加，數(shù)據(jù)庫(kù)中的表就相當(dāng)于 binlog 日志流在某個(gè)時(shí)刻點(diǎn)物化的結(jié)果；日志流就是將表的變更數(shù)據(jù)持續(xù)捕獲的結(jié)果。這說(shuō)明 Flink SQL 的 Dynamic Table 是可以非常自然地表示一張不斷變化的 MySQL 數(shù)據(jù)庫(kù)表。

在此基礎(chǔ)上，我們調(diào)研了一些 CDC 技術(shù)，最終選擇了 Debezium 作為 Flink CDC 的底層采集工具。Debezium 支持全量同步，也支持增量同步，也支持全量 + 增量的同步，非常靈活，同時(shí)基于日志的 CDC 技術(shù)使得提供 Exactly-Once 成為可能。

將 Flink SQL 的內(nèi)部數(shù)據(jù)結(jié)構(gòu) RowData 和 Debezium 的數(shù)據(jù)結(jié)構(gòu)進(jìn)行對(duì)比，可以發(fā)現(xiàn)兩者是非常相似的。

• 每條 RowData 都有一個(gè)元數(shù)據(jù) RowKind，包括 4 種類(lèi)型， 分別是插入 (INSERT)、更新前鏡像 (UPDATE_BEFORE)、更新后鏡像 (UPDATE_AFTER)、刪除 (DELETE)，這四種類(lèi)型和數(shù)據(jù)庫(kù)里面的 binlog 概念保持一致。
• 而 Debezium 的數(shù)據(jù)結(jié)構(gòu)，也有一個(gè)類(lèi)似的元數(shù)據(jù) op 字段， op 字段的取值也有四種，分別是 c、u、d、r，各自對(duì)應(yīng) create、update、delete、read。對(duì)于代表更新操作的 u，其數(shù)據(jù)部分同時(shí)包含了前鏡像 (before) 和后鏡像 (after)。

通過(guò)分析兩種數(shù)據(jù)結(jié)構(gòu)，Flink 和 Debezium 兩者的底層數(shù)據(jù)是可以非常方便地對(duì)接起來(lái)的，大家可以發(fā)現(xiàn) Flink 做 CDC 從技術(shù)上是非常合適的。

2. 傳統(tǒng) CDC ETL 分析

我們來(lái)看下傳統(tǒng) CDC 的 ETL 分析鏈路，如下圖所示：

傳統(tǒng)的基于 CDC 的 ETL 分析中，數(shù)據(jù)采集工具是必須的，國(guó)外用戶(hù)常用 Debezium，國(guó)內(nèi)用戶(hù)常用阿里開(kāi)源的 Canal，采集工具負(fù)責(zé)采集數(shù)據(jù)庫(kù)的增量數(shù)據(jù)，一些采集工具也支持同步全量數(shù)據(jù)。采集到的數(shù)據(jù)一般輸出到消息中間件如 Kafka，然后 Flink 計(jì)算引擎再去消費(fèi)這一部分?jǐn)?shù)據(jù)寫(xiě)入到目的端，目的端可以是各種 DB，數(shù)據(jù)湖，實(shí)時(shí)數(shù)倉(cāng)和離線(xiàn)數(shù)倉(cāng)。

注意，Flink 提供了 changelog-json format，可以將 changelog 數(shù)據(jù)寫(xiě)入離線(xiàn)數(shù)倉(cāng)如 Hive / HDFS；對(duì)于實(shí)時(shí)數(shù)倉(cāng)，Flink 支持將 changelog 通過(guò) upsert-kafka connector 直接寫(xiě)入 Kafka。

我們一直在思考是否可以使用 Flink CDC 去替換上圖中虛線(xiàn)框內(nèi)的采集組件和消息隊(duì)列，從而簡(jiǎn)化分析鏈路，降低維護(hù)成本。同時(shí)更少的組件也意味著數(shù)據(jù)時(shí)效性能夠進(jìn)一步提高。答案是可以的，于是就有了我們基于 Flink CDC 的 ETL 分析流程。

3. 基于 Flink CDC 的 ETL 分析

在使用了 Flink CDC 之后，除了組件更少，維護(hù)更方便外，另一個(gè)優(yōu)勢(shì)是通過(guò) Flink SQL 極大地降低了用戶(hù)使用門(mén)檻，可以看下面的例子：

該例子是通過(guò) Flink CDC 去同步數(shù)據(jù)庫(kù)數(shù)據(jù)并寫(xiě)入到 TiDB，用戶(hù)直接使用 Flink SQL 創(chuàng)建了產(chǎn)品和訂單的 MySQL-CDC 表，然后對(duì)數(shù)據(jù)流進(jìn)行 JOIN 加工，加工后直接寫(xiě)入到下游數(shù)據(jù)庫(kù)。通過(guò)一個(gè) Flink SQL 作業(yè)就完成了 CDC 的數(shù)據(jù)分析，加工和同步。

大家會(huì)發(fā)現(xiàn)這是一個(gè)純 SQL 作業(yè)，這意味著只要會(huì) SQL 的 BI，業(yè)務(wù)線(xiàn)同學(xué)都可以完成此類(lèi)工作。與此同時(shí)，用戶(hù)也可以利用 Flink SQL 提供的豐富語(yǔ)法進(jìn)行數(shù)據(jù)清洗、分析、聚合。

而這些能力，對(duì)于現(xiàn)有的 CDC 方案來(lái)說(shuō)，進(jìn)行數(shù)據(jù)的清洗，分析和聚合是非常困難的。

此外，利用 Flink SQL 雙流 JOIN、維表 JOIN、UDTF 語(yǔ)法可以非常容易地完成數(shù)據(jù)打?qū)?#xff0c;以及各種業(yè)務(wù)邏輯加工。

4. Flink CDC 項(xiàng)目發(fā)展

• 2020 年 7 月由云邪提交了第一個(gè) commit，這是基于個(gè)人興趣孵化的項(xiàng)目；
• 2020 年 7 中旬支持了 MySQL-CDC；
• 2020 年 7 月末支持了 Postgres-CDC；
• 一年的時(shí)間，該項(xiàng)目在 GitHub 上的 star 數(shù)已經(jīng)超過(guò) 800。

三、Flink CDC 2.0 詳解

1. Flink CDC 痛點(diǎn)

MySQL CDC 是 Flink CDC 中使用最多也是最重要的 Connector，本文下述章節(jié)描述 Flink CDC Connector 均為 MySQL CDC Connector。

隨著 Flink CDC 項(xiàng)目的發(fā)展，得到了很多用戶(hù)在社區(qū)的反饋，主要?dú)w納為三個(gè)：

• 全量 + 增量讀取的過(guò)程需要保證所有數(shù)據(jù)的一致性，因此需要通過(guò)加鎖保證，但是加鎖在數(shù)據(jù)庫(kù)層面上是一個(gè)十分高危的操作。底層 Debezium 在保證數(shù)據(jù)一致性時(shí)，需要對(duì)讀取的庫(kù)或表加鎖，全局鎖可能導(dǎo)致數(shù)據(jù)庫(kù)鎖住，表級(jí)鎖會(huì)鎖住表的讀，DBA 一般不給鎖權(quán)限。
• 不支持水平擴(kuò)展，因?yàn)?Flink CDC 底層是基于 Debezium，起架構(gòu)是單節(jié)點(diǎn)，所以Flink CDC 只支持單并發(fā)。在全量階段讀取階段，如果表非常大 (億級(jí)別)，讀取時(shí)間在小時(shí)甚至天級(jí)別，用戶(hù)不能通過(guò)增加資源去提升作業(yè)速度。
• 全量讀取階段不支持 checkpoint：CDC 讀取分為兩個(gè)階段，全量讀取和增量讀取，目前全量讀取階段是不支持 checkpoint 的，因此會(huì)存在一個(gè)問(wèn)題：當(dāng)我們同步全量數(shù)據(jù)時(shí)，假設(shè)需要 5 個(gè)小時(shí)，當(dāng)我們同步了 4 小時(shí)的時(shí)候作業(yè)失敗，這時(shí)候就需要重新開(kāi)始，再讀取 5 個(gè)小時(shí)。

2. Debezium 鎖分析

Flink CDC 底層封裝了 Debezium， Debezium 同步一張表分為兩個(gè)階段：

• 全量階段：查詢(xún)當(dāng)前表中所有記錄；
• 增量階段：從 binlog 消費(fèi)變更數(shù)據(jù)。

大部分用戶(hù)使用的場(chǎng)景都是全量 + 增量同步，加鎖是發(fā)生在全量階段，目的是為了確定全量階段的初始位點(diǎn)，保證增量 + 全量實(shí)現(xiàn)一條不多，一條不少，從而保證數(shù)據(jù)一致性。從下圖中我們可以分析全局鎖和表鎖的一些加鎖流程，左邊紅色線(xiàn)條是鎖的生命周期，右邊是 MySQL 開(kāi)啟可重復(fù)讀事務(wù)的生命周期。

以全局鎖為例，首先是獲取一個(gè)鎖，然后再去開(kāi)啟可重復(fù)讀的事務(wù)。這里鎖住操作是讀取 binlog 的起始位置和當(dāng)前表的 schema。這樣做的目的是保證 binlog 的起始位置和讀取到的當(dāng)前 schema 是可以對(duì)應(yīng)上的，因?yàn)楸淼?schema 是會(huì)改變的，比如如刪除列或者增加列。在讀取這兩個(gè)信息后，SnapshotReader 會(huì)在可重復(fù)讀事務(wù)里讀取全量數(shù)據(jù)，在全量數(shù)據(jù)讀取完成后，會(huì)啟動(dòng) BinlogReader 從讀取的 binlog 起始位置開(kāi)始增量讀取，從而保證全量數(shù)據(jù) + 增量數(shù)據(jù)的無(wú)縫銜接。

表鎖是全局鎖的退化版，因?yàn)槿宙i的權(quán)限會(huì)比較高，因此在某些場(chǎng)景，用戶(hù)只有表鎖。表鎖鎖的時(shí)間會(huì)更長(zhǎng)，因?yàn)楸礞i有個(gè)特征：鎖提前釋放了可重復(fù)讀的事務(wù)默認(rèn)會(huì)提交，所以鎖需要等到全量數(shù)據(jù)讀完后才能釋放。

經(jīng)過(guò)上面分析，接下來(lái)看看這些鎖到底會(huì)造成怎樣嚴(yán)重的后果：

Flink CDC 1.x 可以不加鎖，能夠滿(mǎn)足大部分場(chǎng)景，但犧牲了一定的數(shù)據(jù)準(zhǔn)確性。Flink CDC 1.x 默認(rèn)加全局鎖，雖然能保證數(shù)據(jù)一致性，但存在上述 hang 住數(shù)據(jù)的風(fēng)險(xiǎn)。

3. Flink CDC 2.0 設(shè)計(jì) ( 以 MySQL 為例)

通過(guò)上面的分析，可以知道 2.0 的設(shè)計(jì)方案，核心要解決上述的三個(gè)問(wèn)題，即支持無(wú)鎖、水平擴(kuò)展、checkpoint。

DBlog 這篇論文里描述的無(wú)鎖算法如下圖所示：

左邊是 Chunk 的切分算法描述，Chunk 的切分算法其實(shí)和很多數(shù)據(jù)庫(kù)的分庫(kù)分表原理類(lèi)似，通過(guò)表的主鍵對(duì)表中的數(shù)據(jù)進(jìn)行分片。假設(shè)每個(gè) Chunk 的步長(zhǎng)為 10，按照這個(gè)規(guī)則進(jìn)行切分，只需要把這些 Chunk 的區(qū)間做成左開(kāi)右閉或者左閉右開(kāi)的區(qū)間，保證銜接后的區(qū)間能夠等于表的主鍵區(qū)間即可。

右邊是每個(gè) Chunk 的無(wú)鎖讀算法描述，該算法的核心思想是在劃分了 Chunk 后，對(duì)于每個(gè) Chunk 的全量讀取和增量讀取，在不用鎖的條件下完成一致性的合并。Chunk 的切分如下圖所示：

因?yàn)槊總€(gè) chunk 只負(fù)責(zé)自己主鍵范圍內(nèi)的數(shù)據(jù)，不難推導(dǎo)，只要能夠保證每個(gè) Chunk 讀取的一致性，就能保證整張表讀取的一致性，這便是無(wú)鎖算法的基本原理。

Netflix 的 DBLog 論文中 Chunk 讀取算法是通過(guò)在 DB 維護(hù)一張信號(hào)表，再通過(guò)信號(hào)表在 binlog 文件中打點(diǎn)，記錄每個(gè) chunk 讀取前的 Low Position (低位點(diǎn)) 和讀取結(jié)束之后 High Position (高位點(diǎn)) ，在低位點(diǎn)和高位點(diǎn)之間去查詢(xún)?cè)?Chunk 的全量數(shù)據(jù)。在讀取出這一部分 Chunk 的數(shù)據(jù)之后，再將這 2 個(gè)位點(diǎn)之間的 binlog 增量數(shù)據(jù)合并到 chunk 所屬的全量數(shù)據(jù)，從而得到高位點(diǎn)時(shí)刻，該 chunk 對(duì)應(yīng)的全量數(shù)據(jù)。

Flink CDC 結(jié)合自身的情況，在 Chunk 讀取算法上做了去信號(hào)表的改進(jìn)，不需要額外維護(hù)信號(hào)表，通過(guò)直接讀取 binlog 位點(diǎn)替代在 binlog 中做標(biāo)記的功能，整體的 chunk 讀算法描述如下圖所示：

比如正在讀取 Chunk-1，Chunk 的區(qū)間是 [K1, K10]，首先直接將該區(qū)間內(nèi)的數(shù)據(jù) select 出來(lái)并把它存在 buffer 中，在 select 之前記錄 binlog 的一個(gè)位點(diǎn) (低位點(diǎn))，select 完成后記錄 binlog 的一個(gè)位點(diǎn) (高位點(diǎn))。然后開(kāi)始增量部分，消費(fèi)從低位點(diǎn)到高位點(diǎn)的 binlog。

• 圖中的 - ( k2,100 ) + ( k2,108 ) 記錄表示這條數(shù)據(jù)的值從 100 更新到 108；
• 第二條記錄是刪除 k3；
• 第三條記錄是更新 k2 為 119；
• 第四條記錄是 k5 的數(shù)據(jù)由原來(lái)的 77 變更為 100。

觀察圖片中右下角最終的輸出，會(huì)發(fā)現(xiàn)在消費(fèi)該 chunk 的 binlog 時(shí)，出現(xiàn)的 key 是k2、k3、k5，我們前往 buffer 將這些 key 做標(biāo)記。

• 對(duì)于 k1、k4、k6、k7 來(lái)說(shuō)，在高位點(diǎn)讀取完畢之后，這些記錄沒(méi)有變化過(guò)，所以這些數(shù)據(jù)是可以直接輸出的；
• 對(duì)于改變過(guò)的數(shù)據(jù)，則需要將增量的數(shù)據(jù)合并到全量的數(shù)據(jù)中，只保留合并后的最終數(shù)據(jù)。例如，k2 最終的結(jié)果是 119 ，那么只需要輸出 +(k2,119)，而不需要中間發(fā)生過(guò)改變的數(shù)據(jù)。

通過(guò)這種方式，Chunk 最終的輸出就是在高位點(diǎn)是 chunk 中最新的數(shù)據(jù)。

上圖描述的是單個(gè) Chunk 的一致性讀，但是如果有多個(gè)表分了很多不同的 Chunk，且這些 Chunk 分發(fā)到了不同的 task 中，那么如何分發(fā) Chunk 并保證全局一致性讀呢？

這個(gè)就是基于 FLIP-27 來(lái)優(yōu)雅地實(shí)現(xiàn)的，通過(guò)下圖可以看到有 SourceEnumerator 的組件，這個(gè)組件主要用于 Chunk 的劃分，劃分好的 Chunk 會(huì)提供給下游的 SourceReader 去讀取，通過(guò)把 chunk 分發(fā)給不同的 SourceReader 便實(shí)現(xiàn)了并發(fā)讀取 Snapshot Chunk 的過(guò)程，同時(shí)基于 FLIP-27 我們能較為方便地做到 chunk 粒度的 checkpoint。

當(dāng) Snapshot Chunk 讀取完成之后，需要有一個(gè)匯報(bào)的流程，如下圖中橘色的匯報(bào)信息，將 Snapshot Chunk 完成信息匯報(bào)給 SourceEnumerator。

匯報(bào)的主要目的是為了后續(xù)分發(fā) binlog chunk (如下圖)。因?yàn)?Flink CDC 支持全量 + 增量同步，所以當(dāng)所有 Snapshot Chunk 讀取完成之后，還需要消費(fèi)增量的 binlog，這是通過(guò)下發(fā)一個(gè) binlog chunk 給任意一個(gè) Source Reader 進(jìn)行單并發(fā)讀取實(shí)現(xiàn)的。

對(duì)于大部分用戶(hù)來(lái)講，其實(shí)無(wú)需過(guò)于關(guān)注如何無(wú)鎖算法和分片的細(xì)節(jié)，了解整體的流程就好。

整體流程可以概括為，首先通過(guò)主鍵對(duì)表進(jìn)行 Snapshot Chunk 劃分，再將 Snapshot Chunk 分發(fā)給多個(gè) SourceReader，每個(gè) Snapshot Chunk 讀取時(shí)通過(guò)算法實(shí)現(xiàn)無(wú)鎖條件下的一致性讀，SourceReader 讀取時(shí)支持 chunk 粒度的 checkpoint，在所有 Snapshot Chunk 讀取完成后，下發(fā)一個(gè) binlog chunk 進(jìn)行增量部分的 binlog 讀取，這便是 Flink CDC 2.0 的整體流程，如下圖所示：

Flink CDC 是一個(gè)完全開(kāi)源的項(xiàng)目，項(xiàng)目所有設(shè)計(jì)和源碼目前都已貢獻(xiàn)到開(kāi)源社區(qū)，Flink CDC 2.0 也已經(jīng)正式發(fā)布，此次的核心改進(jìn)和提升包括：

• 提供 MySQL CDC 2.0，核心feature 包括

  • 并發(fā)讀取，全量數(shù)據(jù)的讀取性能可以水平擴(kuò)展；
  • 全程無(wú)鎖，不對(duì)線(xiàn)上業(yè)務(wù)產(chǎn)生鎖的風(fēng)險(xiǎn)；
  • 斷點(diǎn)續(xù)傳，支持全量階段的 checkpoint。
• 搭建文檔網(wǎng)站，提供多版本文檔支持，文檔支持關(guān)鍵詞搜索

筆者用 TPC-DS 數(shù)據(jù)集中的 customer 表進(jìn)行了測(cè)試，Flink 版本是 1.13.1，customer 表的數(shù)據(jù)量是 6500 萬(wàn)條，Source 并發(fā)為 8，全量讀取階段:

• MySQL CDC 2.0 用時(shí) 13 分鐘；
• MySQL CDC 1.4 用時(shí) 89 分鐘；
• 讀取性能提升 6.8 倍。

為了提供更好的文檔支持，Flink CDC 社區(qū)搭建了文檔網(wǎng)站，網(wǎng)站支持對(duì)文檔的版本管理：

文檔網(wǎng)站支持關(guān)鍵字搜索功能，非常實(shí)用：

四、未來(lái)規(guī)劃

關(guān)于 CDC 項(xiàng)目的未來(lái)規(guī)劃，我們希望圍繞穩(wěn)定性，進(jìn)階 feature 和生態(tài)集成三個(gè)方面展開(kāi)。

• 穩(wěn)定性

  • 通過(guò)社區(qū)的方式吸引更多的開(kāi)發(fā)者，公司的開(kāi)源力量提升 Flink CDC 的成熟度；
  • 支持 Lazy Assigning。Lazy Assigning 的思路是將 chunk 先劃分一批，而不是一次性進(jìn)行全部劃分。當(dāng)前 Source Reader 對(duì)數(shù)據(jù)讀取進(jìn)行分片是一次性全部劃分好所有 chunk，例如有 1 萬(wàn)個(gè) chunk，可以先劃分 1 千個(gè) chunk，而不是一次性全部劃分，在 SourceReader 讀取完 1 千 chunk 后再繼續(xù)劃分，節(jié)約劃分 chunk 的時(shí)間。

• 進(jìn)階 Feature

  • 支持 Schema Evolution。這個(gè)場(chǎng)景是：當(dāng)同步數(shù)據(jù)庫(kù)的過(guò)程中，突然在表中添加了一個(gè)字段，并且希望后續(xù)同步下游系統(tǒng)的時(shí)候能夠自動(dòng)加入這個(gè)字段；
  • 支持 Watermark Pushdown 通過(guò) CDC 的 binlog 獲取到一些心跳信息，這些心跳的信息可以作為一個(gè) Watermark，通過(guò)這個(gè)心跳信息可以知道到這個(gè)流當(dāng)前消費(fèi)的一些進(jìn)度；
  • 支持 META 數(shù)據(jù)，分庫(kù)分表的場(chǎng)景下，有可能需要元數(shù)據(jù)知道這條數(shù)據(jù)來(lái)源哪個(gè)庫(kù)哪個(gè)表，在下游系統(tǒng)入湖入倉(cāng)可以有更多的靈活操作；
  • 整庫(kù)同步：用戶(hù)要同步整個(gè)數(shù)據(jù)庫(kù)只需一行 SQL 語(yǔ)法即可完成，而不用每張表定義一個(gè) DDL 和 query。

• 生態(tài)集成

  • 集成更多上游數(shù)據(jù)庫(kù)，如 Oracle，MS SqlServer。Cloudera 目前正在積極貢獻(xiàn) oracle-cdc connector；
  • 在入湖層面，Hudi 和 Iceberg 寫(xiě)入上有一定的優(yōu)化空間，例如在高 QPS 入湖的時(shí)候，數(shù)據(jù)分布有比較大的性能影響，這一點(diǎn)可以通過(guò)與生態(tài)打通和集成繼續(xù)優(yōu)化。

最后，歡迎大家加入 Flink CDC 用戶(hù)群一起交流。

附錄

[1] Flink-CDC 項(xiàng)目地址

[2] Flink-CDC 文檔網(wǎng)站

[3] Percona - MySQL 全局鎖時(shí)間分析

[4] DBLog - 無(wú)鎖算法論文

[5] Flink FLIP-27 設(shè)計(jì)文檔

---

實(shí)時(shí)數(shù)倉(cāng) Meetup 議題征集

8 月 29 日左右 (時(shí)間暫定)，Flink 社區(qū)計(jì)劃舉辦 Meetup 實(shí)時(shí)數(shù)倉(cāng)專(zhuān)場(chǎng)，現(xiàn)征集議題中！
關(guān)于實(shí)時(shí)數(shù)倉(cāng)，大家的關(guān)注度一直很高，目前業(yè)界也有許多落地的公司。在 Meetup 實(shí)時(shí)數(shù)倉(cāng)專(zhuān)場(chǎng)， 我們將更加注重 “交流”，希望將大家聚集在一起相互探討關(guān)于實(shí)時(shí)數(shù)倉(cāng)的話(huà)題，重點(diǎn)在踩過(guò)的坑、碰到的痛點(diǎn)都是怎樣解決的～
現(xiàn)征集實(shí)時(shí)數(shù)倉(cāng) Meetup 的議題，圍繞 “實(shí)時(shí)數(shù)倉(cāng)踩坑痛點(diǎn)和避坑經(jīng)驗(yàn)”，歡迎各位老師和同學(xué)帶上貴公司的介紹，以及議題的初步大綱來(lái)找小松鼠。
公司不議大小，經(jīng)驗(yàn)才論足缺。我們會(huì)選取其中最具代表性的議題，邀請(qǐng)您參加實(shí)時(shí)數(shù)倉(cāng) Meetup 專(zhuān)場(chǎng)～ 你們的經(jīng)驗(yàn)對(duì)于其他技術(shù)開(kāi)發(fā)者和 Flink 社區(qū)都很重要！

原文鏈接：https://developer.aliyun.com/article/786600?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶(hù)自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開(kāi)發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開(kāi)發(fā)者社區(qū)用戶(hù)服務(wù)協(xié)議》和《阿里云開(kāi)發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫(xiě)侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的Flink CDC 2.0 正式发布，详解核心改进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。