大數(shù)據(jù)與現(xiàn)有的科技手段結(jié)合，對大多數(shù)產(chǎn)業(yè)而言都能產(chǎn)生巨大的經(jīng)濟及社會價值。這也是當(dāng)下許多企業(yè)，在大數(shù)據(jù)上深耕的原因。大數(shù)據(jù)分析場景需要解決哪些技術(shù)挑戰(zhàn)?目前，有哪些主流大數(shù)據(jù)架構(gòu)模式及其發(fā)展?今天，我們都會一一解讀，并介紹如何結(jié)合云上存儲、計算組件，實現(xiàn)更優(yōu)的通用大數(shù)據(jù)架構(gòu)模式，美國服務(wù)器租用，以及該模式可以涵蓋的典型數(shù)據(jù)處理場景。

大數(shù)據(jù)處理的挑戰(zhàn)

現(xiàn)在已經(jīng)有越來越多的行業(yè)和技術(shù)領(lǐng)域需求大數(shù)據(jù)分析系統(tǒng)，例如金融行業(yè)需要使用大數(shù)據(jù)系統(tǒng)結(jié)合 VaR(value at risk) 或者機器學(xué)習(xí)方案進(jìn)行信貸風(fēng)控，零售、餐飲行業(yè)需要大數(shù)據(jù)系統(tǒng)實現(xiàn)輔助銷售決策，各種 IOT 場景需要大數(shù)據(jù)系統(tǒng)持續(xù)聚合和分析時序數(shù)據(jù)，各大科技公司需要建立大數(shù)據(jù)分析中臺等等。

抽象來看，支撐這些場景需求的分析系統(tǒng)，面臨大致相同的技術(shù)挑戰(zhàn)： 業(yè)務(wù)分析的數(shù)據(jù)范圍橫跨實時數(shù)據(jù)和歷史數(shù)據(jù)，既需要低延遲的實時數(shù)據(jù)分析，也需要對 PB 級的歷史數(shù)據(jù)進(jìn)行探索性的數(shù)據(jù)分析; 可靠性和可擴展性問題，用戶可能會存儲海量的歷史數(shù)據(jù)，同時數(shù)據(jù)規(guī)模有持續(xù)增長的趨勢，需要引入分布式存儲系統(tǒng)來滿足可靠性和可擴展性需求，同時保證成本可控; 技術(shù)棧深，需要組合流式組件、存儲系統(tǒng)、計算組件和; 可運維性要求高，復(fù)雜的大數(shù)據(jù)架構(gòu)難以維護(hù)和管控;

簡述大數(shù)據(jù)架構(gòu)發(fā)展

Lambda 架構(gòu)

Lambda 架構(gòu)是目前影響最深刻的大數(shù)據(jù)處理架構(gòu)，它的核心思想是將不可變的數(shù)據(jù)以追加的方式并行寫到批和流處理系統(tǒng)內(nèi)，隨后將相同的計算邏輯分別在流和批系統(tǒng)中實現(xiàn)，并且在查詢階段合并流和批的計算視圖并展示給用戶。Lambda的提出者 Nathan Marz 還假定了批處理相對簡單不易出現(xiàn)錯誤，而流處理相對不太可靠，因此流處理器可以使用近似算法，快速產(chǎn)生對視圖的近似更新，而批處理系統(tǒng)會采用較慢的精確算法，產(chǎn)生相同視圖的校正版本。

圖 1 Lambda架構(gòu)示例

Lambda架構(gòu)典型數(shù)據(jù)流程是()：

所有的數(shù)據(jù)需要分別寫入批處理層和流處理層; 批處理層兩個職責(zé)：(i)管理 master dataset (存儲不可變、追加寫的全量數(shù)據(jù))，(ii)預(yù)計算batch view; 服務(wù)層對 batch view 建立索引，以支持低延遲、ad-hoc 方式查詢 view; 流計算層作為速度層，對實時數(shù)據(jù)計算近似的 real-time view，作為高延遲batch view 的補償快速視圖; 所有的查詢需要合并 batch view 和 real-time view;

Lambda 架構(gòu)設(shè)計推廣了在不可變的事件流上生成視圖，并且可以在必要時重新處理事件的原則，該原則保證了系統(tǒng)隨需求演進(jìn)時，始終可以創(chuàng)建相應(yīng)的新視圖出來，切實可行地滿足了不斷變化的歷史數(shù)據(jù)和實時數(shù)據(jù)分析需求。

Lambda 架構(gòu)的四個挑戰(zhàn)

Lambda 架構(gòu)非常復(fù)雜，在數(shù)據(jù)寫入、存儲、對接計算組件以及展示層都有復(fù)雜的子課題需要優(yōu)化： 寫入層上，Lambda 沒有對數(shù)據(jù)寫入進(jìn)行抽象，而是將雙寫流批系統(tǒng)的一致性問題反推給了寫入數(shù)據(jù)的上層應(yīng)用; 存儲上，以 HDFS 為代表的master dataset 不支持?jǐn)?shù)據(jù)更新，云服務(wù)器租用，持續(xù)更新的數(shù)據(jù)源只能以定期拷貝全量 snapshot 到 HDFS 的方式保持?jǐn)?shù)據(jù)更新，數(shù)據(jù)延遲和成本比較大; 計算邏輯需要分別在流批框架中實現(xiàn)和運行，而在類似 Storm 的流計算框架和Hadoop MR 的批處理框架做 job 開發(fā)、調(diào)試、問題調(diào)查都是比較復(fù)雜的;

結(jié)果視圖需要支持低延遲的查詢分析，通常還需要將數(shù)據(jù)派生到列存分析系統(tǒng)，并保證成本可控。

流批融合的 Lambda 架構(gòu)

針對 Lambda 架構(gòu)的問題3，計算邏輯需要分別在流批框架中實現(xiàn)和運行的問題，不少計算引擎已經(jīng)開始往流批統(tǒng)一的方向去發(fā)展，例如 Spark 和 Flink，從而簡化lambda 架構(gòu)中的計算部分。實現(xiàn)流批統(tǒng)一通常需要支持：

以相同的處理引擎來處理實時事件和歷史回放事件; 支持 exactly once 語義，保證有無故障情況下計算結(jié)果完全相同; 支持以事件發(fā)生時間而不是處理時間進(jìn)行窗口化。

Kappa架構(gòu)

Kappa 架構(gòu)由 Jay Kreps 提出，不同于 Lambda 同時計算流計算和批計算并合并視圖，Kappa 只會通過流計算一條的數(shù)據(jù)鏈路計算并產(chǎn)生視圖。Kappa 同樣采用了重新處理事件的原則，對于歷史數(shù)據(jù)分析類的需求，Kappa 要求數(shù)據(jù)的長期存儲能夠以有序 log 流的方式重新流入流計算引擎，重新產(chǎn)生歷史數(shù)據(jù)的視圖。