在之前部分中，我們從宏觀角度考慮了我們的數(shù)據，并區(qū)分了內部數(shù)據和外部數(shù)據。我們還討論了模式和數(shù)據契約，以及它們如何提供隨著時間的推移協(xié)商、更改和發(fā)展我們的流的方法。最后，我們介紹了事實(狀態(tài))和增量事件類型。事實事件最適合通信狀態(tài)和解耦系統(tǒng)，而 Delta 事件往往更多地用于內部數(shù)據，例如在事件溯源和其他緊密耦合的用例中。

規(guī)范化表創(chuàng)建規(guī)范化流

規(guī)范化的表導致規(guī)范化的事件流。連接器(例如，CDC)將數(shù)據直接從數(shù)據庫拉入事件流的鏡像集。這并不理想，因為它在內部數(shù)據庫表和外部事件流之間創(chuàng)建了強耦合。

考慮一個簡單的電子商務項目及其關聯(lián)的品牌和稅收狀態(tài)表。

品牌和稅收狀態(tài)表通過外鍵關系與項目表相關。雖然我們只在表中顯示一項，但您可能會有數(shù)千(或數(shù)百萬)項，具體取決于您銷售的產品。

通常為每個表設置一個連接器，從表中提取數(shù)據，將其組合成事件，并將每個表寫入專用的事件流。

公開數(shù)據庫中的基礎表會導致每個表產生相應的事件流。雖然這種方式很容易上手，但它會導致多個問題，這些問題可以概括為耦合 問題或成本 問題。讓我們逐一看看。

問題：消費者對內部模型的耦合

按原樣公開源Item表會迫使消費者直接耦合它。源系統(tǒng)數(shù)據模型的更改將影響下游消費者。

假設我們重構Item表以將P ricing提取到它自己的表中。

重構源表會導致項目流的數(shù)據契約損壞。不再向消費者提供他們最初期望的相同商品數(shù)據。我們還必須創(chuàng)建一個新的連接器 - 一個新的P米流 - 最后，重構我們的消費者邏輯 以使其再次運行。重命名列、更改默認值和更改列類型是內部數(shù)據模型上的緊密耦合引入的其他形式的破壞性更改。

問題：流式連接(通常)昂貴

關系數(shù)據庫是專門為快速、廉價地解決連接問題而構建的。不幸的是，流連接不是這樣的。

考慮兩個需要訪問Item、其Tax及其Brand信息的服務。如果數(shù)據已寫入其相應的流，則每個使用者(下圖中的右側)將必須計算相同的連接來對Item、B rand和T ax進行非規(guī)范化。

此策略可能會產生高昂的成本，無論是編寫應用程序的開發(fā)時間還是計算連接的服務器成本。大規(guī)模解決流連接可能會導致大量數(shù)據洗牌，從而產生處理能力、網絡和存儲成本。此外，并非所有流處理框架都支持連接，尤其是外鍵連接。在那些這樣做的語言中，例如 Flink、Spark、KSQL 或 Kafka Streams(例如)，您會發(fā)現(xiàn)自己僅限于編程語言的子集(Java、Scala、Python)。

解決方案：提供非規(guī)范化數(shù)據是最好的

原則上，應使事件流易于消費者使用。在使用抽象層將數(shù)據提供給消費者之前對其進行非規(guī)范化，并創(chuàng)建顯式的外部模型數(shù)據契約 (外部數(shù)據)以供消費者耦合。

對內部模型的更改在源系統(tǒng)中保持隔離。消費者獲得一個定義明確的數(shù)據契約來進行耦合。只要源系統(tǒng)為消費者維護數(shù)據契約，對源模型所做的更改就可以不受阻礙地進行。

但是我們在哪里非規(guī)范化呢?兩種選擇：

· 通過專門構建的連接器服務在源系統(tǒng)外部進行重建。

· 在使用事務發(fā)件箱模式在源系統(tǒng)中創(chuàng)建事件期間。