【虹科乾貨】Lambda資料架構和Kappa資料架構——構建現代資料架構

如何 更好 地構建我們 的 資料處理 架構，如何 對IT 系統中 的遺留 問題 進行現代化改造並將其轉變為現代資料架構 ？該怎麼為你的需求匹配最適合的架構設計呢，本文將分析兩種流行的基於速度的資料架構，為你提供一些思路。

文章速覽：

l 什麼是資料架構？

l 基於速度的資料架構

l 結語

 

一、 什麼是資料架構？

資料架構是企業架構中的一個元素，繼承了 企業架構的 主要屬性：流程、策略、變更管理和評估權衡 。根據Open Group架構框架，資料架構是對“企業主要資料型別 、 來源、邏輯資料資產、物理資料資產和資料管理資源的結構和互動 ” 的描述。

根據資料管理知識體系， 資料架構是 “識別企業的資料需求（無論結構如何）並設計和維護 核心 藍圖以滿足這些需求 ”的過程 。它使用 核心 藍圖來指導資料整合、控制資料資產並使資料投資與業務戰略保持一致。

然而， 糟糕的資料架構是僵化且過度集中的 。它使用了錯誤的工具來完成工作，這阻礙了開發和 變更 管理。

二、 基於速度的資料架構

資料速度 是指資料生成的速度、資料移動的速度以及將其處理為可用 指導 的速度。 

根據處理資料的速度，資料架構通常分為兩類：Lambda和Kappa。

（一） Lambda資料架構

1 、什麼是 Lambda

Lambda資料架構由Apache Storm的建立者Nathan Marz於 2011 年開發， 旨在解決大規模實時資料處理的挑戰 。術語 Lambda 源自lambda演算 (λ)，描述了在多個節點上並行執行分散式計算的函式。 Lambda資料架構提供了一個可擴充套件、容錯且靈活的系統來處理大量資料。它允許以混合方式訪問批處理和流處理方法。 

2 、 Lambda 架構的使用場景

1 ） 當您有各種工作負載和速度 要求 時，Lambda架構是理想的選擇。 由於它可以 處理大量資料並提供低延遲查詢結果 ，因此 適合儀表板和報告等實時分析應用程式 。 Lambda 架構對於 批處理 （清理、轉換、資料聚合）、 流處理任務 （事件處理、開發機器學習模型、異常檢測、欺詐預防）以及 構建集中儲存庫 （稱為 “資料湖”）非常有用。

2 ） Lambda架構的關鍵區別在於，它使用兩個獨立的處理系統來處理不同型別的資料處理工作負載 。第一個是 批處理系統 ，它將結果儲存在集中式資料儲存（例如資料倉儲或資料湖）中。第二個系統是 流處理系統 ，它在資料到達時實時處理資料並將結果儲存在分散式資料儲存中。

3 、 Lambda 架構的組成

Lambda架構由攝取層、批處理層、速度層（或流層）和服務層組成。

·  批處理層 ：批處理層處理大量歷史資料並將結果儲存在集中式資料儲存中，例如資料倉儲或分散式檔案系統。該層使用Hadoop或Spark等框架進行高效的 資料 處理，使其能夠提供所有可用資料的總體檢視。

·  速度層：速度層處理高速資料流，並使用 Apache Flink 或Apache Storm等事件處理引擎提供最新的資訊檢視。該層處理傳入的實時資料並將結果儲存在分散式資料儲存中，例如訊息佇列或NoSQL資料庫。

·  服務層 ：無論底層處理系統如何，Lambda架構服務層對於為使用者提供一致的資料訪問 體驗 至關重要。它在支援需要快速訪問當前資訊（例如儀表板和分析）的實時應用程式方面發揮著重要作用。

4 、 Lambda架構 的優勢

Lambda架構解決了計算任意函式的問題，系統必須評估任何給定輸入的資料處理函式（無論是慢動作還是實時） 。此外，它還 提供容錯功能 ，確保在一個系統出現故障或不可用時，任一系統的結果都可以用作另一個系統的輸入。 在高吞吐量、低延遲和近實時應用程式中 ， 這種架構的效率 是很明顯的 。

 

Lambda架構示意圖

5 、 Lambda架構 的缺點

Lambda架構提供了許多優勢，例如可擴充套件性、容錯性以及處理各種資料處理工作負載（批處理和流）的靈活性。但它也有缺點：

·  Lambda架構很複雜 ， 它使用多種技術堆疊來處理和儲存資料。

·  設定和維護可能具有挑戰性 ，尤其是在資源有限的組織中。

·  每個階段的批處理和速度層中都會重複底層邏輯 。這種重複有一個代價：資料差異 。 因為儘管具有相同的邏輯，但一層與另一層的實現不同。因此，錯誤/錯誤的機率較高，並且您可能會遇到批處理層和速度層的不同結果。

（二） Kappa資料架構

2014年，Jay Kreps指出了Lambda架構的一些缺點。這次討論使大資料社群找到了一種使用更少程式碼資源的替代方案 —— Kappa 資料架構。

1 、什麼是 Kappa 資料架構

Kappa（以希臘字母 ϰ 命名，在數學中用於表示迴圈）背後的 主要思想是單個技術堆疊可用於實時和批次資料處理 。該名稱反映了該體系結構對連續資料處理或再處理的重視，而不是基於批處理的方法。 

Kappa 的核心依賴於流式架構 。傳入資料首先儲存在事件流日誌中。然後，它由流處理引擎（例如 Kafka）連續實時處理或攝取到另一個分析資料庫或業務應用程式中。這樣做需要使用各種通訊範例，例如實時、近實時、批處理、微批處理和請求響應 等 。

2 、 Kappa 資料架構的組成

資料重新處理是 Kappa的一項關鍵要求，使源端的任何更改對結果的影響可見。因此， Kappa 架構僅由兩層組成：流 處理 層和服務層。

在Kappa架構中，只有一層處理層：流處理層 。該層負責採集、處理和儲存直播資料。這 種方法消除了對批處理系統的需要。相反，它使用先進的流處理引擎 （例如 Apache Flink、Apache Storm、Apache Kafka 或 Apache Kinesis）來處理大量資料流並提供對查詢結果的快速、可靠的訪問。

流處理層有兩個元件：

·  攝取元件 ：該層從各種來源收集傳入資料，例如日誌、資料庫事務、感測器和 API。資料被實時攝取並儲存在分散式資料儲存中，例如訊息佇列或NoSQL資料庫。

·  處理元件 ：該元件處理大量資料流並提供對查詢結果的快速可靠的訪問。它使用事件處理引擎（例如 Apache Flink 或 Apache Storm）來實時處理傳入資料和歷史資料（來自儲存區域），然後將資訊儲存到分散式資料儲存中。

對於幾乎所有用例，實時資料都勝過 非實時 資料。儘管如此，Kappa架構不應該被視為 Lambda 架構的替代品。 反之，在不需要批處理層的高效能來滿足標準服務質量的情況下， 您應該考慮 Kappa架構。

3 、 Kappa架構 的優勢

Kappa架構旨在提供可擴充套件、容錯且靈活的系統，用於實時處理大量資料 。它使用單一技術堆疊來處理實時和歷史工作負載，並將所有內容視為流。Kappa 架構的主要動機是避免為批處理層和速度層維護兩個獨立的程式碼庫（管道）。 這使得它能夠提供更加精簡的資料處理管道，同時仍然提供對查詢結果的快速可靠訪問。

 

Ka ppa 架構示意圖

4 、 Kappa架構 的缺點

Kappa架構承諾可擴充套件性、容錯性和簡化的管理。然而，它也有缺點。

l Kappa架構理論上比 Lambda更簡單，但對於不熟悉流處理框架的企業來說，技術上仍然可能很複雜。 

l 擴充套件事件流平臺時的基礎設施成本 。在事件流平臺中儲存大量資料可能成本高昂，並會引發其他可擴充套件性問題，尤其是當資料量 達到 TB或PB 級時 。 

l 事件時間和處理時間之間的滯後不可避免地會產生資料 延遲 。因此，Kappa 架構需要一套機制來解決這個問題，例如水印、狀態管理、重新處理或回填。

（三） 探索資料流模型

1 、為什麼會出現資料流模型

Lambda和Kappa試圖透過整合本質上不相容的複雜工具來克服2010年代Hadoop生態系統的缺點。這兩種方法都難以解決協調批處理和流資料的根本挑戰。然而，Lambda和Kappa 為進一步的 改進 提供了靈感和基礎。

統一多個程式碼路徑是管理批處理和流處理的一項重大挑戰。即使有了Kappa架構的統一佇列和儲存層，開發人員也需要使用不同的工具來收集實時統計資料並執行批次聚合作業。今天，他們正在努力應對這一挑戰。

2 、什麼是資料流模型

資料流模型的基本前提是將所有資料視為事件並在不同型別的視窗上執行聚合。實時事件流是無界資料，而批次資料是具有自然視窗的有界事件流。

 

視窗模式示意圖

資料工程師可以選擇不同的視窗，例如滑動 視窗 或 會話視窗 ，以進行實時聚合。資料流模型允許使用幾乎相同的程式碼在同一系統內進行實時和批處理。

“批處理作為流處理的一個特例”的想法已經變得越來越普遍，Flink和Spark等框架也採用了類似的方法。

結語

當然， 關於速度模型的資料架構討論還有另一個 用處 ：適合物聯網 (IoT) 的設計選擇 ，在本篇文章中，我們就不再贅述 。如何最好地構建我們處理資料 的架構，如何 對僵化且緩慢的IT遺留系統 ， 進行現代化改造並將其轉變為現代資料架構 ，顯然，關於這個問題還尚未有定論 。 歡迎與我們共同探討。