預計以以下速度推出新流程 我們準備了有趣材料的翻譯。
Обзор
我們將討論一種相當流行的模式，應用程式使用多個資料存儲，每個存儲都有自己的用途，例如，存儲規範形式的數據（MySQL 等），提供高級搜尋功能（ElasticSearch、等）。） 、快取（Memcached 等）等。 通常，當使用多個資料存儲時，其中一個充當主存儲，其他存儲充當衍生存儲。 唯一的問題是如何同步這些資料儲存。
我們研究了許多試圖解決同步多個儲存問題的不同模式，例如雙寫、分散式事務等。 然而，這些方法在實際使用、可靠性和維護方面具有很大的限制。 除了資料同步之外，有些應用還需要透過呼叫外部服務來豐富資料。
Delta就是為了解決這些問題而開發的。 Delta 最終為資料同步和豐富提供了一個一致的、事件驅動的平台。
現有解決方案
複式輸入
要保持兩個資料存儲同步，您可以使用雙重寫入，即先寫入一個存儲，然後立即寫入另一個存儲。 如果在嘗試次數用盡後第一次記錄失敗，則可以重試第一次記錄，並且可以中止第二次記錄。 但是，如果寫入第二個儲存失敗，兩個資料儲存可能會變得不同步。 這個問題通常透過創建一個恢復過程來解決，該恢復過程可以定期將數據從第一個存儲重新傳輸到第二個存儲，或者僅在檢測到數據差異時才這樣做。
問題：
執行復原過程是一項無法重複使用的特定作業。 此外，在執行復原過程之前，儲存位置之間的資料將保持不同步。 如果使用兩個以上的資料存儲，解決方案將變得更加複雜。 最後，復原過程可以為原始資料來源新增負載。
變更日誌表
當一組表格發生變更（例如插入、更新和刪除記錄）時，變更記錄將作為相同交易的一部分新增至日誌表。 另一個執行緒或進程不斷地從日誌表請求事件並將它們寫入一個或多個資料存儲，如有必要，在所有存儲確認記錄後從日誌表中刪除事件。
問題：
該模式應該作為庫來實現，並且最好不要更改使用它的應用程式的程式碼。 在多語言環境中，這樣的函式庫的實作應該以任何必要的語言存在，但要確保跨語言的功能和行為的一致性是非常困難的。
另一個問題在於在不支援事務模式變更的系統中取得模式變更[1][2]，例如 MySQL。 因此，進行更改（例如架構更改）並以交易方式將其記錄在更改日誌表中的模式並不總是有效。
分散式事務
分散式交易可用於將交易拆分到多個異質資料儲存中，以便該操作要么提交到所有使用的資料存儲，要么不提交到其中任何資料儲存。
問題：
分散式事務對於異質資料儲存來說是一個非常大的問題。 就其本質而言，他們只能依賴所涉及系統的最低公分母。 例如，如果應用程式進程在準備階段失敗，XA 事務將阻止執行。 此外，XA 不提供死鎖偵測或支援樂觀並發控制方案。 此外，某些系統（例如 ElasticSearch）不支援 XA 或任何其他異質事務模型。 因此，確保各種資料儲存技術中的寫入原子性對於應用程式來說仍然是一項非常具有挑戰性的任務[3]。
三角洲
Delta 旨在解決現有資料同步解決方案的局限性，並實現動態資料豐富。 我們的目標是將所有這些複雜性從應用程式開發人員手中抽象化出來，以便他們能夠完全專注於實現業務功能。 接下來我們將描述“電影搜尋”，這是 Netflix Delta 的實際用例。
Netflix廣泛使用微服務架構，每個微服務通常服務一種類型的資料。 電影的基本資訊包含在名為Movie Service 的微服務中，而相關資料（例如製片人、演員、供應商等資訊）則由其他幾個微服務（即Deal Service、Talent Service 和Vendor Service）管理。
Netflix 工作室的商業用戶經常需要搜尋各種電影標準，這就是為什麼能夠搜尋所有電影相關數據對他們來說非常重要。
在 Delta 之前，電影搜尋團隊需要從多個微服務中提取數據，然後才能對電影數據進行索引。 此外，團隊必須開發一個系統，即使根本沒有任何更改，也可以透過要求其他微服務進行更改來定期更新搜尋索引。 該系統很快變得複雜且難以維護。
圖 1. Delta 的輪詢系統
使用Delta後，系統被簡化為事件驅動系統，如下圖所示。 CDC（更改資料擷取）事件使用 Delta-Connector 發送到 Keystone Kafka 主題。 使用 Delta 流處理框架（基於 Flink）建立的 Delta 應用程式從主題接收 CDC 事件，透過呼叫其他微服務來豐富它們，最後將豐富的資料傳遞到 Elasticsearch 中的搜尋索引。 整個過程幾乎是即時發生的，也就是說，一旦將變更提交到資料倉儲，搜尋索引就會更新。
圖 2. 使用 Delta 的資料管道
在下面的部分中，我們將描述 Delta-Connector 的操作，它連接到儲存並將 CDC 事件發佈到傳輸層，傳輸層是一個即時資料傳輸基礎設施，將 CDC 事件路由到 Kafka 主題。 最後，我們將討論 Delta 流處理框架，應用程式開發人員可以使用該框架進行資料處理和豐富邏輯。
CDC（變更資料擷取）
我們開發了一種名為 Delta-Connector 的 CDC 服務，它可以即時擷取資料儲存中提交的變更並將其寫入流中。 即時更改來自交易日誌和儲存轉儲。 使用轉儲是因為交易日誌通常不會儲存整個變更歷史記錄。 變更通常會序列化為 Delta 事件，因此接收者不必擔心更改來自何處。
Delta-Connector 支援多種附加功能，例如：
- 能夠透過 Kafka 寫入自訂輸出資料。
- 能夠隨時為所有表、特定表或特定主鍵啟動手動轉儲。
- 轉儲可以分塊檢索，因此在發生故障時無需重新開始。
- 不需要在表上放置鎖，這對於確保資料庫寫入流量永遠不會被我們的服務阻塞非常重要。
- 由於 AWS 可用區中有冗餘實例，因此具有高可用性。
我們目前支援 MySQL 和 Postgres，包括在 AWS RDS 和 Aurora 上的部署。 我們也支持 Cassandra（多主）。 您可以在此處找到有關 Delta 連接器的更多詳細信息 .
Kafka 和傳輸層
Delta 的事件傳輸層建立在平台的訊息服務之上 .
從歷史上看，Netflix 上的發佈內容一直是針對可訪問性而不是壽命進行優化的（見下文）。 ）。 權衡是各種邊緣場景中潛在的經紀商資料不一致。 例如， 不潔的領導人選舉 對可能出現重複或遺失事件的接收者負責。
對於 Delta，我們希望獲得更強大的持久性保證，以確保將 CDC 活動交付給派生商店。 為此，我們提出了專門設計的 Kafka 群集作為一等物件。 您可以查看下表中的一些經紀商設定：
在 Keystone Kafka 集群中， 不潔的領導人選舉 通常包含在內是為了確保發布者的可訪問性。 如果不同步的副本被選為領導者，這可能會導致訊息遺失。 對於新的高可用性 Kafka 集群，該選項 不潔的領導人選舉 關閉以防止訊息遺失。
我們還增加了 複製因子 從 2 到 3 以及 最小同步副本數 1 到 2。寫入此集群的發布者需要來自所有其他集群的確認，確保 2 個副本中有 3 個擁有發布者發送的最新訊息。
當代理實例終止時，新實例將取代舊實例。 但是，新代理將需要趕上未同步的副本，這可能需要幾個小時。 為了減少這種情況下的復原時間，我們開始使用區塊資料儲存（Amazon Elastic Block Store）而不是本機代理磁碟。 當新實例取代已終止的代理實例時，它會附加已終止實例擁有的 EBS 磁碟區並開始擷取新訊息。 此程序將積壓清理時間從幾小時減少到幾分鐘，因為新實例不再需要從空狀態複製。 整體而言，獨立的儲存和代理生命週期可顯著減少代理切換的影響。
為了進一步提高資料傳輸保證，我們使用 偵測極端條件下的任何訊息遺失（例如，分區領導者中的時鐘不同步）。
串流處理框架
Delta 的處理層建構在 Netflix SPaaS 平台之上，該平台提供 Apache Flink 與 Netflix 生態系統的整合。 該平台提供了一個使用者介面，用於在 Titus 容器管理平台之上管理 Flink 作業的部署和 Flink 叢集的編排。 該介面還管理作業配置，並允許使用者動態更改配置，而無需重新編譯 Flink 作業。
Delta 提供了基於 Flink 和 SPaaS 的流處理框架，使用 基於註釋的 DSL（領域特定語言）抽象技術細節。 例如，要定義透過呼叫外部服務來豐富事件的步驟，使用者需要編寫以下DSL，框架將基於它建立一個模型，該模型將由Flink執行。
圖 3. Delta DSL 豐富範例
此處理框架不僅縮短了學習曲線，還提供了常見的串流處理功能，例如重複資料刪除、模式化以及靈活性和彈性，以解決常見的操作問題。
Delta流處理框架由兩個關鍵模組組成，DSL & API模組和運行時模組。 DSL & API模組提供DSL和UDF（使用者定義函數）API，以便使用者可以編寫自己的處理邏輯（例如過濾或轉換）。 Runtime 模組提供了 DSL 解析器的實現，該解析器會建立 DAG 模型中處理步驟的內部表示。 執行元件解釋 DAG 模型以初始化實際的 Flink 語句並最終執行 Flink 應用程式。 該框架的架構如下圖所示。
圖 4. Delta 流程處理框架架構
這種方法有幾個優點：
- 使用者可以專注於自己的業務邏輯，而無需深入研究 Flink 或 SPaaS 結構的細節。
- 可以以對使用者透明的方式完成最佳化，並且可以修復錯誤而不需要對使用者程式碼（UDF）進行任何更改。
- Delta 應用程式體驗得到簡化，因為該平台提供開箱即用的靈活性和彈性，並收集可用於警報的各種詳細指標。
生產用途
Delta 已經投入生產一年多了，在許多 Netflix Studio 應用程式中發揮關鍵作用。 她幫助團隊實現搜尋索引、資料儲存和事件驅動工作流程等用例。 以下是 Delta 平台的高層架構概述。
圖 5. Delta 的高層架構。
致謝
我們要感謝以下參與 Netflix Delta 的創建和開發的人員：Allen Wang、Charles Zhu、Jaebin Yoon、Josh Snyder、Kasturi Chatterjee、Mark Cho、Olof Johansson、Piyush Goyal、Prashanth Ramdas、Raghuram Onti Srinivasan、Sandeep Gupta、Steven Wu 、Tharanga Gamaethige、王雲和徐振中。
來源
- Martin Kleppmann、Alastair R. Beresford、Boerge Svingen：線上事件處理。 交流。 ACM 62(5): 43–49 (2019)。 數字編號：
：“Amazon Redshift 儲存的資料建構工具。”
來源： www.habr.com