隨著互聯網的快速發展，越來越多的人涌入互聯網，互聯網自此進入大數據時代。在大數據時代之后，云計算、人工智能、物聯網、5G技術的發展又將大數據的發展推向高潮。

數據已經從最初的信息一步步的演變成了數據產品、數據資產。關于數據的處理技術，包含數據庫、數據集市、數據倉庫、數據湖、數據中臺，每次數據處理的演進都代表著業務需求變化的趨勢、技術的演進。

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

第一代基礎設施：以Hadoop為代表的離線數據處理。早期的時候，互聯網還處在一片紅海，大家對于數據分析的要求也不高，主要是做報表、支撐決策，對應的離線數據分析方案就產生了。

Hadoop提供了一整套解決方案，底層以HDFS分布式文件系統做數據存儲，所有的數據都通過MapReduce計算模型進行處理（把數據計算任務拆分成Map和Reduce兩個過程，Map做初次處理，產生中間結果，Reduce做二次處理，拿中間結果進行分析產生最后數據）；為了簡化用戶的使用成本，Hadoop在MapReduce之上提供了Pig、HIve平臺，Pig支持海量數據并行計算，并提供接口給到上層做報表、導入關系型數據庫；HIve基于SQL語句對數據進行分析錯誤，降低了如產品、運營人員的使用成本。整套Hadoop數據處理體系使用Zookeeper進行任務節點的協調管理、資源分配，保障系統的正常運行。

第二代基礎設施：以Lambda為代表的流批數據處理。隨著涌入互聯網的網民變得，很多企業也開始涌入互聯網，對于數據處理的要求、數據分析也變得高起來。

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

Lambda架構通過把數據分解為ServingLayer、SpeedLayer、BatchLayer三層來解決在不同數據集的數據需求。在Batch層主要是對離線數據進行處理，將接入的數據進行預處理、存儲，查詢的時候直接在預處理結果上查詢并不需要再進行完整的計算，最后以View層提供給到業務；在Speed層主要是對實時增量數據進行處理，每來一次新數據就不斷的更新View層，提供給到業務；在Serving層主要是響應用戶的請求，根據用戶需求把Batch層和Speed層的數據集合到一起，得到最終的數據集。Lambda架構優點是將流處理和批處理分開，很好的結合了實時計算和流計算的優點，架構穩定，實時計算成本可控，提高了整個系統的容錯性、降低了復雜性。缺點是離線數據和實時數據很難保障數據的一致性，開發人員需要維護兩套系統。

第三代基礎設施：以Kappa為代表的集成流批數據處理。Lambda架構的流批分離解決了數據一致性問題，也提高了效率，但對應的也增加了系統的復雜性，因此期望一套系統解決流批處理的方案產生了，那便是Kappa架構。利用流計算的分布式特征，增加流計算的并發性，加大流數據的時間窗口，統一批處理和流處理數據。

Kappa架構在Lambda架構的基礎上刪除了Batch層，所有的數據都是流處理實時計算，計算好了之后可以直接給到業務層使用，也可以放在數據湖中，需要進行離線分析時使用。Kappa架構的優點是開發人員只需要維護實時處理模塊，不需要離線實時數據合并，缺點是在實時處理時可能會存在信息丟失情況。

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