實時分析處理三大場景 Lambda 架構部署圖 Kappa 架構部署圖Omega vs. Lambda vs. Kappa

當下，瞬息萬變的商業社會要求企業更快的做出決策，從“雙十一”和春晚直播實時大屏、銀行和稅務的風險實時阻斷、機器學習建模逐步在線化等趨勢中，我們可以發現，企業除了離線數據分析還有大量的實時數據分析需求。因此，摸著“數據”過河，小步快跑就推動了企業“實時”需求的升級。在很多線上場景中，實時性已經成為了提升企業競爭力的核心手段。

運營層面：實時業務變化，實時營銷效果，當日分時業務趨勢分析等；

用戶層面：搜索推薦排序，實時行為等特征變量的生產，為用戶推薦更精準的內容；

風控層面：實時風險識別、反欺詐、異常交易等都是廣泛應用實時數據的場景；

生產層面：實時監控系統的穩定性和健康狀況等。

站在技術角度可以將實時需求分為三類：實時流處理、實時按需分析、離線分析。通過下圖，以一個事件發生的前后作為時間軸，可以將時間線分為三個階段，分別是事件發生的同時、事件發生后短時間內、事件發生后較長時間，對應的實時要求分別是實時流處理、實時按需分析、離線分析。

以一次銀行轉賬為例，交易發生的同時要進行交易反欺詐檢測，通過實時流處理系統將本次交易的時間、金額、位置等要素進行加工形成衍生特征提供給反欺詐應用系統；該筆交易結束后，需要立即反映到實時報表和統計分析中，同時業務用戶也會按照特定需求查詢到該筆交易（比如近 10 分鐘內新增的大額交易），由于實時報表和實時統計分析需求千變萬化，流處理系統難以滿足，所以需要實時按需分析；這筆交易發生后的較長時間內，都會被用來進行報表統計、數據挖掘和機器學習，因此傳統的離線分析也是基本需求之一。

目前，實時處理有兩種典型的架構：Lambda 和 Kappa 架構。出于歷史原因，這兩種架構的產生和發展都具有一定局限性。即便引入流處理引擎實現了部分固定模式的實時分析，仍無達到 T+0 全實時水平。

Lambda架構

Lambda產生背景

當運行大量數據時，Hadoop 所耗費的時間也會變得越來越多，無法滿足一些需要實時分析處理的場景（比如抖音、淘寶的動態推薦），因此新的流式計算引擎如 Spark Streaming、Flink、Storm 等開始出現。流處理、批處理配合使用才能滿足絕大部分應用場景，因此Lambda 架構被提出。

Lambda實現原理

Lambda 架構通過把數據分解為服務層（Serving Layer）、速度層（Speed Layer，亦即流處理層）、批處理層（Batch Layer）三層來解決不同數據集的數據需求。在批處理層主要對離線數據進行處理，將接入的數據進行預處理和存儲，查詢直接在預處理結果上進行，不需再進行完整的計算，最后以批視圖的形式提供給業務應用。

Lambda 架構邏輯圖

批視圖聽起來有些抽象，由于服務層通常使用 MySQL，HBase 等實現，供業務應用查詢使用，此處的批視圖就是 MySQL 或 HBase 中的一些表（見下圖），這些表存儲著批處理作業產生的結果；流處理層主要是對實時增量數據進行處理，新數據通過流計算不斷的更新實時視圖，比如針對實時大屏場景，實時視圖通常就是 MySQL 中的一張表，流處理作業在新數據到來后不停更新實時視圖提供給到業務層；服務層主要是響應用戶的請求，根據用戶需求把批處理層和流處理層產生的數據合并到一起得到最終的數據集。

Lambda 在實際生產環境中的部署通常要比上圖更加復雜，下圖是貼近實際部署的典型示例。可以看出，實際情況要通過一系列不同的存儲和計算引擎 (HBase、Druid、Hive、Presto、Redis 等) 復雜協同才能滿足業務的實時需求，此外多個存儲之間需要通過數據同步任務保持大致的同步。Lambda 架構在實際落地過程中極其復雜，使整個業務的開發耗費了大量的時間。

Lambda 架構在企業落地的實際情況

Lambda 優勢與不足

優點：是將流處理和批處理分開，很好的結合了批處理和實時流計算的優點，架構穩定，實時計算成本可控，提高了整個系統的容錯性。

缺點：(1) 由多個引擎和系統組合而成，批處理 (Batch)、流處理 (Streaming) 以及合并查詢 (Merged Query) 的實現需要使用不同的開發語言，造成開發、維護和學習成本較高；(2) 數據在不同的視圖 (View) 中存儲多份，浪費存儲空間，數據一致性的問題難以解決。

Kappa 架構

Kappa 產生背景

既然 Lambda 架構難保證數據一致性，雙倍維護系統成本，那么一套系統解決批處理和流處理的訴求就產生了，對應的解決方案便是 Kappa 架構（即批流一體）。

Kappa 實現原理

Kappa 架構在 Lambda 架構的基礎上移除了批處理層，利用流計算的分布式特征，加大流數據的時間窗口，統一批處理和流處理，處理后的數據可以直接給到業務層使用。因為在 Kappa 架構下，作業處理的是所有歷史數據和當前數據，其產生的結果我們稱之為實時批視圖（Realtime_Batch_View）。

Kappa 架構邏輯圖

在 Kappa 架構中，輸入數據在源端采集后通常存儲在 Kafka 中，在流處理程序需要升級迭代時，會啟動一個新版本作業（StreamJob_Version_N+1）, 該作業會從 Kafka 中讀取所有歷史數據和新增數據，直到追上舊版本作業（StreamJob_Version_N），舊的作業版本才可以停掉。Kappa 架構通過這種方法升級流處理程序。

Kappa 架構的流處理系統通常使用 Spark Streaming 或者 Flink 等實現，服務層通常使用MySQL 或 HBase 等實現。

Kappa 優勢與不足

優點：由于所有數據都通過流處理計算，開發人員只需要維護實時處理模塊，不需要離線實時數據合并，運維簡單，生產統一。

缺點：(1) 依賴 Kafka 等消息隊列來保存所有歷史，而 Kafka 難以實現數據的查詢、更新和糾錯，發生故障或者升級時需要重做所有歷史，周期較長；(2) Kappa 主要是針對不可變更數據，無法實時匯集多個可變數據源形成的數據集快照，不適合即席查詢。

Kappa 架構實際應用起來有較大的局限性，因此 Kappa 架構在業內生產落地的案例不多見，且場景比較單一。

Omega 架構

Omega 產生背景

既然 Kappa 架構實際落地困難，Lambda 架構又很難保障數據的一致性，兩個架構又都很難處理可變更數據（如關系數據庫中不停變化的實時數據），那么自然需要一種新的架構滿足企業實時分析的全部需求，這就是 Omega 全實時架構。Omega 架構由偶數科技于 2021 年初提出，同時滿足實時流處理、實時按需分析和離線分析。

Omega 實現原理

Omega 架構由流處理系統和實時數倉構成。相比 Lambda 和 Kappa，Omega 架構新引入了實時數倉和快照視圖 (Snapshot View) 的概念，快照視圖是歸集了可變更數據源和不可變更數據源后形成的 T+0 實時快照，可以理解為所有數據源在實時數倉中的鏡像和歷史，隨著源庫的變化實時變化。

因此，實時查詢可以通過存儲于實時數倉的快照視圖得以實現。實時快照提供的場景可以分為兩大類：一類是多個源庫匯集后的跨庫查詢，比如一個保險用戶的權益視圖；另一類是任意時間粒度的分析查詢，比如最近 5 分鐘的交易量、最近 10 分鐘的信用卡開卡量等等。

另外，任意時間點的歷史數據都可以通過 T+0 快照得到（為了節省存儲，T+0 快照可以拉鏈形式存儲在實時數倉 ODS 中，所以快照視圖可以理解為實時拉鏈），這樣離線查詢可以在實時數倉中完成，離線查詢結果可以包含最新的實時數據，完全不再需要通過 MPP+Hadoop 組合來處理離線跑批及分析查詢。

Omega 架構邏輯圖

流處理系統 WASP 既可以實現實時連續的流處理，也可以實現 Kappa 架構中的批流一體，但與Kappa 架構不同的是，OushuDB 實時數倉存儲來自數據源的全部歷史數據（詳見下圖），而在 Kappa 架構中源端采集后通常存儲在 Kafka 中。

Omega 架構部署圖

因此，當需要流處理應用版本變更的時候，流處理引擎不再需要訪問 Kafka，而是訪問實時數倉 OushuDB 獲得所有歷史數據，規避了 Kafka 難以實現數據更新和糾錯的問題，大幅提高效率。此外，整個服務層可以在實時數倉中實現，而無需額外引入 MySQL、HBase 等組件，極大簡化了數據架構。

在 Omega 全實時架構的加持下，偶數率先實現了具備實時能力的湖倉一體，即實時湖倉。實時湖倉統一了湖倉市（數據湖、數倉、集市），避免數據孤島的同時，極大提升了企業實時數據分析能力，讓企業在快速更迭的商業環境中立于不敗之地。