讓我們依次看看每個(gè)解決方案。

選項(xiàng) 1：使用專門(mén)構(gòu)建的連接器服務(wù)進(jìn)行非規(guī)范化

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

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

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

將BrandName 解析到Item表中。

將 StateTax 和 CountryTax 解析為 Item 表

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

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

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

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

選項(xiàng) 2：事務(wù)性發(fā)件箱模式

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

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

發(fā)件箱允許您隔離內(nèi)部數(shù)據(jù)模型，因?yàn)槟梢栽趯?shù)據(jù)寫(xiě)入發(fā)件箱之前連接和轉(zhuǎn)換數(shù)據(jù)。發(fā)件箱充當(dāng)內(nèi)部數(shù)據(jù)和外部數(shù)據(jù)之間的抽象層，充當(dāng)消費(fèi)者的數(shù)據(jù)契約。

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

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

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

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

考慮一個(gè)項(xiàng)目點(diǎn)擊事件流，詳細(xì)說(shuō)明用戶在瀏覽電子商務(wù)項(xiàng)目時(shí)何時(shí)單擊項(xiàng)目。請(qǐng)注意，此商品點(diǎn)擊事件不包含名稱、價(jià)格、描述等更豐富的商品信息，僅包含基本信息ids。

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

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

關(guān)于緩慢變化維度的考慮

我們已經(jīng)討論了寫(xiě)入包含大型數(shù)據(jù)集(例如大型文本 blob)和頻繁更改的數(shù)據(jù)域(例如項(xiàng)目庫(kù)存)的事件的性能注意事項(xiàng)?，F(xiàn)在，我們將研究緩慢變化的維度(SCD)，通常通過(guò)外鍵關(guān)系表示，因?yàn)樗鼈兛赡苁侵匾獢?shù)據(jù)量的另一個(gè)來(lái)源。

讓我們?cè)俅位氐轿覀兊捻?xiàng)目示例。假設(shè)您有一個(gè)更新項(xiàng)目表的操作。我們將把該物品從 Anvil 重命名為 Iron Anvil。

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

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

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

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

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

概括

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

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

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