Apache Hadoop準實時數(shù)據(jù)處理的架構(gòu)模式

Ted Malaska 譯：Robin robinlee@cmu.edu

原文地址：Architectural Patterns for Near Real-Time Data Processing with Apache Hadoop

本文由 董飛老師翻譯并投稿至36大數(shù)據(jù)，轉(zhuǎn)載必須獲得原文作者、譯者和本站的同意。拒絕任何不標明作者和出處的轉(zhuǎn)載。

進入董飛先生 在36大數(shù)據(jù)的專欄>>>

評估好哪一種流架構(gòu)模式最適合你的案例，是成功生產(chǎn)開發(fā)的先決條件。

Apache Hadoop 生態(tài)系統(tǒng)已成為企業(yè)實時地處理和挖掘大數(shù)據(jù)的首選。 Apache的Kafka， Flume， Spark， Storm， Samza等技術在不斷地推進新的可能。人們很容易泛化大規(guī)模實時數(shù)據(jù)案例，但其實他們可以細分為幾種架構(gòu)模式，Apache系統(tǒng)里的不同組件適合于不同的案例。

這篇文章探討四種主要的設計模式，案例來自于我們企業(yè)客戶的數(shù)據(jù)中心的實例，并解釋如何在Hadoop上實現(xiàn)這些架構(gòu)模式。

流處理模式

四種流模式（經(jīng)常串聯(lián)使用）為：

流采集：低延遲將數(shù)據(jù)輸入到HDFS，Apache HBase和Apache Solr。

基于外部環(huán)境的準實時事件處理： 對事件采取警報，標示，轉(zhuǎn)化，過濾等動作。這些動作的觸發(fā)可能取決于復雜的標準，例如異常監(jiān)測模型。通常的使用案例，例如準實時的欺詐監(jiān)測和推薦系統(tǒng)，需要達到100毫秒以內(nèi)的延遲。

準實時事件分割處理：類似于準實時事件處理，但通過將數(shù)據(jù)分割獲得一些好處—例如將更多相關外部信息存入內(nèi)存。這個模式也要求延遲在100毫秒以內(nèi)。

為整合或機器學習使用的復雜拓撲結(jié)構(gòu)：流處理的精髓：實時地通過復雜而靈活的操作從數(shù)據(jù)中獲取答案。這里，因為結(jié)果通常依賴于一段窗口內(nèi)的計算，需要更多的活躍的數(shù)據(jù)， 于是重點從獲得超低延遲轉(zhuǎn)移到了功能性和準確性。

接下來，我們將介紹如何用可檢測的，可被證明的和可維護的方式來實現(xiàn)這些設計模式。

流采集

傳統(tǒng)上，F(xiàn)lume是最為推薦的流采集系統(tǒng)。它的大的源和池囊括了所有關于消費什么和寫到哪里的基礎（關于如何配置和管理flume，參考Using Flume，由O’Reilly 出版的Cloudera工程師/Flume 項目管理委員會成員Hari Shreedharan編寫）。

Figure 1譯者附：Flume架構(gòu)

在過去的一年中，Kafka也變得非常受歡迎，因為playback和replication等特性。由于Flume和Kafka有重疊的目標，他們的關系常常令人困惑。他們?nèi)绾闻浜?？答案是簡單的：Kafka的管道和Flume的通道類似，雖然是一個更好的管道，原因就是剛才所述的特性。一個通行的方法就是用Flume作為源(source)和池(sink)，而Kafka是他們中間的管道。

下圖闡明kafka如何作為Flume的上游數(shù)據(jù)和下游目的，或Flume管道。

下圖的設計是具有大規(guī)模拓展性，經(jīng)過實戰(zhàn)檢驗的架構(gòu)設計，由Cloudera 管理者監(jiān)控，容錯，并且支持回放。

值得注意的一件事就是，這個設計多么優(yōu)雅地處理故障。Flume 池從Kafka消費者群里取回。通過Apache zookeeper的幫助，Kafka 消費者群取回topic的位移。如果一個Flume池發(fā)生故障，Kafka消費者將把負載重新分發(fā)到其他的池中。當那個池恢復了，消費者池將重新分發(fā)。

基于外部環(huán)境的準實時事件處理

重申一下，這個模式的適用案例通常是觀察事件流入然后采取立即動作，可以是轉(zhuǎn)化數(shù)據(jù)或一些外部操作。決策的邏輯依賴于外部的檔案或元數(shù)據(jù)。一個簡單并且可拓展的實現(xiàn)方法是，在你的Kafka/Flume架構(gòu)中添加源（Source）或池（Sink）Flume攔截器。只需簡單配置，不難達到低毫秒級延遲。

Flume攔截器允許用戶的代碼對事件或批量事件進行修改或采取動作。用戶代碼可以與本地內(nèi)存或外部Hbase交互，以獲取決策需要的檔案。Hbase通常可以4-25毫秒內(nèi)給予我們信息，根據(jù)網(wǎng)絡狀況，模式概要，設計和配置而有所不同。你也可以將Hbase配置為永遠不停止服務或被中斷，即便在故障情況下。

這一設計的實現(xiàn)除了攔截器中應用的具體邏輯幾乎不需要編程。Cloudera管理器提供直觀的用戶界面，可以部署這個邏輯，包括連結(jié)，配置，監(jiān)測這一服務。

準實時基于外部環(huán)境的分割化的事件處理

下圖的架構(gòu)（未分割方案），你將需要頻繁查詢Hbase，因為針對某一事件的外部上下文環(huán)境在flume攔截器的本地內(nèi)存中裝不下。

但是，如果你定義一個鍵值來分割數(shù)據(jù)，你將可以把數(shù)據(jù)流匹配到相關上下文的一個子集。如果你將數(shù)據(jù)分割成十部分，那么你只需要將十分之一的檔案放入內(nèi)存里。 Hbase是快，但本地內(nèi)存更快。Kafka允許你自定義分割器來分割數(shù)據(jù)。

注意，在這里，F(xiàn)lume并不是必須的；根本的方案只是一個Kafka消費者。所以，你可以只用一個YARN消費者或只有Mapper的MapReduce。

針對集成或機器學習的復雜拓撲

到此為止，我們探索了事件層面的操作。然而，有時你需要更復雜的操作，例如計數(shù)，求平均，會話流程，或基于流數(shù)據(jù)的機器學習建模。在這種情況，Spark流處理是最理想的的工具，因為：

和其他工具相比，Spark易于開發(fā)

Spark豐富簡明的API讓建設復雜拓撲變得容易

實時流處理和批處理的代碼相似

只需很少的修改，實時小量流處理的代碼就可以用于大規(guī)模離線的批處理。不僅減少了代碼量，這個方法減少測試和整合需要的時間。

只需了解一個技術引擎

訓練員工了解一個分布式處理引擎的機制和構(gòu)件是有成本的。使用spark并標準化將會合并流處理和批處理的成本。

微批處理幫你更可靠地進行拓展規(guī)模

在批處理層面的應答將允許更多的吞吐量，允許無需顧忌雙發(fā)的解決方案。微批處理也幫助在大規(guī)模下高效發(fā)送修改到HDFS或Hbase。

與Hadoop生態(tài)系統(tǒng)的集成

Spark與HDFS，Hbase和Kafka有很深的集成。

無丟失數(shù)據(jù)的風險

由于有了WAL和Kafka，Spark流處理避免了故障時丟失數(shù)據(jù)的風險

易于排錯和運行

在本地的IDE中你就可以對你的spark流處理代碼進行排錯和逐步檢查。而且，代碼和普通函數(shù)式程序代碼類似，對Java或Scala程序員來說，無需花很多時間就能熟悉。（Python也支持）

流處理是天然狀態(tài)化的

Spark流處理中，狀態(tài)是“第一公民”，意味著很容易寫基于狀態(tài)的流處理應用，對節(jié)點的故障可恢復。

作為實際的標準，Spark現(xiàn)在正在得到整個生態(tài)系統(tǒng)的長期投入

在寫此文時，spark在30天內(nèi)已有700次左右的提交—和其它框架相比，例如Storm，只有15次的提交。

你可以使用機器學習的庫

Spark的MLlib庫越來越受歡迎，它的功能只會越來越強大。

如果需要，你可使用SQL結(jié)構(gòu)化查詢語言

通過Spark SQL，你可以為你的流處理應用添加SQL邏輯，從而簡化代碼

結(jié)論

流處理和幾種可能的模式有很強大的功能，但正如你在這篇文章所了解，你可以通過了解哪一種設計模式適合你的案例，從而最少量的代碼做非常好的事情。

Ted Malaska是Cloudera解決方案架構(gòu)師，Spark，F(xiàn)lume和Hbase的貢獻者，O’Reilly書籍 《Hadoop 應用架構(gòu)》的合作作者。

End.

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。