如何進行kappa和lambda對比

這篇文章跟大家分析一下“如何進行kappa和lambda對比”。內容詳細易懂，對“如何進行kappa和lambda對比”感興趣的朋友可以跟著小編的思路慢慢深入來閱讀一下，希望閱讀后能夠對大家有所幫助。下面跟著小編一起深入學習“如何進行kappa和lambda對比”的知識吧。

首先我們會詳細的講解這兩種架構，實現這兩種架構的技術工具，還有就是如何決策使用這兩種架構。

如何構建一個實時處理系統架構一直爭論不斷。一個好的實時處理系統必須是容錯和可升級的。必須支持批量和增量的更新，必須可擴展。

在這些討論中一個重要的里程碑是，storm的創始人，Nathan Marz，描述了我們目前所了解的lambda架構。Lambda架構目前已經有很多使用案例，實時上大量的公司都在使用，比如Yahoo和Netflix。當然，lambda架構也并不是得到的全是贊美，也有一些批判，就是它帶來了編碼的負擔。( 原英：But of course, Lambda is not a silver bullet and has received some fair criticism on the coding overhead it can create.)

在2014年夏天，LinkedIn的Jay Kreps發表了一篇文章描述了Kappa架構，解決了一些Lambda架構的陷阱。Kappa架構并不是Lambda架構的替代，因為有些Lambda架構并不適合遷移到Kappa架構上去。

對于一個給定的案例，準確的評估哪種架構師最好的是很有挑戰性的，錯誤的設計決策可能對數據分析項目的實施產生嚴重的影響。

現在，就深入細節去了解兩種數據處理架構。

Lambda架構有三個層面組成：batch，speed，serving。

Batch層面有兩個主要的任務：

1.管理歷史數據。

2.重新結算結果，例如重新訓練模型。

Batch層接受新的數據，將新的數據和歷史數據進行合并，然后重新計算結果。Batch層計算了所有的數據，這使得系統能產生相對精確的結果。然而，由于計算時間比較久，使的結果延遲也會比較大。

Speed層主要提供低延遲，近實時的計算結果。Speed層接收數據，增量更新batch層的結果。由于speed層的增量算法，計算代價被極大減少。

Serving用batch層和speed層計算的結果提供多樣的查詢。

創建kappa架構的一個最重要的動機是避免維護batch和speed層兩份獨立的代碼。一個核心的思想就是用一個單獨的流處理引擎處理實時的計算和連續不斷的數據的重復計算。代碼的更改對結果影響很大，所以數據必須重新計算。結果kappa架構的組成只有兩個部分：stream processing和serving。流處理層運行流處理任務。運行一個流處理作業以啟用實時數據處理。僅僅當流處理作業更改了一些代碼之后才會進行數據的重新處理。可以通過重啟一個梗概代碼后的流處理作業去處理所有以前的數據。

Serving層也是提供數據查詢的。

關于如何進行kappa和lambda對比就分享到這里啦，希望上述內容能夠讓大家有所提升。如果想要學習更多知識，請大家多多留意小編的更新。謝謝大家關注一下億速云網站！