图10 4G DPI实时统计项目性能

5.2 存在的问题

在4G DPI实时统计项目开发过程中，随着项目的需求越来越多，后面增加了对域名和CGI的去重，而且同一域名或者CGI不在同一Kafka分区，导致结果有偏差。为了解决这一问题，程序设计了二次去重，第一次去重的结果把CGI或者域名作为key输出到Kafka集群，再做了一次去重工作，导致延迟时间变大和系统维护变复杂。

由于宽带DPI处理中不涉及去重，只是数据过滤和数据转换，因此Kafka Stream是非常适合的。但在涉及分区和去重的4G DPI实时统计项目中，应当采用Storm作为流式处理框架。在Storm中，数据从一个bolt流到另外一个bolt，这样数据可以在一个bolt中按手机号码分区，在另外一个bolt中又可以按CGI或者域名分区，可以避免二次去重问题，降低编程模型复杂度。

在程序设计之初，应根据应用场景需求选择合适的技术框架。如果项目基础结构中涉及Spark，那Spark Streaming是不错的选择；如果像4G DPI实时统计项目一样需要数据转移或者去重，那么Storm是首选；如果是简单的数据清洗和转换处理，那么Kafka Stream是不错的选择。对于简单小规模的实时统计，PipeLineDB足以胜任。

6 结束语

大数据流式计算和批处理适用于不同的业务场景，在对时效要求高的场景下，流式计算具有明显的优势。本文首先概述了流式处理以及其与批处理的区别，然后对业界流行的流式计算框架进行了对比，根据业务需求提出了以Kafka Stream为流式处理框架的DPI数据处理方案，搭配Kafka、Flume及ELK等组件，具有入门迅速、编程难度低和部署维护简单等特点。并且将方案应用到了宽带DPI处理项目以及4G DPI实时统计项目中，完成了任务需求，性能优异，运行稳定。

在对实际项目实践中，随着任务需求的增多，发现Kafka Stream在应对多维度数据去重问题时表现不力，需要引入二次过滤来解决问题。因此在项目需求阶段，便要在技术框架选型时充分考虑可能出现的问题，结合技术框架适用场景，综合考虑。

[1] Zikopoulos P, Eaton C. Understanding Big Data: Analytics for Enterprise Class Hadoop and Streaming Data[M]. McGraw-Hill Osborne Media, 1989.

[2] 陈康,付华峥,陈翀,等. 基于DPI的用户兴趣实时分类[J]. 电信科学, 2016,32(12): 109-115.

[3] 孙大为,张广艳,郑纬民. 大数据流式计算:关键技术及系统实例[J]. 软件学报, 2014,25(4): 839-862.

[4] 董斌,杨迪,王铮,等. 流计算大数据技术在运营商实时信令处理中的应用[J]. 电信科学, 2015,31(10): 165-171.

[5] Marz N,Warren J. Big Data: Principles and best practices of scalable realtime data systems[M]. Manning, 2015.

[6] 李祥池. 基于ELK和Spark Streaming的日志分析系统设计与实现[J]. 电子科学技术, 2015,2(6): 674-678.

[7] 李圣,黄永忠,陈海勇. 大数据流式计算系统研究综述[J]. 信息工程大学学报, 2016,17(1): 88-92.