流處理引擎經歷了從Storm到Spark Streaming再到Flink的三代的技術迭代，大數據處理也隨之經歷了從Lambda架構到Kappa架構的演進。本節以電商平臺的數據分析為例，來解釋大數據處理平臺如何支持企業在線服務。電商平臺會將用戶在APP或網頁的搜索、點擊和購買行為以日誌的形式記錄下來，用戶的各類行為形成了一個實時數據流，我們稱之為用戶行為日誌。
Chris Riedon on Unsplash
Lambda架構
當以Storm為代表的第一代流處理引擎成熟後，一些互聯網公司為了兼顧數據的實時性和準確性，採用下圖所示的Lambda架構來處理數據並提供在線服務。Lambda架構主要分為三部分：批處理層、流處理層和在線服務層。其中數據流來自Kafka這樣的消息隊列。
Lambda架構
批處理層
在批處理層，數據流首先會被持久化保存到批處理數據倉庫中，積累一段時間後，再使用批處理引擎來進行計算。這個積累時間可以是一小時、一天也可以是一個月。處理結果最後導入進一個可供應用系統在線查詢的數據庫上。批處理層中的批處理數據倉庫可以是HDFS、Amazon S3或其他數據倉庫，批處理引擎可以是MapReduce或Spark。
假如電商平臺的數據分析部門想查看全網某天哪些商品購買次數最多，使用批處理引擎對該天數據進行計算，像淘寶、京東這種級別的電商，用戶行為日誌數據量非常大，在這份日誌上進行一個非常簡單的計算都可能需要幾個小時。批處理引擎一般會定時啟動，對前一天或前幾個小時的數據進行處理，將結果輸出到一個數據庫中。與用戶行為日誌動輒幾個小時的處理時間相比，直接查詢一個在線數據庫只需要幾毫秒。這裡計算購買次數最多商品的例子相對比較簡單，在實際的業務場景中，一般需要做更為複雜的統計分析和機器學習計算，比如構建用戶畫像時，根據用戶年齡和性別等基礎信息，分析某類用戶最有可能購買的哪類商品，這類計算耗時更長。
批處理層能保證某份數據的結果準確性，而且即使程序失敗，直接重啟即可。此外，批處理引擎一般擴展性好，即使數據量增多，也可以通過增加節點數量來橫向擴展。
流處理層
很明顯，假如整個系統只有一個批處理層，會導致用戶必須等待很久才能獲取計算結果，一般有幾個小時的延遲。電商數據分析部門只能查看前一天的統計分析結果，無法獲取當前的結果，這對於實時決策來說有一個巨大的時間鴻溝，很可能導致管理者錯過最佳決策時機。因此，在批處理層的基礎上，Lambda架構增加了一個流處理層，用戶行為日誌會同時流入流處理層，流處理引擎生成預處理結果，並導入到一個數據庫中。分析人員可以查看到前一小時或前幾分鐘內的數據結果，這大大增加了整個系統的實時性。但數據流會有事件亂序等問題，使用早期的流處理引擎，只能得到一個近似準確的計算結果，相當於犧牲了一定的準確性來換取實時性。
之前的文章曾提到，早期的流處理引擎有一些缺點，在準確性、擴展性和容錯性上，流處理層無法直接取代批處理層，只能給用戶提供一個近似結果，還不能為用戶提供一個一致準確的結果。因此Lambda架構中，出現了批處理和流處理並存的現象。
在線服務層
在線服務層直接面向用戶的特定請求，需要將來自批處理層準確但有延遲的預處理結果和流處理層實時但不夠準確的預處理結果做融合。在融合過程中，需要不斷將批處理層的數據覆蓋流處理層生成的較老的數據。很多數據分析工具在數據融合上下了不少功夫，如Apache Druid。也可以用延遲極低的數據庫存儲來自批處理層和流處理層的預處理結果，在應用程序中人為控制預處理結果的融合。存儲預處理結果的數據庫可能是關係型數據庫MySQL，也可能是鍵值（Key-Value）數據庫Redis或HBase。
Lambda架構的優缺點
Lambda架構在實時性和準確性之間做了一個平衡，能夠解決很多大數據處理的問題，曾大量部署在各大互聯網公司。它的好處有：
- 批處理的準確度較高，而且在數據探索階段可以對某份數據試用不同的方法，可以反覆對數據進行實驗。另外，批處理的容錯性和擴展性較強。
- 流處理的實時性較高，可以提供一個近似準確的結果。
Lambda架構的缺點也比較明顯：
- 使用兩套大數據處理引擎，如果兩套大數據處理引擎的API不同，有任何邏輯上的改動，需要在兩邊同步更新，維護成本高，後期的迭代時間週期長。
- 早期流處理層的結果只是近似準確。
Kappa架構
Kafka的創始人Jay Kreps認為在很多場景下，維護一套Lambda架構的大數據處理平臺耗時耗力，於是提出在某些場景下，沒有必要維護一個批處理層，直接使用一個流處理層即可滿足需求，即下圖所示的Kappa架構。
Lambda架構
Kappa架構的興起主要有兩個原因：
- Kafka不僅起到消息隊列的作用，也可以保存更長時間的歷史數據，以替代Lambda架構中批處理層數據倉庫部分。流處理引擎以一個更早的時間作為起點開始消費，起到了批處理的作用。
- Flink流處理引擎解決了事件亂序下計算結果的準確性問題。
Kappa架構相對更簡單，實時性更好，所需的計算資源遠小於Lambda架構，隨著實時處理的需求在不斷增長，更多的企業開始使用Kappa架構。
Kappa架構的流行並不意味著不再需要批處理，批處理在一些特定場景上仍然有自己的優勢。比如進行一些數據探索、機器學習實驗，需要使用批處理來反覆驗證不同的算法。Kappa架構適用於一些邏輯固定的數據預處理流程，如統計一個時間段內商品的曝光和購買次數、某些關鍵詞的搜索次數等。Flink以流處理見長，但也實現了批處理的，是一個集流批於一體的大數據處理引擎，為架構提供更可靠的數據處理性能，未來Kappa架構將在更多場景下逐漸替換Lambda架構。
閱讀更多 皮皮魯的AI星球 的文章
