經(jīng)過這么多年的發(fā)展，已經(jīng)從大數(shù)據(jù)1.0的BI/Datawarehouse時(shí)代，經(jīng)過大數(shù)據(jù)2.0的Web/APP過渡，進(jìn)入到了IOT的大數(shù)據(jù)3.0時(shí)代，而隨之而來的是數(shù)據(jù)架構(gòu)的變化。

Lambda架構(gòu)

在過去Lambda數(shù)據(jù)架構(gòu)成為每一個(gè)公司大數(shù)據(jù)平臺(tái)必備的架構(gòu)，它解決了一個(gè)公司大數(shù)據(jù)批量離線處理和實(shí)時(shí)數(shù)據(jù)處理的需求。一個(gè)典型的Lambda架構(gòu)如下：

數(shù)據(jù)從底層的數(shù)據(jù)源開始，經(jīng)過各種各樣的格式進(jìn)入大數(shù)據(jù)平臺(tái)，在大數(shù)據(jù)平臺(tái)中經(jīng)過Kafka、Flume等數(shù)據(jù)組件進(jìn)行收集，然后分成兩條線進(jìn)行計(jì)算。一條線是進(jìn)入流式計(jì)算平臺(tái)(例如 Storm、Flink或者Spark Streaming)，去計(jì)算實(shí)時(shí)的一些指標(biāo);另一條線進(jìn)入批量數(shù)據(jù)處理離線計(jì)算平臺(tái)(例如Mapreduce、Hive，Spark SQL)，去計(jì)算T+1的相關(guān)業(yè)務(wù)指標(biāo)，這些指標(biāo)需要隔日才能看見。

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ì)頭疼的問題。
• 數(shù)據(jù)源變化都要重新開發(fā)，開發(fā)周期長(zhǎng)：每次數(shù)據(jù)源的格式變化，業(yè)務(wù)的邏輯變化都需要針對(duì)ETL和Streaming做開發(fā)修改，整體開發(fā)周期很長(zhǎng)，業(yè)務(wù)反應(yīng)不夠迅速。
• 服務(wù)器存儲(chǔ)大：數(shù)據(jù)倉庫的典型設(shè)計(jì)，會(huì)產(chǎn)生大量的中間結(jié)果表，造成數(shù)據(jù)急速膨脹，加大服務(wù)器存儲(chǔ)壓力。

Kappa架構(gòu)

針對(duì)Lambda架構(gòu)的需要維護(hù)兩套程序等以上缺點(diǎn)，LinkedIn的Jay Kreps結(jié)合實(shí)際經(jīng)驗(yàn)和個(gè)人體會(huì)提出了Kappa架構(gòu)。Kappa架構(gòu)的核心思想是通過改進(jìn)流計(jì)算系統(tǒng)來解決數(shù)據(jù)全量處理的問題，使得實(shí)時(shí)計(jì)算和批處理過程使用同一套代碼。此外Kappa架構(gòu)認(rèn)為只有在有必要的時(shí)候才會(huì)對(duì)歷史數(shù)據(jù)進(jìn)行重復(fù)計(jì)算，而如果需要重復(fù)計(jì)算時(shí)，Kappa架構(gòu)下可以啟動(dòng)很多個(gè)實(shí)例進(jìn)行重復(fù)計(jì)算。

一個(gè)典型的Kappa架構(gòu)如下圖所示：

Kappa架構(gòu)的核心思想，包括以下三點(diǎn)：

1. 用Kafka或者類似MQ隊(duì)列系統(tǒng)收集各種各樣的數(shù)據(jù)，你需要幾天的數(shù)據(jù)量就保存幾天。
2. 當(dāng)需要全量重新計(jì)算時(shí)，重新起一個(gè)流計(jì)算實(shí)例，從頭開始讀取數(shù)據(jù)進(jìn)行處理，并輸出到一個(gè)新的結(jié)果存儲(chǔ)中。
3. 當(dāng)新的實(shí)例做完后，停止老的流計(jì)算實(shí)例，并把老的一些結(jié)果刪除。

Kappa架構(gòu)的優(yōu)點(diǎn)在于將實(shí)時(shí)和離線代碼統(tǒng)一起來，方便維護(hù)而且統(tǒng)一了數(shù)據(jù)口徑的問題。而Kappa的缺點(diǎn)也很明顯：

• 流式處理對(duì)于歷史數(shù)據(jù)的高吞吐量力不從心：所有的數(shù)據(jù)都通過流式計(jì)算，即便通過加大并發(fā)實(shí)例數(shù)亦很難適應(yīng)IOT時(shí)代對(duì)數(shù)據(jù)查詢響應(yīng)的即時(shí)性要求。
• 開發(fā)周期長(zhǎng)：此外Kappa架構(gòu)下由于采集的數(shù)據(jù)格式的不統(tǒng)一，每次都需要開發(fā)不同的Streaming程序，導(dǎo)致開發(fā)周期長(zhǎng)。
• 服務(wù)器成本浪費(fèi)：Kappa架構(gòu)的核心原理依賴于外部高性能存儲(chǔ)redis,hbase服務(wù)。但是這2種系統(tǒng)組件，又并非設(shè)計(jì)來滿足全量數(shù)據(jù)存儲(chǔ)設(shè)計(jì)，對(duì)服務(wù)器成本嚴(yán)重浪費(fèi)。

IOTA架構(gòu)

而在IOT大潮下，智能手機(jī)、PC、智能硬件設(shè)備的計(jì)算能力越來越強(qiáng)，而業(yè)務(wù)需求要求數(shù)據(jù)實(shí)時(shí)響應(yīng)需求能力也越來越強(qiáng)，過去傳統(tǒng)的中心化、非實(shí)時(shí)化數(shù)據(jù)處理的思路已經(jīng)不適應(yīng)現(xiàn)在的大數(shù)據(jù)分析需求，我提出新一代的大數(shù)據(jù)IOTA架構(gòu)來解決上述問題，整體思路是設(shè)定標(biāo)準(zhǔn)數(shù)據(jù)模型，通過邊緣計(jì)算技術(shù)把所有的計(jì)算過程分散在數(shù)據(jù)產(chǎn)生、計(jì)算和查詢過程當(dāng)中，以統(tǒng)一的數(shù)據(jù)模型貫穿始終，從而提高整體的預(yù)算效率，同時(shí)滿足即時(shí)計(jì)算的需要，可以使用各種Ad-hoc Query來查詢底層數(shù)據(jù)。