聊聊Lambda架構

時間 2019-11-08

原文原文鏈接

定義

在數據分析場景中，咱們可能會遇到這樣的問題。例如，咱們要作一個推薦系統，若是咱們用批處理任務去作，一天或者一小時的推薦頻次明顯延遲太大。若是用流處理任務，雖然延遲的問題解決了，然而只用實時數據而沒有歷史數據，那麼準確性就沒法保證。所以須要結合批處理的歷史數據和流處理的實時數據進行處理，既能保證準確性，又能保證明時性。再好比反做弊系統，實時識別做弊用戶的時候同時須要用到用戶的歷史行爲。前端

針對上述問題，Storm 的做者 Nathan Marz 提出了 Lambda 架構。根據維基百科的定義，Lambda 架構的設計是爲了在處理大規模數據時，同時發揮流處理和批處理的優點。經過批處理提供全面、準確的數據，經過流處理提供低延遲的數據，從而達到平衡延遲、吞吐量和容錯性的目的。爲了知足下游的即席查詢，批處理和流處理的結果會進行合併。數據庫

從上面定義能夠看出，Lambda 架構包含三層，Batch Layer、Speed Layer 和 Serving Layer。架構圖以下：架構

下面分別介紹這三層架構的做用。框架

Batch Layer：批處理層，對離線的歷史數據進行預計算，爲了下游可以快速查詢想要的結果。因爲批處理基於完整的歷史數據集，所以準確性能夠獲得保證。批處理層能夠用 Hadoop、Spark 和 Flink 等框架計算
Speed Layer：加速處理層，處理實時的增量數據，這一層重點在於低延遲。加速層的數據不如批處理層那樣完整和準確，可是能夠填補批處理高延遲致使的數據空白。加速層能夠用 Storm、Spark streaming 和 Flink 等框架計算
Serving Layer：合併層，計算曆史數據和實時數據都有了，合併層的工做天然就是將二者數據合併，輸出到數據庫或者其餘介質，供下游分析。

Amazon AWS 的 Lambda 架構

這裏，我將用 AWS 做爲例子來介紹 Lambda 架構，AWS Lambda 架構圖以下工具

Batch Layer：使用 S3 bucket 從各類數據源收集數據，使用 AWS Glue 進行 ETL，輸出到 Amazon S3。數據也能夠輸出到 Amazon Athena （交互式查詢工具）oop

Speed Layer：從上圖看加速層有三個過程架構設計

Kinesis Stream 從實時數據流中處理增量的數據，這部分數據數據輸出到 Serving Layer 的 Amazon EMR，也能夠輸出到 Kinesis Firehose 對增量數據進行後續處理
Kinesis Firehose 處理增量數據並寫入 Amazone S3 中
Kinesis Analytics 提供 SQL 的能力對增量的數據進行分析

其實只有上面第一個組件與咱們今天討論的 Lambda 架構有關，其餘兩個組件只是針對實時處理的。設計

Serving Layer：合併層使用基於 Amazon EMR 的 Spark SQL 來合併 Batch Layer 和 Speed Layer 的數據。批處理數據能夠從 Amazon S3 加載批處理數據，實時數據能夠從 Kinesis Stream 直接加載，合併的數據能夠寫到 Amazone S3。下面是一段合併數據代碼3d

以上即是 Amazon AWS 實現 Lambda 架構的簡單介紹。orm

個人經歷

接下來分享下我以前的項目經歷。其實，咱們的項目跟上面的 Lambda 架構並非特別貼合，可是我以爲思想是一致的。本質上都是批處理和流處理相關補充，同時發揮兩者的優點。

咱們的業務是處理用戶的定位數據，最開始主要使用 Spark Streaming 進行增量處理，處理後的數據實時寫入 MongoDB。數據讀寫以用戶 id 爲粒度，因爲粒度比較細，所以天天的數據量比較大。前端若是查詢時間跨度較大的數據，每次都需按照用戶粒度數據作聚合，致使查詢響應比較慢且容易影響實時寫入。所以，咱們用批處理任務對歷史的離線數據進行預計算，再存儲到 MongoDB。同時咱們開發了基於 gRPC 實現的一套 Service 來充當 Serving Layer，將歷史的數據與實時的數據合併返回給前端，避免前端直接鏈接數據庫。在這個項目中咱們的 Batch Layer 和 Speed Layer 都是用的 Spark 框架，所以維護相對容易。

以前介紹 Lambda 都是用加速層彌補批處理層的空白，可是上面的例子中是用批處理層彌補加速層的不足。所以，架構設計只是一個思想，具體的實施仍是要根據業務進行靈活變通，不能生搬硬套。