這期內(nèi)容當中小編將會給大家?guī)碛嘘P大數(shù)據(jù)中如何分析Lambda架構(gòu),文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)于2013年成立,先為鏡湖等服務建站,鏡湖等地企業(yè),進行企業(yè)商務咨詢服務。為鏡湖企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。
一致性:
每個節(jié)點讀取的是最新結(jié)果或者是報錯。
可用性:
每個請求都會收到一個(非錯誤)響應,但不保證它包含最新的寫入。
分區(qū)容錯:
盡管節(jié)點之間的網(wǎng)絡丟棄(或延遲了)任意數(shù)量的消息,系統(tǒng)仍繼續(xù)運行。
2011年,內(nèi)森·馬茲(Nathan Marz)在他的博客中提出了一種解決 CAP 定理局限性的重要方法,即 Lambda 架構(gòu)。
讓我們仔細看看 Lambda 架構(gòu)。Lambda 架構(gòu)分為三層: 批處理層(batch layer),加速層(speed layer),和服務層(serving layer)。
它結(jié)合了對同一數(shù)據(jù)的實時(real-time)和批量(batches)處理。
首先,傳入的實時數(shù)據(jù)流在批處理層(batch layer)存儲在主數(shù)據(jù)集中,并在加速層(speed layer)存儲在內(nèi)存緩存中。然后對批處理層中的數(shù)據(jù)建索引,且通過批處理視圖使之可用。加速層(speed layer)中的實時數(shù)據(jù)通過實時視圖(real-time views)暴露出來。最后,批處理視圖和實時視圖都可以獨立查詢,也可以一起查詢,以回答任何歷史的或?qū)崟r的問題。
該層負責管理主數(shù)據(jù)集。主數(shù)據(jù)集中的數(shù)據(jù)必須具有以下三個屬性。
數(shù)據(jù)是原始的
數(shù)據(jù)是不可變的
數(shù)據(jù)永遠是真實的
主數(shù)據(jù)集是正確性的保證(source of truth)。即使丟失所有服務層數(shù)據(jù)集和加速層數(shù)據(jù)集,也可以從主數(shù)據(jù)集中重建應用程序。
批處理層還將主數(shù)據(jù)集預計算到批處理視圖(batch views)中,以便能進行低延遲查詢。
由于我們的主數(shù)據(jù)集在不斷增長,因此我們必須制定一種策略,以便在有新數(shù)據(jù)可用時管理批處理視圖(batch views)。
重新計算法:
拋棄舊的批處理視圖,重新計算整個主數(shù)據(jù)集的函數(shù)。
增量算法:
當新數(shù)據(jù)到達時,直接更新視圖。
加速層批處理視圖建立索引便于能快速的即席查詢(Ad hoc queries),它存儲實時視圖并處理傳入的數(shù)據(jù)流,以便更新這些視圖?;A存儲層必須滿足以下場景。
隨機讀:
支持快速隨機讀取以快速響應查詢。
隨機寫:
為了支持增量算法,必須盡可能的以低延遲修改實時視圖。
可伸縮性:
實時視圖應隨它們存儲的數(shù)據(jù)量和應用程序所需的讀/寫速率進行縮放。
容錯性:
當機器故障,實時視圖應還能繼續(xù)正常運行。
該層提供了主數(shù)據(jù)集上執(zhí)行的計算結(jié)果的低延遲訪問。讀取速度可以通過數(shù)據(jù)附加的索引來加速。與加速層類似,該層也必須滿足以下要求,例如隨機讀取,批量寫入,可伸縮性和容錯能力。
Lambda 體系結(jié)構(gòu)基于幾個假定:容錯、即席查詢、可伸縮性、可擴展性。
容錯: Lambda 架構(gòu)為大數(shù)據(jù)系統(tǒng)提供了更友好的容錯能力,一旦發(fā)生錯誤,我們可以修復算法或從頭開始重新計算視圖。
即席查詢:批處理層允許針對任何數(shù)據(jù)進行臨時查詢。
可伸縮性:所有的批處理層、加速層和服務層都很容易擴展。
因為它們都是完全分布式的系統(tǒng),我們可以通過增加新機器來輕松地擴大規(guī)模。
擴展:添加視圖是容易的,只是給主數(shù)據(jù)集添加幾個新的函數(shù)。
解決此問題的方法之一是通過使用通用庫或引入流之間共享的某種抽象來為各層提供通用代碼庫。譬如 Summingbird or Lambdoop,Casado 這些框架
是的,在許多應用程序中都不需要速度層(speed layer)。如果我們縮短批處理周期,則可以減少數(shù)據(jù)可用性中的延遲。另一方面,用于訪問存儲在 Hadoop 上的數(shù)據(jù)的新的更快的工具(例如 Impala , Drill 或 Tez 的新版本等),使在合理時間內(nèi)對數(shù)據(jù)執(zhí)行某些操作成為可能。
是的,一個例子是 Kappa Kreps 架構(gòu),它的示例建議在流中處理傳入的數(shù)據(jù),并且每當需要更大的歷史記錄時,它將從 Kafka 緩沖區(qū)中重新流化,或者如果我們必須進一步追溯到歷史數(shù)據(jù)集群。
我們可以使用 Hadoop 數(shù)據(jù)湖在現(xiàn)實世界中實現(xiàn)此架構(gòu),在該數(shù)據(jù)湖中,HDFS 用于存儲主數(shù)據(jù)集, Spark(或 Storm)可構(gòu)成速度層(speed layer), HBase(或 Cassandra)作為服務層,由 Hive 創(chuàng)建可查詢的視圖。
Spark 數(shù)據(jù)傾斜及其解決方案
為了在廣告數(shù)據(jù)倉庫上進行分析,雅虎采取了類似的方法,也使用了 Apache Storm,Apache Hadoop 和 Druid2。
Netflix Suro 項目是 Netflix 數(shù)據(jù)管道的主干,該管道有獨立的數(shù)據(jù)處理路徑,但不嚴格遵循 lambda 體系結(jié)構(gòu),因為這些路徑可能用于不同的目的,不一定提供相同類型的視圖(views)。
使用 Apache Calcite 來橋接離線和近線計算。
上述就是小編為大家分享的大數(shù)據(jù)中如何分析Lambda架構(gòu)了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。