基于通信运营商数据的大数据实时流处理系统

【摘要】 本文利用流式数据处理框架探索了一种新的基于运营商实时大数据业务系统构建模式。首先，在充分研究了业内实时流式处理技术的发展以及运营商本身实时数据源的特点之后，确定以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应用程序会话，网页命中计数等。

整体优化前数据流程如下：

话单文件精细化预处理HDFSHiveGreenPlum

整体优化后数据流程如下：

话单流HDFSHiveGreenPlum

总处理所需时间较原流程缩短至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