Ted Malaska 譯：Robin robinlee@cmu.edu
原文地址：Architectural Patterns for Near Real-Time Data Processing with Apache Hadoop
本文由 董飛老師翻譯并投稿至36大數(shù)據(jù)，轉(zhuǎn)載必須獲得原文作者、譯者和本站的同意。拒絕任何不標(biāo)明作者和出處的轉(zhuǎn)載。
進(jìn)入董飛先生 在36大數(shù)據(jù)的專欄>>>
評(píng)估好哪一種流架構(gòu)模式最適合你的案例，是成功生產(chǎn)開發(fā)的先決條件。
Apache Hadoop 生態(tài)系統(tǒng)已成為企業(yè)實(shí)時(shí)地處理和挖掘大數(shù)據(jù)的首選。 Apache的Kafka， Flume， Spark， Storm， Samza等技術(shù)在不斷地推進(jìn)新的可能。人們很容易泛化大規(guī)模實(shí)時(shí)數(shù)據(jù)案例，但其實(shí)他們可以細(xì)分為幾種架構(gòu)模式，Apache系統(tǒng)里的不同組件適合于不同的案例。
這篇文章探討四種主要的設(shè)計(jì)模式，案例來自于我們企業(yè)客戶的數(shù)據(jù)中心的實(shí)例，并解釋如何在Hadoop上實(shí)現(xiàn)這些架構(gòu)模式。
流處理模式
四種流模式（經(jīng)常串聯(lián)使用）為：
流采集：低延遲將數(shù)據(jù)輸入到HDFS，Apache HBase和Apache Solr。
基于外部環(huán)境的準(zhǔn)實(shí)時(shí)事件處理： 對(duì)事件采取警報(bào)，標(biāo)示，轉(zhuǎn)化，過濾等動(dòng)作。這些動(dòng)作的觸發(fā)可能取決于復(fù)雜的標(biāo)準(zhǔn)，例如異常監(jiān)測模型。通常的使用案例，例如準(zhǔn)實(shí)時(shí)的欺詐監(jiān)測和推薦系統(tǒng)，需要達(dá)到100毫秒以內(nèi)的延遲。
準(zhǔn)實(shí)時(shí)事件分割處理：類似于準(zhǔn)實(shí)時(shí)事件處理，但通過將數(shù)據(jù)分割獲得一些好處—例如將更多相關(guān)外部信息存入內(nèi)存。這個(gè)模式也要求延遲在100毫秒以內(nèi)。
為整合或機(jī)器學(xué)習(xí)使用的復(fù)雜拓?fù)浣Y(jié)構(gòu)：流處理的精髓：實(shí)時(shí)地通過復(fù)雜而靈活的操作從數(shù)據(jù)中獲取答案。這里，因?yàn)榻Y(jié)果通常依賴于一段窗口內(nèi)的計(jì)算，需要更多的活躍的數(shù)據(jù)， 于是重點(diǎn)從獲得超低延遲轉(zhuǎn)移到了功能性和準(zhǔn)確性。
接下來，我們將介紹如何用可檢測的，可被證明的和可維護(hù)的方式來實(shí)現(xiàn)這些設(shè)計(jì)模式。
流采集
傳統(tǒng)上，F(xiàn)lume是最為推薦的流采集系統(tǒng)。它的大的源和池囊括了所有關(guān)于消費(fèi)什么和寫到哪里的基礎(chǔ)（關(guān)于如何配置和管理flume，參考Using Flume，由O’Reilly 出版的Cloudera工程師/Flume 項(xiàng)目管理委員會(huì)成員Hari Shreedharan編寫）。
Figure 1譯者附：Flume架構(gòu)
在過去的一年中，Kafka也變得非常受歡迎，因?yàn)閜layback和replication等特性。由于Flume和Kafka有重疊的目標(biāo)，他們的關(guān)系常常令人困惑。他們?nèi)绾闻浜?？答案是簡單的：Kafka的管道和Flume的通道類似，雖然是一個(gè)更好的管道，原因就是剛才所述的特性。一個(gè)通行的方法就是用Flume作為源(source)和池(sink)，而Kafka是他們中間的管道。
下圖闡明kafka如何作為Flume的上游數(shù)據(jù)和下游目的，或Flume管道。
下圖的設(shè)計(jì)是具有大規(guī)模拓展性，經(jīng)過實(shí)戰(zhàn)檢驗(yàn)的架構(gòu)設(shè)計(jì)，由Cloudera 管理者監(jiān)控，容錯(cuò)，并且支持回放。
值得注意的一件事就是，這個(gè)設(shè)計(jì)多么優(yōu)雅地處理故障。Flume 池從Kafka消費(fèi)者群里取回。通過Apache zookeeper的幫助，Kafka 消費(fèi)者群取回topic的位移。如果一個(gè)Flume池發(fā)生故障，Kafka消費(fèi)者將把負(fù)載重新分發(fā)到其他的池中。當(dāng)那個(gè)池恢復(fù)了，消費(fèi)者池將重新分發(fā)。
基于外部環(huán)境的準(zhǔn)實(shí)時(shí)事件處理
重申一下，這個(gè)模式的適用案例通常是觀察事件流入然后采取立即動(dòng)作，可以是轉(zhuǎn)化數(shù)據(jù)或一些外部操作。決策的邏輯依賴于外部的檔案或元數(shù)據(jù)。一個(gè)簡單并且可拓展的實(shí)現(xiàn)方法是，在你的Kafka/Flume架構(gòu)中添加源（Source）或池（Sink）Flume攔截器。只需簡單配置，不難達(dá)到低毫秒級(jí)延遲。
Flume攔截器允許用戶的代碼對(duì)事件或批量事件進(jìn)行修改或采取動(dòng)作。用戶代碼可以與本地內(nèi)存或外部Hbase交互，以獲取決策需要的檔案。Hbase通?？梢?-25毫秒內(nèi)給予我們信息，根據(jù)網(wǎng)絡(luò)狀況，模式概要，設(shè)計(jì)和配置而有所不同。你也可以將Hbase配置為永遠(yuǎn)不停止服務(wù)或被中斷，即便在故障情況下。
這一設(shè)計(jì)的實(shí)現(xiàn)除了攔截器中應(yīng)用的具體邏輯幾乎不需要編程。Cloudera管理器提供直觀的用戶界面，可以部署這個(gè)邏輯，包括連結(jié)，配置，監(jiān)測這一服務(wù)。
準(zhǔn)實(shí)時(shí)基于外部環(huán)境的分割化的事件處理
下圖的架構(gòu)（未分割方案），你將需要頻繁查詢Hbase，因?yàn)獒槍?duì)某一事件的外部上下文環(huán)境在flume攔截器的本地內(nèi)存中裝不下。
但是，如果你定義一個(gè)鍵值來分割數(shù)據(jù)，你將可以把數(shù)據(jù)流匹配到相關(guān)上下文的一個(gè)子集。如果你將數(shù)據(jù)分割成十部分，那么你只需要將十分之一的檔案放入內(nèi)存里。 Hbase是快，但本地內(nèi)存更快。Kafka允許你自定義分割器來分割數(shù)據(jù)。
注意，在這里，F(xiàn)lume并不是必須的；根本的方案只是一個(gè)Kafka消費(fèi)者。所以，你可以只用一個(gè)YARN消費(fèi)者或只有Mapper的MapReduce。
針對(duì)集成或機(jī)器學(xué)習(xí)的復(fù)雜拓?fù)?/b>
到此為止，我們探索了事件層面的操作。然而，有時(shí)你需要更復(fù)雜的操作，例如計(jì)數(shù)，求平均，會(huì)話流程，或基于流數(shù)據(jù)的機(jī)器學(xué)習(xí)建模。在這種情況，Spark流處理是最理想的的工具，因?yàn)椋?/p>
和其他工具相比，Spark易于開發(fā)
Spark豐富簡明的API讓建設(shè)復(fù)雜拓?fù)渥兊萌菀?/p>
實(shí)時(shí)流處理和批處理的代碼相似
只需很少的修改，實(shí)時(shí)小量流處理的代碼就可以用于大規(guī)模離線的批處理。不僅減少了代碼量，這個(gè)方法減少測試和整合需要的時(shí)間。
只需了解一個(gè)技術(shù)引擎
訓(xùn)練員工了解一個(gè)分布式處理引擎的機(jī)制和構(gòu)件是有成本的。使用spark并標(biāo)準(zhǔn)化將會(huì)合并流處理和批處理的成本。
微批處理幫你更可靠地進(jìn)行拓展規(guī)模
在批處理層面的應(yīng)答將允許更多的吞吐量，允許無需顧忌雙發(fā)的解決方案。微批處理也幫助在大規(guī)模下高效發(fā)送修改到HDFS或Hbase。
與Hadoop生態(tài)系統(tǒng)的集成
Spark與HDFS，Hbase和Kafka有很深的集成。
無丟失數(shù)據(jù)的風(fēng)險(xiǎn)
由于有了WAL和Kafka，Spark流處理避免了故障時(shí)丟失數(shù)據(jù)的風(fēng)險(xiǎn)
易于排錯(cuò)和運(yùn)行
在本地的IDE中你就可以對(duì)你的spark流處理代碼進(jìn)行排錯(cuò)和逐步檢查。而且，代碼和普通函數(shù)式程序代碼類似，對(duì)Java或Scala程序員來說，無需花很多時(shí)間就能熟悉。（Python也支持）
流處理是天然狀態(tài)化的
Spark流處理中，狀態(tài)是“第一公民”，意味著很容易寫基于狀態(tài)的流處理應(yīng)用，對(duì)節(jié)點(diǎn)的故障可恢復(fù)。
作為實(shí)際的標(biāo)準(zhǔn)，Spark現(xiàn)在正在得到整個(gè)生態(tài)系統(tǒng)的長期投入
在寫此文時(shí)，spark在30天內(nèi)已有700次左右的提交—和其它框架相比，例如Storm，只有15次的提交。
你可以使用機(jī)器學(xué)習(xí)的庫
Spark的MLlib庫越來越受歡迎，它的功能只會(huì)越來越強(qiáng)大。
如果需要，你可使用SQL結(jié)構(gòu)化查詢語言
通過Spark SQL，你可以為你的流處理應(yīng)用添加SQL邏輯，從而簡化代碼
結(jié)論
流處理和幾種可能的模式有很強(qiáng)大的功能，但正如你在這篇文章所了解，你可以通過了解哪一種設(shè)計(jì)模式適合你的案例，從而最少量的代碼做非常好的事情。
Ted Malaska是Cloudera解決方案架構(gòu)師，Spark，F(xiàn)lume和Hbase的貢獻(xiàn)者，O’Reilly書籍 《Hadoop 應(yīng)用架構(gòu)》的合作作者。
End.
- 蜜度索驥：以跨模態(tài)檢索技術(shù)助力“企宣”向上生長
- 春運(yùn)搶票有妙招，小米SU7限量版洋紅版閃亮登場，你準(zhǔn)備好了嗎？
- 阿里云通義千問視覺理解模型再降80%，視覺AI進(jìn)入新紀(jì)元
- 騰訊音樂集團(tuán)侵權(quán)風(fēng)波再起：中國音樂著作權(quán)協(xié)會(huì)再勝訴
- 蘋果新Magic Mouse 3重新設(shè)計(jì)充電口，不再“神秘”，究竟能否打破常規(guī)引人關(guān)注
- 日本車企11月產(chǎn)量受新能源沖擊，行業(yè)整合能否破局？
- XR設(shè)備市場風(fēng)向轉(zhuǎn)變：AR崛起，VR熱度不減
- 全球用戶聯(lián)手抵制微軟：自由軟件基金會(huì)呼吁持續(xù)施壓
- 王騰雙喜臨門：小米中國區(qū)重磅晉升，REDMI品牌再添新翼
- 蘋果折疊iPhone爆料：未來已來，2026年亮相，預(yù)計(jì)年產(chǎn)1500萬至2000萬臺(tái)
- 小米大家電團(tuán)隊(duì)遷址武漢，科技園F棟開啟新篇章：科技與傳統(tǒng)的完美融合
免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。
