Kappa架構取代Hadoop的Lambda架構成為主流 - Waehner

實時資料勝過慢速資料。幾乎每個用例都是如此。然而，企業架構師使用 Lambda 架構構建新的基礎架構，其中包括單獨的批處理層和實時層。這篇博文探討了為什麼稱為 Kappa 架構的單個實時管道更適合。迪斯尼、Shopify 和優步等公司的真實示例探索了Kappa的好處，但也展示了批處理如何在不需要 Lambda 的情況下積極地融入這一討論。

這篇文章在很大程度上來自傑伊·克雷普斯的文章‘質疑Lambda架構’2014年和他的想法，對映到2021年今天現實世界的情況，幾乎所有的商業解決方案，資料儲存和分析工具供應商，和業務應用程式利用事件流和非同步、真正解耦的基於事件的通訊正規化進行資料處理。出於這個原因，許多人從 Lambda 遷移到 Kappa 架構。

現代企業架構

現代企業架構提供雲原生特性：靈活性、彈性、自動化、不同應用程式之間的真正解耦以及實時功能（在需要時）。

真正解耦的微服務、資料網格和領域驅動設計

讓我們快速探索一下流行語，以瞭解當今大多數人如何構建現代企業架構：

• 領域驅動設計 (DDD)在服務通訊和去中心化應用程式環境之間實施嚴格的界限。
• 微服務支援使用不同的程式語言和通訊正規化構建靈活、解耦的應用程式。
• 資料網格允許圍繞資料構建服務。資料是資料網格中的產品。自助服務功能和聯合使業務部門能夠專注於他們的業務問題。

我的部落格文章“微服務、Apache Kafka 和領域驅動設計”更詳細地探討了這一討論（儘管在撰寫本文時還沒有流行語“資料網格”）。事件驅動的流媒體基礎設施，如 Apache Kafka，獨特地實現了正確的解耦和實時資料處理（與傳統的基於 Web 服務/REST/HTTP 的微服務架構相反，與傳統的訊息傳遞系統（MQ、ESB）相反。關於Kafka 與 MQ/ETL/ESB的部落格文章也可能有助於瞭解更多資訊。

實時資料勝過慢速資料，但並非總是如此！

想想您的行業、業務部門、您解決的問題以及您構建的創新應用程式。實時資料勝過慢速資料。這種說法幾乎總是正確的。要麼增加收入，降低成本，降低風險，要麼改善客戶體驗。

靜態資料意味著將資料儲存在資料庫、資料倉儲或資料湖中。這樣，在許多用例中資料處理得太晚了——即使實時流元件（如 Kafka）攝取了資料。資料處理仍然是 Web 服務呼叫、SQL 查詢或 map-reduce 批處理，而不是為您的問題提供結果。

不要誤會我的意思。靜止資料並不是一件壞事。報告（商業智慧）、分析（批處理）和模型訓練（機器學習）等幾個用例非常適合這種方法。但是在幾乎所有其他用例中實時資料會擊敗批處理。

我在部落格文章“ Serverless Kafka in a Cloud-native Data Lake Architecture ”中分析了靜態資料和動態資料之間的關係，以及這種關於企業架構的觀點如何隨著大多數公司的雲優先戰略而改變。

實時資料處理的事實標準就是Apache卡夫卡。因此，本文中涵蓋的真實示例使用 Kafka。

考慮到這種情況，讓我們重新審視 Lambda 架構。

Lambda 架構

Nathan Marz 創造了 Lambda 架構：一種資料處理架構，旨在通過利用批處理和流處理方法來處理大量資料。

Lambda 架構包括批處理、速度和服務層。這種方法不僅可以實時處理資料，還可以輕鬆地重新處理批量靜態資料集。亂序資料的問題也解決了。

這種方法試圖通過使用批處理來提供批處理資料的全面和準確的檢視，同時使用實時流處理來提供線上資料的檢視來平衡延遲、吞吐量和容錯性。lambda 架構的興起與大資料、實時分析的穩定增長以及減少 map-reduce 延遲的驅動相關。

 Lambda 架構的兩種不同方法：

1. 最初的方法提供了一個統一的服務層。一個統一的服務層加入了實時層和批處理層：
2. 另一種選擇是兩個獨立的服務層。一層用於實時消費，另一層用於批量消費：

我在該領域更多地看到了第二種選擇。最後，兩者都有相同的概念，即為資料攝取和處理構建兩個獨立的層。

Hadoop的銷售商投巨資Lambda架構部署和操作與許多大資料框架的一個超級複雜的基礎設施。

今天，我只聽到企業抱怨這種複雜性和商業價值缺失的痛苦。毫不奇怪，這些供應商中的大多數都沒有生存下來，或者有一個非常混亂和不明確的未來產品戰略。

迪士尼在一張幻燈片上總結了 Lambda 架構的問題。。。。。

批處理和流處理兩側各自需要不同的程式碼庫必須保持，並且使得處理後的資料從產生兩個路徑相同的結果保持同步。此外，對於批處理、速度和服務層，所有內容都需要（至少）處理兩次。這增加了儲存、網路和計算的成本和運營工作。

Jay Kreps在 2014 年提出 Kappa 架構時也有類似的論點：“Lambda 架構的問題在於，維護需要在兩個複雜分散式系統中產生相同結果的程式碼就像看起來一樣，這將是痛苦”。

Kappa 架構

是基於事件的，並且能夠在實時的事務和分析工作負載的所有規模來處理所有的資料。

Kappa 架構背後的核心前提是您可以使用單個技術堆疊執行實時處理和批處理。基礎設施的核心是流式架構。首先，事件流平臺日誌儲存傳入資料。從那裡，流處理引擎實時連續處理資料，或通過任何通訊正規化和速度（包括實時、近實時、批處理、請求-響應）將資料攝取到任何其他分析資料庫或業務應用程式中。

與 Lambda 架構不同，在這種方法中，您僅在處理程式碼發生變化時才進行重新處理，並且需要重新計算結果。而且，當然，重新計算的工作只是相同程式碼的改進版本，執行在相同的框架上，採用相同的輸入資料。

Kappa 架構有幾個好處：

• 使用單一架構處理所有用例（流、批處理、RPC）
• 一個始終同步的程式碼庫
• 一套基礎設施和技術
• 基礎設施的核心是實時、可擴充套件和可靠
• 提高資料質量，保證排序且無錯配
• 無需為新用例重新設計

Kappa 架構利用單一的事實來源，專注於企業架構中的簡單性。人們可以在實時和批處理系統的單一處理框架上開發、測試、除錯和操作他們的系統。需要明確的是：某些應用程式的領先系統仍然可以是另一個系統。比如ERP的主導系統仍然是SAP，而消費的真實來源是Kafka日誌。

用於事務性和分析性工作負載的 Kappa

與資料湖相反，事件流驅動的Kappa 架構除了支援分析工作負載外，還支援事務性工作負載。

例如，Kafka 及其生態系統支援僅一次語義，因此您可以使用關鍵任務 SLA、低延遲和內建容錯功能構建下一個用於售後或客戶互動的支付平臺。獨立地，資料科學團隊使用歷史事件來使用機器學習在批處理過程中尋找洞察力。

迪斯尼遷移教訓：

Kappa 架構聽起來好得令人難以置信？嗯，一個基本的經驗法則仍然有效：為工作使用正確的工具！

事件流是一種正規化轉變。大爆炸遷移是行不通的。以下是迪士尼在引入 Kappa 架構方面的一些經驗教訓：

由於大爆炸不起作用，一個好方法是重新思考資料和資料庫。Martin Kleppmann 稱其為“將資料庫翻過來”。讓我們看看這種方法以及它如何幫助利用 Kappa 架構與其他資料庫和分析平臺的結合。

解決 Kappa 挑戰的內外視角

將資料庫由內而外是企業架構的一種新思維。基礎設施的核心是基於事件和實時的。在需要時，您可以批量使用事件，或者在使用事件後將它們連同它們的概念和範例儲存在額外的儲存和分析工具中。

Kappa的內在視角：中樞神經系統

想想像 Kafka 這樣的事件流平臺：

• 資料可用性/保留：壓縮主題、分層儲存
• 資料一致性和容錯：恰好一次語義、多區域叢集、叢集連結
• 處理遲到的資料：事件時間和處理時間不同。流應用程式中的狀態管理、適當的資料接收器、保證排序的重放和時間戳。
• 資料再處理和回填：動態叢集（理想情況下是無伺服器雲產品或至少是雲原生自管理叢集）、有狀態應用程式（Kafka Streams、ksqlDB、外部流處理框架，如 Apache Flink）。
• 資料整合：用於源和接收器的Kafka Connect、用於任何語言的客戶端、REST 代理（實時但也可以批處理和 RPC）

其他問題：Kafka 不能很好地擴充套件動態突發工作負載。複雜的 SQL 查詢和連線還需要另一個資料庫。

想想任何業務應用程式、資料儲存或分析平臺：

• 資料消耗：消耗來自中樞神經系統的資料。以您的速度（實時、近實時、批處理、RPC）使用資料。
• 資料儲存：根據需要將資料儲存在您的儲存中（記憶體中、短期儲存、長期儲存）。
• 資料處理：處理用例的資料（實時通知、查詢引擎的索引、報告或模型訓練的批處理等）。複雜的處理在事件流平臺中是不可行的（例如，複雜的連線、使用批處理演算法的密集計算）。

討論“ Apache Kafka可以用作資料庫嗎？”也有助於理解使用 Kafka 作為資料儲存的觀點和權衡。

 。。。。

Kappa 架構的真實示例

• 優步的 Kappa 每天處理數萬億條訊息和 PB

優步是一家非常著名的科技巨頭。他們經常公開談論他們的軟體架構和部署。優步是世界上最重要的 Kafka 使用者之一。與此同時，他們每天處理超過 4 萬億條資訊和 3PB。

作為這篇博文的完美契合，優步在最近的 Kafka 峰會上展示了他們的 Kappa 架構。

• Shopify 的 Kappa 用於無狀態和有狀態資料流

Shopify 在最近的Kafka 峰會演講中展示了他們的 Kappa 架構：“是時候停止使用 Lambda 架構了”該會議涵蓋了 Kappa 架構的問題以及 Shopify 如何使用不同的構建塊來解決這些問題。三個關鍵元件是日誌（Kafka）、流框架（Kafka Streams 和 Apache Flink）和資料接收器（任何實時消費者或資料儲存）。

• 迪斯尼的Kappa作為唯一的真相來源

迪斯尼卡夫卡峰會演講“大資料Kappa ”很有啟發性。它可能包括現實世界 Kappa 部署的最多經驗教訓和權衡。我鼓勵您觀看點播視訊 — 構建您自己的 Kappa 架構的許多見解和指南。

迪士尼的所有資料寫入都通過 Kafka 作為真實來源。

• 示例專案：用於機器學習的 Kappa，包括模型訓練、評分和監控

在 Uber、Shopify 和 Disney 的真實示例之後，我想分享一個更實際的程式碼示例：連線到 100,000 個 IoT 裝置以進行流式機器學習的技術演示。用例是關於整合數以萬計或數十萬個物聯網裝置並實時處理資料。演示用例是聯網汽車基礎設施中的預測性維護（即異常檢測），以預測發動機故障。

實現的 Kappa 架構為各種非常不同的用例和處理範例提供了單一的實時基礎設施：

• 通過 MQTT 代理從 IoT 裝置以高吞吐量實時攝取資料：與數百萬個介面（在本例中為模擬車輛）整合。
• 模型訓練的批處理：來自資料科學家的 TensorFlow Python 應用程式使用來自 Kafka 日誌的歷史資料來訓練分析模型。
• 用於模型評分的實時流處理：基於 Java 的流應用程式由 Kafka Streams / ksqlDB 提供支援，並由具有關鍵任務 SLA 和低延遲的生產工程師操作。
• 近乎實時地將資料攝取到數字孿生中以進行分析：Kafka Connect 將資料攝取到不同的資料庫和應用程式中，在本例中為 MongoDB Atlas 雲服務。
• 用於移動應用程式整合和事務性工作負載的同步請求-響應/RPC 通訊：Confluent REST 代理（或任何其他 Web/移動代理）向人類傳送實時警報。

整個基礎設施都是雲原生的。它在 Kubernetes 上執行，可以部署在資料中心或任何超大規模機上。以下部落格文章詳細解釋了該演示：IoT Live Demo — 100.000 輛互聯汽車與 Kubernetes、Kafka、MQTT、TensorFlow。程式碼在Github 專案中可用。

下一代軟體產品和 SaaS 產品下的 Kappa

軟體公司面臨著與優步、Shopify 或迪士尼等終端使用者相同的挑戰。因此，軟體供應商將 Kappa 架構和實時功能作為其基礎架構的核心也就不足為奇了。

本節展示了一些軟體供應商的示例，這些供應商在其下一代軟體產品中轉向基於事件的架構、事件流和非同步外部介面。

• 業務解決方案（Salesforce、SAP、Slack 等）

跨不同業務解決方案的幾個示例：

1. Salesforce：內部“平臺事件”架構嚴重依賴 Apache Kafka 進行大規模解耦實時資料處理。外部 API，例如與 Salesforce 專有 sObject 資料型別的整合，從 SOAP 和 REST Web 服務轉移到流 API PushTopics、企業訊息傳遞平臺事件和變更資料捕獲事件。
2. SAP：SAP不再依賴 BAPI 和 iDoc 等傳統專有介面，而是在其下一代 SAP S/4 Hana ERP 平臺中轉向基於事件的 API。部落格“ Apache Kafka 的 SAP 整合選項”展示了眾多遺留介面和替代現代基於事件的整合選項的混亂。
3. Slack：作為本質上的訊息傳遞平臺，其核心後端基礎設施的核心利用事件流也就不足為奇了。Slack 的資料流團隊專注於在亞馬遜資料中心的數十個叢集中以每天數萬億條訊息的規模為公司提供 Kafka 即服務。對於前端，Slack 當前的架構利用了使用 Envoy 和 WebSockets 構建的服務網格

• 資料庫、資料倉儲、日誌分析

資料儲存和分析供應商傳統上是用於長期儲存、儀表板、報告和互動式查詢的批處理技術。大多數解決方案的核心仍然是用於分析工作負載的批處理系統。這是這些產品和服務的核心業務。

儘管如此，由於客戶需求，幾乎所有這些供應商都進入了（近）實時業務。因此，基於事件的整合功能和近乎實時的攝取、處理和分析變得越來越普遍。一些例子：

1. MongoDB：“更改流”允許應用程式從基於文件的 NoSQL 資料儲存訪問實時資料更改。
2. Snowflake：“Snowpipe”可以幫助組織將持續生成的資料無縫載入到雲資料倉儲中。
3. Elasticsearch：“資料流”讓您可以跨多個索引儲存僅追加的時間序列資料，同時為請求提供單個命名資源。資料流非常適合日誌、事件、指標和其他連續生成的資料，以將資料提取到 Elastic 搜尋引擎中。

這些解決方案的共同點是，它們從批處理轉變為近乎實時地攝取到其資料儲存或資料湖中。儘管如此，他們仍然儲存和分析靜態資料。因此，這是對事件流的補充而非替代。

市場的新進入者試圖通過在其核心提供實時基礎設施來與上述資料儲存供應商區分開來。Rockset就是一個很好的例子，它是一個可擴充套件的雲實時分析平臺。由於它是一個原生的實時解決方案，Rockset 原生地與 Apache Kafka 等事件流平臺整合。