什麼是Lambda架構

炸雞啤酒不可負發表於2020-09-15

一、Lambda架構需求

Lambda架構背後的需求是由於MR架構的延遲問題。MR雖然實現了分散式、可擴充套件資料處理系統的目的,但是在處理資料時延遲比較嚴重。實際上如果記憶體和CPU足夠強大,MR也可以實現近實時運算,但實際業務環境並非如此,因此我們需要權衡,選擇實時處理和批處理所需要資料量和恰當的資源。

2012年Storm的作者Nathan Marz提出的Lambda資料處理框架。Lambda架構的目標是設計出一個能滿足實時大資料系統關鍵特性的架構,包括有:高容錯、低延時和可擴充套件等。Lambda架構整合離線計算和實時計算,融合不可變性(Immunability),讀寫分離和複雜性隔離等一系列架構原則,可整合Hadoop,Kafka,Storm,Spark,Hbase等各類大資料元件。

二、Lambda架構的關鍵

  • 橫向擴容

可擴充套件性意味著為滿足日益增長的使用者服務需求,同時不用對底層架構或者程式碼,可以透過現有機器新增記憶體或者磁碟資源來實現(垂直擴充套件),或者可以透過在叢集中新增機器實現(水平擴充套件)。無論是實時或者批處理,都應該能夠不停服務的情況下,可以實施水平擴充套件。

  • 故障容錯

系統需要妥善處理故障,確保系統在某些元件發生故障的情況下,整個系統服務的可用性。可能部分元件故障會導致叢集中部分節點當機,影響了整理的SLA,但是系統還是可以相應的,系統不能有單點故障。

  • 低延遲

很多應用對於讀和寫操作的延時要求非常高,要求對更新和查詢的響應是低延時的。

  • 可擴充套件

系統需要足夠靈活,能夠實現新增和修改需求,又不需要重構整個系統。實時處理和批處理隔離開,能夠靈活修改需求。

  • 易維護

開發部署不能夠太複雜。

三、Lambda架構的分層

在Lambda架構中新資料到達時,會被同時分派到批處理層和快速處理層。一旦資料到達批處理層,按照常規批處理時間間隔,每次都從頭開始重新計算並生成批處理檢視。類似地,只要新資料到達快速處理層,快速處理層就會使用新資料生成快速檢視。在查詢到達服務層時,它會合並快速檢視和批處理檢視來生成適當的查詢結果。生成批處理檢視後,快速檢視將被丟棄,除非有新資料抵達,否則只需要查詢批處理檢視,因為此時批處理層中擁有所有的資料。

Lambda架構定義主要層以及每個元件之間的整合。注意分為以下層:

  • 資料來源

資料來源指外部的資料庫、訊息佇列、檔案等,可以開發資料消費層,隱藏來自不同訪問資料的複雜性,定義好資料格式。

  • 資料消費層

負責封裝不能資料來源獲取資料的複雜性,將其轉換可由批處理或者流處理進一步使用同一的格式進行消費。

  • 批處理層

這是Lambda架構核心層之一,批處理接受資料,持久化到使用者定義好的資料結構中,維護著主資料。資料結構一般不做改變,只是追加資料。批處理還負責建立和維護批處理檢視。比如我們常做的Hive ETL ,統計一些資料,最後將結果儲存在hive表中,或者資料庫中,就屬於批處理層。

  • 實時層

這是Lambda另一個核心層。批處理在很多場景下能夠滿足需求,但是隨著業務需求“苛刻性”,他們希望能夠及時看到資料,而不是等到第二天才看指標變化和分析結果。所以引入了實時處理。實時層解決了一個問題,即只儲存可立即向使用者提供的一組資料,這樣就不需要對全量資料進行處理,大大提供處理效率。比如流處理僅僅儲存最近5分鐘的資料,處理計算並形成結果,這就是我們用spark streaming中要有的時間視窗。

  • 服務層

這是Lambda架構的最後一層,服務層的職責是獲取批處理和流處理的結果,向使用者提供統一查詢檢視服務。

四、Lambda架構總結

Lambda資料架構曾經成為每一個公司大資料平臺必備的架構,它解決了一個公司大資料批次離線處理和實時資料處理的需求。

資料從底層的資料來源開始,經過各種各樣的格式進入大資料平臺,在大資料平臺中經過Kafka、Flume等資料元件進行收集,然後分成兩條線進行計算。一條線是進入流式計算平臺(例如 Storm、Flink或者Spark Streaming),去計算實時的一些指標;另一條線進入批次資料處理離線計算平臺(例如Mapreduce、Hive,Spark SQL),去計算T+1的相關業務指標,這些指標需要隔日才能看見。

Lambda架構經歷多年的發展,非常穩定,對於實時計算部分的計算成本可控,批次處理可以用晚上的時間來整體批次計算,這樣把實時計算和離線計算高峰分開,這種架構支撐了資料行業的早期發展,但是它也有一些致命缺點:

  • 實時與批次計算結果不一致

因為批次和實時計算走的是兩個計算框架和計算程式,算出的結果往往不同,經常看到一個數字當天看是一個資料,第二天看昨天的資料反而發生了變化。

  • 批處理的健壯性

隨著資料量級越來越大,經常發現夜間只有4、5個小時的時間視窗,已經無法完成白天20多個小時累計的資料,保證早上上班前準時出資料已成為每個大資料團隊頭疼的問題,同時做個任務並行執行對於大資料叢集的穩定性也是巨大的考驗,經常會有任務因為資源不足沒有定時啟動或者報錯。

  • 開發和維護的複雜

Lambda 架構中對同樣的業務邏輯進行兩次程式設計:一次為批次計算的ETL系統,一次為流式計算的Streaming系統。針對同一個業務問題產生了兩個程式碼庫,各有不同的漏洞。

  • 儲存增長快

資料倉儲的設計不合理,會產生大量的中間結果表,造成資料急速膨脹,加大伺服器儲存壓力。比如我們經常糾結於資料倉儲到底怎麼分層,是直接ODS層到應用呢?還是ODS層要景觀DWS、DW等,最後才到應用呢?

Lambda架構雖然有缺點,但是在很多公司依然適用,有時候我們沒有那麼大的業務量,實時業務需求並沒有那麼明顯,用著Lambda架構依然很爽。對於超大資料量的業務或者實時業務同樣多的情況,可以探索改良Lambda,業內也提出了Kappa架構,感興趣的小夥伴可以搜尋學習下。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69983799/viewspace-2721063/,如需轉載,請註明出處,否則將追究法律責任。

相關文章