摘要：Jay Kreps是Linkedln的一名在線數據架構技術高管，在日常工作中，Jay Kreps經常被問及有關Lambda架構的問題，為此他結合實際經驗和個人體會，針對Lambda架構進行深度剖析，分析了它的優缺點以及采用的替代方案。

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

Lambda架構的組成

該架構的組成是這樣的：

在該架構中，被讀取的數據是不可變的，在并行處理過程中數據會依次進入批處理系統（batch system）與流處理系統。從邏輯上看，傳輸過程發生了兩次，一次是在批處理中，一次是在流處理中。在查詢時，當這兩者都返回結果后，才算是完成一次完整的查詢。

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

Lambda架構的目的是為應用程序提供一個低延遲的復合異步數據傳輸環境，例如新聞類應用，經常需要進行大規模信息處理，包括輸入，歸類，索引，存儲等操作。

我的體會是：架構的引入不能照本宣科，要根據實際情況進行調整優化。

優缺點分析

優點：

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

強調了數據的重新計算問題。在流處理中重新計算是個主要挑戰，但是經常被忽視。比方說，某工作流的數據輸出是由輸入決定的，那么一旦代碼發生改動，我們將不得不重新計算來檢視變更的效度。什么情況下代碼會改動呢？例如需求發生變更，計算字段需要調整或者程序發出錯誤，需要進行調試。

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

缺點：

代碼的維護需要在兩個復雜的分布式系統中進行，這是個困難的工作。例如說在基于分布式框架上如Storm或Hadoop中進行編程，使用不同的框架就需要進行不同的處理。雖然目前有解決方案嘗試從實時和批處理框架中進行抽象綜合，從而使得既能在高階框架中進行編程而后又能在流處理或MapReduce中完成降階處理操作；Summingbird采用的就是這種方法。不過這樣雖然在某程度上能減少編碼的復雜度，但是仍然沒有根本性地解決問題。

即使能解決二次編碼問題，分別在兩個系統中運行和維護應用程序仍然是個艱巨的任務。所以，基于不同系統而抽象得到的新系統，都只能是從兩者的功能交集中來進行。類似地，在跨數據庫系統中進行ORM(對象關系映射)也是個困難的工作。

完成的試驗

在Linkedln中，我們做了不少的試驗。嘗試建立不同類型的分布式計算框架，甚至是開發出使代碼能在實時或Hadoop中無縫運行的專用API。不過，目前來看還不沒做到完美無缺。因為多系統的編程任務實在是太艱巨了。此外，API的使用會讓系統的漏洞不易被發現，同時對開發者有更嚴格的技術要求——對API的運用要足夠的熟練，從而能在調試或效率檢視時能夠對所有影響的因素做到了然于胸。

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

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

一個替代方案

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

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

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

2.? 當需要進行重新計算時，啟動流處理作業的第二個實例對之前獲得的數據進行處理，之后直接把結果數據放入新的數據輸出表中。

3.? 當作業完成時，讓應用程序直接讀取新的數據記錄表。

4.? 停止歷史作業，刪除舊的數據輸出表。

有別于Lambda架構，上述方法是在代碼改動時才進行數據重新計算。如果想加快處理速度，計算作業的并行處理能力是個突破口?；蛟S我們可以把這個架構稱呼為Kappa架構，雖然它真的很簡易。

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

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

背景知識

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

Kafka中是這樣按序來進行日志記錄的：

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

一個流處理在使用這些數據時進行的是“偏移”量維護，就是把每個分區最新加入數據的編號進行記錄。所以，只需使用不同的偏移量來重新執行作業就可以實現重新計算的目的。對統一數據添加第二個消息消費者其實就相當于使另外一個讀者指向不同的日志位置。

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

寫在最后

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

英文出自：radar.oreilly

總結

以上是生活随笔為你收集整理的Linkedln技术高管Jay Kreps：Lambda架构剖析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。