即時資料服務與 OLAP 效能最佳化

在即時分析需求日益增長的背景下，傳統資料架構難以滿足低延遲的服務水準協定。本文探討如何最佳化 OLAP 系統以提供即時分析能力，並深入研究 Apache Pinot 的 Star-Tree 索引、資料分割策略以及推拉查詢機制。同時，也探討了具體化檢視如何結合 CDC 技術實作增量更新，進一步提升查詢效能。文章以實際案例和程式碼範例，解析如何在資料攝入階段進行預處理和最佳化，例如時間戳記轉換和欄位格式調整，為讀者提供實用的技術參考。

即時分析的資料服務挑戰與解決方案

在現代資料驅動的應用程式中，即時分析的需求日益增加。為了滿足這些需求，資料必須能夠快速、準確地被處理和分析。然而，傳統的資料倉儲、資料湖或湖倉架構難以實作即時分析所需的低延遲服務水準協定（SLA）。

資料函式庫與資料儲存的定義

在討論即時分析之前，我們需要澄清「資料函式庫」和「資料儲存」的定義。OLTP（線上交易處理）資料函式庫通常是交易型且根據行的，服務於運算元據平面，為導向使用者的應用程式提供記錄。另一方面，OLAP（線上分析處理）資料儲存則專注於服務分析查詢。

即時分析的挑戰

在即時分析的場景中，資料通常從串流平台（如 Kafka）的主題中取得。這些資料可能需要被多個域消費者使用，每個消費者可能需要不同的資料格式。例如，不同的消費者可能需要不同格式的時間戳記。

時間戳記轉換的挑戰

如果資料在查詢時進行轉換，則會減慢查詢速度並影響 SLA。為瞭解決這個問題，可以在資料攝入過程中進行轉換，即所謂的攝入轉換。

攝入轉換

攝入轉換允許在資料到達持久儲存之前對串流資料進行預處理。這種轉換類別似於無狀態的串流處理器，可以將資料從基礎格式轉換為所需的格式。例如，將毫秒級的時間戳記轉換為年-月-日的格式。

有狀態與無狀態轉換

大多數 RTOLAP（即時 OLAP）資料儲存只能執行無狀態的預處理，但有些系統（如 Apache Pinot）支援有狀態的攝入轉換。Pinot 的 star-tree 索引允許在攝入過程中進行聚合，這是一種有狀態的轉換。

去正規化檢視的優勢

去正規化檢視（Denormalized View），也稱為 One Big Table（OBT），透過將多個表格的資訊合併到一個表格或檢視中，簡化了查詢和分析。這種方法可以提高查詢效能，因為連線操作只需要在資料持久化之前執行一次。

非同步處理與最佳化

攝入轉換和串流處理都是非同步過程，在背景執行，不會與使用者互動。這些過程不僅格式化資料，還最佳化了資料以支援快速分析查詢。例如，使用欄位（columnar）格式，這是許多 OLAP 系統（如 Pinot）所採用的。

欄位格式的優勢

欄位格式與 OLTP 資料函式庫常用的根據行的格式不同，更適合於分析查詢。透過在攝入過程中將資料轉換為欄位格式，可以提高查詢效能並減少延遲。

內容解密：

1. 圖表展示了即時分析系統中的關鍵元件及其相互關係。
2. 串流平台負責發布主題，RTOLAP 資料儲存則負責消費這些主題並進行攝入轉換。
3. 攝入轉換將原始資料最佳化，以提高查詢效能。
4. 去正規化檢視進一步簡化了查詢和分析過程。
5. 最終，分析結果被傳遞給應用程式，以支援業務決策。

透過這種架構，系統能夠提供低延遲的即時分析，滿足現代應用程式的需求。

OLTP 與 OLAP 的比較

比較 OLTP 資料函式庫和 OLAP 資料儲存對於理解資料的處理方式具有重要意義。

OLTP 資料函式庫的特性

OLTP（線上交易處理）資料函式庫主要用於操作層面的交易工作負載。它們負責向使用者應用程式傳回記錄，並被設計為高效處理和管理即時交易操作。主要用於支援日常業務活動，這些活動涉及頻繁的資料互動，例如建立（插入）、檢索、更新和刪除資料記錄，也稱為 CRUD（建立、檢索、更新、刪除）。

OLTP 資料函式庫的主要目的是確保交易處理過程中資料的完整性和一致性。它提供快速可靠的資料存取，用於支援諸如訂單處理、庫存管理、金融交易和客戶互動等操作任務。OLTP 資料函式庫針對處理大量並發交易進行了最佳化，通常涉及多個使用者同時存取系統。

這些資料函式庫通常具有標準化的資料結構，這意味著它們最小化了資料冗餘並保持了資料一致性。它們優先考慮交易能力，支援 ACID（原子性、一致性、隔離性、永續性）屬性，以確保可靠和安全的資料處理。

ACID 屬性

ACID 是一組屬性的縮寫，用於確保 OLTP 資料函式庫中交易處理的可靠性和一致性：

• 原子性：將交易視為單一、不可分割的動作。原子性確保要麼所有的變更都成功應用，要麼都不應用，以保持資料函式庫的一致狀態。
• 一致性：確保交易將資料函式庫從一個有效狀態轉換到另一個。一致性意味著在交易期間和之後，資料函式庫中定義的任何規則、約束或關係都得到維護。
• 隔離性：允許多個交易並發發生而不相互幹擾。每個交易都與其他交易隔離，直到完成，以防止衝突並確保每個交易看到的資料函式庫狀態是一致的。
• 永續性：保證一旦交易成功完成，其變更將永久儲存，並且能夠抵禦隨後的系統故障或當機。變更成為資料函式庫的永久部分，資料被可靠地儲存以供未來使用。

ACID 符合性確保了資料函式庫交易是可靠、一致、彼此隔離且持久的，為資料完整性和可靠性提供了堅實的基礎。

OLAP 資料儲存的特性

相反，OLAP（線上分析處理）資料儲存用於分析層面上的分析工作負載。它們採用與 OLTP 資料函式庫不同的最佳化技術。每種型別的資料儲存都針對其應扮演的角色進行了最佳化。

行導向與列導向最佳化

行導向和列導向是兩種不同的資料組織和儲存方式。

• 在行導向格式中，資料按行儲存和組織。這種格式類別似於傳統的電子試算表表示方式，適合頻繁更新或插入個別行的交易處理。
• 在列導向格式中，資料按列儲存和組織。這種格式針對分析處理進行了最佳化，因為查詢通常涉及聚合、過濾和對特定列或資料子集的分析。

表 3-1：行導向與列導向最佳化的差異

當即時串流資料到達服務層時，由於服務層位於分析層面，因此期望它已經準備好支援快速分析查詢。列式儲存將為分析查詢提供最佳的查詢效能和效率。

每秒查詢數與並發性

每秒查詢數（QPS）衡量 OLAP 資料儲存傳回查詢結果的能力。這反過來表明 OLAP 在一秒內可以處理的查詢量，並最終決定可以呼叫的並發查詢數量。

在我們的點選流使用案例中，我們沒有指定有多少終端使用者正在檢視分析結果。假設每個終端使用者至少會有一個查詢，並且這是一個即時使用案例，因此儀錶板上的資料新鮮度預期是即時的。即時儀錶板往往需要高重新整理率，以使圖表盡可能保持即時。每一次儀錶板的重新整理都會對應一次查詢。

對於 1,000 名使用者以 5 秒的儀錶板重新整理率檢視點選流分析，可以得到以下公式： 1,000 名使用者 × (1 次查詢 / 5 秒重新整理率) = 200 QPS 需求

這表明系統需要能夠支援至少 200 QPS 的查詢負載，以滿足即時分析的需求。

提升即時線上分析處理（RTOLAP）效能的關鍵：索引技術

在即時線上分析處理（RTOLAP）系統中，查詢效能是評估系統好壞的重要指標之一。為了滿足高效能的需求，索引技術扮演著至關重要的角色。適當的索引策略不僅可以提升查詢效能，還能降低硬體成本，從而實作更高的投資回報率。

索引技術的重要性

索引是 RTOLAP 資料函式庫提高每秒查詢數（QPS）的關鍵技術。適當的索引可以幫助資料函式庫快速定位和檢索相關資料，減少查詢回應時間，從而提高 QPS。索引技術主要有以下幾種方式來提升 QPS：

1. 快速資料定位：索引允許資料函式庫直接存取所需的資料，而無需掃描整個資料集，顯著減少查詢回應時間。
2. 提供查詢最佳化器所需的統計資訊：索引提供有價值的統計資訊和元資料，幫助查詢最佳化器決定最有效的查詢執行計畫，最佳化資源分配、資料檢索策略和連線操作，從而提高整體查詢效能。
3. 資料剪枝（Pruning）：索引技術可以讓 OLAP 系統剪枝掉不包含結果的資料區塊，減少搜尋空間，提高查詢處理速度。
4. 減少磁碟 I/O 操作：索引透過組織資料結構，減少查詢處理過程中的磁碟讀取次數，從而降低資料存取時間，提高 QPS。

Apache Pinot 中的索引技術

Apache Pinot 是一種 RTOLAP 資料儲存解決方案，支援多種索引技術來最佳化查詢效能。以下是 Apache Pinot 中常用的索引型別：

表 3-2. Apache Pinot 中的索引型別

這些索引可以單獨使用或組合使用，取決於資料特性和查詢模式。選擇適當的索引對於最佳化 Apache Pinot 中的查詢效能至關重要。

Star-Tree 索引技術

Star-Tree 索引是一種特殊的索引技術，用於對多個欄位進行排序和預聚合，以加速大資料集上的聚合和計算密集型查詢。Star-Tree 索引的工作原理類別似於樹狀結構，每一層對應於用於篩選和聚合資料的欄位。

Star-Tree 索引的工作原理範例

1. 查詢從根節點開始，沿著第一個維度（D1）向下遍歷。
2. 如果 SQL 條件是 D1 = V2，則查詢會掃描 D1 維度下 V2 節點的記錄。
3. 如果 SQL 條件是 D1 = V1，則查詢會直接傳回 D1 維度下 V1 節點的預聚合值。
4. 如果 SQL 條件是 D1 = V1 AND D2 = V1，則查詢會掃描 D2 維度下 V1 節點的記錄。

程式碼範例：建立 Star-Tree 索引

// 建立 Star-Tree 索引的設定範例
{
  "starTreeConfigs": [
    {
      "dimensionsSplitOrder": ["D1", "D2"],
      "functionColumnPairs": [
        {"functionName": "SUM", "columnName": "metric1"}
      ],
      "skipStarNodeCreationForDimensions": []
    }
  ]
}

內容解密：

此 JSON 設定範例展示瞭如何在 Apache Pinot 中組態 Star-Tree 索引。主要包含以下幾個部分：

• dimensionsSplitOrder：指定維度的拆分順序，通常按照基數從高到低排序。
• functionColumnPairs：定義要在 Star-Tree 索引中預聚合的指標和聚合函式。
• skipStarNodeCreationForDimensions：可選組態，用於控制是否為某些維度建立星節點。

在 Apache Pinot 中提供即時分析結果

Apache Pinot 是一種 OLAP（線上分析處理）資料儲存系統，旨在提供即時分析查詢效能。為了達到這個目標，Pinot 使用了一種稱為 star-tree 索引的技術，該技術可以在資料擷取過程中進行資料聚合，從而提高查詢效能。

Star-Tree 索引與分割閾值

在 Pinot 中，star-tree 索引是一種特殊的索引結構，它可以在查詢時減少需要掃描的資料量。透過設定分割閾值（split threshold），可以限制查詢時需要掃描的記錄數。例如，如果設定分割閾值為 100,000，則 star-tree 索引將確保查詢不會掃描超過 100,000 筆記錄。

程式碼範例：設定 Star-Tree 索引

{
  "starTreeIndexConfigs": [
    {
      "dimensionsSplitOrder": ["dimension1", "dimension2"],
      "functionColumnPairs": ["SUM(value)"],
      "maxLeafRecords": 100000
    }
  ]
}

內容解密：

• dimensionsSplitOrder 指定了維度欄位的分割順序。
• functionColumnPairs 定義了需要聚合的欄位和聚合函式。
• maxLeafRecords 設定了分割閾值，確保查詢不會掃描超過指定數量的記錄。

段落（Segment）與資料儲存

在 Pinot 中，資料被組織成段落（Segment），每個段落代表了一部分表格資料。段落以欄位為單位儲存資料，並包含字典和索引，以提高查詢效能。

即時資料服務

為了提供即時分析結果，Pinot 支援兩種查詢模式：同步查詢和非同步查詢。

同步查詢（Pull Queries）

同步查詢是一種請求-回應模式，客戶端提交查詢請求並從 Pinot 提取資料。這種模式下，查詢效能通常以 QPS（每秒查詢數）來衡量。

非同步查詢（Push Queries）

非同步查詢則是將資料推播給客戶端，無需客戶端輪詢。這種模式下，客戶端可以訂閱特定的主題，並在有新資料時接收通知。

使用 Plantuml 圖表展示同步與非同步查詢差異

此圖示展示了同步查詢與非同步查詢之間的差異。

SSE 與 WebSocket

在非同步查詢中，可以使用 SSE（Server-Sent Events）或 WebSocket 技術來實作即時資料推播。SSE 是一種單向通訊技術，允許伺服器向客戶端推播資料，而 WebSocket 則是一種雙向通訊技術，允許客戶端和伺服器之間進行即時通訊。

SSE 與 WebSocket 的比較

此圖示比較了 SSE 和 WebSocket 的主要差異。

即時資料服務中的推拉查詢機制

在即時資料服務中，推拉查詢（Push and Pull Queries）是兩種不同的資料檢索方式，它們在資料取得的即時性、資源效率以及系統架構設計上各有其特點和適用場景。

推查詢（Push Queries）

推查詢是一種主動推播機制，當資料函式庫中的資料發生變化時，系統會主動將更新的資料推播到客戶端或應用程式。這種機制能夠實作即時更新，讓客戶端無需持續輪詢或傳送請求即可取得最新的資料。

推查詢的優點

• 即時性：資料一旦可用就被推播到客戶端，無需等待客戶端的請求，從而降低了延遲。
• 事件驅動架構：推查詢非常適合事件驅動的架構，能夠使系統根據接收到的資料觸發相應的動作，提供更為靈敏和事件導向的處理方式。

拉查詢（Pull Queries）

拉查詢則是一種按需檢索機制，客戶端或應用程式在需要時主動向資料函式庫傳送請求以取得資料。這種方式賦予了客戶端對資料檢索的時間和頻率更大的控制權。

拉查詢的優點

• 靈活性：客戶端可以在任何需要的時候檢索資料，提供了更大的靈活性。
• 資源效率：由於客戶端只在需要時檢索資料，因此可以減少不必要的網路流量和伺服器負載。

推拉查詢的比較與結合使用

推查詢和拉查詢各有其適用場景。推查詢適合需要即時更新和立即取得資料的應用，而拉查詢則在需要按需檢索資料且檢索頻率不高的場景下更為高效。

結合兩者的優勢，可以採用混合策略：首先使用拉查詢取得當前資料狀態，然後訂閱資料變更通知以即時取得更新。這種方法結合了兩者的優點，既能取得初始資料狀態，又能即時接收資料更新。

OLAP系統中的推拉查詢挑戰

然而，在OLAP（線上分析處理）系統中，由於其主要最佳化目標是服務分析查詢結果，因此通常不直接支援非同步的推查詢。OLAP系統擅長處理聚合和分析操作，但難以直接提取原始資料。

實體化檢視（Materialized Views）

實體化檢視是一種預先計算並儲存查詢結果的技術，能夠顯著提高查詢效能。與傳統檢視不同，實體化檢視將查詢結果實體化儲存，並在後台非同步更新，從而保持資料的新鮮度。

實體化檢視的優勢

• 效能提升：透過預先計算和儲存查詢結果，避免了重複執行昂貴的查詢操作。
• 簡化分析：實體化檢視能夠簡化複雜的分析操作，提供即時的分析結果。

傳統檢視與實體化檢視的比較

傳統檢視在每次查詢時動態計算結果，而實體化檢視則預先計算並儲存結果。實體化檢視透過非同步更新機制保持資料的新鮮度，從而提供更快的查詢回應時間。

傳統檢視的類別比

想像一下，你詢問一隻聰明的花栗鼠西蒙（Simon）你庭院中的堅果數量。每次詢問，西蒙都需要跑到庭院中重新計數。這種方式類別似於傳統檢視，每次查詢都需要重新計算結果。

實體化檢視的類別比

為了提高效率，你讓西蒙將堅果的總數寫在紙上並存放在盒子中。當你再次詢問時，西蒙可以直接提供紙上的數字，而無需重新計數。這種方式類別似於實體化檢視，透過預先計算和儲存結果來提高查詢效率。

具體化檢視（Materialized Views）與增量更新的技術解析

在資料處理領域中，具體化檢視是一種預先計算並儲存查詢結果的技術，旨在提升查詢效能並降低系統負擔。具體化檢視的運作機制類別似於一個聰明的花栗鼠（Simon），持續監控資料變化並更新結果，而另一個較簡單的花栗鼠（Alvin）則負責提供已計算好的結果。

增量更新的重要性

具體化檢視的核心優勢在於其採用增量更新機制，而非每次重新計算整個資料集。這種方式大幅減少了計算資源的消耗，並能即時反映資料變化。增量更新的數學表示式可表示為：$X_{new} = X_{old} + \Delta X$，其中 $X$ 代表當前狀態，而 $\Delta X$ 則是增量變化。

變更資料捕捉（CDC）與具體化檢視的關聯

變更資料捕捉（CDC）技術能夠捕捉資料函式庫中的變更記錄，並將這些變更以增量的形式提供給下游系統。具體化檢視可以利用 CDC 提供的增量變更，持續更新預先計算的結果。這種結合使得系統能夠在保持高效能的同時，提供即時且準確的資料檢視。

-- 示例：建立具體化檢視
CREATE MATERIALIZED VIEW nut_count AS
SELECT COUNT(*) 
FROM nuts 
WITH DATA;

內容解密：

1. CREATE MATERIALIZED VIEW nut_count AS: 定義一個名為 nut_count 的具體化檢視，用於儲存查詢結果。
2. SELECT COUNT(*) FROM nuts: 查詢 nuts 表中的總記錄數，這是具體化檢視要預先計算的內容。
3. WITH DATA: 表示在建立具體化檢視時立即填充資料。

推播查詢與提取查詢的平衡

在具體化檢視的使用中，推播查詢（Push Query）和提取查詢（Pull Query）扮演著不同的角色。推播查詢（類別似 Simon）負責非同步計算和更新結果，而提取查詢（類別似 Alvin）則提供低延遲的結果查詢服務。這兩者的平衡取決於具體的使用場景和對延遲與靈活性的需求。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 即時資料服務與 OLAP 效能最佳化

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

此圖示說明：

1. 資料函式庫的 WAL（Write-Ahead Log）被複製到主資料函式庫副本。
2. CDC 機制捕捉 WAL 中的變更，並將其寫入串流平台。
3. 串流處理器和 Sink 聯結器從串流平台消費資料，用於構建具體化檢視或其他下游系統。

技術選型與應用場景

具體化檢視特別適用於需要即時資料洞察和高並發查詢的場景，例如即時分析系統和使用者端應用。透過結合 CDC 和具體化檢視，系統能夠實作高效的增量更新和低延遲查詢，從而滿足不同使用者的需求。