大數(shù)據(jù):簡述 Lambda 架構(gòu)

浪尖聊大數(shù)據(jù)
加速層批處理視圖建立索引便于能快速的即席查詢(Ad hoc queries),它存儲(chǔ)實(shí)時(shí)視圖并處理傳入的數(shù)據(jù)流,以便更新這些視圖。基礎(chǔ)存儲(chǔ)層必須滿足以下場景。

我們?nèi)绾螌?CAP 理論?

1.png

計(jì)算機(jī)科學(xué)中有一個(gè) CAP 定理,分布式數(shù)據(jù)存儲(chǔ)不可能同時(shí)提供以下三個(gè)保證中的兩個(gè)以上。

一致性:

每個(gè)節(jié)點(diǎn)讀取的是最新結(jié)果或者是報(bào)錯(cuò)。

可用性:

每個(gè)請求都會(huì)收到一個(gè)(非錯(cuò)誤)響應(yīng),但不保證它包含最新的寫入。

分區(qū)容錯(cuò):

盡管節(jié)點(diǎn)之間的網(wǎng)絡(luò)丟棄(或延遲了)任意數(shù)量的消息,系統(tǒng)仍繼續(xù)運(yùn)行。

簡史

2011年,內(nèi)森·馬茲(Nathan Marz)在他的博客中提出了一種解決 CAP 定理局限性的重要方法,即 Lambda 架構(gòu)。

2.png

工作原理

讓我們仔細(xì)看看 Lambda 架構(gòu)。Lambda 架構(gòu)分為三層: 批處理層(batch layer),加速層(speed layer),和服務(wù)層(serving layer)。

它結(jié)合了對同一數(shù)據(jù)的實(shí)時(shí)(real-time)和批量(batches)處理。

首先,傳入的實(shí)時(shí)數(shù)據(jù)流在批處理層(batch layer)存儲(chǔ)在主數(shù)據(jù)集中,并在加速層(speed layer)存儲(chǔ)在內(nèi)存緩存中。然后對批處理層中的數(shù)據(jù)建索引,且通過批處理視圖使之可用。加速層(speed layer)中的實(shí)時(shí)數(shù)據(jù)通過實(shí)時(shí)視圖(real-time views)暴露出來。最后,批處理視圖和實(shí)時(shí)視圖都可以獨(dú)立查詢,也可以一起查詢,以回答任何歷史的或?qū)崟r(shí)的問題。

批處理層(Batch layer)

該層負(fù)責(zé)管理主數(shù)據(jù)集。主數(shù)據(jù)集中的數(shù)據(jù)必須具有以下三個(gè)屬性。

數(shù)據(jù)是原始的

數(shù)據(jù)是不可變的

數(shù)據(jù)永遠(yuǎn)是真實(shí)的

主數(shù)據(jù)集是正確性的保證(source of truth)。即使丟失所有服務(wù)層數(shù)據(jù)集和加速層數(shù)據(jù)集,也可以從主數(shù)據(jù)集中重建應(yīng)用程序。

批處理層還將主數(shù)據(jù)集預(yù)計(jì)算到批處理視圖(batch views)中,以便能進(jìn)行低延遲查詢。

3.png

由于我們的主數(shù)據(jù)集在不斷增長,因此我們必須制定一種策略,以便在有新數(shù)據(jù)可用時(shí)管理批處理視圖(batch views)。

重新計(jì)算法:

拋棄舊的批處理視圖,重新計(jì)算整個(gè)主數(shù)據(jù)集的函數(shù)。

增量算法:

當(dāng)新數(shù)據(jù)到達(dá)時(shí),直接更新視圖。

加速層(Speed layer)

加速層批處理視圖建立索引便于能快速的即席查詢(Ad hoc queries),它存儲(chǔ)實(shí)時(shí)視圖并處理傳入的數(shù)據(jù)流,以便更新這些視圖。基礎(chǔ)存儲(chǔ)層必須滿足以下場景。

隨機(jī)讀:

支持快速隨機(jī)讀取以快速響應(yīng)查詢。

隨機(jī)寫:

為了支持增量算法,必須盡可能的以低延遲修改實(shí)時(shí)視圖。

可伸縮性:

實(shí)時(shí)視圖應(yīng)隨它們存儲(chǔ)的數(shù)據(jù)量和應(yīng)用程序所需的讀/寫速率進(jìn)行縮放。

容錯(cuò)性:

當(dāng)機(jī)器故障,實(shí)時(shí)視圖應(yīng)還能繼續(xù)正常運(yùn)行。

服務(wù)層(Serving layer)

該層提供了主數(shù)據(jù)集上執(zhí)行的計(jì)算結(jié)果的低延遲訪問。讀取速度可以通過數(shù)據(jù)附加的索引來加速。與加速層類似,該層也必須滿足以下要求,例如隨機(jī)讀取,批量寫入,可伸縮性和容錯(cuò)能力。

Lambda 架構(gòu)幾乎可以滿足所有屬性

Lambda 體系結(jié)構(gòu)基于幾個(gè)假定:容錯(cuò)、即席查詢、可伸縮性、可擴(kuò)展性。

容錯(cuò):   Lambda 架構(gòu)為大數(shù)據(jù)系統(tǒng)提供了更友好的容錯(cuò)能力,一旦發(fā)生錯(cuò)誤,我們可以修復(fù)算法或從頭開始重新計(jì)算視圖。

即席查詢: 批處理層允許針對任何數(shù)據(jù)進(jìn)行臨時(shí)查詢。

可伸縮性: 所有的批處理層、加速層和服務(wù)層都很容易擴(kuò)展。

因?yàn)樗鼈兌际峭耆植际降南到y(tǒng),我們可以通過增加新機(jī)器來輕松地?cái)U(kuò)大規(guī)模。

擴(kuò)展: 添加視圖是容易的,只是給主數(shù)據(jù)集添加幾個(gè)新的函數(shù)。

一些問題

層之間的代碼如何同步

解決此問題的方法之一是通過使用通用庫或引入流之間共享的某種抽象來為各層提供通用代碼庫。譬如 Summingbird or Lambdoop,Casado 這些框架

我們可以移除速度層(speed layer)嗎?

是的,在許多應(yīng)用程序中都不需要速度層(speed layer)。如果我們縮短批處理周期,則可以減少數(shù)據(jù)可用性中的延遲。另一方面,用于訪問存儲(chǔ)在 Hadoop 上的數(shù)據(jù)的新的更快的工具(例如 Impala , Drill 或 Tez 的新版本等),使在合理時(shí)間內(nèi)對數(shù)據(jù)執(zhí)行某些操作成為可能。

我們可以丟棄批處理層(batch layer)并處理速度層(speed layer)中的所有內(nèi)容嗎?

是的,一個(gè)例子是 Kappa Kreps 架構(gòu),它的示例建議在流中處理傳入的數(shù)據(jù),并且每當(dāng)需要更大的歷史記錄時(shí),它將從 Kafka 緩沖區(qū)中重新流化,或者如果我們必須進(jìn)一步追溯到歷史數(shù)據(jù)集群。

如何實(shí)現(xiàn) Lambda 架構(gòu)?

我們可以使用 Hadoop 數(shù)據(jù)湖在現(xiàn)實(shí)世界中實(shí)現(xiàn)此架構(gòu),在該數(shù)據(jù)湖中,HDFS 用于存儲(chǔ)主數(shù)據(jù)集, Spark(或 Storm)可構(gòu)成速度層(speed layer), HBase(或 Cassandra)作為服務(wù)層,由 Hive 創(chuàng)建可查詢的視圖。

Spark 數(shù)據(jù)傾斜及其解決方案

4.png

使用 Lambda 架構(gòu)的公司

Yahoo

為了在廣告數(shù)據(jù)倉庫上進(jìn)行分析,雅虎采取了類似的方法,也使用了 Apache Storm,Apache Hadoop 和 Druid2。

Netflix

Netflix Suro 項(xiàng)目是 Netflix 數(shù)據(jù)管道的主干,該管道有獨(dú)立的數(shù)據(jù)處理路徑,但不嚴(yán)格遵循 lambda 體系結(jié)構(gòu),因?yàn)檫@些路徑可能用于不同的目的,不一定提供相同類型的視圖(views)。

LinkedIn

使用 Apache Calcite 來橋接離線和近線計(jì)算。

總結(jié)

請記住: batch view = function (all data) realtime view = function (real-time view new data) and query = function (batch view real-time view).

很容易,對吧?

參考文獻(xiàn)

[1] nathanmarz.com/blog/how-to…

[2] www.slideshare.net/Hadoop_Summ…

[3] netflixtechblog.com/announcing-…

原文地址:

Big Data: Lambda Architecture in a nutshell

原文作者:

Trung Anh Dang

譯文出自:

掘金翻譯計(jì)劃

本文永久鏈接:

github.com/xitu/gold-m…

譯者:

jackwener

校對者:

zenblo、bljessica

轉(zhuǎn)自:https://juejin.cn/post/6887845604886741006

THEEND

最新評(píng)論(評(píng)論僅代表用戶觀點(diǎn))

更多
暫無評(píng)論