基于Storm和Hadoop的大數(shù)據(jù)處理架構(gòu)的研究

靳永超，吳懷谷

（1.西華大學(xué)數(shù)學(xué)與計(jì)算機(jī)學(xué)院，成都 610039；2.成都大學(xué)信息科學(xué)與技術(shù)學(xué)院，成都 610106）

基于Storm和Hadoop的大數(shù)據(jù)處理架構(gòu)的研究

靳永超1，2，吳懷谷2

（1.西華大學(xué)數(shù)學(xué)與計(jì)算機(jī)學(xué)院，成都 610039；2.成都大學(xué)信息科學(xué)與技術(shù)學(xué)院，成都 610106）

針對(duì)現(xiàn)有的大數(shù)據(jù)技術(shù)Storm和Hadoop，分析其內(nèi)部實(shí)現(xiàn)機(jī)制，業(yè)務(wù)場(chǎng)景以及技術(shù)優(yōu)缺點(diǎn)，提出一種基于Storm和Hadoop的新型大數(shù)據(jù)處理解決方案，以使得大數(shù)據(jù)處理更穩(wěn)定，更高效，并對(duì)新型大數(shù)據(jù)解決方案進(jìn)行性能測(cè)試，證明其高效性和穩(wěn)定性，所以這種新型架構(gòu)是高效、穩(wěn)定、可行的。

大數(shù)據(jù)；Storm；Hadoop；解決方案

0 引言

在當(dāng)前這個(gè)信息爆炸的時(shí)代，企業(yè)數(shù)據(jù)以幾何的速度增長(zhǎng)，預(yù)測(cè)到2020年，全球存儲(chǔ)數(shù)據(jù)量將會(huì)達(dá)到35ZB，很多像Facebook每天每小時(shí)產(chǎn)生的數(shù)據(jù)就達(dá)到10TB數(shù)據(jù)[1]。像這種海量的數(shù)據(jù)早已經(jīng)遠(yuǎn)遠(yuǎn)超出傳統(tǒng)數(shù)據(jù)處理技術(shù)的極限，無(wú)論是計(jì)算效率，還是計(jì)算時(shí)間都無(wú)法滿(mǎn)足要求。所以對(duì)大數(shù)據(jù)的研究得到廣泛的關(guān)注，目前對(duì)大數(shù)據(jù)處理的研究主要使用兩種核心技術(shù)：一種是基于MapReduce磁盤(pán)處理任務(wù)調(diào)用的批處理Hadoop技術(shù)[1]，另一種是基于內(nèi)存計(jì)算的分布式實(shí)時(shí)流Storm技術(shù)[2]。大數(shù)據(jù)處理現(xiàn)階段面臨的問(wèn)題是各種不同的業(yè)務(wù)場(chǎng)景需求，大數(shù)據(jù)缺乏一個(gè)從全局統(tǒng)一的解決方案。文獻(xiàn)[3]只是單一地解決Hadoop存儲(chǔ)的性能問(wèn)題，文獻(xiàn)[4]也只對(duì)Storm的Topology進(jìn)行設(shè)計(jì)，大數(shù)據(jù)技術(shù)的穩(wěn)定性、擴(kuò)展性和全局性沒(méi)有得到更好的發(fā)展，從本質(zhì)上說(shuō)仍然沒(méi)有解決現(xiàn)有的大數(shù)據(jù)遇到的難題。

1 Storm和Hadoop內(nèi)部實(shí)現(xiàn)機(jī)制原理分析

1.1 Hadoop原理

Hadoop是Apache軟件基金會(huì)旗下的一個(gè)開(kāi)源分布式計(jì)算平臺(tái)，其核心內(nèi)容是：分布式文件系統(tǒng)（Hadoop Distributed File System，HDFS）和MapReduce（Google File System，GFS）編程模式。MapReduce的核心思想就是將數(shù)據(jù)切片計(jì)算來(lái)處理大量的離線數(shù)據(jù)。

Hadoop有很多優(yōu)點(diǎn)，例如動(dòng)態(tài)的分配節(jié)點(diǎn)、MapReduce任務(wù)監(jiān)控、跨機(jī)架保存塊副本，DataNode故障后，可以動(dòng)態(tài)記錄故障，并重新尋找離客戶(hù)端最近的DataNode進(jìn)行任務(wù)重新分配，機(jī)架感知策略等都顯示出其強(qiáng)大的高效性、高擴(kuò)展性和可靠性。但是Hadoop也有其明顯的缺點(diǎn)：①Hadoop的MapReduce擅長(zhǎng)處理少量大數(shù)據(jù)，對(duì)小數(shù)據(jù)處理不擅長(zhǎng)，默認(rèn)64MB為一個(gè)Block，如果出現(xiàn)大量小于64MB的小文件，同樣每個(gè)要占一個(gè)Block，大大降低了性能的利用率。②NameN-ode一旦掛掉，整個(gè)運(yùn)行環(huán)境陷入困境。③其離線全量的處理方式，業(yè)務(wù)場(chǎng)景受到局限性，在數(shù)據(jù)過(guò)大的場(chǎng)景下，可能導(dǎo)入數(shù)據(jù)就要花幾天幾夜。

1.2 Storm原理

Storm是一個(gè)分布式的、可靠的、容錯(cuò)的數(shù)據(jù)實(shí)時(shí)流式處理系統(tǒng)，Spout是Storm中的消息源，用于為T(mén)opology生產(chǎn)消息，一般從外部數(shù)據(jù)源（如Message Queue、RDBMS、NoSQL、Log）不間斷地讀取數(shù)據(jù)并發(fā)送Tuple給Bolt進(jìn)行數(shù)據(jù)操作，Bolt是Storm中的消息處理者，用于為T(mén)opology進(jìn)行消息處理，Bolt可以執(zhí)行過(guò)濾、聚合、查詢(xún)數(shù)據(jù)等操作，而且可以一級(jí)一級(jí)地進(jìn)行處理。這種Topology模型采用消息傳遞方式交互數(shù)據(jù)，數(shù)據(jù)量相比較從磁盤(pán)獲取要小，而且動(dòng)態(tài)地讀取，每次讀取量小。

Storm的高可靠性和容錯(cuò)性主要集中體現(xiàn)在Storm的數(shù)據(jù)重發(fā)機(jī)制上，由于每個(gè)Bolt可以啟動(dòng)多個(gè)task，每個(gè)task都會(huì)帶有一個(gè)唯一標(biāo)示的ID，Storm將此ID持久化，在數(shù)據(jù)重發(fā)時(shí)候讀取發(fā)送失敗的task的ID狀態(tài)，重發(fā)發(fā)送數(shù)據(jù)，保證了數(shù)據(jù)的一致性，這明顯優(yōu)于S4實(shí)時(shí)流系統(tǒng)，而且Topology遞交之后，Storm會(huì)一直運(yùn)行直到主動(dòng)釋放Topology或者kill掉，這明顯要優(yōu)于Hadoop系統(tǒng)。

Hadoop的批處理和Storm的實(shí)時(shí)流處理，本是兩種不同的業(yè)務(wù)場(chǎng)景，但是如果我們很好地進(jìn)行融合和集成，就會(huì)發(fā)現(xiàn)組合在一起的新型處理方案在性能和擴(kuò)展性以及穩(wěn)定性上都得到了提升。

2 集成Storm和Hadoop的新型大數(shù)據(jù)處理方案

從離線批處理和實(shí)時(shí)處理來(lái)說(shuō)，原生Storm支持單個(gè)消息及批量消息的事物機(jī)制，Trident事務(wù)機(jī)制通過(guò)state以及繼承事務(wù)spout支持狀態(tài)持久、更新、查詢(xún)，Storm-trident-drpc遠(yuǎn)程調(diào)用機(jī)制對(duì)同步并行查詢(xún)業(yè)務(wù)有較好的支持，而且Storm的內(nèi)存處理方式要比Hadoop的磁盤(pán)處理速度快幾個(gè)數(shù)量級(jí)，所以數(shù)據(jù)處理層我們選擇Storm技術(shù)為主，存儲(chǔ)層加入Hadoop的HDFS、HBase，以及整個(gè)Hadoop生態(tài)圈。

如圖1所示，首先通過(guò)數(shù)據(jù)采集入口，針對(duì)關(guān)系型數(shù)據(jù)庫(kù)，配置異構(gòu)數(shù)據(jù)源，通過(guò)Storm進(jìn)行大數(shù)據(jù)處理，將數(shù)據(jù)按照實(shí)時(shí)處理、分析、融合等規(guī)則進(jìn)行數(shù)據(jù)處理，這其實(shí)就是設(shè)置Topology架構(gòu)的過(guò)程，為了保證實(shí)時(shí)性能，在處理過(guò)程中加入Kafka消息隊(duì)列。一方面為了為了緩解Web服務(wù)器端的處理壓力，來(lái)緩沖客戶(hù)端發(fā)送的消息，以供后續(xù)程序處理，另外主要是支撐Web服務(wù)器端的處理和持久化保存。通過(guò)Kafka可以降低消息隊(duì)列系統(tǒng)的復(fù)雜性，提高消息隊(duì)列系統(tǒng)的性能，擴(kuò)展性以及吞吐量。而在實(shí)時(shí)的場(chǎng)景中，為了數(shù)據(jù)交換效率，加入Redis內(nèi)存數(shù)據(jù)庫(kù)，其特點(diǎn)是高性能、持久存儲(chǔ)、適應(yīng)高并發(fā)的應(yīng)用場(chǎng)景、保證了效率，數(shù)據(jù)緩存在內(nèi)存中，可以周期性地把更新的數(shù)據(jù)寫(xiě)入磁盤(pán)或者修改操作寫(xiě)入追加的記錄文件中，通過(guò)實(shí)現(xiàn)master-slave（主從同步），提高Storm的并行處理能力。Zookeeper是作為分布式應(yīng)用建立更高層的同步（synchronization）、配置管理、群組以及名稱(chēng)服務(wù)?？梢员O(jiān)控掛在其上的節(jié)點(diǎn)，包括這個(gè)目錄節(jié)點(diǎn)中存儲(chǔ)的數(shù)據(jù)的修改，子節(jié)點(diǎn)目錄變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶(hù)端，通過(guò)這個(gè)特性可以實(shí)現(xiàn)的功能包括配置的集中管理、集群管理、分布式鎖等。

圖1 架構(gòu)設(shè)計(jì)

在數(shù)據(jù)存儲(chǔ)層，我們?cè)O(shè)計(jì)有RDBMS關(guān)系型數(shù)據(jù)庫(kù)、HBase列族數(shù)據(jù)庫(kù)、HDFS分布式文件系統(tǒng)。引入HBase，一方面是由于其列族的NoSQL數(shù)據(jù)庫(kù)在做數(shù)據(jù)分析時(shí)候比較方便，更主要的是為了在Storm做數(shù)據(jù)融合，數(shù)據(jù)分析處理過(guò)程中，為了保證數(shù)據(jù)一致性以及數(shù)據(jù)重發(fā)機(jī)制，存入到HBase，加入時(shí)間戳，一旦任務(wù)掛掉或者數(shù)據(jù)丟失，在數(shù)據(jù)重發(fā)的時(shí)候，讀取HBase庫(kù)中數(shù)據(jù)庫(kù)的時(shí)間戳，返回Storm處理層，通過(guò)Storm自帶的固化ID的重發(fā)機(jī)制進(jìn)行續(xù)傳，在周期性讀取時(shí)候，取時(shí)間戳最大的數(shù)據(jù)，這樣保證了數(shù)據(jù)的實(shí)時(shí)更新和一致性。引入HDFS，由于其對(duì)數(shù)據(jù)類(lèi)型的支持，以及最大的數(shù)據(jù)集，將Storm處理的數(shù)據(jù)統(tǒng)一存儲(chǔ)入HDFS中，包括之前存入到HBase的數(shù)據(jù)，轉(zhuǎn)存在HDFS，如果要進(jìn)行數(shù)據(jù)分析，通過(guò)構(gòu)建Hive構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，并通過(guò)Hive UDF實(shí)現(xiàn)HDFS數(shù)據(jù)提取轉(zhuǎn)化加載，可以存儲(chǔ)、查詢(xún)和分析，數(shù)據(jù)分析師可以對(duì)其進(jìn)行業(yè)務(wù)需求分析，提取數(shù)據(jù)價(jià)值。

針對(duì)數(shù)據(jù)存儲(chǔ)層，采用集群高可用性，提高數(shù)據(jù)庫(kù)穩(wěn)定性。由于實(shí)時(shí)處理對(duì)HBase的數(shù)據(jù)庫(kù)要求比較嚴(yán)格，必須保證數(shù)據(jù)的一致性和時(shí)間戳的問(wèn)題，一旦數(shù)據(jù)庫(kù)掛掉，數(shù)據(jù)將會(huì)無(wú)法插入和讀取，所以必須搭建HBase集群，使用HA（High Available）高可用性集群，對(duì)集群進(jìn)行心跳檢測(cè)，實(shí)時(shí)地對(duì)節(jié)點(diǎn)數(shù)據(jù)進(jìn)行分布式備份和節(jié)點(diǎn)切換，一旦某個(gè)節(jié)點(diǎn)掛掉，自行切換存儲(chǔ)進(jìn)入集群另一個(gè)節(jié)點(diǎn)，對(duì)Storm集群和Hadoop集群以及HBase集群，我們都要有一個(gè)統(tǒng)一的集群協(xié)作和負(fù)載均衡。

3 性能評(píng)估

Hadoop分布式部署，使用三臺(tái)一體機(jī)，安裝系統(tǒng)CentOS 6.4，CPU 2×2.4G，內(nèi)存2G，硬盤(pán)500G，集群安裝環(huán)境：Java1.7+Zookeeper-3.4.5-cdh4.3.0+Kafka+ storm-0.9.1+MySQL5.1.69+Hadoop2.0+HBase-0.94.3。

3.1 實(shí)驗(yàn)步驟

（1）實(shí)驗(yàn)方法：準(zhǔn)備10個(gè)log文件，分別具備10w～100w行數(shù)據(jù)，對(duì)10個(gè)log文件分別進(jìn)行處理，每處理一個(gè)log文件，需要起一個(gè)Topology，測(cè)試過(guò)程中記錄導(dǎo)入的數(shù)據(jù)行數(shù)和數(shù)據(jù)大小，處理過(guò)程中監(jiān)控服務(wù)器master的CPU、I/O和Mem變化情況。

（2）結(jié)果記錄：

①作業(yè)處理速度

表1和圖2所示，在處理從10w～100w數(shù)據(jù)中，新型解決方案在數(shù)據(jù)抽取、數(shù)據(jù)采集、數(shù)據(jù)預(yù)處理中，隨著數(shù)據(jù)量變大，處理數(shù)據(jù)大小變化成規(guī)律性變化，這體現(xiàn)出數(shù)據(jù)處理良好的穩(wěn)定性，而隨著數(shù)據(jù)量變化，所需處理時(shí)間越來(lái)越少，作業(yè)處理速度越來(lái)越快，體現(xiàn)其高效性，數(shù)據(jù)量越大，越能體現(xiàn)這種高性能。

②作業(yè)處理的穩(wěn)定性

如圖3所示，在Storm集群中CPU、I/O和Mem數(shù)據(jù)中，master的CPU占有率和I/O操作數(shù)一直處于良好的負(fù)載值，集群節(jié)點(diǎn)之間的資源處于良好穩(wěn)定的狀態(tài)。

4 結(jié)語(yǔ)

本文結(jié)合Storm和Hadoop構(gòu)建了一種大數(shù)據(jù)架構(gòu)。通過(guò)Kafka消息隊(duì)列，對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行緩沖，通過(guò)Redis內(nèi)存交換數(shù)據(jù)，增強(qiáng)的原生Storm的穩(wěn)定性和處理速度，這種既可以支撐增量的實(shí)時(shí)流處理，也可以實(shí)現(xiàn)類(lèi)似批量的處理方式，通過(guò)擴(kuò)展數(shù)據(jù)存儲(chǔ)層以及增強(qiáng)高可用性，進(jìn)一步擴(kuò)展了大數(shù)據(jù)業(yè)務(wù)場(chǎng)景。面臨各種各樣的大數(shù)據(jù)需求，未來(lái)大數(shù)據(jù)架構(gòu)的發(fā)展將是高度集成、滿(mǎn)足各種業(yè)務(wù)場(chǎng)景需求的大而全的架構(gòu)。

表1

圖2

圖3 master的CPU占有率和I/O操作數(shù)

參考文獻(xiàn)：

[1] 路嘉恒.Hadoop實(shí)戰(zhàn)[M].北京：機(jī)械工業(yè)出版社,2011

[2] Jin X J.Trident Storm and Flow Calculation Experience[J].Journal of Programmers,2012（10）：99～103

[3] 張春明,芮建武,何婷婷.一種Hadoop小文件存儲(chǔ)和讀取的方法[J].計(jì)算機(jī)應(yīng)用與軟件.2012,29（11）：95～100

[4] 杜政,王鵬,黃焱,等.一種基于Storm編程模型的迭代Topology方案[J].成都信息工業(yè)學(xué)院學(xué)報(bào).2014,29（1）：47～51

[5] 鄧華鋒,劉云生,肖迎元.分布式數(shù)據(jù)流處理系統(tǒng)的動(dòng)態(tài)負(fù)載平衡技術(shù)[J].計(jì)算機(jī)科學(xué),2007,34（7）：120～123

[6] 劉鵬.實(shí)戰(zhàn)Hadoop——開(kāi)啟通往云計(jì)算捷徑[M].北京：電子工業(yè)出版社,2011

[7] 黃健宏.Redis設(shè)計(jì)與實(shí)現(xiàn)[M].北京：機(jī)械工業(yè)出版社,2014

[8] 陸嘉桓.大數(shù)據(jù)挑戰(zhàn)與NoSQL數(shù)據(jù)庫(kù)技術(shù)[M].北京：電子工業(yè)出版社，2013

[9] 辛大欣,劉飛.Hadoop集群性能優(yōu)化技術(shù)研究[J].北京：電腦知識(shí)與技術(shù),2011,7（22）：5484～5486

[10] （美）MICHAEL MILLER著.云計(jì)算[M].姜進(jìn)磊,孫瑞志,向勇,史美林譯.機(jī)械工業(yè)出版社,2009

[11] White T.Hadoop：The Definitive Guide[M].US：O'Reilly Media,2012

Research on the Big Data Process Framework Based on Storm and Hadoop

JIN Yong-chao1，2，WU Huai-gu2
（1．College of Mathmatic and Computer,Xihua University，Chengdu 610039；2．College of Information Science Technology,Chengdu University，Chengdu 610106）

Proposes a new solution which is based on the technology of the big data named Storm and Hadoop,analyses the internal implementation mechanism of the Hadoop and Storm,the business scenario,as well as the advantages and disadvantages of them.The new solution can make the processing of the big data more efficient and stable.Tests this new solution which can prove the high efficiency and stability of the solution.So the new solution is efficient,stable and viable.

Big Data;Storm;Hadoop;Solution

1007-1423（2015）04-0009-04

10.3969/j.issn.1007-1423.2015.04.002

靳永超（1987-），男，陜西寶雞人，碩士，研究方向?yàn)樵朴?jì)算、大數(shù)據(jù)處理

吳懷谷（1975-），男，四川成都人，博士，教授，研究方向?yàn)樵朴?jì)算體系結(jié)構(gòu)、移動(dòng)應(yīng)用體系結(jié)構(gòu)和分布式信息系統(tǒng)

2014-12-09

2014-12-26