本篇內(nèi)容介紹了“Apache Spark的Lambda架構示例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供伊通網(wǎng)站建設、伊通做網(wǎng)站、伊通網(wǎng)站設計、伊通網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、伊通企業(yè)網(wǎng)站模板建站服務，十年伊通做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

Apache Hadoop簡史

Apache Hadoop由 Apache Software Foundation 公司于 2005  年秋天作為Lucene的子項目Nutch的一部分正式引入。它受到***由 Google Lab 開發(fā)的 Map/Reduce 和 Google File  System(GFS) 的啟發(fā)。它成為一個獨立項目的時間已有10年。

目前已經(jīng)有很多客戶實施了基于Hadoop的M / R管道，并成功運行到現(xiàn)在：

Oozie的工作流每日運行處理150TB以上的數(shù)據(jù)并生成分析報告

Bash的工作流每日運行處理8TB以上的數(shù)據(jù)并生成分析報告

2016年來了!

2016年商業(yè)現(xiàn)實發(fā)生了變化，越快做出決策往往價值就會越大。另外，技術本身也在發(fā)展，Kafka，Storm，Trident，Samza，Spark，F(xiàn)link，Parquet，Avro，云提供商等都成為了工程師們的流行語。

因此，現(xiàn)代基于Hadoop的M / R管道可能會是下圖所示的這樣：

圖上的M/R通道看起來不錯，但其實它本質(zhì)上還是一個傳統(tǒng)的批處理，有著傳統(tǒng)批處理的缺點，當新的數(shù)據(jù)源源不斷的進入系統(tǒng)中時，還是需要大量的時間來處理。

Lambda 架構

針對上面的問題，Nathan  Marz提出了一個通用、可擴展和容錯性強的數(shù)據(jù)處理架構即Lambda架構，它是通過利用批處理和流處理方法來處理大量數(shù)據(jù)的。Nathan  Marz的書對從源碼的角度對Lambda架構進行了詳盡的介紹。

層結構

這是Lambda架構自上而下的層結構：

所有數(shù)據(jù)進入系統(tǒng)后都分派到批處理層和速度層進行處理。批處理層管理主數(shù)據(jù)集(一個不可變的，只可增加的原始數(shù)據(jù)集)，并預先計算批處理視圖。  服務層對批視圖進行索引，以便可以進行低延遲的臨時查詢。 速度層僅處理最近的數(shù)據(jù)。所有的查詢結果都必須合并批處理視圖和實時視圖的查詢結果。

要點

許多工程師認為Lambda架構就只包含層結構和定義數(shù)據(jù)流程，但是Nathan Marz的書中為我們介紹了其它幾個比較重要的點：

• 分布式思想

• 避免增量結構

• 數(shù)據(jù)的不變性

• 創(chuàng)建重新計算算法

• 數(shù)據(jù)的相關性

如前所述，任何查詢結果都必須通過合并來自批處理視圖和實時視圖的結果，因此這些視圖必須是可合并的。在這里要注意的一點是，實時視圖是前一個實時視圖和新數(shù)據(jù)增量的函數(shù)，因此這里使用增量算法，批處理視圖是所有數(shù)據(jù)的函數(shù)，因此應該使用重新計算算法。

權衡

世間萬物都是在不斷妥協(xié)和權衡中發(fā)展的，Lambda結構也不例外。通常，我們需要解決幾個主要的權衡：

完全重新計算 vs.部分重新計算

在有些情況下，可以使用Bloom過濾器來避免完全重新計算

重計算算法 vs. 增量算法

增量算法其實很具吸引力，但是有時根據(jù)指南，我們必須使用重計算算法，即便它很難得到相同的結果

加法算法 vs. 近似算法

雖然Lambda架構能夠與加法算法很好地協(xié)同工作，但是在有些情況下更適合使用近似算法，例如使用HyperLogLog處理count-distinct問題。

實現(xiàn)

實現(xiàn)Lambda架構的方法有很多，因為每個層的底層解決方案是獨立的。每個層需要底層實現(xiàn)的特定功能，有助于做出更好的選擇并避免過度決策：

• 批量層：一次寫入，批量讀取多次

• 服務層：支持隨機讀取但不支持隨機寫入; 批量計算和批量寫入

• 速度層：隨機讀寫; 增量計算

例如，其中一個實現(xiàn)(使用Kafka，Apache Hadoop，Voldemort，Twitter Storm，Cassandra)可能如下所示：

Apache Spark

Apache Spark被視為在所有Lambda架構層上進行處理的集成解決方案。 其中Spark  Core包含了高級API和支持常規(guī)執(zhí)行圖的優(yōu)化引擎，SparkSQL用于SQL和結構化數(shù)據(jù)處理，Spark  Streaming支持實時數(shù)據(jù)流的可擴展，高吞吐量，容錯流處理。  當然，使用Spark進行批處理的價格可能比較高，而且也不是所有的場景和數(shù)據(jù)都適合。但是，總體來說Apache Spark是對Lambda架構的合理實現(xiàn)。

示例應用

我們創(chuàng)建一個示例應用程序來演示Lambda架構。這個示例的主要目的統(tǒng)計從某個時刻到現(xiàn)在此刻的#morningatlohika  tweets哈希標簽。

批處理視圖

為了簡單起見，假設我們的主數(shù)據(jù)集包含自時間開始以來的所有tweets。  此外，我們實現(xiàn)了一個批處理，創(chuàng)建了我們的業(yè)務目標所需的批處理視圖，因此我們有一個預計算的批處理視圖，其中包含與#morningatlohika一起使用的所有主題標記的統(tǒng)計信息：

因為數(shù)字方便記憶，所以我使用對應標簽的英文單詞的字母數(shù)目作為編號。

實時視圖

當應用程序啟動并運行時，有人發(fā)出了如下的tweet:

在這種情況下，正確的實時視圖應包含以下標簽及其統(tǒng)計信息(在我們的示例中為1，因為相應的hash標簽只使用了一次)：

查詢

當終端用戶查詢hash標簽的統(tǒng)計結果時，我們只需要將批量視圖與實時視圖合并起來。 所以輸出應該如下所示：

場景

示例場景的簡化步驟如下：

• 通過Apache Spark創(chuàng)建批處理視圖(.parquet)

• 在Apache Spark中緩存批處理視圖

• 流應用程序連接到Twitter

• 實時監(jiān)控#morningatlohika tweets

• 構建增量實時視圖

• 查詢，即合并批處理視圖和實時視圖

技術細節(jié)

源代碼基于Apache Spark 1.6.x，(在引入結構化流之前)。 Spark Streaming架構是純微型批處理架構：

所以處理流應用程序時，我使用DStream連接使用TwitterUtils的Twitter：

在每個微批次(使用可配置的批處理間隔)，對新的tweets中hashtags的統(tǒng)計信息的計算，并使用updateStateByKey()狀態(tài)轉(zhuǎn)換函數(shù)更新實時視圖的狀態(tài)。  為了簡單起見，使用臨時表將實時視圖存儲在存儲器中。

查詢服務反映批處理和實時視圖的合并：

輸出

文章開頭提到的基于Hadoop的M/R管道使用Apache Spark來優(yōu)化：

后記：

正如之前提到的Lambda Architecture有其優(yōu)點和缺點，所以支持者和反對者都有。  有些人說批處理視圖和實時視圖有很多重復的邏輯，因為最終他們需要從查詢角度創(chuàng)建可合并的視圖。 所以他們創(chuàng)建了一個Kappa架構，并稱其為Lambda架構的簡化版。  Kappa架構系統(tǒng)是刪除了批處理系統(tǒng)，取而代之的是通過流系統(tǒng)快速提供數(shù)據(jù)：

但即使在這種情況下，Kappa Architecture中也可以應用Apache Spark，例如流處理系統(tǒng)：

“Apache Spark的Lambda架構示例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！