lambda架構的問題

原文：https://www.oreilly.com/ideas...

Storm的做者Nathan Marz提出了 lambda 架構，該架構是在 MapReduce 上和 Storm 上構建流式處理的應用。lambda 架構是捕獲不可變的數據序列並將其並行的發送給批處理系統和流式處理系統。可是你須要分別在批處理系統和流式處理系統中實現一次數據處理邏輯。而在查詢的時候須要將兩個系統計算的結果合併在一塊兒，以完成查詢返回給請求端。

對於兩種處理系統，你能夠靈活替換實現系統，好比使用 kafka+storm 實現流出處理，使用 hadoop 實現批式處理，輸出結果一般在分開的兩個數據庫中，一個是爲了流式而優化，另外一個是爲了批式更新而優化。

可是對於Jay Kreps【原文做者】由於一直在從事實時數據管道的建設，雖然其中有一些風格就是 lambda 架構，可是他更喜歡一個新的替換的方案。

Lambda 架構圖

爲何會提出lambda 架構呢

由於那些試圖構建流式處理系統的人並無過多的考慮數據重計算的問題，最終形成系統沒有便利的方法來處理數據重計算。

lambda 架構強調保持輸入的原始數據不可變而且顯示的將數據從新計算的問題給展示了出來。經過 lambda 架構能夠比較好的解決了流式數據和歷史數據的計算問題。

爲何數據會可能從新計算呢？

由於隨着時間的推移，代碼可能會改變。改變的緣由多是你想在輸出結果中新加一個字段，或者是由於代碼有 bug 須要修復。不論是什麼緣由，要使得歷史數據獲得新的預期結果，就須要將數據從新計算。

Jay Kreps對 lambda 架構的反駁

由於 lambda 架構提出其中一個觀點認爲流式系統是近似的，不許確的，準確度不如批式處理。
Jay Kreps對此觀點不敢苟同，他認爲現存的流式處理的框架不如 MapReduce成熟，但不表明流式系統不能如批式系統那樣提供強大的語義保證。並且 lambda 架構提出的標題是"beats the CAP theorem",即幹掉 CAP 理論，可是實際上儘管在流處理上對延時和可用性間存在權衡，但由於這是一種異步處理架構。因此異步計算的結果也不能當即保持與輸入的數據一致，所以 CAP 理論仍然沒有被打破。

lambda 架構存在的問題是什麼？

lambda 架構須要維護在兩個複雜的分佈式系統中輸出相同結果的代碼，就像看起來那麼痛苦，並且Jay Kreps也不認爲該問題是能夠解決的。

由於 storm 和 Hadoop 分佈式框架很是的複雜，所以不可避免的代碼會針對其運行的框架進行設計。

爲何 Lambda 會這樣使人興奮呢？

Jay Kreps建議若是對延時性不敏感就僅使用如 MapReduce 這樣的批處理系統。若是延遲敏感則使用流式處理框架，除非特別必須才同時使用這兩種系統。

可是需求老是千奇百怪的，人們須要構建複雜的，低延時的處理系統,（並且在天朝 PM 都想要大而全的功能下，這樣需求更盛）。

他們擁有的兩件事情並不能解決他們的問題：一個能夠處理歷史數據的可擴展高延遲批處理系統和一個沒法從新處理結果的低延遲流處理系統。但經過將兩個東西鏈接在一塊兒，實際上構成了一個可行的方案，也就是 lambda 架構。但儘管lambda 架構讓人很痛苦，但確實也解決了從新計算這樣一般讓人忽略的問題。
可是Jay Kreps只認爲 lambda 架構只是臨時解決方案，它不是新的編程範例也不是大數據的將來方向。

Jay Kreps的經驗

由於在 linkedin 內部已經進行過屢次的討論和嘗試。發現保持兩個不一樣系統中編寫的代碼徹底同步很是很是困難。用於隱藏底層框架的API 被證實是最 Low 的抽象，由於這樣設計會須要深刻的 Hadoop 知識和對實時層的深刻了解，並且當你在調試或者由於性能問題排查緣由時，還加上須要深刻了解抽象層是怎麼轉換到底層的處理框架的。 也許簡單的纔是最有效的。

Jay Kreps的靈魂拷問

1. 爲何不能改進流式處理系統來處理它的目標域內的完整問題呢？
2. 爲何須要粘在另外一個系統上？
3. 爲何不能同時進行實時處理並在代碼更改時處理從新處理？
4. 爲何不經過增長並行性和重播歷史很是很是快地處理從新計算的問題？

Jay Kreps 的觀點是什麼？

Jay Kreps在思考爲何不能改進流式處理系統來處理它的目標域中完整的問題集呢。
所以出現了兩種思路

1. 使用一種語言或者框架來抽象實時和批處理框架，能夠用更高層的框架 api 寫代碼，而後該框架會編譯後選擇使用實時處理或者批處理。

   這種方式確定使得事情變得更好些，可是不能解決問題。
   即便這樣能夠避免編寫兩次代碼，可是運行和調試兩個系統的負擔也會很是高，並且新的抽象只能提供兩個系統特性的並集（但如今 Beam 不是在作這樣的事情嗎）。並且這樣作與跨數據庫 透明的 ORM同樣的臭名昭著。
   在原有系統之上提供類似的接口和界面化語言，在幾乎不穩定的分佈式系統上構建統一的抽象層比構建徹底不一樣的編程範式要可貴多。

2. 加強流式系統的能力，以解決其目標域內的完整問題。流處理的基本抽象是數據流DAG，它與傳統數據倉庫中的底層抽象徹底相同，也是MapReduce後繼Tez的基本抽象。流處理只是這種數據流模型的一種推廣，它將中間結果的檢查點和持續輸出暴露給最終用戶。

Jay Kreps提出的在流式處理系統中進行從新計算的邏輯

1. 使用 kafka 或其餘系統保留所有想要從新計算的 log 數據，好比保留 30 天內的數據。
2. 當想要從新計算時，開啓一個新的流式處理 job 的實例從頭開始計算，並將計算結果輸出到一個新的 table 中。
3. 當第二個實例處理的數據追遇上前一個時，將應用切換到讀新表。
4. 停用老版本的 JOB，並刪除老的表數據

該方式只在代碼更改時須要從新計算。固然從新計算只是統一代碼的改進版本，運行在相同的框架上，消費一樣的輸入數據。固然也能夠提升 job 的並行度，以便快速完成。

而該架構被稱爲 Kappa架構

並且新舊兩張表也能夠同時存在，這樣就能夠經過將應用切換到舊錶來恢復舊的邏輯。在特別重要的狀況下，也可使用AB 測試或 bandit 算法來確保不管是修復bug仍是代碼改進都不會意外降級。

一樣的，數據仍是能夠存儲在 HDFS 上的，可是數據的從新計算不會再在 HDFS 作了。

而對於 Kappa 系統，Linkedin 內部使用的Samza就正在使用。

比較

兩種方法之間的效率和資源權衡在某種程度上有所不一樣

1. Lambda架構須要始終運行從新處理和實時處理
2. Kappa 架構只須要在須要從新處理時運行第二份做業，可是，Kappa 架構要求在輸出數據庫中暫時擁有2倍的存儲空間，而且須要一個支持高容量寫入的數據庫來從新加載。

在這兩種狀況下，再加工的額外負荷可能會平均。若是你有不少這樣的工做，他們不會一次所有從新處理，因此在一個有幾十個這樣的工做的共享集羣上，你可能會爲在任何給定時間激活從新處理的少數Job提供額外的幾個百分點的容量預算。

	lambda 架構	kappa 架構
數據處理能力	可處理超大規模的歷史數據	歷史數據處理能力有限
機器開銷	批處理和實時計算需一直運行，機器開銷大	必要時進行全量計算，機器開銷相對較小
存儲開銷	只須要保存一份查詢結果，存儲開銷較小	須要存儲新老實例結果，存儲開銷相對較大。但若是是多 Job 共用的集羣，則只須要預留出一小部分的存儲便可
開發、測試難易程度	實現兩套代碼，開發、測試難度較大	只需面對一個框架，開發、測試難度相對較小
運維成本	維護兩套系統，運維成本大	只需維護一個框架，運維成本小

對比表格參考自：http://bigdata.51cto.com/art/...

Kappa 的優點

Kappa 的真正優點不是關於效率，而是關於容許人們在單個處理框架之上開發，測試，調試和操做他們的系統。所以，在簡單性很重要的狀況下，請將Kappa 架構視爲Lambda架構的替代方案。