串流資料函式庫架構與實作技術探討

串流資料函式庫整合串流處理和資料函式庫技術，實作即時資料處理和分析。它克服了傳統資料函式庫批次處理的限制，能同時處理靜態和流動資料。文章將探討串流資料函式庫的架構、核心元件如狀態儲存和追加表格，以及其工作流程，包含資料接入、建立源表格和物化檢視。此外，文章也將探討 CDC 聯結器的應用、串流資料函式庫的優勢、技術選型考量、未來趨勢預測，以及如何結合 SQL 和物化檢視進行串流資料處理和分析。

串流資料函式庫簡介

串流資料函式庫是一種結合了串流處理器和資料函式庫的系統，能夠同時處理即時資料流和分析查詢。串流資料函式庫的出現是為瞭解決傳統架構中資料流動和處理的複雜性。

串流拓撲架構

串流拓撲是指資料在不同元件之間的流動路徑。常見的串流拓撲包括：

• 資料函式庫 → 主題（Topic）→ 串流處理器 → 主題 → 資料函式庫
• OLTP（線上交易處理）資料函式庫 → 主題 → 串流處理器 → 主題 → RTOLAP（即時線上分析處理）

在這些拓撲中，具體化檢視（Materialized View）的存放位置可能存在於串流處理器的內部狀態儲存、輸出主題或目的端資料函式庫中。

串流資料函式庫的優勢

串流資料函式庫透過整合串流處理器和資料函式庫，消除了中間主題的需求，使得系統更加簡潔高效。這種架構支援推播查詢（Push Query）和提取查詢（Pull Query），前者非同步執行於背景，後者則是由使用者發起的分析查詢。

推播查詢與提取查詢

推播查詢類別似於串流處理器，不斷更新具體化檢視。提取查詢則是使用者發起的即時分析查詢，例如：

-- 建立具體化檢視
CREATE MATERIALIZED VIEW CUSTOMER_CLICKS
AS SELECT * FROM CLICK_EVENTS E
JOIN CUSTOMERS C ON E.ip = C.ip;

-- 提取查詢
SELECT * FROM CUSTOMER_CLICKS
WHERE id = '123';

內容解密：

1. CREATE MATERIALIZED VIEW：建立一個具體化檢視，用於儲存查詢結果。
2. AS SELECT * FROM CLICK_EVENTS E JOIN CUSTOMERS C ON E.ip = C.ip;：定義具體化檢視的查詢邏輯，將 CLICK_EVENTS 和 CUSTOMERS 表根據 ip 欄位進行連線。
3. SELECT * FROM CUSTOMER_CLICKS WHERE id = '123';：對具體化檢視進行查詢，取得特定客戶的點選事件資料。

欄位導向的串流資料函式庫

欄位導向的串流資料函式庫適用於分析查詢，特別是在即時資料分析場景中，如點選事件分析。這種架構允許使用者使用 SQL 編寫推播和提取查詢，並將結果儲存在同一處。

列式儲存與行式儲存的比較

列式儲存適合於分析查詢，而行式儲存則最佳化了交易處理的讀寫操作。兩種儲存方式在串流資料函式庫中都有其應用場景。

圖示：串流資料函式庫架構

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title 圖示：串流資料函式庫架構

rectangle "資料流" as node1
rectangle "訂閱" as node2
rectangle "輸出" as node3
rectangle "儲存" as node4
rectangle "查詢" as node5

node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5

@enduml

此圖示展示了從 OLTP 資料函式庫到串流資料函式庫的資料流動路徑。

圖示內容解密：

1. OLTP 資料函式庫到主題：資料從 OLTP 資料函式庫流入主題。
2. 主題到串流處理器：串流處理器訂閱主題並處理資料。
3. 串流處理器到輸出主題：處理後的資料輸出到另一個主題。
4. 輸出主題到串流資料函式庫：最終資料儲存在串流資料函式庫中。
5. 串流資料函式庫到使用者應用：使用者透過查詢串流資料函式庫取得分析結果。

串流資料函式庫的架構與挑戰

串流資料函式庫是一種結合了串流處理和資料函式庫功能的系統，能夠即時處理和分析大量的資料串流。這種資料函式庫的出現是為瞭解決傳統的 OLTP（線上交易處理）和 OLAP（線上分析處理）系統之間的差異和複雜性。

串流資料函式庫的型別

目前主要有兩種型別的串流資料函式庫：根據列（row-based）的串流資料函式庫和根據欄（column-based）的串流資料函式庫。

根據列的串流資料函式庫

根據列的串流資料函式庫適合處理即時的交易資料，如 CRUD（建立、讀取、更新、刪除）操作。這種資料函式庫的優點是能夠即時處理大量的交易資料，但是對於分析型查詢（如聚合查詢）則不是最佳選擇。

-- 建立一個根據列的串流資料函式庫的表示例
CREATE TABLE transactions (
  id INT,
  amount DECIMAL(10, 2),
  timestamp TIMESTAMP
);

內容解密：

• CREATE TABLE transactions：建立一個名為 transactions 的表格，用於儲存交易資料。
• id INT：定義一個整數欄位 id，用於儲存交易的唯一識別碼。
• amount DECIMAL(10, 2)：定義一個小數欄位 amount，用於儲存交易金額，精確到小數點後兩位。
• timestamp TIMESTAMP：定義一個時間戳欄位 timestamp，用於儲存交易發生的時間。

根據欄的串流資料函式庫

根據欄的串流資料函式庫則是針對分析型查詢進行了最佳化，適合進行聚合查詢等操作。這種資料函式庫能夠高效地處理和分析大量的資料。

CQRS 模式

CQRS（命令查詢責任分離）是一種架構模式，將讀取和寫入操作的責任分離到不同的元件中。在 CQRS 中，讀取和寫入模型是分開的，這使得系統能夠更好地擴充套件和最佳化。

圖示：CQRS 模式

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title 圖示：CQRS 模式

rectangle "命令" as node1
rectangle "事件" as node2
rectangle "查詢" as node3
rectangle "更新" as node4

node1 --> node2
node2 --> node3
node3 --> node4

@enduml

此圖示展示了 CQRS 模式的基本架構，客戶端傳送命令到寫入模型，寫入模型產生事件並更新讀取模型，客戶端再從讀取模型查詢資料。串流資料函式庫則是用於更新讀取模型的資料來源。

SQL 表達能力

SQL 表達能力是指 SQL 能夠有效地表示複雜的資料操作和查詢的能力。將串流處理和 OLAP 資料函式庫的 SQL 引擎合併可能會帶來各種挑戰，如效能不匹配、延遲、資源分配、資料建模差異等。

合併 SQL 引擎的挑戰

1. 效能不匹配：串流處理需要低延遲，而 OLAP 資料函式庫則需要高效的查詢效能。
2. 延遲：串流處理要求即時處理，而 OLAP 資料函式庫則優先考慮查詢最佳化。
3. 資源分配：串流處理和 OLAP 資料函式庫有不同的資源需求，需要適當地分配資源。
4. 資料建模差異：串流處理通常處理原始或半結構化的資料，而 OLAP 資料函式庫需要結構化的資料。
5. 資料一致性：確保串流處理和 OLAP 資料函式庫之間的資料一致性是一個挑戰。

綜上所述，串流資料函式庫是一種能夠即時處理和分析大量資料串流的系統，但同時也面臨著許多挑戰，如 SQL 表達能力、效能不匹配等。採用 CQRS 模式和合適的串流資料函式庫型別可以幫助解決這些挑戰。

串流資料函式庫的挑戰與優勢

串流資料函式庫（Streaming Database）結合了串流處理（Stream Processing）與資料函式庫技術，提供即時資料處理和分析能力。然而，這種整合也帶來了一些挑戰。

挑戰

1. 查詢最佳化

   • OLAP（Online Analytical Processing）資料函式庫針對複雜分析查詢提供先進的最佳化技術。串流處理器可能無法提供相同程度的最佳化，可能導致OLAP查詢的效能不佳。

2. 結構演變

   • 串流處理器在處理結構演變時可能比OLAP資料函式庫更具彈性。合併SQL引擎可能會在處理演變中的資料結構時遇到困難。

3. 維護與更新

   • 管理同時處理串流和OLAP工作負載的SQL引擎的更新和維護更具挑戰性，因為更新必須滿足兩種使用案例的需求。

緩解挑戰的方法

為了緩解這些挑戰，必須進行仔細的架構規劃、徹底的效能測試，並深入瞭解每個SQL引擎的特定使用案例。

OLTP與串流處理器SQL引擎合併的優勢

將OLTP（Online Transactional Processing）與串流處理器的SQL引擎合併可能比將OLAP與串流處理器的SQL引擎合併更容易。這是由於OLTP和串流處理器在資料儲存和處理特性上的相似性：

• 資料格式

  • OLTP資料函式庫通常使用根據列的儲存模型，非常適合捕捉個別交易記錄。串流處理器也以列式格式處理資料，因為它們處理即時事件。這種資料模型的對齊可以促進更平滑的整合和相容性。

• 即時性質

  • OLTP系統和串流處理器都在一定程度上處理即時資料。雖然處理需求可能不同，但共同關注即時資料處理可以使它們的SQL引擎更容易合併。

例項分析

-- 建立一個即時匯總檢視
CREATE MATERIALIZED VIEW sales_summary AS
SELECT 
    product_id,
    SUM(amount) AS total_sales
FROM 
    sales_stream
GROUP BY 
    product_id;

內容解密：

• CREATE MATERIALIZED VIEW 陳述式用於建立一個即時更新的匯總檢視。
• sales_summary 是檢視名稱，根據 sales_stream 串流資料計算每個產品的總銷售額。
• SUM(amount) AS total_sales 表示對 amount 欄位進行求和，並將結果命名為 total_sales。
• 即時匯總檢視使得查詢最新銷售資料更加高效，無需每次都重新計算。

串流可除錯性

串流資料函式庫透過提供更高階的物化檢視（Materialized Views）來簡化除錯過程。這些檢視可以儲存在根據列或根據行的儲存中，使得驗證結果更加容易。

優勢

1. 熟悉的SQL介面

   • 許多串流資料函式庫提供類別似SQL的查詢語言，用於定義串流處理操作。如果您已經熟悉SQL，由於語言的熟悉性，除錯可以更加直接。

2. 更簡單的邏輯

   • 串流資料函式庫通常提供更高層次的抽象，簡化複雜的串流處理任務。這可以導致更簡單的邏輯，從而使除錯更加容易。

3. 整合的生態系統

   • 串流資料函式庫通常是更大資料生態系統的一部分。透過將串流處理器和資料函式庫結合在一個系統中，可以實作與其他資料工具和監控解決方案更好的整合。

現有的串流資料函式庫實作

| 名稱 | 授權 | 狀態儲存實作 | 使用案例 | |

|

|

|

| | ksqlDB | Confluent Community License | RocksDB（LSM樹鍵值儲存） | CQRS、推播查詢 | | RisingWave | Apache 2 | 根據列 | CQRS、推播查詢、單行查詢 | | Materialize | Business Source License (BSL) | 根據列 | CQRS、推播查詢、單行查詢 | | Timeplus (Proton) | Apache 2 | 根據欄 | 分析性推播和提取查詢 |

串流資料函式庫架構解析

串流資料函式庫（Streaming Database）是一種專門為處理實時串流資料而設計的資料函式庫系統。與傳統的資料函式庫不同，串流資料函式庫能夠高效地處理持續流入的資料，並提供即時的查詢和分析能力。

串流資料函式庫的核心元件

串流資料函式庫的核心元件包括狀態儲存（State Store）和追加表格（Append Tables）。狀態儲存用於儲存物化檢視（Materialized Views），而追加表格則用於暫存原始的串流資料。

狀態儲存

狀態儲存是串流資料函式庫中用於儲存物化檢視的儲存層。物化檢視是根據串流資料計算出的結果集，並儲存在狀態儲存中。狀態儲存的實作決定了串流資料函式庫能夠支援的查詢型別和效率。

追加表格

追加表格是一種特殊的表格，用於暫存原始的串流資料。追加表格中的資料是按照時間順序追加的，且不具備更新或刪除的能力。串流資料函式庫可以將追加表格中的資料轉換為物化檢視，並儲存在狀態儲存中。

串流資料函式庫的工作流程

串流資料函式庫的工作流程可以分為以下幾個步驟：

1. 資料接入：串流資料函式庫透過聯結器（Connector）接入來自不同來源的串流資料，例如 Kafka、Debezium 等。

2. 建立源表格：使用資料定義語言（DDL）建立源表格，以定義串流資料的結構和格式。

   CREATE SOURCE click_events (
       id integer,
       ts long,
       url varchar,
       ipAddress varchar,
       sessionId varchar,
       referrer varchar,
       browser varchar
   )
   WITH (
       connector='kafka',
       topic='clicks',
       properties.bootstrap.server='kafka:9092',
       scan.startup.mode='earliest'
   )
   ROW FORMAT JSON;
   

   內容解密：

   • 此 SQL 陳述式用於建立一個名為 click_events 的源表格，從 Kafka 的 clicks 主題中讀取資料。
   • connector='kafka' 指定了聯結器型別為 Kafka。
   • properties.bootstrap.server='kafka:9092' 指定了 Kafka 叢集的引導伺服器地址。
   • ROW FORMAT JSON 指定了資料的格式為 JSON。

3. 建立物化檢視：使用 SQL 陳述式建立物化檢視，以計算和儲存串流資料的結果集。

   CREATE MATERIALIZED VIEW customers_mv AS
   WITH ranked_customers AS (
       SELECT
           c.AFTER,
           c.op,
           c.ts,
           ROW_NUMBER() OVER (PARTITION BY c.AFTER.id ORDER BY c.ts DESC) AS rn
       FROM customers AS c
   )
   SELECT * FROM ranked_customers WHERE rn = 1 AND op IS NOT 'D';
   

   內容解密：

   • 此 SQL 陳述式用於建立一個名為 customers_mv 的物化檢視，儲存客戶資料的最新狀態。
   • 使用了公用表表達式（CTE）和視窗函式（Window Function）來對資料進行分割槽和排序。
   • ROW_NUMBER() 為每個客戶 ID 的記錄分配一個行號，保證最新記錄的行號為 1。
   • 最後選取行號為 1 且操作型別不是刪除（‘D’）的記錄。

CDC 聯結器

CDC（Change Data Capture）聯結器是一種特殊的聯結器，用於捕捉資料函式庫中的變更資料，並將其轉換為串流資料。不同的串流資料函式庫可能提供不同的 CDC 聯結器，例如 Debezium 聯結器。

CREATE SOURCE customers (
    before ROW<id long, name varchar, email varchar, ipAddress varchar>,
    after ROW<id long, name varchar, email varchar, ipAddress varchar>,
    op varchar,
    ts timestamp,
    source <...>,
)
WITH (
    connector='kafka-debezium-cdc',
    topic='customers',
    properties.bootstrap.server='kafka:9092',
    scan.startup.mode='earliest'
)
ROW FORMAT JSON;

內容解密：

• 此 SQL 陳述式使用 Debezium CDC 聯結器直接建立一個物化檢視，儲存客戶資料的最新狀態。
• connector='kafka-debezium-cdc' 指定了聯結器型別為 Debezium CDC 聯結器。
• before 和 after 分別儲存變更前後的資料狀態，op 表示變更操作型別。

技術深度分析與差異化觀點

串流資料函式庫的核心優勢

1. 即時處理能力：串流資料函式庫能夠即時處理和分析持續流入的資料，為企業提供即時的洞察和決策支援。

2. 高效的查詢效能：透過使用物化檢視和狀態儲存，串流資料函式庫能夠提供高效的查詢效能，滿足複雜查詢的需求。

3. 靈活的資料接入：串流資料函式庫支援多種資料來源和格式，能夠靈活地接入不同來源的串流資料。

技術選型考量

在選擇串流資料函式庫時，需要考慮以下因素：

1. 效能需求：評估系統的效能需求，包括資料吞吐量、查詢延遲等指標。

2. 資料來源和格式：考慮系統支援的資料來源和格式，確保能夠與現有的資料生態系統整合。

3. 擴充套件性和可靠性：評估系統的擴充套件性和可靠性，確保能夠滿足未來業務增長的需求。

未來趨勢預測

1. 與 AI 和機器學習技術整合：未來，串流資料函式庫可能會與 AI 和機器學習技術進一步整合，提供更強大的實時分析和預測能力。

2. 增強的安全性和合規性：隨著資料安全和隱私保護的重要性日益增加，串流資料函式庫需要增強其安全性和合規性功能。

3. 更廣泛的應用場景：串流資料函式庫將被應用於更廣泛的場景，包括金融、醫療、物聯網等領域，為企業提供更豐富的實時洞察和分析能力。

串流資料函式庫的實作與應用

串流資料函式庫結合了串流處理和資料函式庫的功能，突破了傳統資料函式庫僅支援批次處理資料的限制。透過將預寫日誌（WAL）和物化檢視（Materialized View）重新整合到資料函式庫中，串流資料函式庫能夠同時處理靜態資料和流動資料。

物化檢視的建立與應用

在圖 5-9 的步驟 4 中，建立了另一個物化檢視。範例 5-7 將 CLICK_EVENTS 表與 CUSTOMERS 表進行連線，生成了一個包含客戶資訊的點選事件物化檢視。

範例 5-7：建立客戶資訊豐富的點選事件物化檢視

CREATE MATERIALIZED VIEW CLICK_EVENTS_ENRICHED AS
SELECT e.*, c.*
FROM CLICK_EVENTS e
JOIN CUSTOMERS c ON e.ipAddress = c.ipAddress;

此範例展示瞭如何使用 SQL 陳述式建立物化檢視，結合兩個表格的資料以提供更豐富的資訊。

內容解密：

1. CREATE MATERIALIZED VIEW：建立物化檢視的語法，用於儲存查詢結果。
2. SELECT e.*, c.*：選擇 CLICK_EVENTS 和 CUSTOMERS 表格中的所有欄位。
3. JOIN CUSTOMERS c ON e.ipAddress = c.ipAddress：根據 ipAddress 欄位將兩個表格進行連線。

進一步地，我們可以結合 PRODUCTS 表格，以取得包含客戶和產品資訊的點選事件資料。

範例 5-8：建立包含客戶和產品資訊的點選事件物化檢視

CREATE MATERIALIZED VIEW CLICK_EVENTS_ENRICHED AS
SELECT e.*, c.*, p.*
FROM CLICK_EVENTS e
JOIN CUSTOMERS c ON e.ipAddress = c.ipAddress
JOIN PRODUCTS p ON e.productid = p.productid;

內容解密：

1. JOIN PRODUCTS p ON e.productid = p.productid：根據 productid 欄位將 CLICK_EVENTS 和 PRODUCTS 表格進行連線。
2. SELECT e.*, c.*, p.*：選擇三個表格中的所有欄位，以提供全面的資料檢視。

串流資料函式庫中的 ELT 處理

傳統的 ELT（Extract, Load, Transform）流程在處理即時資料時存在侷限性，因為轉換操作發生在目標資料函式庫中。然而，如果目標資料函式庫是串流資料函式庫，那麼整個流程仍然可以保持即時性。

透過結合串流平台和串流資料函式庫，ELT 工具（如 dbt）可以支援即時的資料處理。這使得原本在資料倉儲或湖倉中執行的 ELT 任務可以轉移到即時的串流層。

串流資料函式庫的特性與應用場景

串流資料函式庫支援推播（Push）和提取（Pull）查詢。推播查詢適用於即時資料流處理，而提取查詢則用於查詢儲存在資料函式庫中的資料。根據串流資料函式庫的儲存型別（行儲存或列儲存），可以支援不同型別的提取查詢。

圖表說明：串流資料函式庫的光譜

此圖示展示了串流資料函式庫從行儲存到列儲存的光譜。左側主要用於應用程式驅動的事件處理，右側則適用於人類或儀錶板查詢。