欧美交a欧美精品喷水_數字中國·星火文集 | 一種實(shí)時(shí)數據庫數據同步方案及實(shí)現 - 金融科技創(chuàng )新中心觀(guān)點(diǎn) - 神州信息

數字中國·星火文集 | 一種實(shí)時(shí)數據庫數據同步方案及實(shí)現

2022-06-21

一種實(shí)時(shí)數據庫

數據同步方案及實(shí)現

神州信息

董志

概述

變化數據捕獲簡(jiǎn)稱(chēng)CDC（Change Data Capture），可以識別提取從上次提取之后發(fā)生變化的數據，在廣義的概念上，只要能捕獲數據變更的技術(shù)，我們都可以稱(chēng)為CDC。通常我們說(shuō)的 CDC技術(shù)主要面向數據庫的變更，是一種用于捕獲數據庫中數據變更的技術(shù)。CDC的兩種模式：

（1）同步：同步CDC主要是采用觸發(fā)器記錄新增數據，基本能夠做到實(shí)時(shí)增量提取。

（2）異步：異步CDC通過(guò)分析已經(jīng)提交的日志記錄來(lái)得到增量數據信息，有一定的延時(shí)，是本文采用的模式。

1.1. 應用場(chǎng)景

（1）數據同步，用于備份、容災。

（2）數據分發(fā)，一個(gè)數據源分發(fā)給多個(gè)下游。

（3）數據采集，面向數據倉庫/數據湖的ETL數據集成。

1.2. 主流的實(shí)現機制

（1）基于查詢(xún)的CDC

a)離線(xiàn)調度查詢(xún)作業(yè)，批處理。

b)無(wú)法保障數據一致性。

c)不保障實(shí)時(shí)性。

（2）基于日志的CDC

a)實(shí)時(shí)消費日志，流處理。

b)保障數據一致性。

c)提供實(shí)時(shí)數據。

方案對比

主流開(kāi)源CDC方案對比如下圖所示，主要通過(guò)監控各數據庫的事務(wù)日志達到監控數據變化的目的，根據對比采用Flink CDC 方案。

圖：多種CDC技術(shù)對比

(1) DataX 不支持增量同步，Canal 不支持全量同步。雖然兩者都是非常流行的數據同步工具，但在場(chǎng)景支持上仍不完善。

(2) 在全量+增量一體化同步方面，只有Flink CDC、Debezium、Oracle Goldengate 支持較好。

(3) 在架構方面，Apache Flink 是一個(gè)非常優(yōu)秀的分布式流處理框架，因此Flink CDC 作為Apache Flink 的一個(gè)組件具有非常靈活的水平擴展能力。而DataX 和Canal 是個(gè)單機架構，在大數據場(chǎng)景下容易面臨性能瓶頸的問(wèn)題。

(4) 在數據加工的能力上，CDC 工具是否能夠方便地對數據做一些清洗、過(guò)濾、聚合，甚至關(guān)聯(lián)操作？Flink CDC 依托強大的Flink SQL 流式計算能力，可以非常方便地對數據進(jìn)行加工。而 Debezium 等則需要通過(guò)復雜的 Java 代碼才能完成，使用門(mén)檻比較高。

(5) 另外，在生態(tài)方面，這里指的是上下游存儲的支持。Flink CDC 上下游非常豐富，支持對接MySQL、PostgreSQL 等數據源，還支持寫(xiě)入到TiDB、HBase、Kafka、Hudi 等各種存儲系統中，也支持靈活的自定義connector。

因此，不論從性能還是適用范圍上，Flink CDC 都可以作為最佳選擇。Flink CDC Connectors是Apache Flink的一組source連接器，使用變更數據捕獲 (CDC) 從不同的數據庫中獲取變更，Flink CDC連接器集成了Debezium作為引擎來(lái)捕獲數據變化，所以它可以充分發(fā)揮Debezium的能力。目前連接器支持的數據庫有：MySQL（5.6+）、PostgreSQL（9.6+）、MongoDB（3.6+）、Oracle（11+）、TiDB（5.1.x+）、SQL Server（2012+）和Oceanbase（3.1.x+）。

數據庫事務(wù)日志

目前支持的關(guān)系型數據庫包括：MySQL、Oracle、PostgreSQL、SQL Server，主要采用基于WAL日志方式進(jìn)行數據變化監聽(tīng)。下面介紹各關(guān)系型數據庫的日志類(lèi)型：

1. MySQL

（1）Error log錯誤日志記錄了MySQL Server運行過(guò)程中所有較為嚴重的警告和錯誤信息，以及MySQL Server每次啟動(dòng)和關(guān)閉的詳細信息。

（2）Binary log二進(jìn)制日志，記錄著(zhù)數據庫發(fā)生的各種事務(wù)信息。

（3）Update log更新日志是MySQL在較老版本上使用的，其功能跟Bin log類(lèi)似，只不過(guò)不是以二進(jìn)制格式記錄，而是以簡(jiǎn)單文本格式記錄內容。

（4）Query log查詢(xún)日志記錄MySQL中所有的query。

（5）Slow query log慢查詢(xún)日志記錄的就是執行時(shí)間較長(cháng)的query。

（6）InnoDB redo log，InnoDB是一個(gè)事務(wù)安全的存儲引擎，其事務(wù)安全性主要就是通過(guò)在線(xiàn)redo日志和記錄在表空間中的undo信息來(lái)保證的。

2. Oracle

（1）系統報警日志alert.log。

（2）跟蹤日志(用戶(hù)和進(jìn)程) trace.log。

（3）重做日志。

a. 在線(xiàn)重做日志：又稱(chēng)聯(lián)機重做日志，指Oracle以SQL腳本的形式實(shí)時(shí)記錄數據庫的數據更新，換句話(huà)說(shuō)，實(shí)時(shí)保存已執行的SQL腳本到在線(xiàn)日志文件中（按特定的格式）。

b. 歸檔重做日志：指當條件滿(mǎn)足時(shí)，Oracle將在線(xiàn)重做日志以文件形式保存到硬盤(pán)（持久化）。

3. PostgreSQL

（1）pg_log文件夾中的日志一般用來(lái)記錄服務(wù)器與DB的狀態(tài)，如各種Error信息，定位慢查詢(xún)SQL，數據庫的啟動(dòng)關(guān)閉信息，發(fā)生checkpoint過(guò)于頻繁等的告警信息等。

（2）pg_xlog文件夾中的日志是記錄的PostgreSQL的WAL信息，也就是一些事務(wù)日志信息(transaction log)，記錄著(zhù)數據庫發(fā)生的各種事務(wù)信息。

（3）pg_clog文件夾存儲的也是事務(wù)日志文件，但與pg_xlog不同的是它記錄的是事務(wù)的元數據(metadata)，這個(gè)日志告訴我們哪些事務(wù)完成了，哪些沒(méi)有完成。

4. SQL Server

（1）交易日志（Transaction logs），是針對數據庫改變所做的記錄，它可以記錄針對數據庫的任何操作，并將記錄結果保存在獨立的文件中。對于任何每一個(gè)交易過(guò)程，交易日志都有非常全面的記錄，根據這些記錄可以將數據文件恢復成交易前的狀態(tài)。

功能實(shí)現

1. 整體架構

整體架構如下圖所示，首先各源端數據庫需要開(kāi)啟相應的事務(wù)日志，Flink CDC 任務(wù)會(huì )監聽(tīng)各數據庫的事務(wù)變化日志，然后對日志數據進(jìn)行處理，最后將數據進(jìn)行傳輸：

（1）通過(guò)訂閱發(fā)布方式將消息發(fā)送到Redis 的Channel 中，通知消費者數據庫中的數據發(fā)生了變化。

（2）以流的方式存儲到Kafka 的 Topic中，供下游程序進(jìn)行消費。

（3）抽取到其他關(guān)系型數據庫中，實(shí)現 ETL 功能。

圖：整體架構圖

2. 數據格式

由于 Flink CDC 內部集成了 Debezium 組件，通過(guò) Debezium 進(jìn)行數據采集，所以數據格式同 Debezium，監聽(tīng)到的數據格式如下圖所示，after 代表變化后的數據；source 代表源端的數據庫相關(guān)信息，包括 Debezium 版本號、連接器類(lèi)型、數據庫名、表名等；op 代表操作的類(lèi)型，此處為讀操作。