數據系統架構——Lambda architecture(Lambda架構)

傳統系統的問題

「咱們正在從IT時代走向DT時代(數據時代)。IT和DT之間,不只僅是技術的變革,更是思想意識的變革,IT主要是爲自我服務,用來更好地自我控制和管理,DT則是激活生產力,讓別人活得比你好」——阿里巴巴董事局主席馬雲。算法

 

數據量從M的級別到G的級別到如今T的級、P的級別。數據量的變化數據管理系統(DBMS)和數倉系統(DW)也在悄然的變化着。sql

傳統應用的數據系統架構設計時,應用直接訪問數據庫系統。當用戶訪問量增長時,數據庫沒法支撐日益增加的用戶請求的負載時,從而致使數據庫服務器沒法及時響應用戶請求,出現超時的錯誤。出現這種狀況之後,在系統架構上就採用圖(A)的架構,在數據庫和應用中間過一層緩衝隔離,緩解數據庫的讀寫壓力。然而,當用戶訪問量持續增長時,就須要考慮讀寫分離技術(Master-Slave)架構如圖(B),分庫分表技術。如今,架構變得愈來愈複雜了,增長隊列、分區、複製等處理邏輯。應用程序須要瞭解數據庫的schema,才能訪問到正確的數據。數據庫

圖(A)服務器

圖(B)網絡

 

Lambda架構的背景

 

大數據處理技術須要解決這種可伸縮性與複雜性。首先要認識到這種分佈式的本質,要很好地處理分區與複製,不會致使錯誤分區引發查詢失敗,而是要將這些邏輯內化到數據庫中。當須要擴展系統時,能夠很是方便地增長節點,系統也可以針對新節點進行rebalance。其次是要讓數據成爲不可變的。原始數據永遠都不能被修改,這樣即便犯了錯誤,寫了錯誤數據,原來好的數據並不會受到破壞。架構

Storm的做者NathanMarz提出的一個實時大數據處理框架(Lambda架構)就知足以上兩點。Marz在Twitter工做期間開發了著名的實時大數據處理框架Storm,Lambda架構是其根據多年進行分佈式大數據系統的經驗總結提煉而成。app

Lambda架構的目標是設計出一個能知足實時大數據系統關鍵特性的架構,包括有:高容錯、低延時和可擴展等。Lambda架構整合離線計算和實時計算,融合不可變性(Immunability),讀寫分離和複雜性隔離等一系列架構原則,可集成Hadoop,Kafka,Storm,Spark,Hbase等各種大數據組件。框架

大數據系統的關鍵特性

Marz介紹BigData System許具有的屬性:運維

a、Robustandfault-tolerant(容錯性和魯棒性):對大規模分佈式系統來講,機器是不可靠的,可能會當機,可是系統須要是健壯、行爲正確的,即便是遇到機器錯誤。除了機器錯誤,人更可能會犯錯誤。在軟件開發中不免會有一些Bug,系統必須對有Bug的程序寫入的錯誤數據有足夠的適應能力,因此比機器容錯性更加劇要的容錯性是人爲操做容錯性。對於大規模的分佈式系統來講,人和機器的錯誤天天均可能會發生,如何應對人和機器的錯誤,讓系統可以從錯誤中快速恢復尤爲重要。數據庫設計

b、Lowlatency reads and updates(低延時):不少應用對於讀和寫操做的延時要求很是高,要求對更新和查詢的響應是低延時的。

c、Scalable(橫向擴容):當數據量/負載增大時,可擴展性的系統經過增長更多的機器資源來維持性能。也就是常說的系統須要線性可擴展,一般採用scale out(經過增長機器的個數)而不是scale up(經過加強機器的性能)。

d、General(通用性):系統須要可以適應普遍的應用,包括金融領域、社交網絡、電子商務數據分析等。

e、Extensible(可擴展):須要增長新功能、新特性時,可擴展的系統能以最小的開發代價來增長新功能。

f、Allows ad hoc queries(方便查詢):數據中蘊含有價值,須要可以方便、快速的查詢出所須要的數據。

d、Minimal maintenance(易於維護):系統要想作到易於維護,其關鍵是控制其複雜性,越是複雜的系統越容易出錯、越難維護。

h、Debuggable(易調試):當出問題時,系統須要有足夠的信息來調試錯誤,找到問題的根源。其關鍵是可以追根溯源到每一個數據生成點。

數據系統的本質

Marz認爲:數據系統經過查詢過去的(部分、所有)數據去回答問題。如:他是一個什麼樣的人?他有多少朋友?這個帳號是否收支平衡?。所以,DataSystem的通用定義爲Query=Function(alldata)。對通用的表達式進行分解獲得:數據系統=數據+查詢,從而能夠從數據和查詢兩個方面認識大數據系統的本質。

數據本本質:When&What

數據是一個不可分割的單元,數據有兩個關鍵的特性:When和What。

When是隻數據是與時間相關的,也就是數據是在某個時間產生的。這個很是重要,在具備事務特性的數據庫中,操做的前後順序對結果相當重要。例如數據庫的Binlog日誌。所以,數據的時間性質決定了數據的全局發生前後,也就決定了數據的結果。

What是隻數據的自己。因爲數據跟某個時間點相關,因此數據的自己是不可變的(immutable),過往的數據已經成爲事實(Fact),你不可能回到過去的某個時間點去改變數據事實。這也就意味着對數據的操做其實只有兩種:讀取已存在的數據和添加更多的新數據。採用數據庫的記法,CRUD就變成了CR,Update和Delete本質上實際上是新產生的數據信息,用C來記錄。

數據的存儲:StoreEverything Rawly and Immutably

根據上述對數據特性的分析,lambda架構中對數據的存儲採用的方式是:數據不可變,存儲全部數據。

採用這兩種方式存儲的好處:

a、簡單。採用不可變的數據模型,存儲數據時只須要簡單的往主數據集後追加數據便可。相比於採用可變的數據模型,爲了Update操做,數據一般須要被索引,從而能快速找到要更新的數據去作更新操做。

b、應對人爲和機器的錯誤。人和機器天天均可能會出錯,如何應對人和機器的錯誤,讓數據系統快速恢復極其重要。不可變和可重複計算是應對認爲和機器錯誤的經常使用方法。採用可變數據模型,引起錯誤的數據有可能被覆蓋而丟失。相比於採用不可變的數據模型,由於全部的數據都在,引起錯誤的數據也在。修復的方法就能夠簡單的是遍歷數據集上存儲的全部的數據,丟棄錯誤的數據,從新計算獲得Views。從新計算的關鍵點在於利用數據的時間特性決定的全局次序,依次順序從新執行,必然能獲得正確的結果。

當前業界有不少採用不可變數據模型來存儲全部數據的例子。好比分佈式數據庫Datomic,基於不可變數據模型來存儲數據,從而簡化了設計。分佈式消息中間件Kafka,基於Log日誌,以追加append-only的方式來存儲消息。

Lambda架構

Lambda架構的主要思想是將大數據系統架構爲多層個層次,分別爲批處理層(batchlayer)、實時處理層(speedlayer)、服務層(servinglayer)如圖(C)。

理想狀態下,任何數據訪問均可以從表達式Query= function(alldata)開始,可是,若數據達到至關大的一個級別(例如PB),且還須要支持實時查詢時,就須要耗費很是龐大的資源。一個解決方式是預運算查詢函數(precomputedquery funciton)。書中將這種預運算查詢函數稱之爲Batch View(A),這樣當須要執行查詢時,能夠從BatchView中讀取結果。這樣一個預先運算好的View是能夠創建索引的,於是能夠支持隨機讀取(B)。因而系統就變成:

(A)batchview = function(all data);

(B)query =function(batch view)。

圖(C)

 

 

BatchLayer

 

在Lambda架構中,實現(A)batch view =function(all data)的部分稱之爲BatchLayer。他承擔兩個職責:

a、存儲MasterDataset,這是一個不變的持續增加的數據集

b、針對這個MasterDataset進行預運算

在全體數據集上在線運行查詢函數獲得結果的代價太大,同時處理查詢時間過長,致使用戶體驗很差。若是咱們預先在數據集上計算並保存預計算的結果,查詢的時候直接返回預計算的結果,而無需從新進行復制耗時的計算。顯然,batchview是一個批處理過程,如採用Hadoop或spark支持的map-reduce方式。採用這種方式計算獲得的每一個view都支持再次計算,且每次計算的結果都相同。

 

圖(D)

 

對View的理解: 

View是一個和業務關聯性比較大的概念,View的建立須要從業務自身的需求出發。一個通用的數據庫查詢系統,查詢對應的函數變幻無窮,不可能窮舉。可是若是從業務自身的需求出發,能夠發現業務所須要的查詢經常是有限的。BatchLayer須要作的一件重要的工做就是根據業務的需求,考察可能須要的各類查詢,根據查詢定義其在數據集上對應的Views。

Batch Layer的Immutabledata模型和Views

如圖(E)坐席(agentid=50023)的人,在10:00:06分的時候,狀態是calling,在10:00:10的時候狀態爲waiting。在傳統的數據庫設計中,直接後面的紀錄覆蓋前面的紀錄,而在Immutable數據模型中,不會對原有數據進行更改,而是採用插入修改紀錄的形式更改歷史紀錄。

圖(E)

 

上文所說起的View是圖(E)中預先計算獲得的相關視圖,例如:2016-06-21當天全部上線的agent數,每條熱線、公司下上線的Agent數。根據業務須要,預先計算出結果。此過程至關於傳統數倉建模的應用層,應用層也是根據業務場景,預先加工出的view。

SpeedLayer

BatchLayer可以很好的處理離線數據,可是在不少場景數據不斷產生,而且業務場景須要實時查詢。SpeedLayer就是設計用來處理增量實時數據。

SpeedLayer和BatchLayer比較相似,對數據進行計算並生成RealtimeView,其主要的區別在於:

a、SpeedLayer處理的數據是最近的增量數據流,BatchLayer處理的是全體數據集

b、SpeedLayer爲了效率,接收到新數據及時更新RealtimeView,而BatchLayer根據全體離線數據直接獲得BatchView。SpeedLayer是一種增量計算,而非從新計算(recomputation)。

c、SpeedLayer由於採用增量計算,因此延遲小,而BatchLayer是全數據集的計算,耗時比較長。

綜上所訴,SpeedLayer是BatchLayer在實時性上的一個補充。如圖(F)

 

圖(F)

 

 

SpeedLayer可總結爲以(C)RealtimeView=function(RealtimeView,newdata);

LambdaArchitecture將數據處理分解爲BatchLayer和SpeedLayer有以下優勢:

a、容錯性:SpeedLayer中處理的數據不斷寫入BatchLayer,當BatchLayer中從新計算數據集包含SpeedLayer處理的數據集後,當前的RealtimeView就能夠丟棄,這就意味着SpeedLayer處理中引入的錯誤,在BatchLayer從新計算時均可以獲得修證。這點也能夠當作時CAP理論中的最終一致性(EventualConsistency)的體現。

b、複雜性隔離。BatchLayer處理的是離線數據,能夠很好的掌控。Speed Layer採用增量算法處理實時數據,複雜性比Batch Layer要高不少。經過分開BatchLayer和Speed Layer,把複雜性隔離到Speed Layer,能夠很好的提升整個系統的魯棒性和可靠性。

ServingLayer

BatchLayer經過對MasterDataset執行查詢得到BatchView,Speed Layer經過增量計算提供RealtimeView。Lambda架構的ServingLayer用於響應用戶的查詢請求,合併BatchView和Realtime View中的結果數據集到最終的數據集,如圖(G)。所以,ServingLayer的職責包含:

a、對batchView和RealTimeView的隨機訪問

b、更新BatchVeiw和RealTimeView,並負責結合二者的數據,對用戶提供統一的接口

圖(G)

 

綜上所訴,ServingLayer採用以下等式(D)表示:Query=function(BatchViews,RealtimeView)。

Lambda架構組件選型

下圖給出了Lambda架構中各組件在大數據生態系統中和阿里集團的經常使用組件。數據流存儲選用不可變日誌的分佈式系統Kafa、TT、Metaq;BatchLayer數據集的存儲選用Hadoop的HDFS或者阿里雲的ODPS;BatchView的加工採用MapReduce;BatchView數據的存儲採用Mysql(查詢少許的最近結果數據)、Hbase(查詢大量的歷史結果數據)。SpeedLayer採用增量數據處理Storm、Flink;RealtimeView增量結果數據集採用內存數據庫Redis。

圖(H)

 

Lambda是一個通用框架,各模塊選型不要侷限於上面給出的組件,特別是view的選型。由於View是和各業務關聯很是大的概念,View選擇組件時要根據業務的需求,選擇最合適的組件。

Lambda架構的評估

優勢:

a、數據的不可變性。裏面給出的數據傳輸模型是在初始化階段對數據進行實例化,這樣的作法是能獲益良多的。可以使得大量的MapReduce工做變得有跡可循,從而便於在不一樣階段進行獨立調試。

 b、強調了數據的從新計算問題。在流處理中從新計算是個主要挑戰,可是常常被忽視。比方說,某工做流的數據輸出是由輸入決定的,那麼一旦代碼發生改動,咱們將不得不從新計算來檢視變動的效度。什麼狀況下代碼會改動呢?例如需求發生變動,計算字段須要調整或者程序發出錯誤,須要進行調試。

缺點:

a、Jay Kreps認爲Lambda包含固有的開發和運維的複雜性。Lambda須要將全部的算法實現兩次,一次是爲批處理系統,另外一次是爲實時系統,還要求查詢獲得的是兩個系統結果的合併。

 

因爲存在以上缺點,Linkedin的Jaykreps提出了Kappa架構如圖(I):

圖(I)

 

一、使用Kafka或其它系統來對須要從新計算的數據進行日誌記錄,以及提供給多個訂閱者使用。例如須要從新計算30天內的數據,咱們能夠在Kafka中設置30天的數據保留值。

二、當須要進行從新計算時,啓動流處理做業的第二個實例對以前得到的數據進行處理,以後直接把結果數據放入新的數據輸出表中。

三、看成業完成時,讓應用程序直接讀取新的數據記錄表。

四、中止歷史做業,刪除舊的數據輸出表。

 

Kappa架構暫時未作深刻了解,在此不作評價。我我的以爲,不一樣的數據架構有各自的優缺點,咱們使用的時候只能根據應用場景,選擇更合適的架構,才能揚長避短。

 

參考資料:

Big Data:Principles and best practices of scalable real-time data systems——Nathan Marz

http://blog.csdn.net/brucesea/article/details/45937875

https://zhuanlan.zhihu.com/p/20510974

http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions

相關文章
相關標籤/搜索