構建企業CDC資料湖解決方案 -DZone

• CQRS 模式：  其中一種實現涉及具有單獨的寫入（命令）和讀取（查詢）資料庫和資料模型。寫層支援插入、更新和刪除操作，讀層支援查詢資料操作。CDC 允許我們將命令操作從寫資料庫複製到讀資料庫。
• 分析微服務：提供更改事件流以跟蹤何時以及發生哪些更改並分析行為模式。

• OLAP資料庫 遷移：在我們將所有或部分工作負載從當前資料倉儲遷移到新的 OLAP 解決方案的情況下。CDC 允許我們將相同的資料複製到兩個系統並使遷移更容易。如今，許多公司正在將工作負載從 OnPremise 資料倉儲遷移到資料雲解決方案。  
• 將資訊從OLTP 資料庫複製 到 OLAP資料庫：將資料從我們的運算元據庫複製到資料倉儲或資料湖。  
• 資料庫即服務： 為分析沙箱或預生產沙箱提供我們資料庫的副本。
• 從單體到微服務的遷移：應用扼殺者模式將我們的單體應用程式逐步遷移到微服務。在第一階段複製兩個應用程式共存所需的一些資料集。

企業CDC解決方案
基於此，我們提出以下解決方案架構：

• Debezium 作為 Source聯結器：這一塊將是負責讀取從我們的源資料庫引擎的變化，並將它們傳送到通道。它將作為聯結器部署在我們的Kafka Connect Cluster 中。
• 卡夫卡 作為 Channel：它提供了可以在被部署用於事件的生產/消耗和大的生態系統的聯結器廣泛的API沿著中間儲存卡夫卡連線或在另一平臺上。  
• Kafka  Sink JDBC（透過Confluent）與 Event flattering SMT (by Debezium)作為Sink Connector：該聯結器允許我們在目標資料庫上執行復制，有幾個配置引數。作為用於全球目的的通用解決方案，它是一個不錯的選擇。在其他情況下，例如 Snowflake 或其他雲服務，JDBC 聯結器的成本效益和效能比供應商本身提供的其他策略更差。評估切換到供應商本身提供的聯結器而不是使用通用 JDBC 的成本收益是很重要的。 
• Kafka Connect 作為聯結器平臺：它提供了一個框架，可以基於簡單的配置將聯結器部署為外掛，並與我們的 Kafka 完全整合。這是一個非常好的選擇，因為它允許我們標準化接收器/源聯結器管理，例如 Debezium 複製操作和 JDBC 接收器聯結器。