【干货预警】kafka+sparkstreaming搭建流计算引擎

在使用sparkstreaming的过程中,最大的难点在于对spark分布式计算编程范式的理解

问题背景:

词频统计问题,计算定制词库里,各个关键词,在各渠道内,分时段的频次

原离线方案:

周期性拉取增量时间段内,各词在各渠道内的索引数据,然后进行分时频次统计,复杂度:如果词库大小增长到10w,渠道数达到5000,那么就需要5亿次/轮的索引查询开销。该方案下,词频统计相关模块的数据更新时效性很低,一般在天级。

 

优化目标:

1.减少不断大量查询索引的开销(影响线上服务)

2.提高词频更新时效性与抓取时效性达到统一级别(分钟级)

3.均匀化高峰期密集写入数据库的压力

 

思考方案:

1.查询索引 --> 原始数据

对于词频统计这样的计算型需求,其实没有必要使用索引资源进行单个文档定位,而是直接可以用原始文本直接进行统计

2.离线计算 --> 实时计算

在对比离线(map-reduce)和实时(spark、strom)方案的时候,主要考虑到,词频计算具有独立性,无需进行类似join或全局计算的需要。而map-reduce需要从各个节点加载数据,IO和网络开销很大。而原始数据在采集以后,本身就要写入hbase,完全可以利用其缓存直接执行各类计算。

采用实时计算,还应该保证:1.采集模块无需阻塞等待计算完成,2.新增数据总要保证可以完成计算,并且仅计算一次,3.可以错开数据到来的高峰期,以均匀的节奏执行计算,并结果入库。

 

问题扩展

从词频统计的问题出发,经过思考,发现其实需要的是一个高可用性和高效性的流式计算引擎,该引擎还可以完成其他的非阻塞实时计算任务,包括数据统计分析、业务日志统计和后台日志实时监控。

 

技术选型

在技术选型调研的时候,优先考虑以下几个方面

1.高写入吞吐量,随着我们爬虫数据采集能力的大幅提升,数据高峰期的写入量也大大增加,需要保证O(1)的写入延迟以及高并发能力

2.可扩展性,数据渠道不断增加,承载需求也会增加,无论从接入能力、计算能力、存储能力上都要具有足够的扩展性

3.可用性,最好有成熟的应用背景

4.简易性,开发文档需要完备,学习成本、部署成本和开发成本都要低。

基于这些原则,在数据收集端,对比了scribe、flume、chukwa、kafka以及其他的一些Mq技术,在数据计算端,主要是对比了spark和storm技术。最后选择在linkedin有成熟应用的kafka+sparkstreaming的流计算架构,在生产者端使用C++的librdkafka接口,在消费者端使用python进行开发。

实际方案说明

如图所示,各个Spider、业务Log、后台Log的生产者数据,以O(1)时间直接push到kafka进行消息持久化,SparkStreaming负责订阅kafka里的消息,并随后按批次去除消息执行消费者任务,每个批次的计算结果直接写入数据库或文件系统。

 

Kafka负责对消息进行可靠容错拷贝,与sparkstreaming之间保持at least-processed-once原语(即每条数据保证至少被处理一次),我们可以在业务逻辑里实现exactly-processed-once原语,即保证数据不会被重复计算。

利用SparkStreaming里丰富的map-reduce原语,我们可以高效的对数据进行多维度的groupby,通过并行化来提高计算吞吐量。比如我们有很多按渠道、按词进行统计的场景,可以对渠道、关键词进行分组并行计算。

词频统计的逻辑示意图如下:

 

 

1.爬虫抓取的原始数据,将渠道、内容、时间信息实时push到kafka

2.Sparkstreaming以5分钟为周期(一个batch)(时间粒度可配置)订阅数据,并将每个batch的数据按照渠道聚合:<渠道1,[content1,content 2,…]>, <渠道2,[content 1,content 2…]>

3.将每个渠道的数据再按照各个关键词进行聚合并计数:<word1, count1>, <word2, count2>

4.将各个渠道的新增词频更新到存储中供查询。

这种方案下,词频的时效性可以达到N+TC(s),其中N是batch数量,TC是每次的统计开销,如选则N为5s,那么统计结果的时效性可以达到采集时效性的5分钟。

 

实测性能:

24核Intel(R)Xeon(R)CPU E5-26400@2.5GHz,64G,采用C++ librdkafka的生产者串行写入消息,性能10w次/s

单机轻松支撑8000TPS的统计业务。

 

总结:

其实本次流计算方案从调研到开发,只用了两周的时间,但是能够带来不错的业务提升,整体来说性价比不错。对于开源技术框架的选择,其关键是前期充分调研和对比各种成熟方案的优势,并且考虑现有业务的语言和框架,来选择最佳实践。

在使用sparkstreaming的过程中,最大的难点在于对spark分布式计算编程范式的理解,需要清楚每一步transfer或action的计算上下文,合理利用数据并行化和持久化能力提升效率,充分采用资源池技术减少开销等。

目前对spark和streaming的理解还处于初级阶段,后面还需要不断学习深入理解,使得能够在更多业务场景落地发挥价值。

 

腾讯WeTest舆情出品:wetest.qq.com/bee/

 

讯WeTest官网: http://wetest.qq.com/

腾讯WeTest是腾讯游戏官方推出的一站式游戏测试平台,与全民突击、天天酷跑、全民超神等精品手游强强联手深入合作,十余年来不断为游戏提供优秀测试方案和测试工具,是推动腾讯游戏研发效率不断提升、对游戏开发的全生命周期进行质量保障的重要平台。

长按二维码关注腾讯WeTest微信公众号

或者访问wetest.qq.com体验更多游戏质量服务

最新文章
1客户案例研究:小程序资产排查,助力政务机构属地网络安全监管 排查全部小程序/公众号资产清单,摸清资产底数,确保信息资产安全。
2WeTest MTSC赠票活动中奖名单公布 近日,WeTest MTSC赠票活动圆满结束,经过紧张的统计与筛选,以下朋友们中奖,成功获得了我们的门票礼品。
3海外本地化测试的全生命周期服务 第一期 深入案例,探讨Wetest本地化网络测试、支付测试、功能测试为各行业出海客户带来的价值
4文档解析:WeTest安全扫描白皮书前瞻 近期,WeTest安全扫描白皮书正式发布,旨在全面介绍应用安全扫描产品。本文将带您快速前瞻白皮书的核心内容。
5一张图了解WeTest PC&主机游戏测试服务 WeTest PC&主机游戏测试服务是提供游戏兼容、性能、合规、X-Automator等服务的一站式解决方案,精准解决游戏开发者的四大焦虑。
购买
客服
反馈