隨著互聯(lián)網(wǎng)的快速發(fā)展，越來(lái)越多的人涌入互聯(lián)網(wǎng)，互聯(lián)網(wǎng)自此進(jìn)入大數(shù)據(jù)時(shí)代。在大數(shù)據(jù)時(shí)代之后，云計(jì)算、人工智能、物聯(lián)網(wǎng)、5G技術(shù)的發(fā)展又將大數(shù)據(jù)的發(fā)展推向高潮。

數(shù)據(jù)已經(jīng)從最初的信息一步步的演變成了數(shù)據(jù)產(chǎn)品、數(shù)據(jù)資產(chǎn)。關(guān)于數(shù)據(jù)的處理技術(shù)，包含數(shù)據(jù)庫(kù)、數(shù)據(jù)集市、數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖、數(shù)據(jù)中臺(tái)，每次數(shù)據(jù)處理的演進(jìn)都代表著業(yè)務(wù)需求變化的趨勢(shì)、技術(shù)的演進(jìn)。

除了數(shù)據(jù)處理方式在演進(jìn)之外，數(shù)據(jù)處理的基礎(chǔ)措施也在不斷的演進(jìn)，包含Hadoop、Lambda、Kappa，這三種數(shù)據(jù)處理思想都是在為了解決數(shù)據(jù)處理過(guò)程中遇到的問(wèn)題而產(chǎn)生的，每一種解決方案都有對(duì)應(yīng)的場(chǎng)景，不存在過(guò)時(shí)之說(shuō)。今天我們就一起來(lái)看看大數(shù)據(jù)基礎(chǔ)設(shè)施的演進(jìn)吧～

第一代基礎(chǔ)設(shè)施：以Hadoop為代表的離線數(shù)據(jù)處理。早期的時(shí)候，互聯(lián)網(wǎng)還處在一片紅海，大家對(duì)于數(shù)據(jù)分析的要求也不高，主要是做報(bào)表、支撐決策，對(duì)應(yīng)的離線數(shù)據(jù)分析方案就產(chǎn)生了。

Hadoop提供了一整套解決方案，底層以HDFS分布式文件系統(tǒng)做數(shù)據(jù)存儲(chǔ)，所有的數(shù)據(jù)都通過(guò)MapReduce計(jì)算模型進(jìn)行處理(把數(shù)據(jù)計(jì)算任務(wù)拆分成Map和Reduce兩個(gè)過(guò)程，Map做初次處理，產(chǎn)生中間結(jié)果，Reduce做二次處理，拿中間結(jié)果進(jìn)行分析產(chǎn)生最后數(shù)據(jù));為了簡(jiǎn)化用戶的使用成本，Hadoop在MapReduce之上提供了Pig、HIve平臺(tái)，Pig支持海量數(shù)據(jù)并行計(jì)算，并提供接口給到上層做報(bào)表、導(dǎo)入關(guān)系型數(shù)據(jù)庫(kù);HIve基于SQL語(yǔ)句對(duì)數(shù)據(jù)進(jìn)行分析錯(cuò)誤，降低了如產(chǎn)品、運(yùn)營(yíng)人員的使用成本。整套Hadoop數(shù)據(jù)處理體系使用Zookeeper進(jìn)行任務(wù)節(jié)點(diǎn)的協(xié)調(diào)管理、資源分配，保障系統(tǒng)的正常運(yùn)行。 

第二代基礎(chǔ)設(shè)施：以Lambda為代表的流批數(shù)據(jù)處理。隨著涌入互聯(lián)網(wǎng)的網(wǎng)民變得，很多企業(yè)也開(kāi)始涌入互聯(lián)網(wǎng)，對(duì)于數(shù)據(jù)處理的要求、數(shù)據(jù)分析也變得高起來(lái)。

Hadoop這一套體系，當(dāng)運(yùn)行大量數(shù)據(jù)時(shí)，所耗費(fèi)時(shí)間也會(huì)變得越來(lái)越多，無(wú)法再滿足一些需要實(shí)時(shí)分析處理的場(chǎng)景(比如在淘寶中會(huì)動(dòng)態(tài)推薦商品)，因此新的流式計(jì)算引擎如Flink、Storm、SparkStreaming等開(kāi)始產(chǎn)生。新的大數(shù)據(jù)處理方式也被提出，只有流處理、批處理配合一起使用，才能滿足絕大部分使用場(chǎng)景，因此lambda架構(gòu)被提出。

Lambda架構(gòu)通過(guò)把數(shù)據(jù)分解為ServingLayer、SpeedLayer、BatchLayer三層來(lái)解決在不同數(shù)據(jù)集的數(shù)據(jù)需求。在Batch層主要是對(duì)離線數(shù)據(jù)進(jìn)行處理，將接入的數(shù)據(jù)進(jìn)行預(yù)處理、存儲(chǔ)，查詢(xún)的時(shí)候直接在預(yù)處理結(jié)果上查詢(xún)并不需要再進(jìn)行完整的計(jì)算，最后以View層提供給到業(yè)務(wù);在Speed層主要是對(duì)實(shí)時(shí)增量數(shù)據(jù)進(jìn)行處理，每來(lái)一次新數(shù)據(jù)就不斷的更新View層，提供給到業(yè)務(wù);在Serving層主要是響應(yīng)用戶的請(qǐng)求，根據(jù)用戶需求把Batch層和Speed層的數(shù)據(jù)集合到一起，得到最終的數(shù)據(jù)集。Lambda架構(gòu)優(yōu)點(diǎn)是將流處理和批處理分開(kāi)，很好的結(jié)合了實(shí)時(shí)計(jì)算和流計(jì)算的優(yōu)點(diǎn)，架構(gòu)穩(wěn)定，實(shí)時(shí)計(jì)算成本可控，提高了整個(gè)系統(tǒng)的容錯(cuò)性、降低了復(fù)雜性。缺點(diǎn)是離線數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)很難保障數(shù)據(jù)的一致性，開(kāi)發(fā)人員需要維護(hù)兩套系統(tǒng)。 

第三代基礎(chǔ)設(shè)施：以Kappa為代表的集成流批數(shù)據(jù)處理。Lambda架構(gòu)的流批分離解決了數(shù)據(jù)一致性問(wèn)題，也提高了效率，但對(duì)應(yīng)的也增加了系統(tǒng)的復(fù)雜性，因此期望一套系統(tǒng)解決流批處理的方案產(chǎn)生了，那便是Kappa架構(gòu)。利用流計(jì)算的分布式特征，增加流計(jì)算的并發(fā)性，加大流數(shù)據(jù)的時(shí)間窗口，統(tǒng)一批處理和流處理數(shù)據(jù)。

Kappa架構(gòu)在Lambda架構(gòu)的基礎(chǔ)上刪除了Batch層，所有的數(shù)據(jù)都是流處理實(shí)時(shí)計(jì)算，計(jì)算好了之后可以直接給到業(yè)務(wù)層使用，也可以放在數(shù)據(jù)湖中，需要進(jìn)行離線分析時(shí)使用。Kappa架構(gòu)的優(yōu)點(diǎn)是開(kāi)發(fā)人員只需要維護(hù)實(shí)時(shí)處理模塊，不需要離線實(shí)時(shí)數(shù)據(jù)合并，缺點(diǎn)是在實(shí)時(shí)處理時(shí)可能會(huì)存在信息丟失情況。 

整個(gè)互聯(lián)網(wǎng)大數(shù)據(jù)處理基礎(chǔ)設(shè)施體系，從Hadoop演進(jìn)到Lambda，再到Kappa，涵蓋了業(yè)務(wù)所需要的各種數(shù)據(jù)的處理方式，大數(shù)據(jù)平臺(tái)也變成了一個(gè)全量的數(shù)據(jù)處理平臺(tái)。基于這些基礎(chǔ)設(shè)施，在云計(jì)算基礎(chǔ)設(shè)施保障下，我們可以有數(shù)據(jù)集市、數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖、數(shù)據(jù)中臺(tái)的處理方案，更好的將數(shù)據(jù)作為資產(chǎn)管理起來(lái)，作為知識(shí)應(yīng)用起來(lái)～