實(shí)時(shí)分析處理三大場(chǎng)景 Lambda 架構(gòu)部署圖 Kappa 架構(gòu)部署圖Omega vs. Lambda vs. Kappa

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

運(yùn)營(yíng)層面：實(shí)時(shí)業(yè)務(wù)變化，實(shí)時(shí)營(yíng)銷效果，當(dāng)日分時(shí)業(yè)務(wù)趨勢(shì)分析等；

用戶層面：搜索推薦排序，實(shí)時(shí)行為等特征變量的生產(chǎn)，為用戶推薦更精準(zhǔn)的內(nèi)容；

風(fēng)控層面：實(shí)時(shí)風(fēng)險(xiǎn)識(shí)別、反欺詐、異常交易等都是廣泛應(yīng)用實(shí)時(shí)數(shù)據(jù)的場(chǎng)景；

生產(chǎn)層面：實(shí)時(shí)監(jiān)控系統(tǒng)的穩(wěn)定性和健康狀況等。

站在技術(shù)角度可以將實(shí)時(shí)需求分為三類：實(shí)時(shí)流處理、實(shí)時(shí)按需分析、離線分析。通過下圖，以一個(gè)事件發(fā)生的前后作為時(shí)間軸，可以將時(shí)間線分為三個(gè)階段，分別是事件發(fā)生的同時(shí)、事件發(fā)生后短時(shí)間內(nèi)、事件發(fā)生后較長(zhǎng)時(shí)間，對(duì)應(yīng)的實(shí)時(shí)要求分別是實(shí)時(shí)流處理、實(shí)時(shí)按需分析、離線分析。

以一次銀行轉(zhuǎn)賬為例，交易發(fā)生的同時(shí)要進(jìn)行交易反欺詐檢測(cè)，通過實(shí)時(shí)流處理系統(tǒng)將本次交易的時(shí)間、金額、位置等要素進(jìn)行加工形成衍生特征提供給反欺詐應(yīng)用系統(tǒng)；該筆交易結(jié)束后，需要立即反映到實(shí)時(shí)報(bào)表和統(tǒng)計(jì)分析中，同時(shí)業(yè)務(wù)用戶也會(huì)按照特定需求查詢到該筆交易（比如近10 分鐘內(nèi)新增的大額交易），由于實(shí)時(shí)報(bào)表和實(shí)時(shí)統(tǒng)計(jì)分析需求千變?nèi)f化，流處理系統(tǒng)難以滿足，所以需要實(shí)時(shí)按需分析；這筆交易發(fā)生后的較長(zhǎng)時(shí)間內(nèi)，都會(huì)被用來(lái)進(jìn)行報(bào)表統(tǒng)計(jì)、數(shù)據(jù)挖掘和機(jī)器學(xué)習(xí)，因此傳統(tǒng)的離線分析也是基本需求之一。

目前，實(shí)時(shí)處理有兩種典型的架構(gòu)：Lambda 和 Kappa 架構(gòu)。出于歷史原因，這兩種架構(gòu)的產(chǎn)生和發(fā)展都具有一定局限性。即便引入流處理引擎實(shí)現(xiàn)了部分固定模式的實(shí)時(shí)分析，仍無(wú)達(dá)到 T+0 全實(shí)時(shí)水平。

Lambda架構(gòu)

Lambda產(chǎn)生背景

當(dāng)運(yùn)行大量數(shù)據(jù)時(shí)，Hadoop 所耗費(fèi)的時(shí)間也會(huì)變得越來(lái)越多，無(wú)法滿足一些需要實(shí)時(shí)分析處理的場(chǎng)景（比如抖音、淘寶的動(dòng)態(tài)推薦），因此新的流式計(jì)算引擎如 Spark Streaming、Flink、Storm 等開始出現(xiàn)。流處理、批處理配合使用才能滿足絕大部分應(yīng)用場(chǎng)景，因此Lambda 架構(gòu)被提出。

Lambda實(shí)現(xiàn)原理

Lambda 架構(gòu)通過把數(shù)據(jù)分解為服務(wù)層（Serving Layer）、速度層（Speed Layer，亦即流處理層）、批處理層（Batch Layer）三層來(lái)解決不同數(shù)據(jù)集的數(shù)據(jù)需求。在批處理層主要對(duì)離線數(shù)據(jù)進(jìn)行處理，將接入的數(shù)據(jù)進(jìn)行預(yù)處理和存儲(chǔ)，查詢直接在預(yù)處理結(jié)果上進(jìn)行，不需再進(jìn)行完整的計(jì)算，最后以批視圖的形式提供給業(yè)務(wù)應(yīng)用。

Lambda 架構(gòu)邏輯圖

批視圖聽起來(lái)有些抽象，由于服務(wù)層通常使用 MySQL，HBase 等實(shí)現(xiàn)，供業(yè)務(wù)應(yīng)用查詢使用，此處的批視圖就是 MySQL 或 HBase 中的一些表（見下圖），這些表存儲(chǔ)著批處理作業(yè)產(chǎn)生的結(jié)果；流處理層主要是對(duì)實(shí)時(shí)增量數(shù)據(jù)進(jìn)行處理，新數(shù)據(jù)通過流計(jì)算不斷的更新實(shí)時(shí)視圖，比如針對(duì)實(shí)時(shí)大屏場(chǎng)景，實(shí)時(shí)視圖通常就是 MySQL 中的一張表，流處理作業(yè)在新數(shù)據(jù)到來(lái)后不停更新實(shí)時(shí)視圖提供給到業(yè)務(wù)層；服務(wù)層主要是響應(yīng)用戶的請(qǐng)求，根據(jù)用戶需求把批處理層和流處理層產(chǎn)生的數(shù)據(jù)合并到一起得到最終的數(shù)據(jù)集。

Lambda 在實(shí)際生產(chǎn)環(huán)境中的部署通常要比上圖更加復(fù)雜，下圖是貼近實(shí)際部署的典型示例?？梢钥闯?，實(shí)際情況要通過一系列不同的存儲(chǔ)和計(jì)算引擎 (HBase、Druid、Hive、Presto、Redis 等) 復(fù)雜協(xié)同才能滿足業(yè)務(wù)的實(shí)時(shí)需求，此外多個(gè)存儲(chǔ)之間需要通過數(shù)據(jù)同步任務(wù)保持大致的同步。Lambda 架構(gòu)在實(shí)際落地過程中極其復(fù)雜，使整個(gè)業(yè)務(wù)的開發(fā)耗費(fèi)了大量的時(shí)間。

Lambda 架構(gòu)在企業(yè)落地的實(shí)際情況

Lambda 優(yōu)勢(shì)與不足

優(yōu)點(diǎn)：是將流處理和批處理分開，很好的結(jié)合了批處理和實(shí)時(shí)流計(jì)算的優(yōu)點(diǎn)，架構(gòu)穩(wěn)定，實(shí)時(shí)計(jì)算成本可控，提高了整個(gè)系統(tǒng)的容錯(cuò)性。

缺點(diǎn)：(1) 由多個(gè)引擎和系統(tǒng)組合而成，批處理 (Batch)、流處理 (Streaming) 以及合并查詢 (Merged Query) 的實(shí)現(xiàn)需要使用不同的開發(fā)語(yǔ)言，造成開發(fā)、維護(hù)和學(xué)習(xí)成本較高；(2) 數(shù)據(jù)在不同的視圖 (View) 中存儲(chǔ)多份，浪費(fèi)存儲(chǔ)空間，數(shù)據(jù)一致性的問題難以解決。

Kappa 架構(gòu)

Kappa 產(chǎn)生背景

既然 Lambda 架構(gòu)難保證數(shù)據(jù)一致性，雙倍維護(hù)系統(tǒng)成本，那么一套系統(tǒng)解決批處理和流處理的訴求就產(chǎn)生了，對(duì)應(yīng)的解決方案便是 Kappa 架構(gòu)（即批流一體）。

Kappa 實(shí)現(xiàn)原理

Kappa 架構(gòu)在 Lambda 架構(gòu)的基礎(chǔ)上移除了批處理層，利用流計(jì)算的分布式特征，加大流數(shù)據(jù)的時(shí)間窗口，統(tǒng)一批處理和流處理，處理后的數(shù)據(jù)可以直接給到業(yè)務(wù)層使用。因?yàn)樵?Kappa 架構(gòu)下，作業(yè)處理的是所有歷史數(shù)據(jù)和當(dāng)前數(shù)據(jù)，其產(chǎn)生的結(jié)果我們稱之為實(shí)時(shí)批視圖（Realtime_Batch_View）。

Kappa 架構(gòu)邏輯圖

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

Kappa 架構(gòu)的流處理系統(tǒng)通常使用 Spark Streaming 或者 Flink 等實(shí)現(xiàn)，服務(wù)層通常使用MySQL 或 HBase 等實(shí)現(xiàn)。

Kappa 優(yōu)勢(shì)與不足

優(yōu)點(diǎn)：由于所有數(shù)據(jù)都通過流處理計(jì)算，開發(fā)人員只需要維護(hù)實(shí)時(shí)處理模塊，不需要離線實(shí)時(shí)數(shù)據(jù)合并，運(yùn)維簡(jiǎn)單，生產(chǎn)統(tǒng)一。

缺點(diǎn)：(1) 依賴 Kafka 等消息隊(duì)列來(lái)保存所有歷史，而 Kafka 難以實(shí)現(xiàn)數(shù)據(jù)的查詢、更新和糾錯(cuò)，發(fā)生故障或者升級(jí)時(shí)需要重做所有歷史，周期較長(zhǎng)；(2) Kappa 主要是針對(duì)不可變更數(shù)據(jù)，無(wú)法實(shí)時(shí)匯集多個(gè)可變數(shù)據(jù)源形成的數(shù)據(jù)集快照，不適合即席查詢。

Kappa 架構(gòu)實(shí)際應(yīng)用起來(lái)有較大的局限性，因此 Kappa 架構(gòu)在業(yè)內(nèi)生產(chǎn)落地的案例不多見，且場(chǎng)景比較單一。

Omega 架構(gòu)

Omega 產(chǎn)生背景

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

Omega 實(shí)現(xiàn)原理

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

因此，實(shí)時(shí)查詢可以通過存儲(chǔ)于實(shí)時(shí)數(shù)倉(cāng)的快照視圖得以實(shí)現(xiàn)。實(shí)時(shí)快照提供的場(chǎng)景可以分為兩大類：一類是多個(gè)源庫(kù)匯集后的跨庫(kù)查詢，比如一個(gè)保險(xiǎn)用戶的權(quán)益視圖；另一類是任意時(shí)間粒度的分析查詢，比如最近5 分鐘的交易量、最近10 分鐘的信用卡開卡量等等。

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

Omega 架構(gòu)邏輯圖

流處理系統(tǒng) WASP 既可以實(shí)現(xiàn)實(shí)時(shí)連續(xù)的流處理，也可以實(shí)現(xiàn) Kappa 架構(gòu)中的批流一體，但與Kappa 架構(gòu)不同的是，OushuDB 實(shí)時(shí)數(shù)倉(cāng)存儲(chǔ)來(lái)自數(shù)據(jù)源的全部歷史數(shù)據(jù)（詳見下圖），而在 Kappa 架構(gòu)中源端采集后通常存儲(chǔ)在 Kafka 中。

Omega 架構(gòu)部署圖

因此，當(dāng)需要流處理應(yīng)用版本變更的時(shí)候，流處理引擎不再需要訪問 Kafka，而是訪問實(shí)時(shí)數(shù)倉(cāng) OushuDB 獲得所有歷史數(shù)據(jù)，規(guī)避了 Kafka 難以實(shí)現(xiàn)數(shù)據(jù)更新和糾錯(cuò)的問題，大幅提高效率。此外，整個(gè)服務(wù)層可以在實(shí)時(shí)數(shù)倉(cāng)中實(shí)現(xiàn)，而無(wú)需額外引入 MySQL、HBase 等組件，極大簡(jiǎn)化了數(shù)據(jù)架構(gòu)。

在 Omega 全實(shí)時(shí)架構(gòu)的加持下，偶數(shù)率先實(shí)現(xiàn)了具備實(shí)時(shí)能力的湖倉(cāng)一體，即實(shí)時(shí)湖倉(cāng)。實(shí)時(shí)湖倉(cāng)統(tǒng)一了湖倉(cāng)市（數(shù)據(jù)湖、數(shù)倉(cāng)、集市），避免數(shù)據(jù)孤島的同時(shí)，極大提升了企業(yè)實(shí)時(shí)數(shù)據(jù)分析能力，讓企業(yè)在快速更迭的商業(yè)環(huán)境中立于不敗之地。