前言
在大數據架構中，有兩個十分常見的架構，那就是lambda架構和unifield架構，這兩個架構在大數據中佔據著十分重要的地位，在這篇文章中我們就給大家介紹一下lambda架構和unifield架構，幫助大家更深一步的去了解大數據，為今後我們的大數據學習有幫助。
1.lambda架構
在大數據系統中，Lambda架構算是一個重要的架構，大多數架構基本都是Lambda架構或者基於其變種的架構。通常來說，Lambda的數據通道分為兩條分支：實時流和離線。實時流依照流式架構，保障了其實時性，而離線則以批處理方式為主，保障了最終一致性。這就是流式通道處理為保障實效性更多的以增量計算為主輔助參考，而批處理層則對數據進行全量運算，保障其最終的一致性，因此Lambda最外層有一個實時層和離線層合併的動作，此動作是Lambda裡非常重要的一個動作。這也是很多人最容易忽略的地方。而lambda架構的優點十分明顯，那就是既有實時又有離線，對於數據分析場景涵蓋的非常到位。當然，這個架構的缺點也需要我們去了解，那就是離線層和實時流雖然面臨的場景不相同，但是其內部處理的邏輯卻是相同，因此有大量榮譽和重複的模塊存在。正因為如此，這個架構的適用場景同時存在實時和離線需求的情況。
大數據的技術手段百花齊放, 各種NoSQL數據庫或者分佈式計算框架層出不窮, 但是很少有理論來講一講應該怎麼把這些組件有機地組合起來, lambda框架應運而生, 是一種理論指導大數據項目的頂層設計, 幫助企業以數據來驅動。
從業務的角度來思考對於數據的應用有不同的時效性要求, 有的數據比如 E-commerce ，時效性要求非常高, 有的數據比如客戶畫像分析 對時效性要求比較低. 道理很簡單, 電商的促銷推薦瞬息萬變, 而客戶的行為畫像變得很慢(並不是每天都有人從工薪階層變成百萬富翁，從單身漢突然變成已婚人士)。
lambda架構從這點出發, 有兩套解決辦法, 正如圖上的兩條分支, 一條叫Speed Layer 顧名思義 快速的處理實時數據以供查詢, 而另一條分支, 又分作兩層(Batch Layer & Serving Layer) 處理那些對時效性要求不高的數據。
Speed Layer處理實時數據 代價是對計算資源要求很高, 而且邏輯複雜度也會很高， 通常採用的技術比如 Redis，Storm，Kafka，Spark Streaming等。而另外兩層使用的典型技術比如MR或Spark，Hive。這條路線處理延遲比較大， 結果邏輯相對簡單，往往把它的處理叫做“離線處理”， 與Speed Layer的“實時處理”相對應。這種設計被稱作：Complexity Isolation（複雜度分離）。
兩者其實是相輔相成的, Batch Layer會持續地吸收增量數據加以處理（比如漸變維度，增加索引，劃分分區，預計算聚合值等操作）, 當新增數據被Batch Layer處理完成後, 它們的分析就不再由Speed Layer處理了（交由Serving Layer處理），所以保證了Speed Layer處理的歷史數據量永遠不會太大，畢竟對於Speed Layer來說 “快” 是關鍵。
在另一些場景下, 比如在用戶瀏覽購物網站時的推薦系統, 會結合實時分析結果和離線處理結果: 以電商為例, 用戶給購物車加了一件商品，根據這個操作"實時處理"會向用戶做出推薦（用戶把一條裙子加入購物車，立刻推薦這條裙子的搭配商品比如一雙鞋子），但同時也要結合用戶歷史的行為來做推薦（用戶喜歡紅色，腳的尺碼M）, 這依賴於離線處理的結果。兩者結合（該鞋子的紅色款且尺碼M）就是最終用戶在網頁上看到的推薦商品列表。
2.unifield架構
Unifield架構表現更激進，將機器學習和數據處理揉為一體，從核心上來說，Unifield依舊以Lambda為主，不過對其進行了改造，在流處理層新增了機器學習層。新增了模型訓練部分，並且將其在流式層進行使用。同時流式層不單使用模型，也包含著對模型的持續訓練。Unifield架構的優點就是提供了一套數據分析和機器學習結合的架構方案，完美的解決了機器學習如何與數據平臺進行結合的問題。缺點則是這個架構實施複雜度更高，對於機器學習架構來說，從軟件包到硬件部署都和數據分析平臺有著非常大的差別，因此在實施過程中的難度係數更高。所以這個架構學習起來是比較困難的。
我們在這篇文章中為大家介紹了兩種常見的大數據架構的相關知識，具體就是unifield架構以及lambda架構。在大數據中，這兩種架構都是十分常見的架構，所以大家要對這兩個架構有所瞭解，希望這篇文章能夠更好的幫助大家。
3.傳統大數據架構
數據分析的業務沒有發生任何變化，但是因為數據量、性能等問題導致系統無法正常使用，需要進行升級改造，那麼此類架構便是為了解決這個問題。依然保留了ETL的動作，將數據經過ETL動作進入數據存儲。數據分析需求依舊以BI場景為主，但是因為數據量、性能等問題無法滿足日常使用。
4.流式架構
在傳統大數據架構的基礎上，流式架構數據全程以流的形式處理，在數據接入端將ETL替換為數據通道。經過流處理加工後的數據，以消息的形式直接推送給了消費者。存儲部分在外圍系統以窗口的形式進行存儲。適用於預警、監控、對數據有有效期要求的情況。
5.Kappa架構
Kappa架構在Lambda的基礎上進行了優化，將實時和流部分進行了合併，將數據通道以消息隊列進行替代。因此對於Kappa架構來說，依舊以流處理為主，但是數據卻在數據湖層面進行了存儲，當需要進行離線分析或者再次計算的時候，則將數據湖的數據再次經過消息隊列重播一次則可。
