Linkedln技術(shù)高管Jay Kreps：Lambda架構(gòu)剖析

Jay Kreps是Linkedln的一名在線數(shù)據(jù)架構(gòu)技術(shù)高管，其負(fù)責(zé)Linkedln開源項目，包括Apache Kafka、Apache Samza、Voldemort以及Azkaban等項目。在日常工作中，Jay Kreps經(jīng)常被問及有關(guān)Lambda架構(gòu)的問題，為此他結(jié)合實際經(jīng)驗和個人體會，把使用Lambda架構(gòu)的心得總結(jié)為以下幾點，我們一起來看下：

Lambda架構(gòu)的組成

該架構(gòu)的組成是這樣的：

在該架構(gòu)中，被讀取的數(shù)據(jù)是不可變的，在并行處理過程中數(shù)據(jù)會依次進(jìn)入批處理系統(tǒng)（batch system）與流處理系統(tǒng)。從邏輯上看，傳輸過程發(fā)生了兩次，一次是在批處理中，一次是在流處理中。在查詢時，當(dāng)這兩者都返回結(jié)果后，才算是完成一次完整的查詢。

這個架構(gòu)可以有很多的組合變化，我的想法是希望它變得更簡潔。例如可以把里面的Kafka、Storm、Hadoop等換成其它類似的系統(tǒng)；慣常的做法是使用兩個數(shù)據(jù)庫來存儲數(shù)據(jù)輸出表，一個用于實時優(yōu)化查詢，另外一個用于批量優(yōu)化處理。

Lambda架構(gòu)的目的是為應(yīng)用程序提供一個低延遲的復(fù)合異步數(shù)據(jù)傳輸環(huán)境，例如新聞類應(yīng)用，經(jīng)常需要進(jìn)行大規(guī)模信息處理，包括輸入，歸類，索引，存儲等操作。

我的體會是：架構(gòu)的引入不能照本宣科，要根據(jù)實際情況進(jìn)行調(diào)整優(yōu)化。

優(yōu)缺點分析

優(yōu)點：

1.  數(shù)據(jù)的不可變性。里面給出的數(shù)據(jù)傳輸模型是在初始化階段對數(shù)據(jù)進(jìn)行實例化，這樣的做法是能獲益良多的。能夠使得大量的MapReduce工作變得有跡可循，從而便于在不同階段進(jìn)行獨立調(diào)試。
2. 強(qiáng)調(diào)了數(shù)據(jù)的重新計算問題。在流處理中重新計算是個主要挑戰(zhàn)，但是經(jīng)常被忽視。比方說，某工作流的數(shù)據(jù)輸出是由輸入決定的，那么一旦代碼發(fā)生改動，我們將不得不重新計算來檢視變更的效度。什么情況下代碼會改動呢？例如需求發(fā)生變更，計算字段需要調(diào)整或者程序發(fā)出錯誤，需要進(jìn)行調(diào)試。

此外，外界對于Lambda的評論還有其它觀點，例如說實時數(shù)據(jù)處理是固有的，較批處理是高損耗低效率，我對此并不贊同。誠然流處理目的框架前沒有MapReduce那樣成熟，但是我們應(yīng)該用發(fā)展的觀點來看待而不是就此蓋棺定論。

缺點：

1. 代碼的維護(hù)需要在兩個復(fù)雜的分布式系統(tǒng)中進(jìn)行，這是個困難的工作。例如說在基于分布式框架上如Storm或Hadoop中進(jìn)行編程，使用不同的框架就需要進(jìn)行不同的處理。雖然目前有解決方案嘗試從實時和批處理框架中進(jìn)行抽象綜合，從而使得既能在高階框架中進(jìn)行編程而后又能在流處理或MapReduce中完成降階處理操作；Summingbird采用的就是這種方法。不過這樣雖然在某程度上能減少編碼的復(fù)雜度，但是仍然沒有根本性地解決問題。
2. 即使能解決二次編碼問題，分別在兩個系統(tǒng)中運行和維護(hù)應(yīng)用程序仍然是個艱巨的任務(wù)。所以，基于不同系統(tǒng)而抽象得到的新系統(tǒng)，都只能是從兩者的功能交集中來進(jìn)行。類似地，在跨數(shù)據(jù)庫系統(tǒng)中進(jìn)行ORM(對象關(guān)系映射)也是個困難的工作。

完成的試驗

在Linkedln中，我們做了不少的試驗。嘗試建立不同類型的分布式計算框架，甚至是開發(fā)出使代碼能在實時或Hadoop中無縫運行的專用API。不過，目前來看還不沒做到完美無缺。因為多系統(tǒng)的編程任務(wù)實在是太艱巨了。此外，API的使用會讓系統(tǒng)的漏洞不易被發(fā)現(xiàn)，同時對開發(fā)者有更嚴(yán)格的技術(shù)要求――對API的運用要足夠的熟練，從而能在調(diào)試或效率檢視時能夠?qū)λ杏绊懙囊蛩刈龅搅巳挥谛亍?/span>

我的建議是：如果你不太看重延遲問題，可以嘗試使用類似MapReduce的批處理框架或者是流處理框架，但是最好不要同時使用，除非真的有必要。

那么，Lambda架構(gòu)的優(yōu)勢是什么呢？我想是它能夠很好地指導(dǎo)如何搭建一個復(fù)雜的低延遲處理系統(tǒng)。例如搭建一個處理歷史數(shù)據(jù)的高延遲大數(shù)據(jù)處理系統(tǒng)和一個低延遲的流處理系統(tǒng)來減少重新計算的問題。但是這應(yīng)該是暫時性的，未來還會存在更好的替代解決方案。

一個替代方案

很多時候，慣性思維會讓人覺得流處理系統(tǒng)在處理歷史數(shù)據(jù)等大數(shù)據(jù)場合不太適合，但是我覺得這可能與他們使用的系統(tǒng)自身限制有關(guān)。流處理其實是在數(shù)據(jù)輸出的中間階段進(jìn)行的，完成后再把結(jié)果返回給用戶，所以是具備大數(shù)據(jù)處理能力的。

例如，請看下我們的一個替代方案：

1.  使用Kafka或其它系統(tǒng)來對需要重新計算的數(shù)據(jù)進(jìn)行日志記錄，以及提供給多個訂閱者使用。例如需要重新計算30天內(nèi)的數(shù)據(jù)，我們可以在Kafka中設(shè)置30天的數(shù)據(jù)保留值。

2.  當(dāng)需要進(jìn)行重新計算時，啟動流處理作業(yè)的第二個實例對之前獲得的數(shù)據(jù)進(jìn)行處理，之后直接把結(jié)果數(shù)據(jù)放入新的數(shù)據(jù)輸出表中。

3.  當(dāng)作業(yè)完成時，讓應(yīng)用程序直接讀取新的數(shù)據(jù)記錄表。

4.  停止歷史作業(yè)，刪除舊的數(shù)據(jù)輸出表。

有別于Lambda架構(gòu)，上述方法是在代碼改動時才進(jìn)行數(shù)據(jù)重新計算。如果想加快處理速度，計算作業(yè)的并行處理能力是個突破口。或許我們可以把這個架構(gòu)稱呼為Kappa架構(gòu)，雖然它真的很簡易。

這個方案還能繼續(xù)優(yōu)化改進(jìn)。很多情況下，我們可以把兩個數(shù)據(jù)輸出表整合在一起。這樣一來，我們可以很快地在程序中讀取歷史記錄和進(jìn)行其它重要的針對新老版本的測調(diào)試工作。

請注意，這個方法不是說讓我們遠(yuǎn)離HDFS，而是說我們不在HDFS中進(jìn)行重新計算。詳細(xì)的說明文檔，請點擊這里進(jìn)行查閱。

背景知識

對Kafka不太熟悉的讀者，可能理解上會有點困難。我們這里給出一些背景介紹，希望對初學(xué)者有所幫助。

Kafka中是這樣按序來進(jìn)行日志記錄的：

一個Kafka“主題”包含了以下的記錄集：

一個流處理在使用這些數(shù)據(jù)時進(jìn)行的是“偏移”量維護(hù)，就是把每個分區(qū)最新加入數(shù)據(jù)的編號進(jìn)行記錄。所以，只需使用不同的偏移量來重新執(zhí)行作業(yè)就可以實現(xiàn)重新計算的目的。對統(tǒng)一數(shù)據(jù)添加第二個消息消費者其實就相當(dāng)于使另外一個讀者指向不同的日志位置。

Kafka提供了復(fù)制和高容錯的能力，使得能在便宜的商業(yè)硬件中使用，特別是在TB級別的存儲場合中。

寫在最后

雖然在Linkedln中，配合該方法的是Samza流處理系統(tǒng)，但并不代表不能在其他系統(tǒng)中運用。有心的讀者可以進(jìn)行嘗試，我很樂意看到有新的方案產(chǎn)生。

英文出自：radar.oreilly

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈