流處理系統一致性與混合資料函式庫

在流處理系統中，資料一致性是確保資料準確性和可靠性的關鍵因素。最終一致性雖然是常見的模型，但可能導致錯誤結果。以 Flink SQL 為例，在計算銀行交易總和時，若未妥善處理時間戳同步，可能產生大量錯誤結果。透過在 GROUP BY 子句中加入時間戳，可以改善一致性，但可能增加狀態儲存負擔。MiniBatch 技術的引入，則可在效能和一致性之間取得平衡。然而，一致性和延遲之間存在權衡，需要根據應用場景進行調整。混合資料系統的出現，整合了串流處理和資料函式庫的特性，彌合了不同工作負載之間的差距。狀態儲存的實作方式也影響著系統的效能和一致性。混合資料系統的發展趨勢，將進一步簡化基礎設施，並提升即時分析能力。

內部一致性與最終一致性在流處理系統中的比較

流處理系統的一致性問題

在流處理系統中，一致性是一個至關重要的議題。最終一致性（Eventual Consistency）是許多流處理系統的預設行為，但這種一致性模型可能導致不正確或不一致的結果。為了說明這一點，本章使用了一個簡單的範例，計算一系列銀行交易的總和。

Flink SQL 的一致性問題

在預設情況下，Flink SQL 是一種最終一致性的流處理系統。當使用 Flink SQL 計算銀行交易總和時，它輸出了約 80,000 個結果，其中大多數是錯誤的。要解決這個問題，可以透過在 GROUP BY 子句中新增時間戳（ts）來實作顯式的操作員輸入同步。

CREATE VIEW balance(account, balance) AS
SELECT
    credits.account,
    credits - debits as balance
FROM
    credits,
    debits
WHERE
    credits.account = debits.account
AND credits.ts = debits.ts;

內容解密：

CREATE VIEW 陳述式：建立一個名為 balance 的檢視，包含 account 和 balance 兩個欄位。
SELECT 陳述式：從 credits 和 debits 表中選擇資料，並計算每個帳戶的餘額。
WHERE 子句：確保只有當 credits 和 debits 表中的 account 和 ts 欄位相匹配時，才會計算餘額。

為何這種修復方法可能存在問題

雖然上述修復方法可以解決範例中的一致性問題，但它可能導致其他問題：

無限制增長的內部狀態儲存：在 GROUP BY 子句中新增 ts 可能導致內部狀態儲存無限制增長，從而耗盡 Flink 的記憶體。
難以理解和維護的 SQL 程式碼：對於來自資料函式庫背景的工程師來說，很難理解為什麼直觀的 SQL 程式碼會產生錯誤的結果，以及為什麼需要進行額外的修復。
難以推廣的一致性修復方法：在最終一致性的流處理系統中，顯式地新增一致性修復方法只能根據具體情況進行。每個新的使用案例可能需要不同的修復方法。
潛在的細微不一致性：即使進行了修復，仍然可能存在細微的不一致性。例如，當有多個輸入主題時，具有相同時間戳的交易可能會被錯誤地合併。

MiniBatch 在 Flink 1.19+ 中的應用

Flink 1.19 引入了 MiniBatch 語義，用於最佳化 JOIN 操作的效能。透過適當地組態 MiniBatch，可以顯著提高 Flink 的效能，並達到更高的 –一致性。

要啟用 MiniBatch，需要組態以下三個引數：

SET 'table.exec.mini-batch.enabled' = 'true';
SET 'table.exec.mini-batch.allow-latency' = '5S';
SET 'table.exec.mini-batch.size' = '5000';

內容解密：

table.exec.mini-batch.enabled：啟用 MiniBatch 最佳化。
table.exec.mini-batch.allow-latency：設定 MiniBatch 最佳化的最大延遲時間。
table.exec.mini-batch.size：設定要緩衝的最大輸入記錄數。

一致性與延遲的權衡

在流處理系統中，一致性和延遲是兩個相互對立的因素。要實作更高的 –一致性，可能需要犧牲一些低延遲。需要區分兩種不同的延遲：

處理時間延遲（Processing Time Latency）：流處理系統輸出任何查詢結果所需的時間。
端對端延遲（End-to-End Latency）：流處理系統輸出一致的查詢結果所需的時間。

新一代資料系統的演進：混合資料系統的崛起

在前一章中，我們探討了內部一致性串流處理系統的優勢與挑戰。本章將進一步擴充套件視野，探討新興的混合資料系統（Hybrid Data Systems）如何回應現代即時事件驅動應用程式的需求。這些系統雖然不完全等同於本文所定義的串流資料函式庫，但它們分享許多特徵，彌合了關聯式、分析型與串流工作負載之間的差距。

混合資料系統的多重視角

混合資料系統至少結合兩種不同的技術觀點。以串流資料函式庫為例，它同時具備串流處理和資料函式庫兩種特性：

從串流處理角度出發：串流資料函式庫是一種能夠將其狀態儲存暴露給客戶端進行查詢的串流處理器。
從資料函式庫角度出發：串流資料函式庫是一種能夠消費和傳送串流資料，並非同步執行物化檢視的資料函式庫。

這種雙重定義方式拓展了混合系統的可應用範圍和使用案例。例如，在串流處理的一致性問題上，串流資料函式庫工程師不得不從資料函式庫的角度重新審視現有的串流處理器，從而發現並解決一致性不足的問題。

狀態儲存的多樣實作

狀態儲存（State Store）是混合資料系統中的核心元件，可以透過多種方式實作，包括鍵值儲存（Key-Value）、行式儲存（Row-Based）和列式儲存（Column-Based）。不同的實作方式決定了系統能夠支援的使用案例，例如高一致性需求或低延遲分析查詢。

資料平面的交集：即時系統的定位

為了更好地理解這些新興系統，我們可以透過文氏圖（Venn Diagram）來呈現即時系統在目前的技術格局中的位置（圖 7-1）。這種視覺化方法不僅幫助我們辨別不同的使用案例，也揭示了即時分析場景中的佈署模式。

此圖示說明瞭串流處理與資料函式庫技術如何融合形成混合資料系統，並進一步衍生出串流資料函式庫，支援即時分析和事件驅動應用。

混合資料系統的發展趨勢

透過同時考量串流處理和資料函式庫兩種觀點，我們可以預測下一代資料函式庫的發展方向。這些新興的混合系統正在減少基礎設施的複雜性，提高開發者的易用性，並推動即時分析技術的進步。

內容解密：

圖表採用 Plantuml 製作，清晰展示了串流處理與資料函式庫技術的融合路徑。
圖表中的節點代表不同的技術領域，箭頭表示技術的演進或融合關係。
這種視覺化呈現有助於理解混合資料系統在即時分析領域中的角色和定位。

本章探討的混合資料系統代表了資料管理技術的一個重要發展方向。隨著這些系統的不斷成熟，我們可以期待看到更多創新性的應用案例和更強大的即時分析能力。在下一章中，我們將進一步探討這些新興技術對未來資料架構的影響。

資料處理的三個層面：運作、分析與串流

在探討現代資料處理架構時，我們經常會接觸到三個重要的資料層面：運作資料層（Operational Data Plane）、分析資料層（Analytical Data Plane）以及串流資料層（Streaming Data Plane）。這三個層面各自承擔不同的角色，並在某些方面相互重疊，形成了現代資料處理的複雜生態。

串流資料層的角色

串流資料層是連線運作和分析層面的橋樑。它負責捕捉和處理即時資料，使其能夠無縫地流入分析層進行儲存、分析和洞察。因此，串流資料層使得組織能夠結合即時和歷史資料，做出更快速的資料驅動決策。

三個資料層面的詳細解析

運作資料層（Operational Data Plane）：主要包含線上交易處理（OLTP）資料函式庫，這些資料函式庫使用根據行的儲存，並且強調一致性。此層面也包含了使用這些OLTP資料函式庫的應用程式。
分析資料層（Analytical Data Plane）：包含線上分析處理（OLAP）資料函式庫，這些資料函式庫使用欄位導向的儲存，並且通常具有最終一致性。這些OLAP資料函式庫針對分析查詢進行了最佳化。
串流資料層（Streaming Data Plane）：包含源聯結器和接收聯結器，分別負責將靜態資料轉換為流動資料，以及將流動資料寫入即時OLAP資料函式庫以實作低延遲服務。串流資料層利用Kafka和Kafka Connect等平台來複製和服務串流資料。同時，這一層面也包含了狀態化的串流處理器和串流資料函式庫。

重疊區域：混合式交易/分析資料函式庫

當我們觀察這三個層面的重疊區域時，會發現一些有趣的架構。例如，運作和分析層面的重疊區域代表了混合式交易/分析處理（HTAP）資料函式庫。這些資料函式庫能夠同時處理OLTP和OLAP工作負載，實作了更及時的商業決策。

HTAP 資料函式庫

HTAP 資料函式庫結合了 OLTP 和 OLAP 的特性，能夠在不破壞交易處理的同時進行分析查詢。Gartner 在 2014 年提出了 HTAP 的概念，將其定義為一種新興的應用架構，能夠打破交易處理和分析之間的壁壘。

HTAP 資料函式庫內部通常包含兩種儲存型別：記憶體內儲存和持久儲存。透過利用記憶體內資料函式庫，HTAP 資料函式庫能夠在執行寫入交易的同時，對「飛行中」的交易執行分析查詢。

現有的 HTAP 資料函式庫

目前市場上有多個 HTAP 資料函式庫，包括：

名稱	供應商	儲存實作
Unistore	Snowflake	所有混合表中的資料同時儲存在行儲存和欄儲存中。資料變更時，會同步更新行儲存並非同步重新整理到欄儲存。
SingleStoreDB	SingleStore	支援兩種型別的表格：根據磁碟的欄式儲存（預設表格型別）和記憶體內行式儲存。
TiDB	PingCAP	支援交易型鍵值儲存和欄式儲存。TiKV 是一個分散式且具交易性的鍵值資料函式庫，提供符合 ACID 的交易 API。TiFlash 是 TiDB 的分析擴充套件，透過欄式儲存和 MPP 查詢引擎支援 TiDB。
HydraDB	Hydra	開源資料函式庫，支援稱為堆積疊表格的交易型行式儲存和欄式儲存佈局，後者是預設佈局。

HTAP 資料函式庫的限制

雖然 HTAP 資料函式庫能夠有效地服務簡單的即時分析，但它們也有一些限制，例如無法像純 OLAP 系統那樣儲存歷史資料。因此，在需要大量歷史資料的情況下，可能需要同時使用 OLAP 和 HTAP 資料函式庫，這又回到了資料分隔的問題。

混合資料函式庫的崛起與其在即時分析中的角色

在現代資料處理的架構中，不同型別的資料函式庫系統各自扮演著特定的角色，包括線上交易處理（OLTP）、線上分析處理（OLAP）以及串流處理系統。然而，這些系統各自的最佳化和擴充套件性需求往往導致基礎設施的複雜性和資料整合的挑戰。混合資料函式庫的出現正是為了應對這些挑戰，特別是在即時分析領域。

混合資料函式庫的三元結構

Figure 7-5 展示了混合資料函式庫的三元重疊結構，分別是 HTAP（混合交易/分析處理）、串流 OLTP 資料函式庫和串流 OLAP 資料函式庫。這三者的重疊區域代表了一種新型的資料函式庫系統，能夠同時滿足交易處理、即時分析和串流資料處理的需求。

此圖示展示了混合資料函式庫的三元結構及其交集。

內容解密：

HTAP：結合了 OLTP 和 OLAP 的能力，使得系統能夠同時處理交易和分析查詢。
串流 OLTP：專注於即時交易處理，並具備處理串流資料的能力。
串流 OLAP：針對即時分析進行最佳化，能夠處理和分析串流資料。

其他混合資料函式庫

在研究過程中，我們發現了一些不完全符合上述分類別的混合資料函式庫系統，例如 PeerDB、Epsio 和 Turso。這些系統透過結合不同的技術（如 Postgres 和串流處理引擎）來提供獨特的功能。

PeerDB

PeerDB 是一個根據 Postgres 的資料移動平台，能夠快速、簡單地在 Postgres 和其他系統之間同步、轉換和載入資料。

Epsio

Epsio 透過外部非同步物化檢視來更新查詢結果，無需重新計算整個資料集，從而提供即時且最新的結果。

Turso

Turso 允許開發者在本地開發並全球複製到多個位置，提供同步存取資料的能力。

Redpanda

Redpanda 結合了串流平台和 Apache Iceberg，能夠在不行動資料的情況下查詢資料，減少了分析基礎設施的足跡。

混合系統的動機

串流處理系統和供應商試圖透過提供類別似資料函式庫的體驗來簡化串流處理的採用，降低使用門檻。同時，OLTP 資料函式庫也在嘗試採用 OLAP 和串流處理的特性，以更好地服務於即時分析需求和減少資料不一致性的問題。

PostgreSQL 對混合資料函式庫的影響

許多混合資料函式庫根據 PostgreSQL（或稱 Postgres），這得益於 Postgres 的可擴充套件性、效能最佳化、豐富的第三方生態系統和企業採用率。Postgres 的受歡迎程度預計將推動更多混合資料函式庫的發展，使其提供類別似 Postgres 的體驗。

近邊緣分析

將分析功能帶到操作層面是為了使資料洞察更易取得和更具反應性。混合資料函式庫在這方面扮演了關鍵角色，透過減少延遲來實作即時決策。

下一代混合資料函式庫的演進與實時分析

在當今的資料驅動環境中，組織對於實時資料處理和分析的需求日益增長。為了滿足這一需求，新一代的混合資料函式庫正在不斷演進，提供更全面的資料處理能力。

實時分析的最佳化

實時分析的關鍵在於提供即時的洞察力，而無需複製整個分析平面。使用者通常不需要存取整個資料倉儲，而是需要特定且相關的資料子集來支援他們的即時決策。這種最佳化的資料傳遞確保了能夠迅速獲得有價值的洞察。

某些分析工作負載永遠不會進入操作平面，因為它們通常涉及：

聚合大量歷史資料，儲存在 OLAP 資料函式庫中。
訓練機器學習模型，需要專門的系統。
需要高度分散的系統來分割資料以進行大規模平行處理。
需要靈活性來執行即席查詢，以向內部使用者提供資料。

下一代混合資料函式庫

圖 7-6 提供了當前實時系統格局的視覺表示。它是組織目前用於滿足其實時資料處理需求的技術和解決方案的快照。這些重疊區域形成了花瓣狀，是實時分析最新趨勢和創新最為顯著的地方。它們包括 HTAP、流式 OLTP 資料函式庫和流式 OLAP 資料函式庫。

圖 7-6 的中心區域標識了下一代實時資料函式庫的特徵

狀態化的流處理
用於分析工作負載的列式儲存
用於操作工作負載的一致性

截至本文出版時，圖 7-6 的下一代區域內尚不存在任何資料函式庫。屬於花瓣區域的資料函式庫需要新增各自缺失的功能才能獲得下一代的資格。例如：

HTAP 資料函式庫可以新增增量檢視維護（IVM），就像狀態化的流處理器一樣。它們還需要與 Kafka 等流式平台整合。
流式 OLTP 資料函式庫只需要提供根據列的儲存。它們可以透過嵌入式 OLAP 資料函式庫（如 DuckDB）來實作這一點。
流式 OLAP 資料函式庫可以為其流處理器新增一致性，以便更好地參與應用程式的實際邏輯。

下一代流式 OLTP 資料函式庫

下一代流式 OLTP 資料函式庫有三個領域可以繼續改進。首先是改進其資料一致性模型。流處理中的資料一致性是參與應用程式邏輯所必需的。其次是改進對變更資料或 WAL 的存取。CDC 使用案例需要執行在專用和分散式叢集中的聯結器。第三，流式 OLTP 資料函式庫將開始整合列式儲存格式，以提供分析資料給應用程式。

圖 7-7：下一代流式 OLTP 將 CDC 資料直接推播到符合 Kafka 的主題中

透過發出變更，資料函式庫系統消除了為每個可能的整合點構建聯結器以攝取和輸出資料的需求。開發這些聯結器耗時且昂貴，而且還限制了系統一次只能處理少數使用案例，直到開發出一個在財務上可行的解決方案為止。此外，一些 CDC 聯結器通常難以管理，會導致諸如記憶體不足或磁碟空間不足等異常。原生發出 CDC 事件可以防止使用外部 CDC 解決方案時遇到的問題。

此圖示

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 流處理系統一致性與混合資料函式庫

package "資料庫架構" {
    package "應用層" {
        component [連線池] as pool
        component [ORM 框架] as orm
    }

    package "資料庫引擎" {
        component [查詢解析器] as parser
        component [優化器] as optimizer
        component [執行引擎] as executor
    }

    package "儲存層" {
        database [主資料庫] as master
        database [讀取副本] as replica
        database [快取層] as cache
    }
}

pool --> orm : 管理連線
orm --> parser : SQL 查詢
parser --> optimizer : 解析樹
optimizer --> executor : 執行計畫
executor --> master : 寫入操作
executor --> replica : 讀取操作
cache --> executor : 快取命中

master --> replica : 資料同步

note right of cache
  Redis/Memcached
  減少資料庫負載
end note

@enduml

內容解密：

此圖示展示了現有的資料函式庫系統如何透過新增特定的功能來演進成下一代混合資料函式庫。例如，HTAP 資料函式庫透過新增增量檢視維護（IVM）功能，可以轉變為下一代 HTAP。流式 OLTP 資料函式庫透過新增列式儲存功能，可以提供更好的分析能力。同樣，流式 OLAP 資料函式庫透過新增一致性，可以更好地參與應用程式邏輯。每個步驟都是為了提高資料函式庫系統在實時分析和操作方面的能力。

下一代混合資料函式庫的發展趨勢

現今的即時資料處理需求促使混合資料函式庫（Hybrid Databases）不斷演進，以滿足不同的業務需求。本章節將探討混合資料函式庫，特別是在串流處理、即時分析以及零ETL（Zero-ETL）架構方面的進展。

下一代串流RTOLAP資料函式庫

現有的即時線上分析處理（RTOLAP）資料函式庫通常缺乏內建的串流處理能力。Proton是一種創新性的解決方案，它將串流處理與OLAP系統融合在一起，提供更先進的資料擷取功能，並能有效平衡推播（Push）和提取（Pull）查詢的需求。

大多數現有的RTOLAP系統嚴重依賴外部的串流處理器，這增加了整個即時架構的複雜性和維護工作量。透過在資料擷取過程中加入串流處理功能，可以減少對外部串流處理器的依賴，從而簡化系統架構。

串流處理與推播查詢

在傳統的資料處理流程中，資料工程師通常負責撰寫推播查詢，而資料分析師則負責提取查詢。這兩個角色往往位於不同的團隊中，導致協調上的困難。將特定的資料轉換邏輯放入推播查詢中，可以讓串流處理系統直接發布資料給特定的訂閱者，從而提高資料處理的效率。

下一代HTAP資料函式庫

下一代混合事務分析處理（HTAP）資料函式庫將利用其混合儲存能力，結合增量檢視維護（IVM）技術。IVM是一種非同步計算和更新物化檢視的方法，只對檢視進行增量修改，而不需要重新評估整個內容。這種方法與串流處理的概念非常相似。

透過實施IVM，HTAP資料函式庫可以將事務資料從根據行的格式轉換為根據列的格式，以支援低延遲的分析查詢，而無需將資料匯出到外部系統。此外，HTAP資料函式庫還可能具備從分析平面匯入有限歷史資料的能力，為即時分析資料提供有限的歷史背景。

零ETL與近零ETL架構

零ETL是一種由Amazon Web Services（AWS）首次提出的模式，旨在簡化從線上交易處理（OLTP）資料函式庫到線上分析處理（OLAP）資料函式庫的資料整合過程。零ETL的核心思想是消除或最小化傳統的ETL資料管道需求。

ETL模型的演進

圖8-1展示了現有的ETL解決方案，從頂部的HTAP資料函式庫（無需ETL）到底部的「將資料函式庫內翻外」（Turn-the-Database-Inside-Out）分散式解決方案。越往下，解決方案越分散，複雜度也越高。左側是交易型資料函式庫，右側是列式資料函式庫。在三角形的中間位置，可以找到零ETL的實作方案。

零ETL的定義

零ETL是一種資料整合和分析方法，旨在最小化或消除傳統的ETL流程。傳統的ETL流程涉及從來源系統中提取資料，將其轉換以滿足目標系統的要求，然後將其載入到目的地系統中。圖8-2展示了零ETL的架構概述。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。