劉琴

摘? 要：由于數(shù)據(jù)流的不穩(wěn)定性，將數(shù)據(jù)流查詢安排在固定節(jié)點上就會造成分布式數(shù)據(jù)流處理技術很難對計算資源實現(xiàn)較高的處理效率，基于此，提出大數(shù)據(jù)分析下分布式數(shù)據(jù)流處理技術研究。具體流程是數(shù)據(jù)收集、歷史數(shù)據(jù)的存儲和查詢、Storm實時處理、智能索引、數(shù)據(jù)模型的建立。根據(jù)實驗結果可知，本文提出的大數(shù)據(jù)分析下分布式數(shù)據(jù)流處理技術與傳統(tǒng)技術相比，在數(shù)據(jù)流的處理效率上占有較大優(yōu)勢，一般維持在75%以上，能夠大大節(jié)省處理時間。

關鍵詞：大數(shù)據(jù);分布式;數(shù)據(jù)流處理技術;處理效率

中圖分類號：TP333? ? ?文獻標識碼：A

Research on Distributed Data Flow Processing

Technology under Big Data Analysis

LIU Qin

（School of Computer Science，Qinghai Nationalities University，Xining 810007，China）

Abstract：Because of the instability of data flow，it is difficult for distributed data flow processing technology to achieve high processing efficiency for computing resources by arranging data flow query on fixed nodes.For this reason，this paper proposes the research of distributed data flow processing technology under big data analysis.The specific process is data collection，historical data storage and query，storm real-time processing，intelligent index，data model building.According to the experimental results，compared with the traditional technology，the distributed data flow processing technology proposed in this paper has a greater advantage in the efficiency of data flow processing，generally maintained at more than 75%，which can greatly save processing time.

Keywords：big data;distributed;data flow processing technology;processing efficiency

1? ?引言（Introduction）

近幾年，隨著信息技術與計算機技術的迅猛發(fā)展及其大規(guī)模推廣應用，越來越多的客戶逐漸加入互聯(lián)網(wǎng)世界中，全球范圍數(shù)據(jù)總量也呈現(xiàn)出了爆炸式增長趨勢[1]。面對如此龐大的數(shù)據(jù)，傳統(tǒng)的數(shù)據(jù)處理技術已經(jīng)遠遠不能滿足人們對數(shù)據(jù)應用的需求。主要是由于傳統(tǒng)數(shù)據(jù)處理技術以處理器為核心，利用數(shù)據(jù)移動對其進行一系列的操作。在大數(shù)據(jù)分析背景下，因為數(shù)據(jù)總量過于龐大，給數(shù)據(jù)移動也帶來了諸多不便，所以迫切需要采取以數(shù)據(jù)為中心的處理模式，以此降低因數(shù)據(jù)移動而帶來的一系列開銷。除此之外，傳統(tǒng)的數(shù)據(jù)處理技術滿足不了大規(guī)模數(shù)據(jù)流的處理，無法提供充足的存儲空間，因而面向大規(guī)模數(shù)據(jù)流的處理技術已發(fā)展為一項全新的挑戰(zhàn)。

對此，在大數(shù)據(jù)分析環(huán)境下，提出新型的分布式數(shù)據(jù)流處理技術。此技術主要是利用基于Map Reduce的Hadoop系統(tǒng)處理構架實現(xiàn)的[2]，因Hadoop系統(tǒng)在常規(guī)環(huán)境下的處理策略是先進先出（FIFO），此類處理策略在運行任務時，以數(shù)據(jù)流到達時間點為依據(jù)進行相關處理，基本不將數(shù)據(jù)的本地性和集聚拓撲構造列入考慮范圍之內(nèi)，可避免因為任務等待時間過長、資源使用率較低、沒有考慮任務優(yōu)先級別等原因導致的緊急作業(yè)無法得到優(yōu)先處理的問題，所以針對基于Map Reduce的分布式數(shù)據(jù)流處理技術研究將會推動大數(shù)據(jù)分析下Hadoop系統(tǒng)的廣泛應用。

2? 大數(shù)據(jù)分析下分布式數(shù)據(jù)流處理技術（Distributed data flow processing technology under big data analysis）

2.1? ?數(shù)據(jù)收集

海量數(shù)據(jù)是產(chǎn)生大數(shù)據(jù)的基本條件，然而數(shù)據(jù)的收集就成了大數(shù)據(jù)分析的基礎[3]。日志數(shù)據(jù)采集處于流數(shù)據(jù)集中一個很大比例，大部分公司的業(yè)務平臺每一天都將產(chǎn)生數(shù)量龐大的零散數(shù)據(jù)，將這些業(yè)務日志數(shù)據(jù)集中進行收集并加以整合，用來滿足客戶在線和離線情況下能夠同時使用。需考慮日志收集的基本特點是：可靠性能高、實用性強、可擴展性強?！胺稚⑹占?、統(tǒng)一處理”是目前主流的日志處理的技術手段。日志收集也變成了分布式日志數(shù)據(jù)處理的基礎和前提。只有在完成日志的實時收集和整合后，才能繼續(xù)跟蹤日志之后的相關操作。

2.2? ?歷史數(shù)據(jù)的存儲和查詢

有關分布式數(shù)據(jù)庫的歷史數(shù)據(jù)存儲和ORM技術的聯(lián)系，與傳統(tǒng)數(shù)據(jù)庫存儲區(qū)別較大，分布式數(shù)據(jù)庫的數(shù)據(jù)在硬盤中支持混合手段（依據(jù)行或列）進行混合存儲和管理[4]。因為列存儲構造對數(shù)據(jù)查詢、整理和分析類操作具有一定的優(yōu)勢，所以在運行分析管理系統(tǒng)等大數(shù)據(jù)分析背景下混合存儲時可以獲得較好的應用效果。而傳統(tǒng)數(shù)據(jù)存儲主要根據(jù)數(shù)據(jù)大小進行優(yōu)先分配進行存儲，存在存儲不佳的問題。有關混合存儲的優(yōu)勢主要表現(xiàn)在以下幾方面：

首先具有更高的靈活性：對數(shù)據(jù)進行混合存儲可根據(jù)列或行分別進行，每張表或表分區(qū)可以被管理員按照現(xiàn)實需求或數(shù)據(jù)格式的不一樣進行直接操作處理，選擇不同的存儲和壓縮方法。這種方式能夠在一定程度上有效提高系統(tǒng)整體配置的靈活性，具體如圖1所示。

其次可以大大提高其響應速度：在對語句進行查詢時，傳統(tǒng)的行存數(shù)據(jù)庫必須從硬盤上將整行數(shù)據(jù)全部提取出來，而列存儲只能夠讀取所需數(shù)列，不讀取其他列的數(shù)據(jù)[5]。這種方式能夠有效降低I/O的運營成本，提高數(shù)據(jù)查詢功能和響應速度。

最后在高擴展性，分布式數(shù)據(jù)庫獨特的存儲格式可以將列數(shù)據(jù)細劃為“數(shù)據(jù)包”的格式。不管一個表的內(nèi)存有多大，數(shù)據(jù)庫只會對有關的數(shù)據(jù)包進行標準操作，其性能并不會隨著數(shù)據(jù)量的增多而降低，如此表數(shù)據(jù)就能夠實現(xiàn)較高的可擴展性。

ORM（Object Relation Mapping）也叫作對象——關系直接式映射，是針對面向對象的軟件開發(fā)手段而出現(xiàn)的。它主要作用于程序對象至關系數(shù)據(jù)庫內(nèi)數(shù)據(jù)的直接映射，ORM的引進對于數(shù)據(jù)庫數(shù)據(jù)的相關操作有非常重要的作用，使數(shù)據(jù)處理與查詢能夠更加方便和迅速。ORM常常用于數(shù)據(jù)的長久性工作，比較常用的ORM技術主要包括OJB、MFC-OODE、Hibernate、PDO、TJDO等。本文主要采取MFC-OODE進行常規(guī)性的數(shù)據(jù)存儲與查詢處理，數(shù)據(jù)庫內(nèi)的表信息在該系統(tǒng)中均是以類對象的方式存在，而對于系統(tǒng)中在處理后出現(xiàn)的歷史數(shù)據(jù)，可利用定時器進行精準控制，當數(shù)據(jù)流超時或數(shù)據(jù)流緩沖區(qū)內(nèi)存被占滿時，可以一次性將存儲數(shù)據(jù)即內(nèi)存中的類對象信息全部導入數(shù)據(jù)庫中方便數(shù)據(jù)查詢。利用該機制能夠將多個數(shù)據(jù)流一次性全部導入數(shù)據(jù)庫內(nèi)，大大節(jié)省了相關數(shù)據(jù)表和數(shù)據(jù)庫的處理時間，有效地降低了I/O出現(xiàn)并發(fā)沖突的可能性，提升了系統(tǒng)的處理能力。有關數(shù)據(jù)查詢方面，數(shù)據(jù)查詢所提取到的數(shù)據(jù)能夠從系統(tǒng)硬盤中獲得，也能夠從數(shù)據(jù)庫中獲得，這是由于系統(tǒng)利用定時器對歷史數(shù)據(jù)進行存儲操作，如果是對最近存儲的數(shù)據(jù)信息進行相關查詢，則可以直接從硬盤內(nèi)中提取，這能夠大幅度提高查詢效率，同時也省去了對數(shù)據(jù)庫和數(shù)據(jù)表的一系列操作步驟節(jié)省操作時間。

2.3? ?Storm實時處理

在大數(shù)據(jù)分析的影響下，將數(shù)據(jù)實時進行收集與整合，使其變成有效數(shù)據(jù)流之后，想要盡可能快的得到應用系統(tǒng)實時需要數(shù)據(jù)結果，則數(shù)據(jù)解析系統(tǒng)一定要對原始數(shù)據(jù)迅速地完成一系列實時處理[6]。處理時，一臺服務器不能在短暫的時間內(nèi)滿足整個系統(tǒng)能夠計算超大量數(shù)據(jù)的需求，主要是因為考慮到業(yè)務水準和數(shù)據(jù)上升幅度的原因，需要數(shù)據(jù)處理系統(tǒng)具有很強的擴展性。storm最開始是通過twitter開發(fā)來擴源，以分布式實時數(shù)據(jù)處理系統(tǒng)為基礎，在twitter、Yahoo等眾多著名的互聯(lián)網(wǎng)公司得到了大力的推廣和應用。具有良好的可擴展和容錯性，并能夠獲得次秒級的延遲，適用于延遲較低的應用環(huán)境[7]。它的主要組成部分是：

（1）Nimbus是數(shù)據(jù)集群的重要節(jié)點，主要負責數(shù)據(jù)集群的資源管理、任務分配。

（2）Supervisor主要用作接收Nimbus分配的任務，能夠實時結束系統(tǒng)工作管理的進度。

（3）Zookeeper是storm主要應用的外部組件，提供Supervisor和Nimbus之間的協(xié)調(diào)服務，Nimbus和Supervisor的資源任務管理狀況都存儲在Zookeeper內(nèi)。storm組合的數(shù)據(jù)流包括Topoloy（拓撲），與Hadoop上的Map Reduce任務類似，節(jié)點間的數(shù)據(jù)流動方向形成了標準形式下運行的數(shù)據(jù)處理邏輯;Tuple（消息元組），也就是最小的消息處理和上傳單元，每個Tuple均為不可逆的數(shù)據(jù)消息組;Spout（噴嘴），主要的職責是把從storm外部獲取的數(shù)據(jù)轉換成內(nèi)部數(shù)據(jù)組件，并上傳初始數(shù)據(jù)到Tuple;Bolt（螺栓）的職責是接收來自Spout或者上個流程的Bolt的Tuple內(nèi)傳送的信息，在內(nèi)部進行簡單的數(shù)據(jù)轉換和計算以后，會產(chǎn)生很多的輸出Tuple數(shù)據(jù)流，再把它發(fā)送到別的Bolt，互相合作進而實現(xiàn)更為復雜的計算邏輯。

2.4? ?智能索引

智能索引和以往數(shù)據(jù)庫在行數(shù)據(jù)上建立數(shù)據(jù)細粒度索引的技術比較，分布式數(shù)據(jù)庫的智能索引是一種建立在數(shù)據(jù)流基礎上的數(shù)據(jù)粗粒度索引。每一個數(shù)據(jù)流在完成數(shù)據(jù)加載后就會自動建立，其中包含數(shù)據(jù)過濾信息和整合信息[8]。粗粒度的智能索引包含了預存數(shù)據(jù)之間互相依存關系的高級信息，可以精準描繪和識別出數(shù)據(jù)流的實際需求，有效完成復雜多表區(qū)的連接和子查詢問題。表中所有列完成自動建立后，無須用戶自行建立和人工維護。這就使得智能索引對數(shù)據(jù)存儲空間的占用較低，具備較高的擴展性，可以在使用索引后不會發(fā)生數(shù)據(jù)膨脹。后續(xù)數(shù)據(jù)流構建索引的速度也不會受到前面數(shù)據(jù)流的影響，加快索引構建速度。

2.5? ?數(shù)據(jù)流處理模型的建立

數(shù)據(jù)流作為由數(shù)據(jù)元組構成的無限序列，用表示。數(shù)據(jù)元組可以用表示，其中的代表數(shù)據(jù)元組的按鍵;代表數(shù)據(jù)元組的細分數(shù)值;代表數(shù)據(jù)元組的作用時間段。數(shù)據(jù)元組的并不是唯一指定的，一般其經(jīng)常用來確保數(shù)據(jù)元組路由的順利。時間段主要是由一個持續(xù)遞增的邏輯時鐘在數(shù)據(jù)元組建立之初完成標準分配。數(shù)據(jù)元組在數(shù)據(jù)流處理過程中根據(jù)時間段有序排列。數(shù)據(jù)元組由諸多的操作符組成。一個操作符具體是以一條或多條數(shù)據(jù)流為輸入，處理輸入數(shù)據(jù)流中的主要元組，并產(chǎn)生一條或多條輸出數(shù)據(jù)流。操作符函數(shù)用表示操作符對輸入數(shù)據(jù)流元組的處理程序。操作符主要有兩種：無狀態(tài)操作符（比如過濾和映射）和有狀態(tài)操作符（比如連接和集聚）。有狀態(tài)操作符的操作函數(shù)以表示，其會在新的數(shù)據(jù)元組抵達時被調(diào)取。有狀態(tài)操作符保留了之前處理數(shù)據(jù)流元組的狀態(tài)。當一個新的數(shù)據(jù)流元組抵達并被操作符函數(shù)完成處理后，就會產(chǎn)生新的數(shù)據(jù)流元組，而同時其狀態(tài)也會隨之被更換為，實現(xiàn)數(shù)據(jù)流的綜合處理。

3? ?實驗與效果分析（Experiment and effect analysis）

為了更加直觀地看出大數(shù)據(jù)分析下，本文提出的分布式數(shù)據(jù)流處理技術的實際應用效果，采用本文方法與傳統(tǒng)分布式數(shù)據(jù)流處理技術為對比，以處理效率作為標準進行實驗對比分析。

3.1? ?實驗準備

為確保實驗的準確性，把這兩種分布式數(shù)據(jù)流的處理技術處在同樣的服務器環(huán)境中，再進行處理能力有關的實驗。具體的服務器配置見表1所示。

在實驗中使用了三個數(shù)據(jù)集（S1，S2，S3），為了便于表述，使用Size（Si）（1≤i≤3）表示數(shù)據(jù)集的規(guī)模，Size（Si）的單位為數(shù)據(jù)條數(shù)。HadoopDB和HBase的數(shù)據(jù)文件格式不同，導致文件大小差異較大。各個數(shù)據(jù)集相關參數(shù)見表2。

按照一定的文件格式生成所有的數(shù)據(jù)，并載入相關數(shù)據(jù)，由于數(shù)據(jù)的生成是ETL 階段，針對處理效率進行對比。

3.2? ?實驗結果分析

實驗過程中，在相同配置環(huán)境下，通過兩種不同的分布式數(shù)據(jù)流處理技術同時進行工作，分析其處理能力的變化。實驗效果對比圖如圖2所示。

根據(jù)實驗結果可知，本文提出的大數(shù)據(jù)分析下分布式數(shù)據(jù)流處理技術與傳統(tǒng)技術相比，在數(shù)據(jù)流的處理效率上占有較大優(yōu)勢，一般維持在75%以上，能夠大大節(jié)省處理時間。

4? ?結論（Conclusion）

本文對大數(shù)據(jù)分析下分布式數(shù)據(jù)流處理技術研究進行分析，在分布式環(huán)境下，根據(jù)大數(shù)據(jù)反饋與分析，調(diào)整數(shù)據(jù)流的處理技術，完成本文設計。實驗論證證明，本文設計的方法有效性極高?？蔀楹罄m(xù)大數(shù)據(jù)分析下分布式數(shù)據(jù)流的處理方法提供理論依據(jù)。

參考文獻（References）

[1] 朱蔚林，木偉民，金宗澤，等.基于MR的高可靠分布式數(shù)據(jù)流統(tǒng)計模型[J].計算機技術與發(fā)展，2018，28（01）：6-10;16.

[2] 王春凱，孟小峰.應對傾斜數(shù)據(jù)流在線連接方法[J].軟件學報，2018，29（03）：869-882.

[3] 張愿.基于Spark Streaming的在線多數(shù)投票提升算法研究[J].福建電腦，2018，34（07）：105-107;115.

[4] 相坤，楊建設.面向廣域電網(wǎng)的分布式流協(xié)同處理技術研究[J].計算機與網(wǎng)絡，2018，44（23）：68-71.

[5] 鄭鈐.基于MapReduce模式的大數(shù)據(jù)分布式計算態(tài)勢分析[J].通訊世界，2018（06）：102-104.

[6] 譚亮，周靜.基于Spark Streaming的實時交通數(shù)據(jù)處理平臺[J].計算機系統(tǒng)應用，2018，27（10）：133-139.

[7] 付眸，楊賀昆，吳唐美，等.基于Spark Streaming的快速視頻轉碼方法[J].計算機應用，2018，38（12）：3500-3508.

[8] 閭程豪，荊一楠，何震瀛，等.基于分布式流處理的自適應數(shù)據(jù)分發(fā)策略[J].計算機應用與軟件，2018，35（08）：24-30.

作者簡介：

劉? ?琴（1976-），女，本科，副教授.研究領域：軟件工程.