写点什么

使用 Akka 来优化 Spark+ElasticSearch 的准实时系统

  • 2015-12-17
  • 本文字数:1562 字

    阅读完需:约 5 分钟

假如有这样一个场景:系统每秒钟都会收到大量的事件,每个事件又包含很多参数,用户不仅需要准实时地还需要定期地判断每一种事件、事件的每一种参数值的组合是否超过了系统设定的阈值。面对这一场景,用户应该采用什么样的方案呢?最近,来自于 Premium Minds 的软件架构师 André Camilo 在博客上发表了一篇文章,介绍了他们是如何使用 Akka 解决这一棘手问题的

在该文章中 André Camilo 首先介绍了他们的应用场景:

我们的系统每秒钟最多会收到几百个事件,有些事件有 8 个参数,有些事件有超过 240,000 个参数值的组合(* 假如有一个 PhoneCall(phoneNumber, countryCode, geoZone) 事件,该事件有三个参数,其中 phoneNumber 有 4,000 个值, countryCode 有 5 个值,geoZone 有 10 个值,那么可能的参数值组合约为 (4000+1)(5+1)(10+1)=240k 个 *),我们不仅需要实时地判断这些事件以及参数值的组合是否超过了系统设定的阀值,还要保留最近 30 分钟的数据,以便于判断在这段时间内它们出现的频率是否也超过了阀值。

处理该问题最简单的方式或许就是将这些数据都存起来,然后每隔一秒钟就去计算每一种组合出现的频率,但是事实上这是无法实现的,因为这样每秒钟会有超过 240,000 个查询,系统是无法承受的。 André Camilo 给出的第一种方案是使用 Spark 和 ElasticSearch:

我们创建了一个 Spark Streaming 的数据流管道,该管道首先从 JMS 队列中读取消息并将其转换成 PhoneCall 事件,然后根据事件的参数值将一个事件分离成多个事件,之后再使用 countByWindow 函数计算每一种事件组合的频率,最后检查每种组合的平均频率是否超过了阈值。在使用 countByWindow 计算时,每秒钟都会设置一个 30 分钟的窗口,同时函数输出值会除以 1800 秒以得到每个窗口的平均频率,最终结果使用 ElasticSearch 集群存储。

该方案的流程如下:

这一方案虽然可行,但是并没有解决 André Camilo 的问题,不是因为 Spark 不行,而是因为虽然 Spark Streaming 能够处理大量的实时数据,但是却无法处理大量的窗口。在 André Camilo 的实验中,如果组合数低于 1000,那么这种方案能够工作的很好,但是如果超出了这一数量,那么就会导致内存溢出问题。

André Camilo 给出的第二种方案是使用 Akka

  • 对每一种参数值的组合创建一个组合 Actor
  • 创建一个负责接收所有事件的 Actor,该 Actor 根据事件的参数值将一个事件分离成多个事件,并根据参数组合的对应关系将分离后的事件发送到步骤 1 创建的组合 Actor
  • 每一个组合 Actor 通过环形缓冲区存储最近 30 分钟的事件数(单位为秒),每过一秒,该缓冲区就滚动一个位置,同时该 Actor 会计算事件的频率,检查该频率是否超过了系统设定的阈值,并将结果发送到 ElasticSearch Actor
  • ElasticSearch Actor 仅仅是一个 ActorPublisher,负责将数据发送到 ElasticSearch 流驱动

第二种方案的流程如下:

环形缓冲区的结构如下:

你可能会问,为每一种组合创建一个 Actor 会不会导致 Actor 太多?André Camilo 告诉我们,对 Akka 这个超轻量级的事件驱动框架来说这都不是问题。使用该方案 André Camilo 在一个 i7 4GB 的笔记本上轻松解决了 800 个事件的分离处理。更为重要的是,Akka 支持水平扩展,如果系统有更多的参数值组合,或者需要更大的吞吐量,那么只需要增加更多的机器即可。

最后,André Camilo 的结论是:Spark 有非常好的特性,它的解决方案更简单、更直观,但不太适合这个场景。Akka 非常适合处理 CPU 敏感的问题,Actor 模型更适合处理高并发的问题。


感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。

2015-12-17 18:009039
用户头像

发布了 321 篇内容, 共 120.0 次阅读, 收获喜欢 19 次。

关注

评论

发布
暂无评论
发现更多内容

基于Verilog HDL的状态机描述方法

timerring

FPGA

试试 IntelliJ IDEA 新的 UI

HoneyMoose

2022阿里云技术年报:基础产品篇

阿里巴巴云原生

阿里云 云原生 基础产品

核心应用实现云原生改造升级,波司登数字化战略加速落地

阿里巴巴云原生

阿里云 云原生

Java 中如何限制方法的返回时间

HoneyMoose

C++ 友元与运算符重载那些事

王玉川

c++ 编程语言 运算符 重载 friend

ChatGPT真的可以取代基础工作岗位吗?

老张

人工智能 产业发展 ChatGPT

Higress + Nacos 微服务网关最佳实践

阿里巴巴云原生

阿里云 云原生 nacos Higress

基于SLO告警(Part 4):开源项目 pyrra 使用

Grafana 爱好者

云原生 可观测性 Prometheus SRE SLO

从 JDK 9 到 19,我们帮您提炼了和云原生场景有关的能力列表(上)

阿里巴巴云原生

阿里云 云原生

重磅发布丨《云原生实战指南》助力企业上云实践!

阿里巴巴云原生

阿里云 云原生实战

OpenMMLab图像分类实战代码演示

IT蜗壳-Tango

CV OpenMMLab 图片分类

架构训练营模块七作业

张建闯

架构实战营

docker setup mysql

平凡人生

MySQL

全景剖析阿里云容器网络数据链路(五):Terway ENI-Trunking

阿里巴巴云原生

阿里云 容器 云原生

Java高手速成 | Hibernate的配置文件与JPA API的基本用法

TiAmo

hibernate jpa api 网关

突破边界:“超融合+”带来的商业化精益之路

脑极体

IntelliJ IDEA 修改只读模式和可写模式

HoneyMoose

10 亿月活用户下,快手基于 Dragonfly 的超大规模镜像分发实践

阿里巴巴云原生

阿里云 容器 云原生

设计「业务」与「技术」方案

Java 架构 技术 业务

为什么在容器中 1 号进程挂不上 arthas?

阿里巴巴云原生

Java 阿里云 容器 云原生

CleanMyMac X2023电脑最新版本更新内容

茶色酒

CleanMyMac X CleanMyMac X2023

应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践

阿里巴巴云原生

阿里云 容器 云原生 KubeVela

架构实战营模块5 高性能高可用计算作业

西山薄凉

「架构实战营」

架构训练营模块8

张建闯

架构实战营

图片竟能直接生成逼真音效?这AI模型也太神奇了吧!

科技热闻

推进行业生态发展完善,中国信通院第八批RPA评测工作正式启动

王吉伟频道

RPA 机器人流程自动化 中国信通院 RPA评测 RPA产业推进方阵

IntelliJ IDEA 撤销和反撤销

HoneyMoose

vue实现一个鼠标滑动预览视频封面组件(精灵图版本)

JYeontu

Vue 视频

C# 如何部分加载“超大”解决方案中的部分项目

newbe36524

C# Docker Kubernetes

技术服务深耕本地市场:阿里云在日本的探索与实践|国家经理专栏

阿里巴巴云原生

阿里云 云原生

使用Akka来优化Spark+ElasticSearch的准实时系统_语言 & 开发_孙镜涛_InfoQ精选文章