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

问题背景：

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

原离线方案：

周期性拉取增量时间段内，各词在各渠道内的索引数据，然后进行分时频次统计，复杂度：如果词库大小增长到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体验更多游戏质量服务