日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

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

創(chuàng)新互聯(lián)是專業(yè)的吉木乃網(wǎng)站建設(shè)公司，吉木乃接單;提供網(wǎng)站制作、網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行吉木乃網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

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

一、引入 Flink CDC 的背景

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

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

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

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

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

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

• 數(shù)據(jù)源：Flink CDC 除了對(duì)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫做到了很好的支持外，對(duì)文檔型、NewSQL（TiDB、OceanBase） 等當(dāng)下流行的數(shù)據(jù)庫都能夠支持；Debezium 對(duì)數(shù)據(jù)庫的支持相對(duì)沒有那么廣泛，但是對(duì)主流的關(guān)系型數(shù)據(jù)庫都做到了很好的支撐；Canal 和 OGG 只支持單一的數(shù)據(jù)源。
• 斷點(diǎn)續(xù)傳：四種技術(shù)都能夠支持。
• 同步模式：除了 Canal 只支持增量，其他技術(shù)均支持全量 + 增量的方式。而全量 + 增量的方式意味著第一次上線時(shí)全量到增量的切換過程全部可以通過 CDC 技術(shù)實(shí)現(xiàn)，無須人為地通過全量的任務(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)，只有官方資料。
• 開發(fā)難度：Flink CDC 依靠 Flink SQL 和 Flink DataStream 兩種開發(fā)模式，尤其是 Flink SQL，通過非常簡單的 SQL 即可完成數(shù)據(jù)同步任務(wù)的開發(fā)，開發(fā)上手尤為簡單；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ù)庫以及大數(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 年之前，大健云倉數(shù)據(jù)同步的方式為：通過多數(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 年我們開始調(diào)研選型 CDC 技術(shù)，搭建了小型試驗(yàn)場(chǎng)景，進(jìn)行小規(guī)模的試驗(yàn)。
• 2022 年，上線了基于 Flink CDC 實(shí)現(xiàn)的 LDSS 系統(tǒng)庫存場(chǎng)景同步功能。
• 未來，我們希望依托 Flink CDC 打造數(shù)據(jù)同步平臺(tái)，通過界面的開發(fā)和配置完成同步任務(wù)的開發(fā)、測(cè)試和上線，能夠全程在線管理同步任務(wù)的整個(gè)生命周期。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)同步的需求在公司內(nèi)部特別旺盛，需要通過平臺(tá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. 簡化開發(fā)，快速上手，業(yè)務(wù)開發(fā)人員經(jīng)過簡單培訓(xùn)即可上手開發(fā)同步任務(wù)。

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

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

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

• 實(shí)時(shí)數(shù)倉：希望通過 Flink CDC 以支持更多實(shí)時(shí)數(shù)倉的業(yè)務(wù)場(chǎng)景，借助 Flink 強(qiáng)大的計(jì)算能力做一些數(shù)據(jù)庫的物化視圖。將計(jì)算從 DB 里解脫出來，通過 Flink 的外部計(jì)算再重新寫回?cái)?shù)據(jù)庫，以加速平臺(tái)應(yīng)用的報(bào)表、統(tǒng)計(jì)、分析等實(shí)時(shí)應(yīng)用場(chǎng)景。
• 實(shí)時(shí)應(yīng)用：Flink CDC 能夠從 DB 層捕獲變更，因此可以通過 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)通過跑定時(shí)任務(wù)以及經(jīng)過大量關(guān)聯(lián)、聚合、分組等操作才能計(jì)算出來，再推送到財(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ù)的問題，減少公司的損失。
• 緩存：通過 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 后，主要反饋的問題有以下三個(gè)：

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

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

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

提問&解答

Q1需要開啟 SqlServer 自己的 CDC 嗎？

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

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

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

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

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

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

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

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

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

Q6中間需要 Kafka 嗎？

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

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

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

Q8Flink CDC 支持讀取 Oracle 從庫的日志嗎？

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

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

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

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

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

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

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

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

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

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

（未通過并發(fā)無鎖框架實(shí)現(xiàn)的連接器）全量過程中不可以觸發(fā) savepoint，增量過程中如果需要停機(jī)發(fā)布，可通過 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 的日志操作類型進(jìn)行過濾嗎？會(huì)影響效率嗎？

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

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

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

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

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

分享文章：FlinkCDC在大健云倉的實(shí)踐
文章出自：http://m.5511xx.com/article/cdsspds.html