1.概述
Hadoop已被公認(rèn)為大數(shù)據(jù)分析領(lǐng)域無可爭(zhēng)辯的王者，它專注與批處理。這種模型對(duì)許多情形(比如：為網(wǎng)頁建立索引)已經(jīng)足夠，但還存在其他一些使用模型，它們需要來自高度動(dòng)態(tài)的來源的實(shí)時(shí)信息。為了解決這個(gè)問題，就得借助Twitter推出得Storm。Storm不處理靜態(tài)數(shù)據(jù)，但它處理預(yù)計(jì)會(huì)連續(xù)的流數(shù)據(jù)。考慮到 Twitter用戶每天生成1.4億條推文，那么就很容易看到此技術(shù)的巨大用途。
但Storm不只是一個(gè)傳統(tǒng)的大數(shù)據(jù)分析系統(tǒng)：它是復(fù)雜事件處理(CEP)系統(tǒng)的一個(gè)示例。CEP系統(tǒng)通常分類為計(jì)算和面向檢測(cè)，其中每個(gè)系統(tǒng)都是通過用戶定義的算法在Storm中實(shí)現(xiàn)。舉例而言，CEP可用于識(shí)別事件洪流中有意義的事件，然后實(shí)時(shí)的處理這些事件。
2.為什么Hadoop不適合實(shí)時(shí)計(jì)算這里說的不適合,是一個(gè)相對(duì)的概念。如果業(yè)務(wù)對(duì)時(shí)延要求較低,那么這個(gè) 問題就不存在了;但事實(shí)上企業(yè)中的有些業(yè)務(wù)要求是對(duì)時(shí)延有高要求的。下面我 就來說說:
2.1時(shí)延Storm 的網(wǎng)絡(luò)直傳與內(nèi)存計(jì)算,其時(shí)延必然比 Hadoop 的 HDFS 傳輸?shù)偷枚?當(dāng)計(jì)算模型比較適合流式時(shí),Storm 的流試處理,省去了批處理的收集數(shù)據(jù)的時(shí) 間;因?yàn)?Storm 是服務(wù)型的作業(yè),也省去了作業(yè)調(diào)度的時(shí)延。所以從時(shí)延的角 度來看,Storm 要快于 Hadoop,因而 Storm 更適合做實(shí)時(shí)流水?dāng)?shù)據(jù)處理。下面用一個(gè)業(yè)務(wù)場(chǎng)景來描述這個(gè)時(shí)延問題。
2.1.1業(yè)務(wù)場(chǎng)景幾千個(gè)日志生產(chǎn)方產(chǎn)生日志文件,需要對(duì)這些日志文件進(jìn)行一些 ETL 操作存 入數(shù)據(jù)庫(kù)。
我分別用 Hadoop 和 Storm 來分析下這個(gè)業(yè)務(wù)場(chǎng)景。假設(shè)我們用 Hadoop 來 處理這個(gè)業(yè)務(wù)流程,則需要先存入 HDFS,按每一分鐘(達(dá)不到秒級(jí)別,分鐘是最小緯度)切一個(gè)文件的粒度來計(jì)算。這個(gè)粒度已經(jīng)極端的細(xì)了,再小的話 HDFS 上會(huì)一堆小文件。接著 Hadoop 開始計(jì)算時(shí),一分鐘已經(jīng)過去了,然后再開始 調(diào)度任務(wù)又花了一分鐘,然后作業(yè)運(yùn)行起來,假設(shè)集群比較大,幾秒鐘就計(jì)算完 成了,然后寫數(shù)據(jù)庫(kù)假設(shè)也花了很少時(shí)間(理想狀況下);這樣,從數(shù)據(jù)產(chǎn)生到 最后可以使用已經(jīng)過去了至少兩分多鐘。
而我們來看看流式計(jì)算則是數(shù)據(jù)產(chǎn)生時(shí),則有一個(gè)程序一直監(jiān)控日志的產(chǎn)生, 產(chǎn)生一行就通過一個(gè)傳輸系統(tǒng)發(fā)給流式計(jì)算系統(tǒng),然后流式計(jì)算系統(tǒng)直接處理, 處理完之后直接寫入數(shù)據(jù)庫(kù),每條數(shù)據(jù)從產(chǎn)生到寫入數(shù)據(jù)庫(kù),在資源充足(集群 較大)時(shí)可以在毫秒級(jí)別完成。
2.1.2吞吐在吞吐量方面,Hadoop 卻是比 Storm 有優(yōu)勢(shì);由于 Hadoop 是一個(gè)批處理計(jì)算,相比 Storm 的流式處理計(jì)算,Hadoop 的吞吐量高于 Storm。
2.2應(yīng)用領(lǐng)域Hadoop 是基于 MapReduce 模型的,處理海量數(shù)據(jù)的離線分析工具,而 Storm是分布式的,實(shí)時(shí)數(shù)據(jù)流分析工具,數(shù)據(jù)是源源不斷產(chǎn)生的,比如:Twitter 的 Timeline。另外,M/R 模型在實(shí)時(shí)領(lǐng)域很難有所發(fā)揮,它自身的設(shè)計(jì)特點(diǎn)決定了 數(shù)據(jù)源必須是靜態(tài)的。
2.3硬件Hadoop 是磁盤級(jí)計(jì)算,進(jìn)行計(jì)算時(shí),數(shù)據(jù)在磁盤上,需要讀寫磁盤;Storm是內(nèi)存級(jí)計(jì)算,數(shù)據(jù)直接通過網(wǎng)絡(luò)導(dǎo)入內(nèi)存。讀寫內(nèi)存比讀寫磁盤速度快 N 個(gè) 數(shù)量級(jí)。根據(jù)行業(yè)結(jié)論,磁盤訪問延遲約為內(nèi)存訪問延遲的 7.5w 倍,所以從這 個(gè)方面也可以看出,Storm 從速度上更快。
3.詳細(xì)分析在分析之前,我們先看看兩種計(jì)算框架的模型，首先我們看下MapReduce的模型，以WordCount為例，如下圖所示：
閱讀過Hadoop源碼下的hadoop-mapreduce-project工程中的代碼應(yīng)該對(duì)這個(gè)流程會(huì)熟悉，我這里就不贅述這個(gè)流程了。
接著我們?cè)趤砜聪耂torm的模型，如下圖所示：
然后下面我們就會(huì)涉及到2個(gè)指標(biāo)問題：延時(shí)和吞吐。
延時(shí):指數(shù)據(jù)從產(chǎn)生到運(yùn)算產(chǎn)生結(jié)果的時(shí)間。與“速度”息息相關(guān)。吞吐:指系統(tǒng)單位時(shí)間處理的數(shù)據(jù)量。另外,在資源相同的情況下;一般 Storm 的延時(shí)要低于 MapReduce,但是
吞吐吞吐也要低于 MapReduce,下面我描述下流計(jì)算和批處理計(jì)算的流程。 整個(gè)數(shù)據(jù)處理流程來說大致可以分為三個(gè)階段:
1. 數(shù)據(jù)采集階段
2. 數(shù)據(jù)計(jì)算(涉及計(jì)算中的中間存儲(chǔ))
3. 數(shù)據(jù)結(jié)果展現(xiàn)(反饋)
3.1.1數(shù)據(jù)采集階段目前典型的處理策略:數(shù)據(jù)的產(chǎn)生系統(tǒng)一般出自 Web 日志和解析 DB 的 Log,流計(jì)算數(shù)據(jù)采集是獲取的消息隊(duì)列(如:Kafka,RabbitMQ)等。批處理系統(tǒng)一 般將數(shù)據(jù)采集到分布式文件系統(tǒng)(如:HDFS),當(dāng)然也有使用消息隊(duì)列的。我們 暫且把消息隊(duì)列和文件系統(tǒng)稱為預(yù)處理存儲(chǔ)。二者在這個(gè)階段的延時(shí)和吞吐上沒 太大的區(qū)別,接下來從這個(gè)預(yù)處理存儲(chǔ)到數(shù)據(jù)計(jì)算階段有很大的區(qū)別。流計(jì)算一 般在實(shí)時(shí)的讀取消息隊(duì)列進(jìn)入流計(jì)算系統(tǒng)(Storm)的數(shù)據(jù)進(jìn)行運(yùn)算,批處理系 統(tǒng)一般回累計(jì)大批數(shù)據(jù)后,批量導(dǎo)入到計(jì)算系統(tǒng)(Hadoop),這里就有了延時(shí)的 區(qū)別。
3.1.2數(shù)據(jù)計(jì)算階段流計(jì)算系統(tǒng)(Storm)的延時(shí)主要有以下幾個(gè)方面:
Storm 進(jìn)程是常駐的,有數(shù)據(jù)就可以進(jìn)行實(shí)時(shí)的處理。MapReduce 數(shù)據(jù)累 計(jì)一批后由作業(yè)管理系統(tǒng)啟動(dòng)任務(wù),Jobtracker 計(jì)算任務(wù)分配,Tasktacker 啟動(dòng)相關(guān)的運(yùn)算進(jìn)程。
Storm 每個(gè)計(jì)算單元之間數(shù)據(jù)通過網(wǎng)絡(luò)(ZeroMQ)直接傳輸。MapReduce Map 任務(wù)運(yùn)算的結(jié)果要寫入到 HDFS,在 Reduce 任務(wù)通過網(wǎng)絡(luò)拖過去運(yùn)算。 相對(duì)來說多了磁盤讀寫,比較慢。
對(duì)于復(fù)雜運(yùn)算,Storm的運(yùn)算模型直接支持DAG(有向無環(huán)圖,多個(gè)應(yīng)用程 序存在依賴關(guān)系,后一個(gè)應(yīng)用程序的 輸入為前一個(gè)的輸出),MapReduce 需 要多個(gè) MR 過程組成,而且有些 Map 操作沒有意義。
3.1.3數(shù)據(jù)展現(xiàn)流計(jì)算一般運(yùn)算結(jié)果直接反饋到最終結(jié)果集中(展示頁面,數(shù)據(jù)庫(kù),搜索引擎的索引)。而 MapReduce 一般需要整個(gè)運(yùn)算結(jié)束后將結(jié)果批量導(dǎo)入到結(jié)果集中。
4.總結(jié)Storm 可以方便的在一個(gè)計(jì)算機(jī)集群中編寫與擴(kuò)展復(fù)雜的實(shí)時(shí)計(jì)算,Storm 之于實(shí)時(shí),就好比 Hadoop 之于批處理。Storm 保證每個(gè)消息都會(huì)得到處理,而 且速度很快,在一個(gè)小集群中,每秒可以處理數(shù)以百萬計(jì)的消息。
Storm 的主要特點(diǎn)如下:
簡(jiǎn)單的編程模型。類似于MR降低了并行批處理的復(fù)雜行,Storm降低了實(shí)時(shí)處理的復(fù)雜行。
可以使用各種編程語言。只要遵守實(shí)現(xiàn)Storm的通信協(xié)議即可。
容錯(cuò)性。Storm會(huì)管理工作進(jìn)程和節(jié)點(diǎn)故障。
水平擴(kuò)展。計(jì)算是在多個(gè)線程,進(jìn)程和服務(wù)器之間并行進(jìn)行的。
可靠的消息處理。Storm保證每個(gè)消息至少能得到處理一次完整的處理,使用 MQ 作為其底層消息隊(duì)列。
本地模式。Storm 有一個(gè)“本地模式”,可以在處理過程中完全模擬Storm集群。這讓你可以快速進(jìn)行開發(fā)和單元測(cè)試。
最后總結(jié)出:Hadoop 的 MR 基于 HDFS,需要切分輸入數(shù)據(jù),產(chǎn)生中間數(shù)據(jù)文件,排序,數(shù)據(jù)壓縮,多分復(fù)制等,效率地下。而 Storm 基于 ZeroMQ 這個(gè)高 性能的消息通訊庫(kù),不能持久化數(shù)據(jù)。這篇文章就分享到這里，若有疑問，可以加入QQ群或發(fā)送郵件給我，我會(huì)盡我所能給予幫助，與君共勉！
Ubuntu14.04下Hadoop2.4.1單機(jī)/偽分布式安裝配置教程 http://www.linuxidc.com/Linux/2015-02/113487.htm
CentOS安裝和配置Hadoop2.2.0 http://www.linuxidc.com/Linux/2014-01/94685.htm
Ubuntu 13.04上搭建Hadoop環(huán)境 http://www.linuxidc.com/Linux/2013-06/86106.htm
Ubuntu 12.10 +Hadoop 1.2.1版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm
Ubuntu上搭建Hadoop環(huán)境（單機(jī)模式+偽分布模式） http://www.linuxidc.com/Linux/2013-01/77681.htm
Ubuntu下Hadoop環(huán)境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm
單機(jī)版搭建Hadoop環(huán)境圖文教程詳解 http://www.linuxidc.com/Linux/2012-02/53927.htm
搭建Hadoop環(huán)境（在Winodws環(huán)境下用虛擬機(jī)虛擬兩個(gè)Ubuntu系統(tǒng)進(jìn)行搭建） http://www.linuxidc.com/Linux/2011-12/48894.htm
京公網(wǎng)安備 11010502049343號(hào)