奈飛的資料網格是什麼樣？

banq發表於2022-08-13

作者：雷波, Guilherme Pires , James Shao , Kasturi Chatterjee , Sujay Jain , Vlad Sydorenko
背景
實時處理技術（AKA 流處理）是使 Netflix 在娛樂使用者的競爭中保持領先地位的關鍵因素之一。我們的上一代流式管道解決方案Keystone在滿足我們多種關鍵業務需求方面有著良好的記錄。然而，隨著我們擴充套件我們的產品並嘗試新的想法，越來越需要解鎖 Keystone 尚未涵蓋的其他新興用例。在評估選項後，團隊決定建立資料網格作為我們的下一代資料管道解決方案。
去年，我們寫了一篇關於 Data Mesh 如何幫助我們的 Studio 團隊實現資料移動用例的部落格文章。一年過去了，Data Mesh 已經達到了它的第一個重要里程碑，並且它的範圍不斷擴大。隨著越來越多的用例加入它，我們有更多的東西要分享。我們將釋出一系列文章，涵蓋資料網格的不同方面以及我們從旅程中學到的東西。本文概述了該系統。以下將深入探討它的不同方面。

資料網格概述
資料網格的新定義
之前，我們將資料網格定義為一種完全託管的流式資料管道產品，用於啟用變更資料捕獲(CDC) 用例。隨著系統發展以解決越來越多的用例，我們擴大了其範圍，不僅可以處理 CDC 用例，還可以處理更一般的資料移動和處理用例，例如：

  • 事件可以來自更通用的應用程式（不僅是資料庫）。
  • 可用資料庫聯結器的目錄正在增長（例如 CockroachDB，Cassandra）
  • 更多處理模式，如過濾、投影、聯合、連線等。

因此，今天我們將資料網格定義為通用資料移動和處理平臺，用於在 Netflix 系統之間大規模移動資料。
整體架構

奈飛的資料網格是什麼樣？
​

Data Mesh系統可以分為控制平面（Data Mesh Controller）和資料平面（Data Mesh Pipeline）。控制器接收使用者請求、部署和編排管道。部署後，管道將執行實際繁重的資料處理工作。供應管道涉及不同的資源。控制器將責任委託給相應的微服務來管理它們的生命週期。
管道

奈飛的資料網格是什麼樣？
​

資料網格管道從各種來源讀取資料，對傳入事件應用轉換，並最終將它們接收到目標資料儲存中。可以從 UI 或透過我們的宣告性 API 建立管道。在建立/更新請求中，控制器計算出與管道相關的資源併為每個資源計算適當的配置。

聯結器
源聯結器是資料網格託管的生產者。它監控源資料庫的 bin 日誌，併為面向 Kafka 主題的資料網格源生成 CDC 事件。它能夠與資料網格控制器對話以自動建立/更新源。
以前我們只有 RDS 源聯結器來使用DBLog 庫來監聽 MySQL 和 Postgres ；現在我們新增了 Cockroach DB 源聯結器和 Cassandra 源聯結器。他們使用不同的機制將事件從源資料庫中流出。我們將有部落格文章深入探討它們。
除了託管聯結器之外，應用程式所有者還可以透過公共庫發出事件，該庫可用於 DB 聯結器尚不可用或偏好在不與 DB 模式耦合的情況下發出域事件的情況。

來源
應用程式開發人員可以在集中的源目錄中公開他們的域資料。這允許資料共享，因為 Netflix 的多個團隊可能有興趣接收實體的更改。此外，可以將 Source 定義為一系列處理步驟的結果——例如，具有多個維度（例如Talents列表）的豐富電影實體，可以進一步對其進行索引以實現搜尋用例。

處理器
處理器是 Flink Job。它包含一個可重用的資料處理邏輯單元。它從上游傳輸讀取事件並將一些業務邏輯應用於每個事件。中間處理器將資料寫入另一個傳輸。接收器處理器將資料寫入外部系統，例如 Iceberg、ElasticSearch 或單獨的可發現 Kafka 主題。
我們提供了一個處理器 SDK 來幫助高階使用者開發自己的處理器。由我們團隊之外的 Netflix 開發人員開發的處理器也可以註冊到平臺並與管道中的其他處理器一起使用。註冊處理器後，平臺還會自動設定預設警報 UI 和指標儀表板

傳送
我們使用 Kafka 作為互連處理器進行通訊的傳輸層。上游處理器的輸出事件被寫入 Kafka 主題，下游處理器從那裡讀取它們的輸入事件。
Kafka 主題也可以跨管道共享。管道#1 中儲存其上游處理器輸出的主題可用作管道#2 中的源。我們經常看到不同消費者需要一些中間輸出資料的用例。這種設計使我們能夠儘可能地重用和共享資料。我們還實現了跟蹤資料沿襲的功能，以便我們的使用者可以更好地瞭解整體資料使用情況。

架構
資料網格在所有管道上強制執行模式，這意味著我們要求透過管道的所有事件都符合預定義的模板。我們使用 Avro 作為我們所有模式的共享格式，因為它簡單、強大且被社群廣泛採用。
由於以下原因，我們將模式作為資料網格中的一等公民：

  • 更好的資料質量：只有符合模式的事件才能被編碼。讓消費者更有信心。
  • 更精細的資料沿襲粒度：該平臺能夠跟蹤不同消費者如何使用欄位並將其顯示在 UI 上。
  • 資料發現：模式描述資料集，使使用者能夠瀏覽不同的資料集並找到感興趣的資料集。

在建立管道時，該管道中的每個處理器都需要定義它使用和生成的模式。該平臺處理架構驗證和相容性檢查。我們還圍繞處理模式演變建立了自動化。如果架構在源頭髮生變化，平臺會嘗試自動升級消費管道，無需人工干預。

未來
資料網格最初是作為一個解決我們變更資料捕獲需求的專案開始的。在過去的一年裡，我們觀察到機器學習、日誌記錄等其他領域對各種需求的需求不斷增加。今天，資料網格仍處於早期階段，還有很多有趣的問題有待解決. 以下是我們路線圖中一些高優先順序任務的重點。

使資料網格成為資料移動和處理的鋪墊路徑（推薦解決方案）
如上所述，Data Mesh 旨在成為 Netflix 的下一代實時資料管道解決方案。到目前為止，我們仍然有幾個專門的內部系統服務於他們自己的用例。為了簡化產品，將這些用例逐漸遷移到資料網格是有意義的。我們目前正在努力確保 Data Mesh 可以實現與 Delta 和 Keystone 的功能對等。此外，我們還希望增加對更多源和接收器的支援，以解鎖廣泛的資料整合用例。

更多的處理模式和更高的效率
人們不僅使用資料網格來移動資料。他們通常還希望在此過程中處理或轉換他們的資料。我們的另一個高優先順序任務是為我們的使用者提供更常見的處理模式。由於預設情況下處理器是 Flink 作業，因此讓每個簡單的處理器在自己的 Flink 作業中完成它們的工作可能會降低效率。我們還在探索將多種處理模式合併到一個 Flink 作業中的方法。

更廣泛地支援聯結器
使用者經常問我們，Data Mesh 是否能夠從資料儲存 X 中獲取資料並將其放入資料儲存 Y。今天我們支援某些源和接收器，但這還遠遠不夠。對更多型別聯結器的需求是巨大的，我們看到了一個巨大的機會，這絕對是我們也想投資的東西。
資料網格是一個複雜而強大的系統。我們相信，隨著它的成熟，它將有助於 Netflix 未來的成功。同樣，我們仍處於旅程的開始，我們對即將到來的機會感到興奮。在接下來的幾個月中，我們將釋出更多討論資料網格不同方面的文章。敬請期待！
團隊
沒有團隊的辛勤工作和巨大貢獻，Data Mesh 是不可能實現的。
 

相關文章