隨著互聯(lián)網(wǎng)的快速發(fā)展，越來越多的人涌入互聯(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ù)庫、數(shù)據(jù)集市、數(shù)據(jù)倉庫、數(shù)據(jù)湖、數(shù)據(jù)中臺，每次數(shù)據(jù)處理的演進(jìn)都代表著業(yè)務(wù)需求變化的趨勢、技術(shù)的演進(jìn)。

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

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

Hadoop提供了一整套解決方案，底層以HDFS分布式文件系統(tǒng)做數(shù)據(jù)存儲，所有的數(shù)據(jù)都通過MapReduce計(jì)算模型進(jìn)行處理（把數(shù)據(jù)計(jì)算任務(wù)拆分成Map和Reduce兩個(gè)過程，Map做初次處理，產(chǎn)生中間結(jié)果，Reduce做二次處理，拿中間結(jié)果進(jìn)行分析產(chǎn)生最后數(shù)據(jù)）；為了簡化用戶的使用成本，Hadoop在MapReduce之上提供了Pig、HIve平臺，Pig支持海量數(shù)據(jù)并行計(jì)算，并提供接口給到上層做報(bào)表、導(dǎo)入關(guān)系型數(shù)據(jù)庫；HIve基于SQL語句對數(shù)據(jù)進(jìn)行分析錯(cuò)誤，降低了如產(chǎn)品、運(yùn)營人員的使用成本。整套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è)也開始涌入互聯(lián)網(wǎng)，對于數(shù)據(jù)處理的要求、數(shù)據(jù)分析也變得高起來。

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

Lambda架構(gòu)通過把數(shù)據(jù)分解為ServingLayer、SpeedLayer、BatchLayer三層來解決在不同數(shù)據(jù)集的數(shù)據(jù)需求。在Batch層主要是對離線數(shù)據(jù)進(jìn)行處理，將接入的數(shù)據(jù)進(jìn)行預(yù)處理、存儲，查詢的時(shí)候直接在預(yù)處理結(jié)果上查詢并不需要再進(jìn)行完整的計(jì)算，最后以View層提供給到業(yè)務(wù)；在Speed層主要是對實(shí)時(shí)增量數(shù)據(jù)進(jìn)行處理，每來一次新數(shù)據(jù)就不斷的更新View層，提供給到業(yè)務(wù)；在Serving層主要是響應(yīng)用戶的請求，根據(jù)用戶需求把Batch層和Speed層的數(shù)據(jù)集合到一起，得到最終的數(shù)據(jù)集。Lambda架構(gòu)優(yōu)點(diǎn)是將流處理和批處理分開，很好的結(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ù)的一致性，開發(fā)人員需要維護(hù)兩套系統(tǒng)。

第三代基礎(chǔ)設(shè)施：以Kappa為代表的集成流批數(shù)據(jù)處理。Lambda架構(gòu)的流批分離解決了數(shù)據(jù)一致性問題，也提高了效率，但對應(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)是開發(fā)人員只需要維護(hù)實(shí)時(shí)處理模塊，不需要離線實(shí)時(shí)數(shù)據(jù)合并，缺點(diǎn)是在實(shí)時(shí)處理時(shí)可能會存在信息丟失情況。

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