資料平台：建構企業變更資料捕獲（CDC）解決方案

資料是資料平台最重要的資源，企業需要對如何将資料攝取到新的資料平台中進行設計和規劃。

本文将讨論變更資料捕獲(CDC)解決方案，如何基于Debezium等開源工具設計标準的複制解決方案，以及CDC可以幫助企業遷移到新的資料平台的原因。

什麼是變更資料捕獲(CDC)

變更資料捕獲(CDC)是一個軟體過程，它捕獲在源資料庫中所做的變更(DDL和DML)以同步另一個資料存儲庫，例如資料庫、記憶體緩存、資料倉庫或資料湖。CDC用于本文沒有讨論的其他互補的用例，例如：

• CQRS模式：其中一種實作涉及具有單獨的寫入(指令)和讀取(查詢)資料庫和資料模型。寫入層支援插入、更新和删除操作，讀取層支援查詢資料操作。CDC允許将指令操作從寫入資料庫複制到讀取資料庫。
• 分析微服務：提供變更事件流以跟蹤變更發生的時間和内容，并分析行為模式。

CDC解決方案由三個主要元件組成：

• 源連接配接器：它從資料庫中捕獲變更并生成包含這些變更詳細資訊的事件。
• 通道：它是源連接配接器将這些事件與變更保持在一起的資料存儲庫。
• 接收器連接配接器：從通道讀取事件并處理應用特定邏輯以将資料整合到目标系統或其他目的(例如分析警報過程)。

實作CDC有多種方法，例如基于日志、基于觸發器或基于SQL腳本。本文将關注基于日志的方法，因為它是一種更有效的方法，以下将描述這種方法的優點。

源連接配接器釋出的事件包含同步遠端資料存儲庫所需的所有資訊。它由以下部分組成：

• 中繼資料：提供諸如表名、操作類型(插入、删除等)、事務辨別符、源連接配接器進行或捕獲變更時的時間戳等資訊。
• 前值：變更前的資料值。
• 後值：變更後的資料值。

JSON  { "table":"stock" "operation": "update", "ts_ms" : "1627817475", "transaction_id": 2, "before" : {   "id" : "0001",  "item" : "T-Shirt",  "quantity" : "10"  },  "after" : {   "id" : "0001",   "item" : "T-Shirt",  "quantity" : "5"   }  }           

并非所有連接配接器都具有相同的行為。有一些連接配接器(例如官方的MongoDB連接配接器)不提供“前值”。

在資料複制的情況下，這些事件由接收器連接配接器使用，并合并到目标資料庫中。企業必須按照事件生成的順序使用事件，以確定流程的彈性。

如果事件沒有按順序進行，就不能保證複制過程的彈性。以下是可能發生的一些場景的示例：

在複制以外的場景中，基于事件驅動模式以及想要對特定事件做出反應的情況下，按順序使用事件并不重要。

基于日志的CDC優勢

與其他CDC方法或ETL複制過程相比，基于日志的CDC具有以下一些優勢：

• 性能：通過讀取該檔案，從事務日志檔案中檢索所有變更。與ETL等其他方法相比，這種操作對資料庫性能的影響較小。ETL方法是基于SQL查詢，需要持續優化(索引、分區等)，是以将消耗大量計算資源。
• 解耦資料提取：它提供解耦資料提取計算層，與其餘工作負載隔離。這個解決方案允許僅在CDC解決方案上進行垂直和水準擴充。觸發器CDC方法使用資料庫計算層，此複制過程可能影響資料庫的性能。
• 接近實時：低計算影響能夠提供接近實時的事件變更，而不會對源資料庫造成風險。檢測有序檔案中的變更比對表進行查詢輪詢過程更容易、更快。
• 捕獲所有變更：事務日志按确切順序提供所有資料變更，其中包括删除操作。ETL過程忽略了ETL執行之間發生的中間資料變更。可以使用其他方法(ETL、基于CDC觸發器、CDC SQL)識别删除操作需要建立表來注冊此操作，以及確定資料彈性的特定邏輯。
• 不影響資料模型和應用程式：這不需要變更資料模型或源應用程式。ETL和其他CDC解決方案需要建立觸發器和表或向表中添加時間戳。

需要考慮一些重要的細節：

• 無日志事務操作：所有操作都不會在事務日志上注冊。資料倉庫中通常使用目錄級别的操作，例如目标表和臨時表之間的分區移動。這種類型的操作取決于每個資料庫版本以及團隊的工作方式。
• 商業工具：每個資料庫供應商都提供特定于CDC的工具，通常帶有附加許可證。在複雜的多供應商環境中，企業使用不同的CDC工具來複制資料會增加營運成本。
• 開源工具：它們是一個不錯的選擇。通常需要更多時間來更新資料庫供應商釋出的新功能。有時，對故障排除或錯誤解決的支援更為複雜。
• 反模式：在某些情況下，必須将特定源資料庫複制到多個目标資料庫。有時，團隊會配置多個CDC複制，所有這些複制都從同一個事務日志中讀取。這是一個危險的反模式。低影響并不意味着沒有影響，CDC會增加I/O操作，是以從同一檔案中讀取多個CDC會增加大量I/O操作，并産生I/O的性能問題。而使用中心輻射模式是一種更好的方法。

中心輻射型CDC模式(Data Hub)

中心輻射式架構是最常見的資料內建架構模式之一。這種架構允許一次從資料庫中捕獲變更并多次傳遞它們。這種模式與Apache Kafka和其他流媒體平台使用的釋出和訂閱模式非常相似，并具備一些好處，例如：

(1)可重用性：更改事件從源資料庫讀取一次，并由接收器連接配接器多次使用。

(2)減少內建次數：與源資料庫隻有一次內建。

(3)标準接口：為所有消費者提供相同的接口。在這種情況下，接收器連接配接器複制共享同一接口的目标資料庫中的資料。

根據通道的特性，它将允許提供一些Data Hub的功能。資料保留是Data Hub的一項基本功能。如果無法存儲所有曆史資料甚至每個文檔或行的最後狀态，使用者将不得不采用其他工具和流程來補充解決方案。

CDC的常見場景

CDC是一個很好的解決方案，并且有四種常見的場景：

• OLAP資料庫遷移：在企業将所有或部分工作負載從目前資料倉庫遷移到新的OLAP解決方案的情況下，CDC允許将相同的資料複制到另一個系統并使遷移變得更容易。如今，許多企業正在将工作負載從内部部署資料庫遷移到資料雲解決方案。
• 将資訊從OLTP資料庫複制到OLAP資料庫：将資料從營運資料庫複制到資料倉庫或資料湖。
• 資料庫即服務：為分析沙箱或提供資料庫的副本。
• 從單體到微服務的遷移：應用扼殺者模式将單體應用程式逐漸遷移到微服務。在第一階段複制兩個應用程式共存所需的一些資料集。

企業CDC解決方案

下圖描述了CDC程序的行為方式以及組成它的元件。基于此提出以下解決方案架構：

• Debezium作為源連接配接器：這一部分将負責從源資料庫引擎讀取變更并将其發送到通道。它将作為連接配接器部署在Kafka Connect叢集中。
• Kafka作為通道：它提供中間存儲以及用于事件生産/消費的廣泛API和可部署在Kafka Connect或其他平台上的大型生态系統連接配接器。
• Kafka Sink JDBC(Confluent提供)與Event flattering SMT(Debezium提供)作為Sink連接配接器：這個連接配接器允許使用者使用一些配置參數在目标資料庫上執行複制。作為一個通用解決方案，這是一個不錯的選擇。在其他情況下，例如Snowflake或其他雲服務，JDBC連接配接器的成本效益和性能比供應商本身提供的其他政策更差。評估切換到供應商本身提供的連接配接器而不是使用通用JDBC的成本收益是很重要的。
• Kafka Connect as Connector Platform：它提供了一個架構，可以基于簡單的配置将連接配接器部署為插件，并與Kafka完全內建。這是一個非常好的選擇，因為它允許企業标準化接收器/源連接配接器管理，例如Debezium複制操作和JDBC接收器連接配接器。

1.Debezium

Debezium是一個開源解決方案，提供了非常有趣的功能來捕獲資料庫中的變化。Debezium架構提供了一些優勢，例如：

與特定的資料庫供應商解決方案相比，事件标準化是使用Debezium等産品的重要優勢之一。通常情況下，每個供應商解決方案都有不同的事件規範，因為這些解決方案主要設計用于複制來自同一供應商的資料庫。在多個資料庫産品之間進行複制處理的場景中，具有多個事件規範會增加解決方案在操作、可維護性和編碼方面的複雜性。Debezium提供了一個通用、清晰且簡單的事件規範，可以促進與其他第三方産品(例如Kafka Connect接收器連接配接器)的內建。

以下看一個事件示例(為了便于閱讀而進行了調整)：

JSON  { "after": {  "field_id": 1,   "field_1": "Value 1" },  "before": null,  "op": "c",  "source": {   "connector": "mysql",    "db": "inventory",    "name": "mysqldb",   "snapshot": "false",    "table": "product",   "ts_ms": 1627489969029,   "version": "1.6.1.Final",   (... other source vendor fields ...)  },  "transaction": null,  "ts_ms": 1627489969200 }           

• after：包含表格列及其值的文檔。其值可以為null，例如在删除操作中。
• before：包含表格列及其值的文檔。其值可以為null，例如在建立(插入)操作中。
• op：在資料庫中運作的操作，如更新、插入或删除。
• source：事件的中繼資料。該文檔具有公共資訊，但它有幾個字段，具體取決于源資料庫(Oracle、SqlServer、MySQL或PostgreSQL)。
• t source.ts_ms：表示在資料庫中進行更改的時間。
• ts_ms：Debezium處理該事件時的時間戳，與source.ts_ms不同。通過比較這些值，可以确定源資料庫更新和Debezium之間的延遲。

Debezium與Kafka生态系統完全內建。源連接配接器使用Kafka API釋出更改事件，但也可以部署為Kafka連接配接器。可以使用REST API将其部署在Kafka Connet叢集中，以簡化新CDC源連接配接器的部署和管理。

JSON  { "name": "debezium-postgres-inventory-connector", "config": {   "connector.class": "io.debezium.connector.postgresql.PostgresConnector",  "tasks.max": "1", "database.hostname": "postgres",  "database.port": "5432",   "database.user": "postgres",   "database.password": "postgres",   "database.dbname": "postgres",  "database.server.name": "postgresdb",  "schema.include": "inventory",   "table.include.list": "inventory.product"  } }           

在這個示例中，在PostgreSQL資料庫中部署了一個新的Debezium源連接配接器，并啟用了對庫存模式上産品表的變更捕獲。連接配接器讀取更改并将事件推送到Kafka主題“postgres.inventory.product”。

盡管每個Debezium資料庫連接配接器都有特定的配置、屬性和選項，但也有通用的連接配接屬性。作為一個常見的選擇，可以在第一次配置資料庫快照到Kafka或禁用它。這些通用配置屬性加入Kafka連接配接器API，提供了一個标準的管理源連接配接器層，可以簡化解決方案的操作。

需要考慮的事項：

雖然有多種Debezium連接配接器，但并非所有連接配接器都提供相同的功能：

• MongoDB
• MySQL
• PostgreSQL
• Oracle
• Etc

在做出決定之前，對每一項進行審查非常重要，因為在某些情況下，使用供應商連接配接器可能會更好，例如：

• Debezium MongoDB Source Connector：目前無法發送文檔的目前狀态，隻能發送幂等格式的操作。
• Debezium SQL Server Source Connector：它不是基于日志的連接配接器，而是基于觸發器的連接配接器，它需要安裝觸發器過程并建立一個階段表。

2.Kafka

Kafka是提供通道功能的一個很好的選擇，因為它提供了幾個重要的功能，例如：

• 可擴充的事件流平台：高度可配置以提供高可用性、低延遲、高性能、多次傳遞和持久性保證。
• 釋出/訂閱模式：它促進了一次釋出和多次消費的機制，提供了良好的系統，每個使用者可以或按照希望提供的速度工作。
• 大型生态系統：如今已被數千家公司使用。有許多用于資料管道、流分析和資料內建的開源和商業工具。
• 無限存儲和保留：提供具有無限存儲和保留的集中平台。Confluent最近提供的一些功能讓使用者能夠擁有更好的成本效益存儲層，将存儲和計算資源解耦。

Debezium CDC事件釋出在Kafka主題中。一個Kafka事件由三部分組成：

• 鍵：用于确定将附加消息的分區。具有相同僚件鍵的事件被寫入同一個分區。Kafka保證分區的事件将被任何消費者以與寫入它們完全相同的順序讀取。
• 值：它包含事件本身。
• 标頭：它是與Kafka記錄關聯的中繼資料，并提供有關鍵/值對的額外資訊。

作為一個鍵，Debezium包含了表的鍵域。這允許使用者按照變更事件在資料庫中發生的順序處理變更事件。

(1)主題政策

活動釋出有兩種政策：

• 每個表有一個主題。
• 每個資料庫有一個主題或一對資料庫和模式有一個主題。

最佳政策取決于環境的特征，兩種解決方案各有利弊。“每個表有一個主題”政策的主要問題是所需的主題和分區的數量。Kafka對每個叢集有一個分區限制，是以當使用者的很多資料庫有成百上千的表時，不建議使用這種政策。

(2)表現

這個解決方案中有兩個級别的并行性：

• 基于目标資料庫的數量。
• 特定目标資料庫的吞吐量。

Kafka提供了釋出/訂閱模式，這允許使用者部署多個接收器連接配接器來處理事件，并将資訊從主題并行複制到多個目标資料庫。為了增加每個接收器連接配接器的吞吐量，需要組合兩個元件：

• 主題分區的數量。
• Kafka消費者組中的消費者數量。每個接收器連接配接器都與一個特定且獨特的消費者群體相關聯。在Kafka連接配接器的情況下，消費者統一體就像一個線程或任務。

資源組的成員劃分分區，以便分區僅由組的消費者使用，并且該消費者将按順序讀取鍵的事件。基于此，可以使用Kafka Connect來處理影響每個鍵的事件以将狀态複制到另一個目标資料庫中，例如一個簡單配置的資料倉庫，例如：

JSON  {   "name": "jdbc-sink",  "config": {   "connector.class": "io.confluent.connect.jdbc.JdbcSinkConnector",  "tasks.max": "1",  "topics": "postgres.inventory.product",   "connection.url": "jdbc:dwhdriver://connection",  "transforms": "unwrap",   "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState",  "transforms.unwrap.drop.tombstones": "false",  "auto.create": "true",  "insert.mode": "upsert",  "delete.enabled": "true",  "pk.fields": "id",  "pk.mode": "record_key"  } }           

一個連接配接器可以讀取多個主題，并且可以在作為使用者組工作的任務中進行擴充。使用此配置中定義的屬性，可以執行源的副本，或者可能僅将事件作為曆史演變附加以執行某些分析過程。

(3)資料保留

Kafka資料保留在主題級别進行管理，并且有不同的政策：

• 時間保留：超過時間時，Kafka代理會定期删除舊事件。
• 大小保留：當超過主題大小時，Kafka代理會定期删除舊事件。
• 無限制。

作為一個有趣的新功能，Confluent提供了分層存儲：可以将熱資料發送到經濟高效的對象存儲，并且僅在需要更多計算資源時進行擴充。在某些情況下，資料可能需要無限長的存儲時間。

按時間或大小保留并不是Kafka定義清理政策的唯一能力。使用者可以定義一個緊湊政策，其中Kafka代理定期删除事件，隻保留每個鍵的最後一個事件，并在最後一個事件為null作為s值時删除該鍵。

壓縮政策是CDC解決方案的一個非常有趣的功能。它允許使用者保留行或文檔的最後一個事件。這意味着使用者擁有最後的合并值，但丢失了變更的曆史記錄。

壓縮清理政策是一項代價昂貴的操作，但它允許使用者清理舊事件，保持資料庫的最後狀态，其優點是，如果一年後需要新的使用者，則不需要處理這一年發生的事件。

結論

在有大量資料和技術多樣的複雜環境中，為新的資料平台提供資料是一個巨大的挑戰。但真正的挑戰是在提供這些資料的同時確定企業做出有價值決策所需的品質。

準确性、一緻性、唯一性、及時性是衡量資料品質的一些名額。CDC代替了其他解決方案，使使用者能夠以相對簡單的方式标準化資料攝取并確定資料品質。而标準化和自動化是提高任何流程品質的關鍵。