Lambda架構串流資料處理層深度解析

Lambda 架構有效結合批次層、速度層和服務層，應對大資料分析的複雜性。批次層處理完整歷史資料，速度層專注於低延遲即時資料，服務層則整合兩者結果提供統一檢視。這種架構在處理大量資料的同時，兼顧了資料的完整性和即時性，適合各種資料分析應用場景。然而，維護兩個獨立的處理路徑也增加了系統複雜度，需要額外關注資料一致性問題。為簡化架構，Kappa 架構等替代方案應運而生，以單一流處理引擎取代批次和速度層，降低維護成本。此外，結合 Flink 或 Pathway 等流處理器和 Pinot 等 OLAP 資料函式庫，也能提供高效的即時分析能力。Pinot 的混合表格設計，更能有效整合流資料和歷史資料，簡化資料管理。

Lambda 架構深度解析

Lambda 架構是一種專為大資料分析設計的架構模式，能夠同時處理批次和即時資料處理需求。該架構主要由三個核心層組成：批次層、速度層和服務層。

批次層（Batch Layer）

批次層負責處理大規模的資料集，採用批次導向的方式進行計算。該層利用 Apache Hadoop 等分散式處理技術對整個資料集進行預計算，並將結果儲存在批次服務層中。這種設計使得批次層非常適合進行複雜的分析和歷史資料查詢。

速度層（Speed Layer）

速度層專注於即時資料處理，旨在實作低延遲的資料處理能力。它處理尚未被批次層處理的最新資料，並將結果與批次層的結果合併，提供完整且最新的資料檢視。Apache Storm 和 Apache Flink 等技術常被用於速度層的即時資料處理。

服務層（Serving Layer）

服務層結合批次層和速度層的結果，提供統一的資料檢視。它負責回應使用者或應用程式的查詢和分析請求。服務層通常建立在可擴充套件的 NoSQL 資料函式庫（如 Apache HBase 或 Apache Cassandra）之上，以高效處理讀取密集的工作負載。

Lambda 架構的優勢與挑戰

Lambda 架構的最大優勢在於能夠同時處理批次和即時資料處理，提供全面的大資料分析解決方案。然而，維護兩個獨立的處理路徑可能會增加系統複雜度，並在確保批次和即時檢視的一致性方面帶來挑戰。

替代方案與創新

為瞭解決 Lambda 架構的複雜性，一些替代架構如 Kappa 架構被提出，旨在簡化整體系統設計，透過統一的流處理方式來處理批次和即時資料。此外，使用獨立的流處理器和 OLAP 資料函式庫（如 Apache Pinot 結合 Flink 或 Pathway）也是一種可行的選擇。

Apache Pinot Hybrid Tables

Apache Pinot 的混合表格（Hybrid Tables）是一種特殊的表格，由兩個內部表格（一個離線表格和一個即時表格）組成，共用相同的名稱。這種設計使得 Pinot 能夠合併流資料和歷史資料。

{
  "tableName": "airlineStats",
  "tableType": "REALTIME",
  "tenants": {},
  "segmentsConfig": {
    "timeColumnName": "DaysSinceEpoch",
    "retentionTimeUnit": "DAYS",
    "retentionTimeValue": "5",
    "replication": "1"
  },
  // ... 其他組態
}

即時資料擷取與轉換

在 Example 8-10 中，我們看到了從 Kafka 進行即時資料擷取的組態。Pinot 的即時資料擷取支援從 Kafka 等發布-訂閱系統中擷取資料，並進行必要的轉換，以滿足不同的分析需求。

#### 內容解密：

此段 JSON 組態定義了一個名為 airlineStats 的即時表格，用於從 Kafka 主題 flights-realtime 中擷取資料。其中：

• timeColumnName 指定了時間欄位為 DaysSinceEpoch。
• retentionTimeUnit 和 retentionTimeValue 定義了資料保留策略為 5 天。
• replication 設定為 1，表示資料的複製因子。
• streamIngestionConfig 詳細組態了從 Kafka 擷取資料的相關引數，包括解碼器類別、消費者工廠類別等。

Lambda架構與Pinot的整合應用

Lambda架構是一種結合批次處理與串流處理的資料處理架構，能夠有效處理大量資料。Apache Pinot是一種OLAP（線上分析處理）資料函式庫，專門為即時分析設計。將Lambda架構與Pinot結合，可以實作即時資料分析與歷史資料查詢的無縫整合。

Pinot的組態與應用

Pinot的組態包括REALTIME和OFFLINE兩種表格型別，分別用於處理即時資料和歷史資料。REALTIME表格用於儲存即時資料，而OFFLINE表格則用於儲存歷史資料。兩者透過查詢引擎進行整合。

{
  "tableName": "exampleTable",
  "tableType": "REALTIME",
  "segmentsConfig": {
    "timeColumnName": "ts",
    "timeType": "SECONDS",
    "schemaName": "exampleSchema"
  },
  "ingestionConfig": {
    "transformConfigs": [
      {
        "columnName": "ts",
        "transformFunction": "fromEpochDays(DaysSinceEpoch)"
      }
    ]
  }
}

組態解讀：

1. tableName與tableType: 定義表格名稱與型別（REALTIME或OFFLINE）。
2. segmentsConfig: 組態時間欄位名稱與型別。
3. ingestionConfig: 定義資料轉換規則，將DaysSinceEpoch轉換為時間戳。

資料流程與整合

資料流程從OLTP資料函式庫（如Postgres）開始，透過Debezium CDC聯結器捕捉變更交易，並寫入Kafka主題。Flink SQL用於轉換資料並將其寫回Kafka主題，最後由Pinot進行即時查詢。

CREATE TABLE KafkaSource (
  `id` BIGINT,
  `col1` STRING,
  `col2` STRING,
  `ts` TIMESTAMP(3) METADATA FROM 'timestamp'
) WITH (
  'connector' = 'kafka',
  'topic' = 'my_data',
  'properties.bootstrap.servers' = 'localhost:9092',
  'properties.group.id' = 'abc',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'json'
);

SQL解讀：

1. CREATE TABLE KafkaSource: 定義Kafka來源表格。
2. WITH子句: 組態Kafka聯結器屬性，包括主題名稱、伺服器位址和群組ID。

Pinot的分層儲存

Pinot支援分層儲存，可以將舊資料移至較低階層，以釋放更多容量。這種設計使得即時資料與歷史資料的管理更加靈活。

"tierConfigs": [
  {
    "name": "hotTier",
    "segmentSelectorType": "time",
    "segmentAge": "3130d",
    "storageType": "pinot_server",
    "serverTag": "DefaultTenant_OFFLINE"
  },
  {
    "name": "coldTier",
    "segmentSelectorType": "time",
    "segmentAge": "3140d",
    "storageType": "pinot_server",
    "serverTag": "DefaultTenant_OFFLINE"
  }
]

分層儲存解讀：

1. tierConfigs: 定義分層儲存組態。
2. hotTier與coldTier: 分別組態熱資料與冷資料的儲存策略。

未來趨勢與技術選型

隨著大資料技術的發展，未來將有更多企業採用Lambda架構與OLAP資料函式庫結合的方案，以滿足日益增長的即時資料分析需求。在技術選型上，應考慮資料來源的多樣性、資料處理的即時性以及系統的可擴充套件性。

技術挑戰與解決方案

在實施Lambda架構與Pinot整合的過程中，可能會面臨資料一致性、系統延遲等挑戰。解決這些挑戰需要最佳化資料處理流程、提升系統硬體效能以及採用更高效的資料壓縮技術。

第9章：串流平面

在前一章中，我們探討了當今生態系統中現有的即時系統，並介紹了三個不同的資料平面：操作、分析與串流。操作和分析平面主要處理靜態資料，而串流平面則是唯一以動態資料為特徵的領域。

在本章中，我們將探討串流平面，以及資料架構師和工程師如何開始思考其在簡化即時分析中的作用。我們一直將諸如非同步、動態資料和串流等術語相互關聯，將它們視為可互換的表達方式。它們與長期執行的流程相關，這些流程持續進行轉換，簡化並加快應用程式對即時分析資料的檢索。

圖9-1僅顯示第7章中維恩圖的串流平面部分。我們將在整章中參考此圖表。

圖9-1. 第7章維恩圖中的串流平面

本章將探討幾個關鍵主題，以瞭解串流平面上即時資料處理的複雜性。其中一個重點是操作平面上的分析（或操作分析）的概念，它探討在操作平面上靠近應用程式執行分析工作負載的實踐。此外，我們將探討資料區域性的方面，研究資料與其處理環境的地理接近程度如何影響整體系統效能。瞭解資料區域性對於最佳化資源利用和最小化串流分析場景中的延遲至關重要。

另一個我們將探討的重要主題是資料複製，這是串流平面中的基本策略。資料複製涉及跨多個節點或全球區域進行資料複製，促進去中心化。我們將涵蓋受資料網格啟發的資料產品概念。我們將討論如何利用即時分析生成有價值的資料產品，並在全球範圍內進行複製以供本地使用。

透過探討這些重要主題，讀者將瞭解串流平面所呈現的多方面挑戰和機遇，提供在全球串流分析領域設計彈性和高效系統的關鍵解決方案。

資料重力

將資料視為一個行星。當資料累積品質時，它會像重力吸引月球到地球並讓你不漂浮到太空一樣吸引服務和應用程式。例如，當你在社交媒體上發布訊息時，你就建立了資料。你的訊息被提交到一個服務，該服務吸引了朋友的互動並創造了更多資料。

在不考慮串流平面的典型資料架構中，操作平面會直接將資料推播到分析平面。可以將操作平面視為圍繞著一個密集行星（分析平面）執行的月球。操作平面月球將資料推播到行星。隨著越來越多的操作平面月球將資料發送回分析平面行星，該行星變成了一個歷史資料的單一系統。工作負載開始受到資料大小的影響，這引入了延遲。

正如我們在前幾章中所說，從操作平面到分析平面的資料移動是單向的下游流動。強制資料朝相反的上游方向流動是很困難的。另一種看法是資料重力的概念。

圖9-2. 資料重力對資料和基礎設施的影響

圖9-2描繪了一個典型的資料架構，沒有考慮串流平面。操作平面作為外部節點存在，將資料發布到代表地球的分析平面。

隨著越來越多的作業系統將其資料傳送到分析平面，分析平面變成了一個歷史資料的單一系統。分析平面上的工作負載開始感受到資料大小的影響，這引入了更多的延遲，使得它無法再提供即時分析。

如果您擁有帶有串流平面的資料架構，情況就會有所不同。操作平面月球不是直接將資料推播到行星，而是將資料推播到串流平面內的衛星。這些衛星提供了一種方法，可以在更接近操作平面月球的地方實作分析，同時向行星提供資料產品。它減輕了重力的影響。串流平面提供了所需的流動性，使資料能夠迴流到操作平面，用於導向使用者的分析。

在圖9-3中，可以將串流平面中物化檢視中的資料視為圍繞著一個行星（或分析平面）執行的衛星。您可以像觀看來自衛星的即時電視節目一樣，從這些物化檢視中消費即時資料。

與觀看即時電視節目類別似，串流平面中的資料可以全球範圍內提供服務。

圖9-3. 透過複製實作物化檢視圍繞全球執行

串流平面提供了一種方法，可以在更接近操作平面的地方實作分析，同時提供構成這些分析的資料產品。它減輕了資料重力的影響，同時仍然為分析平面提供了增量資料，用於存檔和大規模批處理。

串流平面的組成部分

圖9-4顯示了當今串流平面中的多種解決方案和系統。在本章中，我們將利用此圖表來描述構成串流平面的系統，以及它們如何促進資料去中心化和即時分析。

圖9-4顯示了熟悉的操作和分析平面位於兩端，由代表雲的串流平面分隔開。串流平面由兩個組成部分支撐：像Kafka這樣的串流平台和源/匯聯結器。雙向箭頭在圖9-4中標識了它們。正是從這個基礎上，串流平面中的其他組成部分消費即時資料。

圖9-4. 串流平面的架構

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

title 圖9-4. 串流平面的架構

rectangle "資料推播" as node1
rectangle "即時資料" as node2
rectangle "源/匯聯結器" as node3
rectangle "消費即時資料" as node4

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

@enduml

此圖示展示了操作平面、串流平台、源/匯聯結器和其他元件之間的關係，以及它們如何共同支援即時分析和資料處理。

內容解密：

1. 操作平面：負責生成和推播資料到串流平台。
2. 串流平台：如Kafka，是串流平面的核心，負責處理和傳輸即時資料。
3. 源/匯聯結器：連線不同的資料來源和匯點，使得資料可以在不同的系統之間流動。
4. 其他元件：包括各種處理和分析工具，用於消費即時資料並提供進一步的分析和處理結果。

透過這種架構，串流平面有效地減輕了資料重力的影響，提高了系統的整體效能和可擴充套件性。

資料流處理層的基礎架構與應用

在設計即時分析的資料基礎架構時，架構師需要考慮一致性和消費分析的使用者。資料流處理層包含了多個關鍵元件，包括串流平台（如 Kafka）、來源和接收器聯結器、串流處理器（如 Flink）、即時線上分析處理（RTOLAP）資料函式庫和串流資料函式庫。這些元件共同合作，以實作即時分析資料的轉換和提供。

資料流處理層的元件

• 串流平台，如 Kafka
• 來源和接收器聯結器
• 串流處理器，如 Flink
• RTOLAP 資料函式庫
• 串流資料函式庫

資料流處理層的基礎架構

在建立運作層、分析層和串流層的基礎架構時，架構師應該考慮為每個層面提供獨立的基礎架構。為串流系統提供專用的基礎架構至關重要，以確保資料在傳輸過程中的有效、安全和可靠的管理。

為資料系統提供獨立基礎架構的原因

運作分析

運作分析是指在資料產生的源頭附近收集、處理和分析資料，通常是在導向使用者的應用程式處，或是靠近該處，而不是僅依賴分析層系統。這種方法能夠讓組織從即時資料中獲得洞察，從而做出快速且明智的決策。

將分析工作負載移至運作層的原因

1. 即時決策：運作分析使組織能夠即時從資料中獲得洞察，這對於影響正在進行的操作至關重要。
2. 提高效率：將分析能力嵌入運作系統中，可以簡化流程並減少手動干預的需求。
3. 改善客戶體驗或個人化：即時分析允許組織根據客戶當前的行為和偏好來個人化與客戶的互動。
4. 主動問題解決和預測分析：運作分析通常包括預測建模，幫助組織在問題升級之前識別潛在問題。
5. 成本文約和資源最佳化：透過將分析整合到運作系統中，組織可以最佳化資源分配，從而實作成本文約和提高資源利用率。

總之，資料流處理層是即時分析的關鍵組成部分，它使得組織能夠即時處理和分析資料，從而做出更好的決策並提高營運效率。

@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

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

@enduml

此圖示展示了運作層、串流層和分析結果之間的關係，突出了資料如何在不同層面之間流動和被處理。

圖表解說

此圖表展示了從運作層到串流層，再到分析結果和決策支援的流程。首先，運作層產生資料，這些資料隨後被傳輸到串流層進行處理和分析。串流層負責對這些資料進行即時處理和分析，以產生有價值的分析結果。這些結果隨後被用於提供洞察，以支援決策制定。最後，這些決策會反過來影響運作層的操作，形成一個閉環。

程式碼範例

from kafka import KafkaConsumer

# 建立 Kafka Consumer
consumer = KafkaConsumer('my_topic', bootstrap_servers='localhost:9092')

# 消費訊息
for message in consumer:
    print(f"Received message: {message.value.decode('utf-8')}")

內容解密：

1. 建立 Kafka Consumer：首先，我們從 kafka 函式庫中匯入 KafkaConsumer 類別，並建立一個 Kafka Consumer 物件，指定要訂閱的主題（my_topic）和 Kafka 叢集的位置（localhost:9092）。
2. 消費訊息：接著，我們使用一個迴圈來消費來自 Kafka 主題的訊息。每當有新的訊息到達時，我們就列印出訊息的內容。在這個例子中，我們假設訊息是以 UTF-8 編碼的字串，因此我們使用 decode('utf-8') 方法來解碼訊息內容。
3. 邏輯說明：這個程式碼範例展示瞭如何使用 Python 的 KafkaConsumer 從 Kafka 主題中讀取訊息。它適用於需要即時處理和分析串流資料的場景，例如即時日誌分析、監控系統或事件驅動的應用程式。
4. 技術原理：KafkaConsumer 使用 Kafka 的訂閱/發布模型來消費訊息。它可以訂閱一個或多個主題，並從 Kafka 叢集中讀取訊息。這種機制使得應用程式能夠以即時的方式處理和分析串流資料。
5. 潛在改進點：為了提高程式碼的健壯性和可擴充套件性，可以考慮新增錯誤處理機制、支援多個主題的訂閱、以及使用更高效的訊息處理邏輯。此外，也可以考慮使用更先進的 KafkaConsumer 組態，例如調整 group_id、auto_offset_reset 等引數，以滿足特定的應用需求。