讓我們依次看看每個解決方案。

選項 1：使用專門構建的連接器服務進行非規(guī)范化

在此示例中，左側的流鏡像它們來自數(shù)據(jù)庫中的表。

我們使用基于外鍵關系的專用應用程序(或流式 SQL 查詢)加入事件，并發(fā)出單個豐富的項目流。

從邏輯上講，我們正在解決關系并將數(shù)據(jù)壓縮到單個非規(guī)范化行中。

將BrandName 解析到Item表中。

將 StateTax 和 CountryTax 解析為 Item 表

專門構建的連接器依靠 Apache Kafka Streams 和 Apache Flink 等流處理框架來解決主鍵連接和外鍵連接。它們將流數(shù)據(jù)具體化為持久的內部表格式，使連接器應用程序能夠連接任何時期的事件 - 而不僅僅是那些受時間限制的窗口約束的事件。

使用 Flink 或 Kafka Streams 的連接器還具有顯著的可擴展性——它們可以根據(jù)負載進行擴展和縮減，并處理大量流量。

提示：不要將任何業(yè)務邏輯放入連接器中。為了在這種模式中取得成功，連接的數(shù)據(jù)必須準確地表示源，簡單地作為非規(guī)范化的結果。讓下游消費者應用自己的業(yè)務邏輯，使用非規(guī)范化數(shù)據(jù)作為單一事實來源。

如果您不想使用下游連接器，還有其他選擇。接下來讓我們看一下事務發(fā)件箱模式。

選項 2：事務性發(fā)件箱模式

首先，創(chuàng)建一個專用的發(fā)件箱表，用于將事件寫入流。

其次，將所有必要的內部表更新包裝在事務內。事務保證對內部表所做的任何更新也將寫入發(fā)件箱表。

發(fā)件箱允許您隔離內部數(shù)據(jù)模型，因為您可以在將數(shù)據(jù)寫入發(fā)件箱之前連接和轉換數(shù)據(jù)。發(fā)件箱充當內部數(shù)據(jù)和外部數(shù)據(jù)之間的抽象層，充當消費者的數(shù)據(jù)契約。

最后，您可以使用連接器將數(shù)據(jù)從發(fā)件箱取出并放入 Kafka。

您必須確保發(fā)件箱不會無限期增長 - 要么在 CDC 捕獲數(shù)據(jù)后刪除數(shù)據(jù)，要么通過計劃作業(yè)定期刪除數(shù)據(jù)。

示例：非規(guī)范化用戶行為跟蹤事件

跟蹤網(wǎng)頁和應用程序上的用戶行為是標準化事件的常見來源 - 想想 Google Analytics 或第一方內部選項。但我們并沒有包含事件中的所有信息;相反，我們將其限制為標識符(更快、更小、更便宜)，在創(chuàng)建事實后進行非規(guī)范化。

考慮一個項目點擊事件流，詳細說明用戶在瀏覽電子商務項目時何時單擊項目。請注意，此商品點擊事件不包含名稱、價格、描述等更豐富的商品信息，僅包含基本信息ids。

許多點擊流消費者所做的第一件事是將其與項目事實流結合起來。由于您正在處理許多點擊事件，您會發(fā)現(xiàn)它最終會使用大量的計算資源。專門構建的 Flink 應用程序可以將項目點擊與詳細的項目數(shù)據(jù)結合起來，并將它們發(fā)送到豐富的項目點擊流。

擁有多個部門(和系統(tǒng))的大型公司可能會看到他們的數(shù)據(jù)來自不同的來源，并且在事后使用流連接器加入是最可能的結果。

關于緩慢變化維度的考慮

我們已經(jīng)討論了寫入包含大型數(shù)據(jù)集(例如大型文本 blob)和頻繁更改的數(shù)據(jù)域(例如項目庫存)的事件的性能注意事項。現(xiàn)在，我們將研究緩慢變化的維度(SCD)，通常通過外鍵關系表示，因為它們可能是重要數(shù)據(jù)量的另一個來源。

讓我們再次回到我們的項目示例。假設您有一個更新項目表的操作。我們將把該物品從 Anvil 重命名為 Iron Anvil。

更新數(shù)據(jù)庫中的數(shù)據(jù)后，我們還會發(fā)出更新的項目(例如通過發(fā)件箱模式)，以及非規(guī)范化的稅收狀態(tài)和品牌表。

然而，我們還需要考慮當我們更改品牌或稅表中的值時會發(fā)生什么。更新這些緩慢變化的維度之一可能會導致所有受影響的項目發(fā)生大量更新。

例如，ACME 公司進行了品牌重塑并提出了新的品牌名稱，從 ACME 更改為 Rotunda。我們?yōu)?舉辦另一個活動ItemId=123。

然而，Rotunda(以前稱為 ACME)可能有數(shù)百(或數(shù)千)個項目也因此更改而更新，從而導致相應數(shù)量的更新豐富項目事件。

當對 SCD 和外鍵關系進行非規(guī)范化時，請記住 SCD 中的更改可能對整個事件流產(chǎn)生的影響。如果更改 SCD 會導致數(shù)百萬或數(shù)十億個更新事件，您可能會決定放棄非規(guī)范化并將其留給消費者。

概括

非規(guī)范化使消費者更容易使用數(shù)據(jù)，但代價是更多的上游處理和仔細選擇要包含的數(shù)據(jù)。消費者可以更輕松地構建應用程序，并且可以從更廣泛的技術中進行選擇，包括那些本身不支持流連接的技術。

當數(shù)據(jù)較小且不經(jīng)常更新時，標準化上游數(shù)據(jù)效果很好。較大的事件規(guī)模、頻繁的更新和 SCD 都是在確定哪些內容要對上游進行非規(guī)范化以及哪些內容要留給消費者自行處理時需要注意的因素。

最終，選擇在事件中包含哪些數(shù)據(jù)以及排除哪些數(shù)據(jù)是消費者需求、生產(chǎn)者能力和獨特數(shù)據(jù)模型關系之間的平衡行為。但最好的起點是了解消費者的需求并隔離源系統(tǒng)的內部數(shù)據(jù)模型。