串流處理架構與資料網格整合實踐

隨著企業對即時資料分析需求的增長，將分析工作負載遷移到操作層面已成為趨勢。然而，操作層面的基礎設施通常無法儲存所有歷史資料，限制了即時分析的完整性。本文將探討如何整合串流處理架構和資料網格，以克服這些挑戰，並深入研究不同佈署模型的優缺點，為構建高效能、可擴充套件的即時分析系統提供參考。從資料複製技術到一致性串流資料函式庫，我們將分析各種技術方案，並提供程式碼範例和圖表說明，幫助讀者理解不同架構的應用場景和最佳實踐。最後，我們還將比較 ksqlDB 和增量檢視維護方案，為讀者提供更全面的技術選型參考。

串流處理架構與資料網格的整合

將分析工作負載遷移到操作層面是由於對敏捷性、即時決策和在業務運作中提取可行的洞察力的需求所驅動。這種整合使組織能夠變得更加資料驅動，並對快速變化的營運環境做出反應。然而，操作層面的基礎設施無法儲存所有歷史資料，因此在操作層面上執行的分析工作負載對歷史資料的存取受到限制。

即時分析的挑戰與解決方案

從分析層面取得歷史資料以供操作層面的分析工作負載使用可能很困難。由於資料重力（data gravity）的影響，不僅資料本身，還有處理資料的應用程式都會受到影響。為瞭解決這個問題，我們需要建立一個能夠克服資料重力限制的解決方案。

信任串流資料的三個特性

根據Frank McSherry的說法，信任串流資料需要具備三個特性：

1. 回應性（Responsiveness）：指對分析資料的同步互動存取，以查詢延遲、每秒查詢次數（QPS）和並發性（終端使用者數量）來衡量。
2. 新鮮度（Freshness）：指分析結果接近即時的程度。資料的新鮮度是衡量其價值隨著時間變化的指標。
3. 一致性（Consistency）：在第6章中已經詳細討論過一致性的重要性。

圖示說明：即時資料的價值變化

此圖示說明瞭即時資料的價值如何隨著時間的推移而降低。橫軸代表時間，縱軸代表資料的價值。

串流處理層的作用

串流處理層為操作層面提供了即時分析處理所需的一切，包括串流資料函式庫和串流處理器。它以表格結構提供即時分析結果，供應用程式和使用者使用。此外，串流處理層的通用視角是由連線和表格組成的網狀結構，類別似於串流資料函式庫。

資料網格（Data Mesh）架構

資料網格是一種概念性的資料架構框架，由Zhamak Dehghani在2019年提出。它主張去中心化的資料管理方式，將資料視為產品，並將所有權分配給不同的域或業務單位。每個域負責自己的資料，促進自治和問責制。資料團隊作為產品團隊，管理所處理資料的整個生命週期，包括品質、檔案和可存取性。

資料網格的四大支柱

1. 域導向的去中心化資料所有權：強調將資料所有權分配給組織內不同的域或業務單位。
2. 將資料視為產品：將資料視為具有自身生命週期、品質標準和檔案管理的產品。
3. 自助式資料基礎設施：建立自助式資料基礎設施，使域團隊能夠自主存取和管理自己的資料。
4. 聯邦計算治理：透過聯邦計算治理來設定共同的標準和政策，同時允許每個域內部進行本地控制。

透過這四個支柱，資料網格框架為組織提供了建立可擴充套件和敏捷的資料架構的指導原則。去中心化的資料所有權和將資料視為產品的做法，旨在克服集中式模型的侷限性，促進自治、效率和改進治理。

資料網格與串流資料網格的整合實踐

資料網格的核心概念與實踐

資料網格（Data Mesh）是一種去中心化的資料架構，強調將資料所有權分配給不同的業務領域或部門。這種架構使得各個領域能夠自主管理自己的資料，並且能夠更靈活地進行資料分析。將分析工作負載移至操作層面（operational plane），可以進一步實作資料和工作負載的去中心化，從而支援資料網格的核心原則。

領域導向的去中心化資料所有權

在資料網格中，不同的業務領域負責管理自己的資料。將分析工作負載移至操作層面，進一步強化了這一原則，使操作團隊能夠直接存取和分析其特定領域內的資料。這種去中心化的資料管理方式，使得操作團隊能夠根據其對自身資料的深入理解，進行更為敏捷和具備上下文意識的分析。

將資料視為產品

將資料視為產品意味著資料不僅被收集和儲存，還需要被分析和消費，作為整體資料產品生命週期的一部分。將分析工作負載移至操作層面，可以確保從分析中獲得的洞察力能夠無縫整合到操作流程中。操作團隊負責其資料的端對端生命週期，包括分析、解釋和應用，以推動業務成果。

-- 建立一個即時分析檢視
CREATE MATERIALIZED VIEW operational_insights AS
SELECT 
    transaction_id,
    SUM(amount) AS total_amount,
    COUNT(*) AS transaction_count
FROM 
    transactions_stream
GROUP BY 
    transaction_id;

內容解密：

此 SQL 程式碼建立了一個即時分析檢視 operational_insights，用於統計交易資料中的 transaction_id、total_amount 和 transaction_count。透過使用串流資料函式庫，這些分析結果可以即時更新，幫助操作團隊做出資料驅動的決策。

串流資料網格的實踐

串流資料網格是資料網格的一種實作方式，它利用即時的串流資料進行分析。這種架構使得不同領域的使用者能夠即時存取和分析資料，從而實作更快速的決策。

串流資料函式庫的作用

串流資料函式庫是一種能夠消費和發射串流資料，並且非同步執行物化檢視的資料函式庫。它使得領域團隊能夠在不深入瞭解串流概念的情況下，建立串流資料產品。透過使用串流資料函式庫，不同領域之間可以建立起一個串流資料的網路，分享和消費資料。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 串流處理架構與資料網格整合實踐

package "機器學習流程" {
    package "資料處理" {
        component [資料收集] as collect
        component [資料清洗] as clean
        component [特徵工程] as feature
    }

    package "模型訓練" {
        component [模型選擇] as select
        component [超參數調優] as tune
        component [交叉驗證] as cv
    }

    package "評估部署" {
        component [模型評估] as eval
        component [模型部署] as deploy
        component [監控維護] as monitor
    }
}

collect --> clean : 原始資料
clean --> feature : 乾淨資料
feature --> select : 特徵向量
select --> tune : 基礎模型
tune --> cv : 最佳參數
cv --> eval : 訓練模型
eval --> deploy : 驗證模型
deploy --> monitor : 生產模型

note right of feature
  特徵工程包含：
  - 特徵選擇
  - 特徵轉換
  - 降維處理
end note

note right of eval
  評估指標：
  - 準確率/召回率
  - F1 Score
  - AUC-ROC
end note

@enduml

此圖示說明瞭串流資料網格中不同領域之間的資料流動和分享過程。

資料網格實施中的挑戰

儘管資料網格具有諸多好處，但其實施過程仍然面臨著諸多挑戰，包括文化轉變、技術複雜性、組織孤島和技能差距等。為了克服這些挑戰，需要進行有效的溝通和協調，並且需要仔細規劃和實施。

串流資料網格中的資料複製與佈署模型

在串流資料網格（Streaming Data Mesh）中，資料複製是實作本地端資料存取的關鍵技術，能夠支援不同領域間的即時資料共用與處理。本章節將探討資料複製的技術細節，以及如何透過不同的佈署模型滿足多樣化的即時分析需求。

資料複製的重要性

在串流資料網格架構中，資料複製扮演著至關重要的角色，確保資料能夠即時地傳遞到需要的領域進行本地端處理。這不僅提高了資料處理的效能，也使得各個領域能夠根據自身需求獨立擴充套件其基礎設施，而不會影響到其他領域。

資料複製的優勢

• 提高效能：透過將資料複製到本地端，減少了資料存取的延遲，提高了分析工作負載的效能。
• 增強安全性：在領域層級實施安全措施，使得每個領域能夠執行自己的安全政策和存取控制。
• 支援擴充套件性：允許各個領域根據自身的業務需求獨立擴充套件其基礎設施。

資料複製技術：Mirror Maker 2.0

Kafka 的 Mirror Maker 2.0（MM2）是一種典型的資料複製工具，用於在不同的 Kafka 叢集之間映象主題（topics）。以下是一個 MM2 的設定範例，用於在兩個 Kafka 叢集之間複製主題：

# 指定叢集別名
clusters = source, destination

# 各叢集的連線資訊
source.bootstrap.servers = kafka-source1:9092,kafka-source2:9092,kafka-source3:9092
destination.bootstrap.servers = kafka-dest1:9092,kafka-dest2:9092,kafka-dest3:9092

# 啟用並設定個別的複製流程
source->destination.enabled = true
source->destination.topics = foo
groups=.*
topics.blacklist="*.internal,__.*"

# 設定新建立的遠端主題的複製因子
replication.factor=3
checkpoints.topic.replication.factor=1
heartbeats.topic.replication.factor=1
offset-syncs.topic.replication.factor=1
offset.storage.replication.factor=1
status.storage.replication.factor=1
config.storage.replication.factor=1

程式碼解析：

此範例展示瞭如何組態 MM2 以實作兩個 Kafka 叢集之間的資料複製。主要步驟包括：

1. 定義叢集別名：指定來源和目的叢集的名稱。
2. 設定叢集連線資訊：提供各叢集的 bootstrap servers 位址。
3. 啟用複製流程：指定來源到目的叢集的複製是否啟用，並定義要複製的主題。
4. 調整複製引數：根據需求調整主題的複製因子和其他相關引數。

佈署模型的多樣性

在串流資料網格中，不同的佈署模型能夠滿足多樣化的即時分析需求。這些模型涵蓋了從需要強一致性的應用程式互動，到僅需進行即時分析的場景。

佈署模型的考慮因素

• 一致性需求：不同的應用場景對資料一致性的要求不同，從強一致性到最終一致性。
• 工作負載型別：不同的工作負載型別，如即時交易處理或歷史資料分析。
• 儲存格式：選擇適合的儲存格式以支援即時分析。

隨著業務需求的不斷演變，串流資料網格將繼續扮演著重要的角色。未來，我們可以期待看到更多關於串流資料處理、分析和應用的創新技術和架構模式。這些創新將進一步推動企業在即時資料處理和分析方面的能力，從而更好地支援業務決策和營運。

一致性串流資料函式庫的佈署模型

在現代的資料處理架構中，串流資料函式庫扮演著越來越重要的角色。對於熟悉資料函式庫但初次接觸串流處理的工程師來說，他們期待更高的資料一致性，而不需要額外模擬或附加功能。具備更高一致性的解決方案可以以較少的努力提供更高的價值。

一致性串流資料函式庫

當應用程式邏輯需要執行複雜的非同步/串流處理時，可以使用一致性串流資料函式庫來建置。這樣的資料函式庫不僅能執行串流處理，還能直接查詢非同步處理的輸出結果，從而簡化基礎設施架構，無需深入的串流知識。目前滿足此需求的解決方案包括 RisingWave 和 Materialize。

圖 10-1：使用一致性串流資料函式庫的操作分析

在圖 10-1 中，像 RisingWave 或 Materialize 這樣的一致性串流資料函式庫展現了其混合特性，位於串流和操作層面的邊界。實線箭頭代表串流資料，虛線箭頭代表應用程式與資料函式庫之間的讀寫互動。一致性串流資料函式庫從 OLTP 資料函式庫中消費資料，並透過串流處理執行分析轉換，將結果儲存在串流資料函式庫中的行式儲存中。

優缺點分析

適用於需要一致性串流處理參與應用程式邏輯，但不需要（太多）來自分析層面的歷史資料的使用案例。

一致性串流處理器與 RTOLAP

如果希望將串流輸出到列式資料函式庫，可以使用像 Pathway 這樣的一致性串流處理器。一致性串流處理器可以在操作層面附近執行推查詢，參與應用程式邏輯，並將輸出寫入像 Kafka 這樣的串流平台，然後由 RTOLAP 資料函式庫（如 Pinot）消費資料並提供服務。

圖 10-2：一致性串流處理器

在圖 10-2 中，展示瞭如何在串流處理器中轉換資料，並將結果寫入資料倉儲/湖倉和 RTOLAP 資料函式庫。RTOLAP 還可以從資料倉儲/湖倉（分析層面）讀取歷史資料，將其與來自一致性串流處理器的即時資料結合，並以低延遲的拉查詢形式提供給操作層面。

優缺點分析

適用於需要大多數或所有歷史資料可用於使用者面對的分析，並需要一致性串流處理器參與應用程式邏輯的使用案例。

最終一致性 OLAP 串流資料函式庫

如果擁有單獨的串流處理器和 OLAP 資料函式庫使得基礎設施過於複雜，可以利用像 Proton 這樣的 OLAP 串流資料函式庫來將所有分析工作負載整合到一個解決方案中。但由於其最終一致性的特性，它不應該參與應用程式邏輯。

圖 10-3：最終一致性 OLAP 串流資料函式庫

在圖 10-3 中，OLTP 和串流資料函式庫之間的資料移動是單向的。應用程式可以利用 OLAP 的列式儲存進行低延遲查詢。

串流OLAP資料函式庫的最終一致性架構

圖10-3. 最終一致性串流OLAP資料函式庫

由於Proton是一種串流資料函式庫，它能夠將其串流處理的輸出寫入Kafka。這使得其他資料函式庫可以消費分析串流，以在其他資料函式庫中建立副本。但是，由於Proton嵌入了ClickHouse（一種RTO-LAP），它已經具備了列式儲存，能夠以低延遲提供分析查詢。將分析結果輸出到Kafka具有將分析結果即時分發到其他全球區域的額外功能。以下是其優缺點的概述：

優點

• 資料的新鮮度可達毫秒至秒級。
• 提供更多甚至全部的歷史資料，為即時資料提供更多上下文。
• Proton可以發出分析變更，以允許開發人員建立分析結果的副本。
• 更簡單的解決方案，融合了串流處理和OLAP技術。
• 提供單一的SQL引擎來建立推播和提取查詢。
• 不臃腫。

缺點

• 僅具有最終一致性；不應參與應用邏輯。

使用串流OLAP資料函式庫的最大好處是，它能夠在單一查詢引擎和介面中平衡推播和提取查詢。它減少了對單一工程師的工作量，不像包含獨立串流處理器和OLAP資料函式庫的解決方案。Proton為即時分析提供了一個簡單的解決方案。

使用場景

使用此解決方案可以減少基礎設施和工程複雜性，並允許存取更多歷史資料以進行導向使用者的分析。

最終一致性串流處理器與RTOLAP

圖10-4. 最終一致性串流處理器與RTOLAP

這種解決方案在當今許多高規模、即時應用中得到了驗證：

優點

• 資料的新鮮度可以達到毫秒至秒級。
• 可以將歷史資料與即時資料結合，提供完整的分析檢視。

缺點

• 這是一個複雜且臃腫的解決方案，可能導致更高的成本。
• 由於Flink具有最終一致性，因此不應參與應用邏輯。
• 由於串流處理器和即時OLAP執行引擎是分開的，因此該解決方案不提供單一的SQL引擎來進行推播和提取查詢，這可能導致更高的工程和組織壓力。

使用場景

當您的使用案例需要在應用程式中為導向使用者的分析提供更多歷史資料時，請使用此解決方案。在用維度串流豐富事實串流時，一致性不應成為一個重大問題。

最終一致性串流處理器與HTAP

圖10-5. 最終一致性串流處理器與HTAP

在您希望將分析工作負載保持在操作平面附近或內部的情況下，使用HTAP資料函式庫與OLTP資料函式庫結合可以很方便。您可以新增一個最終一致性串流處理器來捕捉歷史資料，並將其傳送到您的資料倉儲或湖倉。

優點

• 提供毫秒級的資料新鮮度。
• HTAP資料函式庫具有列式儲存，用於快速分析查詢。
• 基礎設施複雜度低。

缺點

• 歷史資料有限。
• 在實施HTAP資料函式庫中保留的歷史資料的保留策略時，複雜度增加。
• 串流處理器不能參與應用邏輯。

使用場景

如果您的使用案例需要毫秒級的資料新鮮度，並且只需要一小部分歷史資料用於導向使用者的分析，請使用此解決方案。

ksqlDB

ksqlDB的使用場景與限制

在第6章中，我們討論了ksqlDB提供的保證（“連續改進”，類別似於“最終一致性”）。ksqlDB根據底層的JVM函式庫Kafka Streams構建，用於在微服務內佈署。微服務作為應用程式後端的一部分佈署在操作平面中。

我們建議僅將Kafka Streams和ksqlDB用於較簡單的串流處理操作。JOIN操作很難正確實作，尤其是當結合僅追加的“串流”和類別似變更日誌的“表”時。ksqlDB僅支援SQL語法和語義的子集（例如，不支援自JOIN，不支援巢狀JOIN）。即使擁有豐富的串流處理專家團隊，實施不一致邏輯的風險也很高。

優點

• 資料的新鮮度。
• 串流處理能力。
• 啟用使用物化檢視（TABLE）執行點查詢，以支援僅批次的目的地。

缺點

• 僅支援Kafka作為來源/接收器。
• 需要大量的串流處理專業知識。
• 複雜的串流處理操作難以正確實作。
• 不支援完整的SQL語法和語義。

增量檢視維護（IVM）

IVM解決方案

支援IVM的解決方案，如Feldera、PeerDB或Epsio，也可用於支援根據批次的點查詢對預處理的新鮮資料。與ksqlDB不同，這些解決方案與PostgreSQL等操作型資料函式庫更緊密地整合，不需要使用Kafka作為中間層。

優點

• 資料的新鮮度。
• 完整的SQL語法和語義。
• 一致性。
• 啟用點查詢。
• 將串流方面引入資料函式庫世界。

缺點

• 受限於各自供應商支援的來源/接收器。

這些解決方案還可以提高IT組織對非同步和連續處理資料的理解，並作為進入串流、串流處理和串流資料函式庫世界的“入口”。它們仍然可以以相同的方式操作（例如，PeerDB和Epsio），甚至可以在Postgres生態系統內部操作，但它們的操作方式已經接近串流、串流處理和串流資料函式庫——這可能是整合大型組織中較大架構所必需的。