董 斌，杨 迪，王 铮，周文红

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

1 引言

自从Google发布了基于云计算的分布式MapReduce[1]大数据处理编程模型，大数据技术和应用得到了广泛的应用，开源的Hadoop分布式计算软件框架[2]更是将大数据应用推向了极限，网页搜索、RTB（real time bidding）广告、精准营销等典型应用的成功使Hadoop、MapReduce成为大数据的象征。MapReduce是一种离线的批处理方式，可以成功处理TB、PB级海量数据，但无法应对实时数据分析需求和对消息事件的实时响应，大数据处理需要支持实时处理和迭代计算技术作为补充，因此流式计算成为大数据技术研究的新热点。流式计算来自于一个信念：数据的价值随着时间的流逝而降低，所以事件出现后必须尽快地对它们进行处理，发生一个事件进行一次处理，而不是缓存起来成批处理。

电信运营商是天然的大数据拥有者，丰富的数据资源已成为电信运营商的重要战略资产，而运营商数据也有鲜明特点，其在大数据产业链中处于数据传递和交换中心的地位，拥有的数据一般不是最终落地数据，主要由实时信令和流式数据构成，因此在运营商大数据应用实践过程中，对实时信令数据处理、分析的实时性需求越来越迫切。流式大数据技术的应用为运营商数据信息化提供了新的机遇和工具，并有助于提升数据价值和推进业务创新。

在运营商动态数据信息开放 （open information of dynamic data，OIDD）平台的大数据集约运营应用中，实时信令采集、清理汇聚需要在省层面进行，全国层面再进行汇聚和加工处理开放。目前最快获取信令中实时信息（如用户状态、位置信息等）的时延能达到小时量级，这无法满足对数据实时性敏感的数据增值服务要求。以解决OIDD所面临的问题为出发点，本文提出了基于流式计算的全国OIDD平台的实时信令处理大数据技术解决方案。

2 基于Hadoop架构的动态数据信息开放平台

用户信息能力是电信能力的重要组成部分，具有丰富的潜在价值。动态数据信息开放平台是对用户动态信息进行实时采集、汇聚、挖掘和开放的平台，为网络优化和第三方应用提供“快数据”的增值服务。

2.1 OIDD平台架构

通过网络信令接口可以实时获取到用户状态信息，包括终端能力信息、用户状态信息、用户位置信息、网络状态及IP地址和电话号码临时绑定关系等，OIDD对从网络中实时采集的数据集约汇聚，并经过脱敏处理后，根据数据不同类型和特性封装成核心数据能力，面向第三方应用提供“快数据”能力服务和对网络状态进行实时的监控和优化。

目前，OIDD平台基于Hadoop大数据平台建设，平台技术架构如图1所示。

·ETL（extraction transformation loading）：负责将分散的、从异构数据源中收集的数据（如信令数据、位置数据、DPI数据等）抽取到临时中间层后进行清洗、转换、集成，最后通过数据总线存入Hadoop分布式数据库。

图1 OIDD平台架构

·运营管理平台（OP）：系统数据开放接口的管理平台，提供数据路由、接入鉴权、数据访问权限、数据脱敏等功能。

·数据总线：系统的数据总线，整合了系统Hadoop、数据库、缓存等资源池访问、系统消息队列，并提供高速网络访问接口，使各模块可以分开部署，灵活扩容。

·缓存（cache）：OIDD的高速数据缓存主体为内存数据库，在海量数据环境下它提供了数十倍于物理数据库的数据查询速度。

·数据库（DB）：保存数据挖掘和数据分析的结果性数据、被经常访问的数据以及其他的临时性数据等。

2.2 OIDD平台多级组网

电信网络按地域部署，信令信息、DPI信息都需要在省层面采集，并在集团层面进一步汇聚。OIDD平台组网分为集团和省份2个层面，集团平台完成数据统一汇聚，省份部署采集系统，并可根据自身发展，决定是否建设省级OIDD平台。

图2是数据源采集和汇聚的过程，数据源可以分为3种类型：集团集中建设的平台系统（如业务平台、集团IT平台等）、已经具备数据集约的省份OIDD平台、按省建设但是集团具备统一数据集约的系统（如综合网管、集团信令系统、日志采集系统等）。

2.3 业务应用与发展问题

基于已建成的OIDD平台，封装成API和独立的服务地址，提供数据的查询、状态订阅和通知的功能。现已开展了用户漫游服务、企业名片挂机推送、行车路线定位监测等服务，并取得良好的经济效益。在平台运营实践中，虽然通过高速数据缓存能提升系统效率，显著降低外部应用对分析结果的查询时延，但由于需要经过层层汇聚和批处理，数据时效性最快只能达到小时量级，限制了新业务创新，提升“快数据”实时性价值成为OIDD平台的未来发展重点。

图2 动态信息开放平台的多级组网

根据现有OIDD平台架构和组网提高数据时效性，重点要解决以下2个方面问题。

·原有平台基于Hadoop大数据处理技术，本质是批处理方式，实时信令数据采集需要积累到一定量或时间后再统一处理。平台要进一步支持对实时、单独的消息和事件进行处理，并且这个过程是消息/事件驱动和不间断的。

·全国OIDD平台数据需要通过省、集团两个层面的汇聚，也是导致数据实时性无法保证的重要原因，有的在省公司可以开展的业务，由于数据时效性已过，集团层面难以开展。全国OIDD平台需要及时获得实时信令信息，尽量消除批量存储再转发的中间环节。

3 流式大数据处理技术及应用分析

流式数据处理系统和批量数据处理系统有着本质的差别，流式数据处理系统需要维护消息队列并进行实时消息的及时处理。分布式流式大数据处理技术虽然处于起步发展阶段，但由于市场广泛需求的驱动，成为关注和研究热点[3]。当前具有代表性的流式处理系统有Storm[4]、S4[5]以及Spark Streaming[6]。

流式计算组件是实时大数据技术平台的核心，但是几种技术的比较不是本文重点，本文目标是选择一款便于引入OIDD平台的实时大数据处理技术。Storm主从方式比S4去中心方式更适合消息处理（保证消息顺序性）[2]，因此Storm越来越得到广泛关注和应用，如阿里巴巴、百度实时数据处理都采用了Storm架构。Spark Streaming也是当前热点，其原理是将数据流分成小的时间片断（秒级），以类似批处理的方式处理数据，对于目前版本的Spark Streaming而言，其最小的批处理时间间隔选取为0.5～2 s[6]，所以Spark Streaming能够满足除了对实时性要求非常高之外的所有流式准实时计算场景。但相比Storm系统，Spark Streaming计算时延大，Storm目前最小的时延是毫秒级[3]。基于上述分析，本文有针对性地对如何将Strom引入OIDD平台的解决方案进行了分析。

大数据处理架构包括数据采集、数据接入、数据处理和数据输出，如图3所示。流式大数据处理也要选择和配置满足实时信令处理要求的数据采集、汇聚、处理和分析相关组件。

图3 大数据处理流程

通过Flume-ng+Kafka+Storm可以搭建实现支持实时信令处理的大数据分析平台。Flume-ng负责从各节点上实时采集数据；由于数据采集的速度和数据处理的速度不一定同步，因此需要一个消息中间件作为缓冲，Kafka作为一种高吞吐量的分布式消息系统非常适合承担此项工作；流式数据处理作为关键组件，根据前述分析选择了Storm；数据 输 出 可 以 用MySQL和 自 定 义API（application programming interface，应用程序编程接口）。

3.1 数据收集服务组件Flume-ng

Flume目前是一个分布式、高可用、可扩展的海量信息收集工具，可以实时进行数据的收集和传输，Apache Flume项目将Flume1.0以后的版本统称为Flume-ng[7]。为了简洁，后续涉及的Flume组件都是指Flume-ng版本。

Flume架构如图4所示，以代理（agent）为最小的独立运行单位，由数据源采集（source）、数据临时存储（sink）和数据流通道（channel）3层组成，一个agent就是一个JVM（Java virtual machine，Java虚拟机）。数据流的采集由事件（event）贯穿始终，事件是Flume的基本数据单位，运营商网络中信令消息和日志记录都可以看成一个个事件。

·source负责接收事件，并进行简单处理后，写到定制的各种数据接收方。通过编程，可针对不同数据源或数据类别对source进行定制。

·channel位于source和sink之间，用于缓存接收进来的事件。

·sink负责取出channel中事件，传输到下一跳或最终目的，sink也是可以通过编程自定义的。当sink成功地将事件发送到下一跳或最终目的地，事件从channel移除。

图4 Apache Flume架构[7]

Flume是分布式的，每一层均可以水平扩展，具有端到端的数据传送保障，非常适合实时性高、协议需要定制分析的网络信令的实时采集。

3.2 分布式消息队列组件Kafka

Kafka也是Apache下的开源消息系统项目[8]，是一种高吞吐量的分布式消息发布订阅系统，在普通的服务器上每秒也能处理几十万条消息，可用于低时延的收集和发送大量的事件和日志数据。

Kafka架构如图5所示，它维护按照类别进行区分的消息[8]。一个典型的Kafka集群包含若干生产者（producer）、处理服务器（broker）、消费者（consumer）以及一个ZooKeeper集群[9]。producer就是向Kafka发消息的客户端，consumer则是从Kafka取消息的客户端，一台Kafka服务器就是一个broker，负 责 消 息 的 处 理 分 发，ZooKeeper管 理broker与consumer的动态加入与离开，各组件都可以水平扩展。

Kafka具有消息缓存能力，Kafka集群可以在一个可配置的时间内保存所有发布上来的消息，不管这些消息有没有被消费。

在网络实时信令处理中，需要一个消息队列系统来缓冲实时信令采集客户端发送过来的消息，并且要求这个消息队列系统支持良好的扩展性和大规模的数据流，同时为了和下个环节的数据处理速度匹配。Kafka组件非常适合承担这项工作，根据配置的订阅规则将缓存的消息转发到消息使用者，从而降低实时信令数据处理系统的复杂性。Flume-ng+Kafka+Storm架构中，Flume Sink作为Kafka的生产者，将消息事件传送到Kafka集群中，按照消息类别（例如按消息发布者区分）进行缓存，Kafka根据配置的订阅规则转发到消费者客户端Storm spout（参见第3.3节的Storm介绍）。

图5 Apache Kafka架构[8]

3.3 实时流计算组件Storm

Hadoop是基于批量的数据处理，需要等待数据的收集和任务调度，因此是离线的处理方式，通常的时间跨度在数十分钟到数小时。与Hadoop不同，Storm是基于流式的数据处理，可以持续处理到达的数据，并且是基于内存级的计算，从而让处理进行得更加实时，处理时延在几十毫秒到几百毫秒量级。

Storm也是一个分布式、高容错的实时计算系统，计算在多个线程、进程和服务器之间并行进行，节点可以方便地水平扩展[4]。根据测试，单个节点服务器大约每秒可处理几万条消息或日志。

如图6所示，Storm集群主要由一个主节点和一群工作节点组成，并通过ZooKeeper进行协调。主节点运行nimbus进程，负责任务调度和资源分配。每个工作节点都运行supervisor进程，supervisor负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程，nimbus和supervisor不存在直接通信，两者的协调都是由ZooKeeper来完成的，任务状态和心跳信息等也都保存在ZooKeeper上。

图6 Apache Storm架构[4]

拓扑是Storm中最关键的一个抽象概念，相当于一个实时数据流的处理逻辑，可以被提交到Storm集群任务中执行，图6的worker中执行的任务就是一个个拓扑。Storm中的拓扑如图7所示[4]。拓扑的基本元素是spout和bolt。spout是一个拓扑的数据源，通常情况下spout会从外部数据源中读取数据，然后转换为拓扑内部的源数据；bolt是实时流数据处理逻辑的执行进程，用户所希望的对数据流的分析和处理操作在这里执行，复杂的消息流处理可能需要经过多个步骤，即经过多步bolt。

图7 Storm的流计算拓扑[4]

实时信令数据的处理逻辑预先加载到Storm集群，Storm根据从Kaffka接收到的消息，按消息类别触发任务，进行信令数据处理分析，并输出结果。

4 融合实时处理的OIDD大数据平台解决方案

现有动态数据信息开放平台OIDD是Hadoop大数据处理平台，基于批处理方式。从第2节的分析可知，OIDD平台亟需解决数据的时效性问题，通过引入流式计算大数据技术，提高数据处理实时性能力，同时要考虑同现有平台的融合方案。

4.1 实时信令处理大数据技术解决方案

实时信令处理大数据技术解决方案包括数据实时采集、流式的数据处理以及消息的调度和缓存，需要关注的关键技术包括组件的选取和部署、数据的处理时延和吞吐量以及与现有平台的融合。

根据第3节分析，实时采集采用Flume组件，流式数据处理采用Storm，Kaffka作为消息中间件进行消息的缓存和调度。

（1）相关组件关键技术及部署方案

信令实时采集组件Flume：Flume负责网络信令的采集以及DPI日志采集。通信网络信令是实时的消息接口，不同设备的接口消息协议也有差别，DPI采集的则是一条条使用记录。针对不同的数据源，需要通过开发不同的定制化Flume source程序，Flume source组件即嵌入网络设备，也可以部署在云资源池，通过网络接口连接。Flume agent的channel集中部署在云资源池，需要同时处理不同数据源数据，应该采用内存处理模式，提高处理性能。Flume部署则最好靠近数据源，因此建议在省层面云资源池部署Flume集群，通过管理平台为不同的数据源加载对应的Flume source程序，根据数据吞吐量弹性配置计算、存储资源。

分布式消息中间件Kafka：Kafka整体架构简单，部署方便，有内置的分区，这让Kafka成为了一个很好的大规模消息处理应用的解决方案。在实时信令的大数据处理中，Kafka主要是作为消息缓存中间件，保证数据采集和数据分析处理的消息同步，Flume sink作为Kafka的生产者，而Storm spout作为Kafka的消费者，Kafka将从Flume sink接收到的数据缓存到不同分区，Kafka broker对接收到的数据进行持久化处理，保存到存储服务器，基于订阅机制，将缓存的消息按需发送到不同的大数据处理平台。Kafka集群也部署在省层面，同时为省OIDD平台、集团OIDD平台提供服务。

Storm平台：Storm平台是实时信令处理的大数据平台关键组件，通过spout从Kafka消息队列中读取数据，发送到相应的bolt中进行处理，bolt则按业务需求配置对应的规则策略，可以针对不同数据源划分不同bolt类，根据吞吐量在云资源池分配相应的资源。Storm还需要同集团/省的动态数据信息开放平台进行整合，与Hadoop平台实现资源共享，平台整合的解决方案在第4.2节中描述。

（2）关键流程描述

图8是实时信令大数据技术方案中的主要环节和处理流程。

·数据采集：通过Flume集群上部署的各类数据源采集接口机，采集OIDD所需的数据源信息，并进行数据格式转化，传送到Kafka消息队列。

图8 实时信令处理大数据技术方案

·建立消息队列：Kafka将接收到的数据，按不同数据源建立多条分布式消息队列并将数据缓存，根据不同OIDD大数据平台对数据的订阅规则，传送给相应的OIDD平台分别处理，省OIDD平台和集团OIDD平台的数据源可以不一致，消费者可以是OIDD的Storm平台，也可以是原来的Hadoop平台。

·消息接收：不同数据源具有不同的数据分析处理逻辑，对于实时信令由Storm平台处理，Storm的spout接收消息或文件内容信息，并送到对应的bolt处理。

·规则匹配：由Storm与关联规则筛选符合规则的数据内容，这些规则可以是对原有数据的更新，也可根据外部应用对数据的订阅需求转化而来，然后输出结果。

·数据输出：数据发送到数据库存储或者根据外部应用的订阅需求触发通知、查询等事件。

4.2 与Hadoop平台融合解决方案

Hadoop 2.0平台中引入了新的资源管理系统YARN[10]，MapReduce、Storm和Spark等组件均可运行在YARN之上，这就为Storm与Hadoop大数据平台整合提供了解决方案。将Storm运行在Hadoop YARN上，Storm与原有Hadoop平台可共享整个集群中的资源，并实现了数据的复用，避免了在多个数据平台上保存同样的数据副本，从而节省了存储资源和跨群复制数据导致的网络开销，也避免了多个集群带来的维护成本。

OIDD平台汇聚运营商网络中多种数据源，实时信令也是OIDD大数据平台需要采集的数据源，基于YARN架构，可以将负责实时信令处理的Storm大数据平台组件整合到原有Hadoop大数据平台中，Storm平台输出的数据仍然入库到已经部署的HDFS/HBase数据库中，从而实现云资源、大数据组件和数据的共享。整合后的大数据平台，原有平台中的数据管理、安全控制、服务封装和业务生命周期管理等模块可以基本保持不变，但Hadoop平台的版本需要升级到YARN，并提供对Storm模块的数据管理、规则配置的接口。融合的大数据平台和组网架构如图9所示。

图9 融合的大数据平台和组网架构

在新的平台组网架构中，数据采集分为ETL组件和流采集组件，实时性要求高的数据通过Flume，由Storm流计算模块实时分析处理，满足对数据时效性要求高的数据业务需求；数据总线基于消息中间件调度，实现基于消息发布订阅的任务调度；大数据平台实现了资源共享，采集的源数据整合加工后仍然保存到共享的统一数据库，因此仍然能够满足原来基于Hadoop的大数据应用。

5 结束语

大数据流式计算和批量计算适用于不同的应用场景。批处理汇聚海量数据分析出的结果可能更精确，但对数据时效性要求严格而对历史数据积累并不非常关注的场景，流式计算具有明显的优势。批量计算和流式计算是有优劣互补的，因此在多种应用场合下可以将两者结合起来使用。

以Hadoop大数据技术为基础的OIDD平台已在现网应用，随着业务开展，业务创新对数据的时效性提出了更高要求。结合流式计算的研究，本文提出了融合流式计算和批量计算的OIDD解决方案，对所需的组件进行了分析和选择，从实验室搭建Flume-ng+Kafka+Storm大数据处理环境，10万条数据可在几秒内完成采集、汇聚、处理端到端过程，大大提高了数据有效性。

大数据流式计算的研究和应用仍处于起步和尝试阶段，为了促进大数据流式计算平台的成熟，还需要在实践中进行试点和完善。

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 孙大为,张广艳,郑纬民.大数据流式计算:关键技术及系统实例.软件学报,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 崔星灿,禹晓辉,刘洋等.分布式流处理技术综述.计算机研究与发展,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