隨著網際網路的快速發展，越來越多的人湧入網際網路，網際網路自此進入大資料時代。在大資料時代之後，雲計算、人工智慧、物聯網、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，涵蓋了業務所需要的各種資料的處理方式，大資料平臺也變成了一個全量的資料處理平臺。基於這些基礎設施，在雲計算基礎設施保障下，我們可以有資料集市、資料倉庫、資料湖、資料中臺的處理方案，更好的將資料作為資產管理起來，作為知識應用起來～