變更資料捕獲CDC的八個實際案例 - Dunith

1. 能有助於快取失效
Redis和Memcached等鍵值儲存用作快取以加快讀取速度。通常，他們將預先計算的 SQL 查詢結果儲存在記憶體中，以便可以消除對資料庫的後續訪問。
快取最大的挑戰是如何讓快取的資料與源資料保持一致。例如，源資料庫中的記錄更新多久傳播到快取？
通常，快取會超時並定期自動失效。但是在 CDC 的幫助下，快取的條目可以以事件驅動的方式失效。
假設我們有一個 DynamoDb 表來捕獲對候選人的投票。每當記錄新投票時，它都會作為事件捕獲併發布到 DynamoDb 流，由 Lambda 函式處理。該函式的邏輯聚合投票計數並將其寫入 ElasticCache。因此，儀表板可以直接讀取快取的結果，而無需 DynamoDb 每次都執行聚合。
 

2.更新一個搜尋索引，比如Elasticsearch
我們經常使用 OLTP 資料庫作為我們的操作記錄系統。但它們不適合執行諸如全文搜尋之類的專門操作。雖然資料庫可以配備相關的擴充套件，但人們經常將全文搜尋操作解除安裝到像 Elasticsearch 這樣的專門系統。
例如，我們可以在 Elasticsearch 中維護一個高度非規範化的聚合檢視，以滿足客戶訂單等查詢。在關聯式資料庫中，此查詢將透過連線多個表來提供，如果要連線的行數很多且查詢頻繁，則它是不可擴充套件的。但 Elasticsearch 可以將這些資訊捕獲到單個文件中，並使消費者能夠按產品名稱搜尋訂單。
我們在這裡面臨的挑戰是如何將源系統更改可靠地傳播到 Elasticsearch 並始終保持兩個系統一致。
在這一點上，像 Debezium 這樣的 CDC 系統可以透過檢測源資料庫更改並以可擴充套件且可靠的方式將它們傳播到 Elasticsearch 來幫助您。
Debezium 獲取 MySQL 的行級更改並將其寫入 Kafka 主題。然後，部署到 Kafka Connect 的 Elasticsearch sink 聯結器讀取更改並傳播到 Elasticsearch 的相關索引。您可以從這裡閱讀更多相關資訊。
 

3.實時資料載入到資料倉儲
運算元據庫不是執行繁重分析工作負載的好選擇，因為它們會阻礙常規 OLTP 操作的效能。因此，必須將運營資料移動到專用系統（例如資料倉儲）以執行支援 BI 和報告需求的分析查詢。
有兩種方法；ETL 是傳統的方法，您可以批次運算元據並定期將它們載入到倉庫。ETL 的缺點是延遲。但是使用 CDC，您可以在源系統更改發生時捕獲它們並將它們實時傳送到倉庫。
今天，許多資料倉儲允許以流方式載入資料。AWS Redshift、Google BigQuery、Apache Druid 和 Apache Pinot 就是幾個例子。
您可以捕獲 DynamoDb 表的更改並將它們寫入 Kinesis 流。然後使用 Kinesis Firehose 將它們載入到 RedShift。同樣，您可以使用 Debezium 將運算元據移動到 Kafka 主題中，Apache Pinot 可以以流式方式讀取該主題。
  

4. 將本地資料同步到雲端
有時，通常需要將在諸如本地系統（例如 POS 系統、COTS 應用程式）等邊緣位置產生的運算元據移動到位於雲中的中央資料庫。主要目標是利用雲供應商提供的可擴充套件和持久的儲存選項。
例如，本地事務資料可以傳送到雲資料倉儲，在那裡可以執行豐富的分析操作，而無需在本地配置昂貴的基礎設施。另一個用例是將本地資料遷移到雲中提供的新應用程式。
您可以利用 CDC 有效地捕獲本地資料庫更改並將其傳播到雲。大多數情況下，它是作為位於本地和雲的兩個資料庫之間的連續資料複製來完成的。
 

5. 微服務物化檢視的事件驅動更新
微服務架構提倡每個服務都有一個資料庫來儲存服務私有的資料。儘管這提高了跨服務的自治性和可擴充套件性，但這可能會導致一些複雜情況。
例如，當一個服務嘗試訪問另一個服務擁有的資料時，唯一的方法是進行 API 呼叫。但是當涉及級聯 API 呼叫時，此模型不可擴充套件。消費者必須執行低效的記憶體中連線才能保持來自多個服務的響應。
作為一種補救措施，微服務依靠命令查詢職責分離（CQRS）模式將狀態突變與查詢分離。服務可以偵聽來自下游系統的域事件並更新內部物化檢視以在本地執行查詢，而不是實時查詢服務。這提高了讀取效能、整體系統可用性和自主性。
 

6. 使用發件箱模式進行可靠的微服務資料交換
微服務的另一個常見問題是跨多個服務邊界可靠地更新資料。例如，考慮一個管理採購訂單的微服務。下新訂單時，可能必須將有關該訂單的資訊轉發給運輸服務和客戶服務。
Saga模式在一定程度上有助於解決這個問題。但是由於其同步性質，實現 Saga 通常很複雜和脆弱。
CDC 透過捕獲對發件箱表所做的更改並以可靠且最終一致的方式將它們傳播到下游微服務來進入畫面。
Debezium 部落格有一篇關於使用 Debezium 實現這一點的優秀文章。
 

7.實時資訊釋出
CDC 允許您將源資料庫中的更改作為事件流捕獲。然後可以使用Apache Flink等流處理引擎處理這些事件，以實時應用轉換或執行聚合。清理後的事件比它們的原始版本更有意義。因此它們可以用於人類消費，如下所示。
更新實時儀表板
Microsoft Power BI 等儀表板可以透過從流資料集中讀取來實時更新。
釋出到非同步 API
處理後的更改事件可以寫入 WebSocket，以便訂閱者可以採取適當的操作。 
 

8. 建立審計日誌
維護審計日誌是業務應用程式的常見要求，即應用程式資料的所有更改的持久跟蹤。
在其自然形式中，像 Debezium 這樣的 CDC 系統根據更改應用於源系統的順序來捕獲、儲存和傳播更改。因此，接收此資料的目標系統可以建立已應用於源系統的更改的時間順序並追溯到特定時間點。
可以使用來自外部系統的資訊來豐富變化，以提供有助於對事件進行取證分析的整體檢視。例如，透過從頭開始重放審計日誌，可以找到誰在哪個時間做了什麼操作的答案。
Debezium 部落格有一篇關於這個主題的深入文章。您可以閱讀它以獲取更多資訊。

更多：變更資料捕獲CDC文章