1.Lambda架構(gòu)

對于在云端的數(shù)據(jù)中心實現(xiàn)針對海量歷史數(shù)據(jù)的批量計算(及優(yōu)化)，同時需要分別在云端、邊緣端實現(xiàn)針對流數(shù)據(jù)的實時處理的場景。換言之，為了達到全量數(shù)據(jù)批處理的準確性與實時數(shù)據(jù)流處理的低延遲的兼具，Nathan Marz基于他在Backtype和Twitter公司中對大數(shù)據(jù)處理系統(tǒng)的設(shè)計、開發(fā)經(jīng)驗，于2013年提出了批流處理系統(tǒng)架構(gòu)——Lambda。

Lambda架構(gòu)是當前大數(shù)據(jù)中批流處理方向影響最為深刻、應(yīng)用最為廣泛的架構(gòu)，主要分為以下3個組成部分：

(1)批處理層(batch layer)

該層負責兩方面的內(nèi)容：1)管理“主數(shù)據(jù)庫”，即保存有完整的歷史數(shù)據(jù)、持久化存儲的、不可變的、僅支持追加的數(shù)據(jù)倉庫;2)計算批處理視圖，即通過批處理的方式對全量數(shù)據(jù)進行分析所得出的視圖。

可見，批處理部分類似于其他專用批處理系統(tǒng)，對大規(guī)模的數(shù)據(jù)在保證準確性和完整性的前提下，利用批處理優(yōu)化技術(shù)進行全局分析。

(2)服務(wù)層(serving layer)

該層與批處理層一同工作，功能上作為應(yīng)用程序進行查詢的服務(wù)器，負責對批處理層中產(chǎn)生的批處理視圖建立索引，以便應(yīng)用程序能夠根據(jù)用戶的指定進行低延遲的、點對點(ad-hoc)的查詢。需要注意的是，這里的“低延遲”指的是用于進行查詢(query)時系統(tǒng)響應(yīng)結(jié)果的延遲，這個時間會因為索引的建立而大大降低，但并不會改變批處理層中對全量數(shù)據(jù)進行計算更新的時間開銷。

(3)流處理層(speed layer)

上述由批處理層與服務(wù)層組成的批處理部分能夠?qū)﹄x線的歷史數(shù)據(jù)進行完整的分析，但如同傳統(tǒng)的批處理專用系統(tǒng)，這個處理過程將會遍歷所有已存在的數(shù)據(jù)，將不可避免地造成較大的計算開銷，并占用較長的處理時間。那么為了實現(xiàn)對實時數(shù)據(jù)的流式處理，便需要“流處理層”與它相結(jié)合。流處理層即基于流式處理建立的數(shù)據(jù)處理模塊，彌補了批處理部分的高延遲更新缺陷，僅用于接收最近產(chǎn)生的流數(shù)據(jù)，并根據(jù)它進行計算得出即時結(jié)果。這里的“計算”更準確而言應(yīng)是“近似計算”，因為流處理部分并不能夠獲知全局的數(shù)據(jù)，而僅僅能夠獲取剛剛發(fā)生的事件及最近的狀態(tài)信息，但同時也由于這個原因，流處理層具備批處理模塊無法達到的視圖更新速度，能夠以高出數(shù)個數(shù)量級的響應(yīng)效率，支撐用戶對于最新數(shù)據(jù)的分析要求。

在上述批處理層、服務(wù)層和流處理層的基礎(chǔ)上，Lambda架構(gòu)的核心思想便是將數(shù)據(jù)輸入到了批處理、流處理兩個數(shù)據(jù)鏈路中，分別并行地進行計算，并在用戶進行查詢的階段，將兩個數(shù)據(jù)鏈路產(chǎn)生的結(jié)果(視圖)進行融合，返回給用戶。這樣，一方面，批處理模塊基于全量數(shù)據(jù)計算得出的結(jié)果保證了最終響應(yīng)結(jié)果的完整性與準確性;另一方面，流處理模塊基于實時數(shù)據(jù)進行流處理獲得的即時更新保證了用戶查詢的極低延遲。

缺陷：設(shè)計和實現(xiàn)該架構(gòu)的過程中，存在一些無法避免的問題，其中最為主要的便是開發(fā)和維護的復(fù)雜性。對于開發(fā)人員而言，實現(xiàn)一個較為完善的分布式處理系統(tǒng)需要付出很大的精力，這不僅表現(xiàn)在設(shè)計、編碼的過程中，更表現(xiàn)在效率優(yōu)化、后期維護升級等方面，每一個細節(jié)的調(diào)整都可能會導(dǎo)致設(shè)計思路的轉(zhuǎn)變，從而造成較大的更新代價。

那么，是否能夠在盡量避免同時開發(fā)批、流兩個系統(tǒng)的復(fù)雜性的同時，實現(xiàn)基于云邊協(xié)同平臺的批流融合處理呢?換言之，能否改進批處理或流處理其中一個，以使它不足的方面達到或接近另一模塊的水平?

2.Kappa架構(gòu)

Kappa架構(gòu)由來自于LinkedIn公司的Jay Kreps在2014年提出，這一架構(gòu)不僅大大降低了開發(fā)人員的負擔，而且更為重要的是，使得在更高程度邊緣化的云邊協(xié)同平臺上，利用邊緣端的計算，使得批流一體化處理成為可能。

該架構(gòu)提出輸入數(shù)據(jù)只通過流計算一條鏈路進行處理，并生成待查詢的視圖。它的核心是數(shù)據(jù)以日志(log)的形式，以追加(append-only)且不可變的方式，存儲在數(shù)據(jù)倉庫中。換句話說，它要求長期存儲的歷史數(shù)據(jù)能夠以有序日志流重新流入計算引擎，以備需要重新計算全局視圖時，從數(shù)據(jù)倉庫中取出這些數(shù)據(jù)進行全量計算，直到該數(shù)據(jù)副本的進度趕上當前事件發(fā)生的進度，丟棄原有視圖，將新的副本視圖作為主要結(jié)果。

利用這一架構(gòu)，不僅能夠在邊緣端實現(xiàn)低延遲的流處理，同時也能夠?qū)崿F(xiàn)歷史數(shù)據(jù)的批量處理。這為主要依賴于邊緣計算能力的諸多應(yīng)用場景提供了有力的技術(shù)支撐。

3.其他技術(shù)

在對基于云邊協(xié)同環(huán)境下數(shù)據(jù)處理方案以及數(shù)據(jù)系統(tǒng)架構(gòu)的研究外，相關(guān)的其他研究也在不斷嘗試、探索。其中，一個方向便是將傳統(tǒng)系統(tǒng)(例如MapReduce)中基于硬盤的存儲改進為基于內(nèi)存的存儲。一方面，借助內(nèi)存在硬件上天生具有的低延遲、高吞吐等特性，不論是實時的自動駕駛行車數(shù)據(jù)，還是短時高密度的健康行為統(tǒng)計數(shù)據(jù)，都能夠避免大量的I/O(輸入/輸出)開銷，支撐批流數(shù)據(jù)處理的速度要求;另一方面，通過檢查點(checkpoint)備份算法、自動恢復(fù)(recovery)機制等補充，實現(xiàn)硬盤持久化存儲的穩(wěn)定性，保證了數(shù)據(jù)的可追溯、可恢復(fù)。目前，相關(guān)的研究人員已經(jīng)在該研究方向上進行了長久的探索，并取得了較好的成效，實現(xiàn)了包括Spark在內(nèi)的多個系統(tǒng)。

關(guān)于作者：

韓銳，北京理工大學(xué)特別研究員，博士生導(dǎo)師。專注于研究面向典型負載(機器學(xué)習(xí)、深度學(xué)習(xí)、互聯(lián)網(wǎng)服務(wù))的云計算系統(tǒng)優(yōu)化，在 TPDS、TC、TKDE、TSC等領(lǐng)域頂級(重要)期刊和INFOCOM、ICDCS、ICPP、RTSS等會議上發(fā)表超過40篇論文，Google學(xué)術(shù)引用1000 余次。

劉馳，北京理工大學(xué)計算機學(xué)院副院長，教授，博士生導(dǎo)師。智能信息技術(shù)北京市重點實驗室主任，國家優(yōu)秀青年科學(xué)基金獲得者，國家重點研發(fā)計劃首席科學(xué)家，中國電子學(xué)會會士，英國工程技術(shù)學(xué)會會士，英國計算機學(xué)會會士。

本文摘編自《云邊協(xié)同大數(shù)據(jù)：技術(shù)與應(yīng)用》，經(jīng)出版方授權(quán)發(fā)布。(ISBN：9787111701002)轉(zhuǎn)載請保留文章出處。