基于通信運營商數據的大數據實時流處理系統

朱奕健 張正卿

【摘要】 本文利用流式數據處理框架探索了一種新的基于運營商實時大數據業務系統構建模式。首先，在充分研究了業內實時流式處理技術的發展以及運營商本身實時數據源的特點之后，確定以Flume作為實時采集和分流組件，Kafka作為緩存和多模塊通信組件，以Spark Streaming的分布式結構作為數據ETL集群；然后，利用該系統進行了重點區域的人流實時監控的業務，在實施過程中為了提供毫秒級的數據結果流查詢能力，采用了Redis組件提供基于內存的Key-Value引擎；最終，通過流式數據處理效率的對比和實時監控的人流效果，我們驗證了了這種新的技術架構針對運營商CS域和PS域數據實時處理需求的可行性，結果表明，新的實時業務架構能更加有效的提高從實時采集到業務觸發的運行效率，并且為公安部門在重大節假日的區域級人流監控、預警和疏導提供了技術保障。

【關鍵詞】 大數據 流處理 簡單事件處理引擎（PME） Flume Kafka

一、引言

隨著網絡、通信和傳感器應用的飛速發展，尤其是移動通信全面進入移動互聯網時代，直接帶來通信網絡中的數據復雜度、信息量迅速增長，諸多的移動設備實時收集用戶各種信息，如位置、喜愛偏好、移動軌跡、血壓、體溫等，帶來數據的規模、種類和關聯性等急劇膨脹。“大數據”成為時下各個行業中出現頻率最高的關鍵詞之一。思科估算在2015年僅移動網絡的數據量將突破6EB/月，相當于億字節的海量數據；而IDC預計到2020年全世界的數據存儲總量將達到35萬億GB。大數據時代的到來使得隱藏在海量數據中的信息開始深刻的影響著人們的日常生活。當顧客在網上購物時，推薦系統會根據從海量數據中挖掘出的信息向其推薦適合的商品；當乘客出行時，打車軟件又替他們搜索周圍空閑出租車并選擇最優車輛來提供服務；當病人看病時，醫生又會根據該病人的日常醫療數據制定最優的治療方案。

而隨著4G時代的到來，移動通信業務已經正式全面進入移動互聯網時代，飛速發展的移動網絡帶寬直接帶來繁雜的應用和用戶行為，而通信網絡中的數據復雜度、信息量都隨之迅速增長，通信運營商所能掌握的數據量級與日俱增，導致數據處理的復雜度和運算量要求都隨之有了更高的要求，傳統數據庫體系的數據處理能力受到了極大的挑戰，面對海量數據處理需求和更低的時延性限制要求，傳統數據系統投入的CPU計算能力、內存響應和吞吐、網絡帶寬都有著巨大的基準，且在高安全性，多中心的發展趨勢下面臨諸多的瓶頸。

大數據時代的到來使單節點的計算模式已經不能滿足數據處理的需求，分布式數據處理與存儲系統逐步成為大數據平臺首選的架構，包括Hadoop，MongoDB等開放型的大數據技術成為了眾相研究的熱點。而Hadoop大數據平臺主要基于靜態數據文件的并行處理，雖然在海量數據吞吐、計算、存儲方面有著極高的效率，但是實時性較差，屬于高吞吐，高并發，高時延的架構，對于小文件的處理性能一直是其不可回避的問題，故針對一些實時性較高的數據處理和使用場景下無能為力。基于這樣的原因，面對動態數據處理的需求，實時流式數據處理技術應運而生。

隨著針對數據流的研究逐漸進入學術界，大規模動態數據集（也稱為實時數據流）成為研究及工程人員爭相探索的熱點領域[12]。而實時流式數據具有海量性、實時性和動態變化性三個基本特點，基于這些特性，數據研究領域內發展了諸多的研究方向。如流式數據處理的數學工具研究[11]，研究如何保證在數據流處理過程中的QoS服務質量[2]，研究利用滑動窗口來實現實時流數據處理[1][8]，基于實時性流數據查詢算法的優化[3]，研究數據流的分布式處理和最后聚集[6]，流式數據的實時分類[9]。也有融合流處理技術在其他科技領域來完成復雜性的計算，如射頻標簽領域的實時數據處理[4]，高速網絡中的數據流模型設計[7]，數據流量變化的處理模型[10]。而在大數據應用領域，更多的企業在開發如何利用流處理技術來構造一個企業級的實時性數據業務平臺[5]

本論文所有的研究都集中在如何構造基于運營商大數據流處理系統方面，主要圍繞實時性的業務場景下，如何從數據產生，數據采集，到數據流的處理，再到實時業務規則匹配的過程中尋找最佳流式數據平臺的架構展開研究。全文采用總分結構給出了實時流處理系統的構建思路：在第二節，對實時流處理系統的整體架構進行整體性闡述；第三節主要闡述采用Flume+Kafka+SparkStreaming架構來有效解決Hadoop系統對于小數據的流式處理效率的提高；在第四節中，通過該系統成功實現針對固定區域進行實時人流監控的業務場景，最后，針對整個系統對于流式處理的效率和實時監控效果進行總結，并形成研究結論和下一步的研究計劃。

二、流式大數據系統綜述

流式大數據系統的總體架構如圖1所示。

整個系統的流處理框架使用了學術界內公認較為高效的開源組件，整體系統實時數據來源于兩方面：

PS域數據：基于移動網絡Gn口中的全量用戶移動上網數據；

CS域數據：基于信令網絡中A口中的基站定位數據。

在系統底層，利用Flume組件來實時采集匯攏2種來源的數據，并根據上層數據需求進行分流，對于需要實時處理的數據實時傳送至Kafka集群，對于非實時性數據挖掘模型需要的靜態數據來形成文件寫入Hadoop集群的HDFS文件。

在實時數據的ETL層，采用Kafka組件來完成所有的數據流緩存，該架構可以保證整體數據流通訊的可靠性以及短時延的對外服務能力。一些復雜的數據挖掘和處理通過分布式的流式處理結構-Spark streaming來實施，該架構充分的結合了Hadoop的分布式處理的思想和內存數據庫的實時處理效率，充分保證整體處理過程的高并發、低時延，并實現了數據內容和挖掘能力的高魯棒性。而諸多簡單業務規則和數據的匹配則通過引入簡單事件匹配引擎（PME）來完成。處理結果最終會回寫到Kafka中供應用層調用。

在實時業務層，實時數據處理結果通過Kafka來被業務觸發系統調用，結合Hadoop的靜態數據挖掘結果（非實時），來形成最終的業務觸發，而在部分業務場景需求中，為了提高整個處理效率，我們采用了Redis（內存Key-Value引擎）來提供數據關聯查詢。

三、流式大數據處理效率提高

3.1針對靜態數據的小文件處理效率提升

小文件指的是那些Size比HDFS的Block Size（默認64M）小很多的文件。如果在HDFS中存儲許許多多這樣的小文件，我們發現HDFS根本無法很有效的處理數量龐大的小文件。任何一個文件，目錄和Block，在HDFS中都會被表示為一個Object存儲在NameNode的內存中，每一個Object占用150Bytes的內存空間。所以，如果有10 Million個文件，每一個文件對應一個Block，那么就將要消耗NameNode 3G的內存來保存這些Block的信息。如果規模再無限制的擴大下去，那么將會超出現階段計算機硬件所能滿足的極限。

不僅如此，HDFS并不是為了有效的處理大量小文件而存在的。它主要是為了流式的訪問大文件而設計的。對小文件的讀取通常會造成大量從DataNode到DataNode的Seeks和Hopping來Retrieve文件，而這樣是非常的低效的一種訪問方式。

針對Gn口和A口中的實時數據結構中存在小容量數據塊，如果利用傳統Hadoop結構勢必需要針對數量巨大的小文件進行高效處理，雖說Hadoop開源組件對小文件提供了許多的解決方案，但是帶來的系統構造成本巨大，而且在運營商開展的具體業務場景下并不能完全適用。

在利用實時性通訊組件Flume開始接管A口信令數據以及Gn口數據的采集時，改善平臺小文件狀況的契機開始顯現。我們在Flume中使用了Hadoop一個官方API使之在接收流式數據并寫入HDFS時進行文件追加，通過接收一條數據追加一條數據至當天文件內，這種快速積聚小文件到標準大小文件的方式解決了小文件在Hadoop集群中需要較多時延來存儲至HDFS文件的問題。

使用append函數需要如下兩個步驟：

配置集群（hdfs-site. xml）

dfs.support.append

true

API實現（Flume中數據輸出邏輯需要進行API調用）

String hdfs_path=”hdfs：//ip：xx/file/fileuploadFileName”；//文件路徑

Configuration conf= new Configuration（）；

FileSystem fs= FileSystem.get（URI.create（hdfs_path），conf）；

InputStream in=new BufferedInputStream（new FileInputsStream（file））；

//要追加的文件流，file為文件

IOUtils.copyBytes（in，out，4096，true）；

3.2針對實時性的流數據挖掘結果的結果查詢技術

為了保證事件處理結果的實時讀取，本文選擇Redis來進行結果存儲。Redis是一個開源、先進的key-value內存存儲，用于構建高性能、可擴展的Web應用程序的完美解決方案。

Redis從它的許多競爭者繼承來的三個主要特點：數據庫完全在內存中，使用磁盤僅用于持久性；相比許多鍵值數據存儲，Redis擁有一套較為豐富的數據類型；Redis可以將數據復制到任意數量的從服務器。

而對于時延要求極低的結果查詢使用Redis優勢包括：

異常快速：Redis的速度非常快，每秒能執行約11萬集合，每秒約81000+條記錄。

支持豐富的數據類型：Redis支持最大多數開發人員已經知道像列表，集合，有序集合，散列數據類型。這使得它非常容易解決各種各樣的問題，因為我們知道哪些問題是可以處理通過它的數據類型更好。

操作都是原子性：所有Redis操作是原子的，這保證了如果兩個客戶端同時訪問的Redis服務器將獲得更新后的值。

多功能實用工具：Redis是一個多實用的工具，可以在多個用例如緩存，消息，隊列使用（Redis原生支持發布/訂閱），任何短暫的數據，應用程序，如Web應用程序會話，網頁命中計數等。

整體優化前數據流程如下：

話單文件→精細化預處理→HDFS→Hive→GreenPlum

整體優化后數據流程如下：

話單流→HDFS→Hive→GreenPlum

總處理所需時間較原流程縮短至1/3，效率提高了200%。

四、 流式大數據系統實現的業務場景

在互聯網界，百度、亞馬遜、阿里巴巴、京東、騰訊等大型互聯網企業將大數據的應用提高到前所未有的高度，并形成了了一系列滿足各種業務需求的大數據處理平臺，通過挖掘海量數據中蘊含的信息點，并用業務流程來關聯起來，真正形成數據生產力來提高業務感知和質量，向日益增長的移動互聯網用戶提供更加優質的服務。比如：百度通過典型數學計算工具結合Hadoop框架向用戶提供搜索引擎，通過毫秒級DSP處理引擎向廣告服務提供商實時提供廣告點擊信息；騰訊通過Storm數據流處理系統進行簡單的數據處理，如過濾、聚類等，以及復雜數據處理，如運行簡單的機器學習算法等；阿里巴巴通過、等計算框架向用戶提供商品的推薦服務；京東通過海量數據的挖掘進行電子商務的倉儲備貨策略和物流控制策略。在科技學術界，《自然》雜志于年出版了大數據專刊。

2012年10月，哈佛商業評論上發表了一篇里程碑式的專題文章《Data scientist： The sexist job of 21st century》，標志著“數據科學家”已經正式在企業中收到廣泛的尊重，這類專家的主要工作是從海量非結構化數據中挖掘出有價值的信息，而不斷涌現的大數據技術使得從海量數據中獲取有價值信息成為可能。

本次實時系統研究過程中，恰逢2015年上海外灘踩踏事故的發生，考慮到該系統可以基于基站定位實時統計指定區域內的人流量，因此，在與公安系統對接后可以通過有效的技術手段來預先判斷人流擁擠程度，避免踩踏事故的再次發生。

實時人流監控架構見圖2。

數據流程中主要由PME負責訂閱kafka中的簡單的事件并進行處理。將A口信令中Cell_id、Lac字段匹配公參表中的經緯度信息，輸出用戶號碼目前匹配的經緯度信息。Storm組件負責訂閱復雜事件并進行處理（如分析小區用戶群），同時將簡單事件復雜事件處理結果輸出至存Redis，以便應用頁面能夠快速查詢結果。

實時人流監控系統能力如下（系統界面見圖3）：

客戶信令觸發30秒后，系統就會捕捉到信令事件，通過2-3秒的計算后即可將用戶位置信息存儲至Redis里。

展示頁面每5秒刷新一次。這樣在頁面內展示的內容都是1分鐘內人流變化情況。

通過在大數據平臺引入實時性Flume+Redis的架構實現了實時性數據采集、處理、展現的大數據能力，并利用該能力搭建了從A口信令觸發開始到最終監控界面的幾個熱點區域實時性人流監控，該技術方案在整個運營商業內屬于首創。

五、結論

本文提出了一種基于運營商網絡的實時大數據系統的構建，并成功的利用基于基站定位的實時人流監控業務來驗證了這種技術架構的合理性，這種模式不僅僅為未來運營商的實時大數據業務開發提供了新的思路，同時確保了該技術架構對于具體運營商對外合作業務的可實施型。本文下一步工作首先要對實時處理時效繼續優化，構建在1分鐘內從事件觸發，源數據采集，流處理，到業務觸發到用戶的全流程。然后，增強整個流式數據模型開發，以優化數據流ETL過程，實現多條實時流大數據業務的并發。此外，本文未來的研究工作還將在將在完善實時流處理和運營商推薦平臺融合建設等方面繼續開展。

參 考 文 獻

[1] 李俊奎； 王元珍，可重寫循環滑動窗口：面向高效的在線數據流處理[J]. 計算機科學， 2007

[2] 武珊珊，于戈，呂雁飛，谷峪，李曉靜， 數據流處理中確定性QoS的保證方法[J]， 軟件學報， 2008

[3] 左利云，馬英杰， 基于數據流處理模型的多查詢優化算法[J]， 計算機工程與科學， 2009

[4] 陰曉加，鞠時光，王英杰， 基于復雜事件處理機制的RFID數據流處理方法[J]， 計算機應用， 2009

[5] 楊瑋，企業級數據中心數據流處理方案設計[J]， 中國科技信息 2007

[6] 侯燕，王永利， 基于近似等深柱狀圖的數據流并行聚集算法[J]， 解放軍理工大學學報（自然科學版）， 2008

[7] 陳磊松，林錦賢， 面向高速網絡的數據流處理模型研究[J]， 漳州師范學院學報（自然科學版）， 2006

[8] Yishan Jiao， Maintaining stream statistics over multiscale sliding windows[J]. ACM Transactions on Database Systems （TODS） ， 2006 （4）[9] 徐花芬，毛國君，吳靜， 分布式數據流分類關鍵技術研究[J]， 華北科技學院學報， 2015

[10] 秦首科，錢衛寧，周傲英，基于分形技術的數據流突變檢測算法[J]， ， 2006， （9）

[11] Sudipto Guha， Nick Koudas， Kyuseok Shim， Approximation and streaming algorithms for histogram construction problems[J]， ACM Transactions on Database Systems （TODS）， 2006 （1）

[12] 張鵬，李鵬霄，任彥，林海倫，楊嶸，鄭超，面向大數據的分布式流處理技術綜述，計算機研究與發展[J]，2014