市場上很多玩家已經(jīng)建造了MapReduce工作流用來日常處理兆兆字節(jié)的歷史數(shù)據(jù)。但是誰愿意等待24小時來拿到更新后的分析報告?這篇博客會向你介紹Lambda Architecture，它被設計出來既可以利用批量處理方法，也可以使用流式處理方法。這樣我們就可以利用Apache Spark(核心, SQL, 流)，Apache Parquet，Twitter Stream等工具處理實時流式數(shù)據(jù)，實現(xiàn)對歷史數(shù)據(jù)的快速訪問。代碼簡潔干凈，而且附上直接明了的示例!
Apache Hadoop: 簡要歷史
Apache Hadoop的豐富歷史開始于大約2002年。Hadoop是Doug Cutting創(chuàng)立的, 他也是Apache Lucene這一被廣泛使用的文本檢索庫的創(chuàng)造者. Hadoop的起源與Apache Nutch有關, Apache Nutch是一個開源的web搜索引擎, 本身也是Lucene項目的一部分. Apache Nutch在大約10年前成為一個獨立的項目.
事實上,許多用戶實現(xiàn)了成功的基于HadoopM/R的通道,一直運行到現(xiàn)在.現(xiàn)實生活中我至少能舉出好幾個例子:
- Oozie協(xié)調下的工作流每日運行和處理多達8TB數(shù)據(jù)并生成分析報告
- bash管理的工作流每日運行和處理多達8TB數(shù)據(jù)并生成分析報告
現(xiàn)在是2016年了
商業(yè)現(xiàn)實已經(jīng)改變，所以做出長遠的決定變得更有價值。除此以外，技術本身也在演化進步。Kafka, Storm, Trident, Samza, Spark, Flink, Parquet, Avro, Cloud providers等時髦的技術被工程師們和在商業(yè)上廣泛使用.
因此，現(xiàn)代基于Hadoop的 M/R通道 (以及Kafka，現(xiàn)代的二進制形式如Avro和數(shù)據(jù)倉庫等。在本例中Amazon Redshift用作ad-hoc查詢) 可能看起來像這樣:
以上M/R通道看起來很不錯，但是它仍然是傳統(tǒng)上具有許多缺點的批處理。由于在新數(shù)據(jù)不斷進入系統(tǒng)時，批處理過程通常需要花費很多時間來完成，它們主要是提供給終端用戶的乏味的數(shù)據(jù)罷了。
Lambda 架構
Nathan Marz為通用，可擴展和容錯性強的數(shù)據(jù)處理架構想出了一個術語Lambda架構。這個數(shù)據(jù)架構結合了批處理和流處理方法的優(yōu)點來處理大批量數(shù)據(jù)。
我強烈推薦閱讀 Nathan Marz 的書 ，這本書從源碼角度對Lambda架構進行了完美的詮釋。
層結構
從頂層來看，這是層的結構：
所有進入系統(tǒng)的數(shù)據(jù)被分配到了批處理層和高速層來處理。批處理層管理著主數(shù)據(jù)集(一個不可修改，只能新增的原始數(shù)據(jù))和預計算批處理視圖。服務層索引批處理視圖，因此可以對它們進行低延時的臨時查詢。高速層只處理近期的數(shù)據(jù)。任何輸入的查詢結果都合并了批處理視圖和實時視圖的查詢結果。
焦點
許多工程師認為 Lambda架構就包含這些層和定義數(shù)據(jù)流程，但是 Nathan Marz在他的書中把焦點放在了其他重要的地方，如：
- 分布式思想
- 避免增量架構
- 關注數(shù)據(jù)的不可變性
- 創(chuàng)建再計算算法
- 數(shù)據(jù)的相關性
正如前面所提到的，任何輸入的查詢結果都會從批處理視圖和實時視圖的查詢結果返回，因此這些視圖需要被合并。在這里，需要注意的一點是，一個實時視圖是上一個實時視圖和新的數(shù)據(jù)增量的函數(shù)，因此一個增量算法可以在這里使用。批處理視圖是所有數(shù)據(jù)的視圖，因此再計算算法可以在這里使用。
均衡取舍
我們生活中的一切問題都存在權衡，Lambda架構(Lambda Architecture)不例外。 通常，我們需要解決幾個主要的權衡：
完全重新計算vs.部分重新計算
某些情況下，可以考慮使用Bloom過濾器來避免完全重新計算
重算算法 vs. 增量算法
使用增量算法是個很大的誘惑，但參考指南，我們必須使用重算算法，即使它更難得到相同的結果
加法算法 vs. 近似算法