保持同步

資料工程師修煉之路走到現在，真的沒有一個系統能同足滿足資料儲存、查詢和邏輯處理，現實世界的應用程式都是由多個不同的系統組件搭建起來；舉例來說我們會使用 OLTP 資料庫來服務客戶，使用快取系統幫 request 加速，使用文字檢索搜尋引擎處理搜尋需求，最後使用資料倉儲做 OLAP，每一個系統組件都為了特地目的而優化。

當你的應用程式需要因應事件發生，需要同步資料到所有系統組件上時該怎麼做呢？

資料倉儲的同步一般都是使用 ETL，取得資料庫的複製並轉換，也就是批次處理 (Day 23)。

如果預期資料庫的 dump 很慢，我們的另一個選擇就是使用 雙重寫入 (dual writes) ：當資料改變時同時寫到所有系統組件中。舉例來說就是當資料庫第一次被寫入時，同時更新搜尋引擎索引、快取和其他系統組件。

然而雙重寫入可能會發生如下圖 11-4 的 競爭條件 (race condition) 寫入：2 個 Client 並發的更新資料庫和索引，因為網路或其他理由的時間差，最終導致 2 邊的值不一致。

除非你在這 2 個系統間額外實做並發寫入檢測機制 (2020 Day 26 - Detecting Concurrent Writes)，否則你根本不會知道並發寫入發生。

另一個雙重寫入的問題是可能會有部份寫入成功，也是導致 2 邊的值不一致，想當然爾，面對這種 atomic commit 問題還是有方法可以解，但在多個系統上實做的代價很昂貴 (可參考 Day 20 - Atomic Commit and Two-Phase Commit 的介紹)。

Change Data Capture

變更資料補獲 (change data capture - CDC) 是一個能觀察資料寫入至資料庫並提取它們讓其他系統能複製的過程。

如下圖 11-5，CDC 能補獲所有資料庫的變更，並寫入到一個 log 裡，其他的系統組件擔任消費者的角色，以 相同順序 取得資料，我們稱這些 log 消費者為 衍生數據系統 (derived data systems) 。

實現變更資料補獲

衍生數據系統視為資料的多種不同的面向，CDC 機制能確保所有的變更能如實的反應在衍生數據系統上。

至於實現 CDC 的一個好選擇就是用 基於 log 的訊息代理 (log-based message broker) 啦！它很適合從源頭資料庫傳遞變更並保留訊息的順序。

寫 2 期的 資料工程師修煉之路 結束囉！

感謝 Designing Data-Intensive Applications 書中的精采內容才會有這些文章產生，可以的話還是拜讀原文吧！這系列文只是我挑選個人覺得重要的部份來分享，更何況我的文筆也沒有這麼好 XD

希望工程師們能從系統文了解一些常用工具的黑科技，跟這本書一樣，也希望能幫助工程師建立符合 Reliable、Scalable 和 Maintainable 的系統。

拜啦！