董 斌，楊 迪，王 錚，周文紅

（1.中國電信股份有限公司上海研究院 上海200122；2.中國電信集團公司 北京100032）

1 引言

自從Google發(fā)布了基于云計算的分布式MapReduce[1]大數(shù)據(jù)處理編程模型，大數(shù)據(jù)技術(shù)和應(yīng)用得到了廣泛的應(yīng)用，開源的Hadoop分布式計算軟件框架[2]更是將大數(shù)據(jù)應(yīng)用推向了極限，網(wǎng)頁搜索、RTB（real time bidding）廣告、精準營銷等典型應(yīng)用的成功使Hadoop、MapReduce成為大數(shù)據(jù)的象征。MapReduce是一種離線的批處理方式，可以成功處理TB、PB級海量數(shù)據(jù)，但無法應(yīng)對實時數(shù)據(jù)分析需求和對消息事件的實時響應(yīng)，大數(shù)據(jù)處理需要支持實時處理和迭代計算技術(shù)作為補充，因此流式計算成為大數(shù)據(jù)技術(shù)研究的新熱點。流式計算來自于一個信念：數(shù)據(jù)的價值隨著時間的流逝而降低，所以事件出現(xiàn)后必須盡快地對它們進行處理，發(fā)生一個事件進行一次處理，而不是緩存起來成批處理。

電信運營商是天然的大數(shù)據(jù)擁有者，豐富的數(shù)據(jù)資源已成為電信運營商的重要戰(zhàn)略資產(chǎn)，而運營商數(shù)據(jù)也有鮮明特點，其在大數(shù)據(jù)產(chǎn)業(yè)鏈中處于數(shù)據(jù)傳遞和交換中心的地位，擁有的數(shù)據(jù)一般不是最終落地數(shù)據(jù)，主要由實時信令和流式數(shù)據(jù)構(gòu)成，因此在運營商大數(shù)據(jù)應(yīng)用實踐過程中，對實時信令數(shù)據(jù)處理、分析的實時性需求越來越迫切。流式大數(shù)據(jù)技術(shù)的應(yīng)用為運營商數(shù)據(jù)信息化提供了新的機遇和工具，并有助于提升數(shù)據(jù)價值和推進業(yè)務(wù)創(chuàng)新。

在運營商動態(tài)數(shù)據(jù)信息開放 （open information of dynamic data，OIDD）平臺的大數(shù)據(jù)集約運營應(yīng)用中，實時信令采集、清理匯聚需要在省層面進行，全國層面再進行匯聚和加工處理開放。目前最快獲取信令中實時信息（如用戶狀態(tài)、位置信息等）的時延能達到小時量級，這無法滿足對數(shù)據(jù)實時性敏感的數(shù)據(jù)增值服務(wù)要求。以解決OIDD所面臨的問題為出發(fā)點，本文提出了基于流式計算的全國OIDD平臺的實時信令處理大數(shù)據(jù)技術(shù)解決方案。

2 基于Hadoop架構(gòu)的動態(tài)數(shù)據(jù)信息開放平臺

用戶信息能力是電信能力的重要組成部分，具有豐富的潛在價值。動態(tài)數(shù)據(jù)信息開放平臺是對用戶動態(tài)信息進行實時采集、匯聚、挖掘和開放的平臺，為網(wǎng)絡(luò)優(yōu)化和第三方應(yīng)用提供“快數(shù)據(jù)”的增值服務(wù)。

2.1 OIDD平臺架構(gòu)

通過網(wǎng)絡(luò)信令接口可以實時獲取到用戶狀態(tài)信息，包括終端能力信息、用戶狀態(tài)信息、用戶位置信息、網(wǎng)絡(luò)狀態(tài)及IP地址和電話號碼臨時綁定關(guān)系等，OIDD對從網(wǎng)絡(luò)中實時采集的數(shù)據(jù)集約匯聚，并經(jīng)過脫敏處理后，根據(jù)數(shù)據(jù)不同類型和特性封裝成核心數(shù)據(jù)能力，面向第三方應(yīng)用提供“快數(shù)據(jù)”能力服務(wù)和對網(wǎng)絡(luò)狀態(tài)進行實時的監(jiān)控和優(yōu)化。

目前，OIDD平臺基于Hadoop大數(shù)據(jù)平臺建設(shè)，平臺技術(shù)架構(gòu)如圖1所示。

·ETL（extraction transformation loading）：負責(zé)將分散的、從異構(gòu)數(shù)據(jù)源中收集的數(shù)據(jù)（如信令數(shù)據(jù)、位置數(shù)據(jù)、DPI數(shù)據(jù)等）抽取到臨時中間層后進行清洗、轉(zhuǎn)換、集成，最后通過數(shù)據(jù)總線存入Hadoop分布式數(shù)據(jù)庫。

圖1 OIDD平臺架構(gòu)

·運營管理平臺（OP）：系統(tǒng)數(shù)據(jù)開放接口的管理平臺，提供數(shù)據(jù)路由、接入鑒權(quán)、數(shù)據(jù)訪問權(quán)限、數(shù)據(jù)脫敏等功能。

·數(shù)據(jù)總線：系統(tǒng)的數(shù)據(jù)總線，整合了系統(tǒng)Hadoop、數(shù)據(jù)庫、緩存等資源池訪問、系統(tǒng)消息隊列，并提供高速網(wǎng)絡(luò)訪問接口，使各模塊可以分開部署，靈活擴容。

·緩存（cache）：OIDD的高速數(shù)據(jù)緩存主體為內(nèi)存數(shù)據(jù)庫，在海量數(shù)據(jù)環(huán)境下它提供了數(shù)十倍于物理數(shù)據(jù)庫的數(shù)據(jù)查詢速度。

·數(shù)據(jù)庫（DB）：保存數(shù)據(jù)挖掘和數(shù)據(jù)分析的結(jié)果性數(shù)據(jù)、被經(jīng)常訪問的數(shù)據(jù)以及其他的臨時性數(shù)據(jù)等。

2.2 OIDD平臺多級組網(wǎng)

電信網(wǎng)絡(luò)按地域部署，信令信息、DPI信息都需要在省層面采集，并在集團層面進一步匯聚。OIDD平臺組網(wǎng)分為集團和省份2個層面，集團平臺完成數(shù)據(jù)統(tǒng)一匯聚，省份部署采集系統(tǒng)，并可根據(jù)自身發(fā)展，決定是否建設(shè)省級OIDD平臺。

圖2是數(shù)據(jù)源采集和匯聚的過程，數(shù)據(jù)源可以分為3種類型：集團集中建設(shè)的平臺系統(tǒng)（如業(yè)務(wù)平臺、集團IT平臺等）、已經(jīng)具備數(shù)據(jù)集約的省份OIDD平臺、按省建設(shè)但是集團具備統(tǒng)一數(shù)據(jù)集約的系統(tǒng)（如綜合網(wǎng)管、集團信令系統(tǒng)、日志采集系統(tǒng)等）。

2.3 業(yè)務(wù)應(yīng)用與發(fā)展問題

基于已建成的OIDD平臺，封裝成API和獨立的服務(wù)地址，提供數(shù)據(jù)的查詢、狀態(tài)訂閱和通知的功能?，F(xiàn)已開展了用戶漫游服務(wù)、企業(yè)名片掛機推送、行車路線定位監(jiān)測等服務(wù)，并取得良好的經(jīng)濟效益。在平臺運營實踐中，雖然通過高速數(shù)據(jù)緩存能提升系統(tǒng)效率，顯著降低外部應(yīng)用對分析結(jié)果的查詢時延，但由于需要經(jīng)過層層匯聚和批處理，數(shù)據(jù)時效性最快只能達到小時量級，限制了新業(yè)務(wù)創(chuàng)新，提升“快數(shù)據(jù)”實時性價值成為OIDD平臺的未來發(fā)展重點。

圖2 動態(tài)信息開放平臺的多級組網(wǎng)

根據(jù)現(xiàn)有OIDD平臺架構(gòu)和組網(wǎng)提高數(shù)據(jù)時效性，重點要解決以下2個方面問題。

·原有平臺基于Hadoop大數(shù)據(jù)處理技術(shù)，本質(zhì)是批處理方式，實時信令數(shù)據(jù)采集需要積累到一定量或時間后再統(tǒng)一處理。平臺要進一步支持對實時、單獨的消息和事件進行處理，并且這個過程是消息/事件驅(qū)動和不間斷的。

·全國OIDD平臺數(shù)據(jù)需要通過省、集團兩個層面的匯聚，也是導(dǎo)致數(shù)據(jù)實時性無法保證的重要原因，有的在省公司可以開展的業(yè)務(wù)，由于數(shù)據(jù)時效性已過，集團層面難以開展。全國OIDD平臺需要及時獲得實時信令信息，盡量消除批量存儲再轉(zhuǎn)發(fā)的中間環(huán)節(jié)。

3 流式大數(shù)據(jù)處理技術(shù)及應(yīng)用分析

流式數(shù)據(jù)處理系統(tǒng)和批量數(shù)據(jù)處理系統(tǒng)有著本質(zhì)的差別，流式數(shù)據(jù)處理系統(tǒng)需要維護消息隊列并進行實時消息的及時處理。分布式流式大數(shù)據(jù)處理技術(shù)雖然處于起步發(fā)展階段，但由于市場廣泛需求的驅(qū)動，成為關(guān)注和研究熱點[3]。當(dāng)前具有代表性的流式處理系統(tǒng)有Storm[4]、S4[5]以及Spark Streaming[6]。

流式計算組件是實時大數(shù)據(jù)技術(shù)平臺的核心，但是幾種技術(shù)的比較不是本文重點，本文目標(biāo)是選擇一款便于引入OIDD平臺的實時大數(shù)據(jù)處理技術(shù)。Storm主從方式比S4去中心方式更適合消息處理（保證消息順序性）[2]，因此Storm越來越得到廣泛關(guān)注和應(yīng)用，如阿里巴巴、百度實時數(shù)據(jù)處理都采用了Storm架構(gòu)。Spark Streaming也是當(dāng)前熱點，其原理是將數(shù)據(jù)流分成小的時間片斷（秒級），以類似批處理的方式處理數(shù)據(jù)，對于目前版本的Spark Streaming而言，其最小的批處理時間間隔選取為0.5～2 s[6]，所以Spark Streaming能夠滿足除了對實時性要求非常高之外的所有流式準實時計算場景。但相比Storm系統(tǒng)，Spark Streaming計算時延大，Storm目前最小的時延是毫秒級[3]?；谏鲜龇治?，本文有針對性地對如何將Strom引入OIDD平臺的解決方案進行了分析。

大數(shù)據(jù)處理架構(gòu)包括數(shù)據(jù)采集、數(shù)據(jù)接入、數(shù)據(jù)處理和數(shù)據(jù)輸出，如圖3所示。流式大數(shù)據(jù)處理也要選擇和配置滿足實時信令處理要求的數(shù)據(jù)采集、匯聚、處理和分析相關(guān)組件。

圖3 大數(shù)據(jù)處理流程

通過Flume-ng+Kafka+Storm可以搭建實現(xiàn)支持實時信令處理的大數(shù)據(jù)分析平臺。Flume-ng負責(zé)從各節(jié)點上實時采集數(shù)據(jù)；由于數(shù)據(jù)采集的速度和數(shù)據(jù)處理的速度不一定同步，因此需要一個消息中間件作為緩沖，Kafka作為一種高吞吐量的分布式消息系統(tǒng)非常適合承擔(dān)此項工作；流式數(shù)據(jù)處理作為關(guān)鍵組件，根據(jù)前述分析選擇了Storm；數(shù)據(jù) 輸 出 可 以 用MySQL和 自 定 義API（application programming interface，應(yīng)用程序編程接口）。

3.1 數(shù)據(jù)收集服務(wù)組件Flume-ng

Flume目前是一個分布式、高可用、可擴展的海量信息收集工具，可以實時進行數(shù)據(jù)的收集和傳輸，Apache Flume項目將Flume1.0以后的版本統(tǒng)稱為Flume-ng[7]。為了簡潔，后續(xù)涉及的Flume組件都是指Flume-ng版本。

Flume架構(gòu)如圖4所示，以代理（agent）為最小的獨立運行單位，由數(shù)據(jù)源采集（source）、數(shù)據(jù)臨時存儲（sink）和數(shù)據(jù)流通道（channel）3層組成，一個agent就是一個JVM（Java virtual machine，Java虛擬機）。數(shù)據(jù)流的采集由事件（event）貫穿始終，事件是Flume的基本數(shù)據(jù)單位，運營商網(wǎng)絡(luò)中信令消息和日志記錄都可以看成一個個事件。

·source負責(zé)接收事件，并進行簡單處理后，寫到定制的各種數(shù)據(jù)接收方。通過編程，可針對不同數(shù)據(jù)源或數(shù)據(jù)類別對source進行定制。

·channel位于source和sink之間，用于緩存接收進來的事件。

·sink負責(zé)取出channel中事件，傳輸?shù)较乱惶蜃罱K目的，sink也是可以通過編程自定義的。當(dāng)sink成功地將事件發(fā)送到下一跳或最終目的地，事件從channel移除。

圖4 Apache Flume架構(gòu)[7]

Flume是分布式的，每一層均可以水平擴展，具有端到端的數(shù)據(jù)傳送保障，非常適合實時性高、協(xié)議需要定制分析的網(wǎng)絡(luò)信令的實時采集。

3.2 分布式消息隊列組件Kafka

Kafka也是Apache下的開源消息系統(tǒng)項目[8]，是一種高吞吐量的分布式消息發(fā)布訂閱系統(tǒng)，在普通的服務(wù)器上每秒也能處理幾十萬條消息，可用于低時延的收集和發(fā)送大量的事件和日志數(shù)據(jù)。

Kafka架構(gòu)如圖5所示，它維護按照類別進行區(qū)分的消息[8]。一個典型的Kafka集群包含若干生產(chǎn)者（producer）、處理服務(wù)器（broker）、消費者（consumer）以及一個ZooKeeper集群[9]。producer就是向Kafka發(fā)消息的客戶端，consumer則是從Kafka取消息的客戶端，一臺Kafka服務(wù)器就是一個broker，負 責(zé) 消 息 的 處 理 分 發(fā)，ZooKeeper管 理broker與consumer的動態(tài)加入與離開，各組件都可以水平擴展。

Kafka具有消息緩存能力，Kafka集群可以在一個可配置的時間內(nèi)保存所有發(fā)布上來的消息，不管這些消息有沒有被消費。

在網(wǎng)絡(luò)實時信令處理中，需要一個消息隊列系統(tǒng)來緩沖實時信令采集客戶端發(fā)送過來的消息，并且要求這個消息隊列系統(tǒng)支持良好的擴展性和大規(guī)模的數(shù)據(jù)流，同時為了和下個環(huán)節(jié)的數(shù)據(jù)處理速度匹配。Kafka組件非常適合承擔(dān)這項工作，根據(jù)配置的訂閱規(guī)則將緩存的消息轉(zhuǎn)發(fā)到消息使用者，從而降低實時信令數(shù)據(jù)處理系統(tǒng)的復(fù)雜性。Flume-ng+Kafka+Storm架構(gòu)中，F(xiàn)lume Sink作為Kafka的生產(chǎn)者，將消息事件傳送到Kafka集群中，按照消息類別（例如按消息發(fā)布者區(qū)分）進行緩存，Kafka根據(jù)配置的訂閱規(guī)則轉(zhuǎn)發(fā)到消費者客戶端Storm spout（參見第3.3節(jié)的Storm介紹）。

圖5 Apache Kafka架構(gòu)[8]

3.3 實時流計算組件Storm

Hadoop是基于批量的數(shù)據(jù)處理，需要等待數(shù)據(jù)的收集和任務(wù)調(diào)度，因此是離線的處理方式，通常的時間跨度在數(shù)十分鐘到數(shù)小時。與Hadoop不同，Storm是基于流式的數(shù)據(jù)處理，可以持續(xù)處理到達的數(shù)據(jù)，并且是基于內(nèi)存級的計算，從而讓處理進行得更加實時，處理時延在幾十毫秒到幾百毫秒量級。

Storm也是一個分布式、高容錯的實時計算系統(tǒng)，計算在多個線程、進程和服務(wù)器之間并行進行，節(jié)點可以方便地水平擴展[4]。根據(jù)測試，單個節(jié)點服務(wù)器大約每秒可處理幾萬條消息或日志。

如圖6所示，Storm集群主要由一個主節(jié)點和一群工作節(jié)點組成，并通過ZooKeeper進行協(xié)調(diào)。主節(jié)點運行nimbus進程，負責(zé)任務(wù)調(diào)度和資源分配。每個工作節(jié)點都運行supervisor進程，supervisor負責(zé)接受nimbus分配的任務(wù)，啟動和停止屬于自己管理的worker進程，nimbus和supervisor不存在直接通信，兩者的協(xié)調(diào)都是由ZooKeeper來完成的，任務(wù)狀態(tài)和心跳信息等也都保存在ZooKeeper上。

圖6 Apache Storm架構(gòu)[4]

拓撲是Storm中最關(guān)鍵的一個抽象概念，相當(dāng)于一個實時數(shù)據(jù)流的處理邏輯，可以被提交到Storm集群任務(wù)中執(zhí)行，圖6的worker中執(zhí)行的任務(wù)就是一個個拓撲。Storm中的拓撲如圖7所示[4]。拓撲的基本元素是spout和bolt。spout是一個拓撲的數(shù)據(jù)源，通常情況下spout會從外部數(shù)據(jù)源中讀取數(shù)據(jù)，然后轉(zhuǎn)換為拓撲內(nèi)部的源數(shù)據(jù)；bolt是實時流數(shù)據(jù)處理邏輯的執(zhí)行進程，用戶所希望的對數(shù)據(jù)流的分析和處理操作在這里執(zhí)行，復(fù)雜的消息流處理可能需要經(jīng)過多個步驟，即經(jīng)過多步bolt。

圖7 Storm的流計算拓撲[4]

實時信令數(shù)據(jù)的處理邏輯預(yù)先加載到Storm集群，Storm根據(jù)從Kaffka接收到的消息，按消息類別觸發(fā)任務(wù)，進行信令數(shù)據(jù)處理分析，并輸出結(jié)果。

4 融合實時處理的OIDD大數(shù)據(jù)平臺解決方案

現(xiàn)有動態(tài)數(shù)據(jù)信息開放平臺OIDD是Hadoop大數(shù)據(jù)處理平臺，基于批處理方式。從第2節(jié)的分析可知，OIDD平臺亟需解決數(shù)據(jù)的時效性問題，通過引入流式計算大數(shù)據(jù)技術(shù)，提高數(shù)據(jù)處理實時性能力，同時要考慮同現(xiàn)有平臺的融合方案。

4.1 實時信令處理大數(shù)據(jù)技術(shù)解決方案

實時信令處理大數(shù)據(jù)技術(shù)解決方案包括數(shù)據(jù)實時采集、流式的數(shù)據(jù)處理以及消息的調(diào)度和緩存，需要關(guān)注的關(guān)鍵技術(shù)包括組件的選取和部署、數(shù)據(jù)的處理時延和吞吐量以及與現(xiàn)有平臺的融合。

根據(jù)第3節(jié)分析，實時采集采用Flume組件，流式數(shù)據(jù)處理采用Storm，Kaffka作為消息中間件進行消息的緩存和調(diào)度。

（1）相關(guān)組件關(guān)鍵技術(shù)及部署方案

信令實時采集組件Flume：Flume負責(zé)網(wǎng)絡(luò)信令的采集以及DPI日志采集。通信網(wǎng)絡(luò)信令是實時的消息接口，不同設(shè)備的接口消息協(xié)議也有差別，DPI采集的則是一條條使用記錄。針對不同的數(shù)據(jù)源，需要通過開發(fā)不同的定制化Flume source程序，F(xiàn)lume source組件即嵌入網(wǎng)絡(luò)設(shè)備，也可以部署在云資源池，通過網(wǎng)絡(luò)接口連接。Flume agent的channel集中部署在云資源池，需要同時處理不同數(shù)據(jù)源數(shù)據(jù)，應(yīng)該采用內(nèi)存處理模式，提高處理性能。Flume部署則最好靠近數(shù)據(jù)源，因此建議在省層面云資源池部署Flume集群，通過管理平臺為不同的數(shù)據(jù)源加載對應(yīng)的Flume source程序，根據(jù)數(shù)據(jù)吞吐量彈性配置計算、存儲資源。

分布式消息中間件Kafka：Kafka整體架構(gòu)簡單，部署方便，有內(nèi)置的分區(qū)，這讓Kafka成為了一個很好的大規(guī)模消息處理應(yīng)用的解決方案。在實時信令的大數(shù)據(jù)處理中，Kafka主要是作為消息緩存中間件，保證數(shù)據(jù)采集和數(shù)據(jù)分析處理的消息同步，F(xiàn)lume sink作為Kafka的生產(chǎn)者，而Storm spout作為Kafka的消費者，Kafka將從Flume sink接收到的數(shù)據(jù)緩存到不同分區(qū)，Kafka broker對接收到的數(shù)據(jù)進行持久化處理，保存到存儲服務(wù)器，基于訂閱機制，將緩存的消息按需發(fā)送到不同的大數(shù)據(jù)處理平臺。Kafka集群也部署在省層面，同時為省OIDD平臺、集團OIDD平臺提供服務(wù)。

Storm平臺：Storm平臺是實時信令處理的大數(shù)據(jù)平臺關(guān)鍵組件，通過spout從Kafka消息隊列中讀取數(shù)據(jù)，發(fā)送到相應(yīng)的bolt中進行處理，bolt則按業(yè)務(wù)需求配置對應(yīng)的規(guī)則策略，可以針對不同數(shù)據(jù)源劃分不同bolt類，根據(jù)吞吐量在云資源池分配相應(yīng)的資源。Storm還需要同集團/省的動態(tài)數(shù)據(jù)信息開放平臺進行整合，與Hadoop平臺實現(xiàn)資源共享，平臺整合的解決方案在第4.2節(jié)中描述。

（2）關(guān)鍵流程描述

圖8是實時信令大數(shù)據(jù)技術(shù)方案中的主要環(huán)節(jié)和處理流程。

·數(shù)據(jù)采集：通過Flume集群上部署的各類數(shù)據(jù)源采集接口機，采集OIDD所需的數(shù)據(jù)源信息，并進行數(shù)據(jù)格式轉(zhuǎn)化，傳送到Kafka消息隊列。

圖8 實時信令處理大數(shù)據(jù)技術(shù)方案

·建立消息隊列：Kafka將接收到的數(shù)據(jù)，按不同數(shù)據(jù)源建立多條分布式消息隊列并將數(shù)據(jù)緩存，根據(jù)不同OIDD大數(shù)據(jù)平臺對數(shù)據(jù)的訂閱規(guī)則，傳送給相應(yīng)的OIDD平臺分別處理，省OIDD平臺和集團OIDD平臺的數(shù)據(jù)源可以不一致，消費者可以是OIDD的Storm平臺，也可以是原來的Hadoop平臺。

·消息接收：不同數(shù)據(jù)源具有不同的數(shù)據(jù)分析處理邏輯，對于實時信令由Storm平臺處理，Storm的spout接收消息或文件內(nèi)容信息，并送到對應(yīng)的bolt處理。

·規(guī)則匹配：由Storm與關(guān)聯(lián)規(guī)則篩選符合規(guī)則的數(shù)據(jù)內(nèi)容，這些規(guī)則可以是對原有數(shù)據(jù)的更新，也可根據(jù)外部應(yīng)用對數(shù)據(jù)的訂閱需求轉(zhuǎn)化而來，然后輸出結(jié)果。

·數(shù)據(jù)輸出：數(shù)據(jù)發(fā)送到數(shù)據(jù)庫存儲或者根據(jù)外部應(yīng)用的訂閱需求觸發(fā)通知、查詢等事件。

4.2 與Hadoop平臺融合解決方案

Hadoop 2.0平臺中引入了新的資源管理系統(tǒng)YARN[10]，MapReduce、Storm和Spark等組件均可運行在YARN之上，這就為Storm與Hadoop大數(shù)據(jù)平臺整合提供了解決方案。將Storm運行在Hadoop YARN上，Storm與原有Hadoop平臺可共享整個集群中的資源，并實現(xiàn)了數(shù)據(jù)的復(fù)用，避免了在多個數(shù)據(jù)平臺上保存同樣的數(shù)據(jù)副本，從而節(jié)省了存儲資源和跨群復(fù)制數(shù)據(jù)導(dǎo)致的網(wǎng)絡(luò)開銷，也避免了多個集群帶來的維護成本。

OIDD平臺匯聚運營商網(wǎng)絡(luò)中多種數(shù)據(jù)源，實時信令也是OIDD大數(shù)據(jù)平臺需要采集的數(shù)據(jù)源，基于YARN架構(gòu)，可以將負責(zé)實時信令處理的Storm大數(shù)據(jù)平臺組件整合到原有Hadoop大數(shù)據(jù)平臺中，Storm平臺輸出的數(shù)據(jù)仍然入庫到已經(jīng)部署的HDFS/HBase數(shù)據(jù)庫中，從而實現(xiàn)云資源、大數(shù)據(jù)組件和數(shù)據(jù)的共享。整合后的大數(shù)據(jù)平臺，原有平臺中的數(shù)據(jù)管理、安全控制、服務(wù)封裝和業(yè)務(wù)生命周期管理等模塊可以基本保持不變，但Hadoop平臺的版本需要升級到Y(jié)ARN，并提供對Storm模塊的數(shù)據(jù)管理、規(guī)則配置的接口。融合的大數(shù)據(jù)平臺和組網(wǎng)架構(gòu)如圖9所示。

圖9 融合的大數(shù)據(jù)平臺和組網(wǎng)架構(gòu)

在新的平臺組網(wǎng)架構(gòu)中，數(shù)據(jù)采集分為ETL組件和流采集組件，實時性要求高的數(shù)據(jù)通過Flume，由Storm流計算模塊實時分析處理，滿足對數(shù)據(jù)時效性要求高的數(shù)據(jù)業(yè)務(wù)需求；數(shù)據(jù)總線基于消息中間件調(diào)度，實現(xiàn)基于消息發(fā)布訂閱的任務(wù)調(diào)度；大數(shù)據(jù)平臺實現(xiàn)了資源共享，采集的源數(shù)據(jù)整合加工后仍然保存到共享的統(tǒng)一數(shù)據(jù)庫，因此仍然能夠滿足原來基于Hadoop的大數(shù)據(jù)應(yīng)用。

5 結(jié)束語

大數(shù)據(jù)流式計算和批量計算適用于不同的應(yīng)用場景。批處理匯聚海量數(shù)據(jù)分析出的結(jié)果可能更精確，但對數(shù)據(jù)時效性要求嚴格而對歷史數(shù)據(jù)積累并不非常關(guān)注的場景，流式計算具有明顯的優(yōu)勢。批量計算和流式計算是有優(yōu)劣互補的，因此在多種應(yīng)用場合下可以將兩者結(jié)合起來使用。

以Hadoop大數(shù)據(jù)技術(shù)為基礎(chǔ)的OIDD平臺已在現(xiàn)網(wǎng)應(yīng)用，隨著業(yè)務(wù)開展，業(yè)務(wù)創(chuàng)新對數(shù)據(jù)的時效性提出了更高要求。結(jié)合流式計算的研究，本文提出了融合流式計算和批量計算的OIDD解決方案，對所需的組件進行了分析和選擇，從實驗室搭建Flume-ng+Kafka+Storm大數(shù)據(jù)處理環(huán)境，10萬條數(shù)據(jù)可在幾秒內(nèi)完成采集、匯聚、處理端到端過程，大大提高了數(shù)據(jù)有效性。

大數(shù)據(jù)流式計算的研究和應(yīng)用仍處于起步和嘗試階段，為了促進大數(shù)據(jù)流式計算平臺的成熟，還需要在實踐中進行試點和完善。

1 Condiet T,Alvaro P,Hellerstein J M,et al.MapReduce Online.UCB/EECS-2009-136,2009

2 Apache Software Foundation.Welcome to Apache Hadoop.http://hadoop.apache.org,2015

3 孫大為,張廣艷,鄭緯民.大數(shù)據(jù)流式計算:關(guān)鍵技術(shù)及系統(tǒng)實例.軟件學(xué)報,2014,25(4):839～862 Sun D W,Zhang G Y,Zheng W M.Big data stream computing:technologies and instances.Journal of Software,2014,25(4):839～862

4 Neumeyer L,Robbins B,Nair A,et al.S4:distributed stream computing platform.Proceedings of the IEEE International Conference on Data Mining Workshops,Sydney,Australia,2010

5 崔星燦,禹曉輝,劉洋等.分布式流處理技術(shù)綜述.計算機研究與發(fā)展,2015,52(2):318～332 Cui X C,Yu X H,Liu Y,et al.Distributed stream processing:a survey.Journal of Computer Research and Development,2015,52(2):318～332

6 Apache Software Foundation.Spark Streaming makes it easy to build scalable fault-tolerant streaming applications.http://spark.apache.org/streaming/,2015

7 Apache Software Foundation.Apache Kafka:a high-throughput distributed messaging system.http://kafka.apache.org/,2015

8 Apache Software Foundation.Storm official website.http://storm.apache.org/,2015

9 Apache Software Foundation.Welcome to Apache ZooKeeper.http://zookeeper.apache.org/,2015

10 Vavilapali V K,Murthy A C,Douglas C,et al.Apache Hadoop YARN:yet another resource negotiator.Proceedings of the 4th ACM Symposium on Cloud Computing,Santa Clara,California,USA,2013