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

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

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

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

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

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

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

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

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

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

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

我們得到下面的一個(gè)公式

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

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

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

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

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

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

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

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

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

• 實(shí)時(shí)與批量計(jì)算結(jié)果不一致引起的數(shù)據(jù)口徑問題：因?yàn)榕亢蛯?shí)時(shí)計(jì)算走的是兩個(gè)計(jì)算框架和計(jì)算程序，算出的結(jié)果往往不同，經(jīng)常看到一個(gè)數(shù)字當(dāng)天看是一個(gè)數(shù)據(jù)，第二天看昨天的數(shù)據(jù)反而發(fā)生了變化。

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

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

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