怎么理解大數(shù)據(jù)Lambda架構(gòu)

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

縷一縷it的發(fā)展，第一階段是各大系統(tǒng)各大平臺的出現(xiàn)，解決的是線下搬到線上的效率問題，而下一個階段是數(shù)據(jù)時代，處理這些各大平臺積累的數(shù)據(jù)，積累的數(shù)據(jù)，一般比較大，大數(shù)據(jù)做的是什么，大規(guī)模的數(shù)據(jù)處理，主要是離線為主，所以就出現(xiàn)了hadoop的三大基礎(chǔ)組件，分別解決大數(shù)據(jù)存儲，計算，大表存儲，這個階段基本解決了大數(shù)據(jù)的計算，也即可以編寫出程序，完成大數(shù)據(jù)的大規(guī)模運算，后面又出現(xiàn)了實時處理，第一個出現(xiàn)的就是storm，可以處理實時的單個數(shù)據(jù)，這樣就展現(xiàn)了最新的數(shù)據(jù)，但是同時也看到了，如果既想要最新的又想要歷史的，要怎么辦呢，所以Storm的作者Nathan Mara提出了Lambda架構(gòu)，這種架構(gòu)主要解決離線數(shù)據(jù)計算結(jié)果怎么和實時處理的結(jié)果合并提供最后的結(jié)果。

2.大數(shù)據(jù)Lambda架構(gòu)應(yīng)該有那些特點

首先縷縷需求，我們要的就是一種在線計算結(jié)果和離線計算結(jié)果合并的架構(gòu)，試想一種信貸場景，我要得到某個用戶交易過的所有貸款機構(gòu)，假設(shè)用這個結(jié)果來算多頭分，需求場景就是要實時取到最新的數(shù)據(jù)，比如上一秒交易是A機構(gòu)，那下一秒交易就得拿到這個機構(gòu)，那么對于歷史數(shù)據(jù)必然是要存量計算，這種計算必然是需要花費一定時間的，而上一秒交易的A機構(gòu)，一般在離線倉庫里面不會馬上放進去，只能將這種數(shù)據(jù)放到實時處理里邊， 細想這種結(jié)構(gòu)，要有下面幾個特點，

• 至少保證離線exact-once，環(huán)境有時候是不可靠的，尤其是在線系統(tǒng)，在保證exact-once又更差一點，通過離線復(fù)算 覆蓋在線的方式，即是重刷數(shù)據(jù)的過程

• 可擴展性，比如離線計算效率不行，可以通過加資源來實現(xiàn)

• 維護性，lambda架構(gòu)需要保證在線離線的計算邏輯一致，盡量將邏輯用相同的方式來實現(xiàn)在線離線一致性

• 可以通過查詢接口查詢離線在線計算出來的數(shù)據(jù)

總的來說本質(zhì)就是，數(shù)據(jù)記錄 + 查詢服務(wù)

3.大數(shù)據(jù)Lambda架構(gòu)簡介

前面從需求角度來說明了，一個lambda架構(gòu)要滿足什么特點，我們就得到了數(shù)據(jù)記錄 + 查詢服務(wù)的這種模式，由于數(shù)據(jù)記錄的寫入方式不同，lambda架構(gòu)里面把寫數(shù)據(jù)記錄的曾分為離線批計算層和在線實時計算層

我們得到下面的一個公式

為了方便查詢Query又常常作為一個view, 這樣的一個lambda架構(gòu)，其實現(xiàn)方案又很多，比如批計算層，可以使用spark，hive等來計算 離線批大數(shù)據(jù)，而實時層可以使用程序?qū)崟r計算，可以選擇Flink等框架，如果邏輯不復(fù)雜也可以使用程序直接生成，至于存儲，又可以將離線計算和實時計算的結(jié)果分開存儲或者使用時序數(shù)據(jù)庫合并存儲，另外對于查詢，既可以用程序來合并讀全部數(shù)據(jù)，有可以在視圖級別做合并。

4.Lambda架構(gòu)的分層

前面講到大概lambda架構(gòu)里面的三個模塊，分別為離線計算層，在線計算層，查詢服務(wù)層

首先是離線計算層，由于歷史數(shù)據(jù)較多，會放到hdfs上面，計算方式，使用mr的模型計算 就可，如果有問題，是支持批量重新計算來修復(fù)的。

其次是查詢view，對于離線預(yù)處理好的數(shù)據(jù)和在線計算結(jié)果進行合并提供服務(wù)。

5.Lambda架構(gòu)的實現(xiàn)示例

這個架構(gòu)，是一種實現(xiàn)方式，離線計算采用hive和spark，為了和在線計算邏輯對齊，采用相同jar依賴的方式，只不過離線計算的邏輯是在udf里面，同時有個enable_time來區(qū)分在線離線數(shù)據(jù)時間點，eggroll可以理解為類似于hbase的離線kv存儲數(shù)據(jù)庫。

6.思考Lambda架構(gòu)的問題

Lambda架構(gòu)經(jīng)歷多年的發(fā)展，其優(yōu)點是穩(wěn)定，對于實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構(gòu)支撐了數(shù)據(jù)行業(yè)的早期發(fā)展，但是它也有一些致命缺點，并在大數(shù)據(jù)3.0時代越來越不適應(yīng)數(shù)據(jù)分析業(yè)務(wù)的需求。缺點如下：

• 實時與批量計算結(jié)果不一致引起的數(shù)據(jù)口徑問題：因為批量和實時計算走的是兩個計算框架和計算程序，算出的結(jié)果往往不同，經(jīng)?？吹揭粋€數(shù)字當(dāng)天看是一個數(shù)據(jù)，第二天看昨天的數(shù)據(jù)反而發(fā)生了變化。

• 批量計算在計算窗口內(nèi)無法完成：在IOT時代，數(shù)據(jù)量級越來越大，經(jīng)常發(fā)現(xiàn)夜間只有4、5個小時的時間窗口，已經(jīng)無法完成白天20多個小時累計的數(shù)據(jù)，保證早上上班前準(zhǔn)時出數(shù)據(jù)已成為每個大數(shù)據(jù)團隊頭疼的問題。

• 開發(fā)和維護的復(fù)雜性問題：Lambda 架構(gòu)需要在兩個不同的 API（application programming interface，應(yīng)用程序編程接口）中對同樣的業(yè)務(wù)邏輯進行兩次編程：一次為批量計算的ETL系統(tǒng)，一次為流式計算的Streaming系統(tǒng)。針對同一個業(yè)務(wù)問題產(chǎn)生了兩個代碼庫，各有不同的漏洞。這種系統(tǒng)實際上非常難維護

• 服務(wù)器存儲大：數(shù)據(jù)倉庫的典型設(shè)計，會產(chǎn)生大量的中間結(jié)果表，造成數(shù)據(jù)急速膨脹，加大服務(wù)器存儲壓力。