【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

使用 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:008893
用户头像

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

关注

评论

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

企业专属语言模型与知识图谱:定制化智能解决方案

测吧(北京)科技有限公司

测试

私有版语言模型开发:保障数据隐私与安全

测吧(北京)科技有限公司

测试

深度学习:开启人工智能的未来探索之旅

快乐非自愿限量之名

人工智能 机器学习 深度学习

2023 IoTDB Summit:清安储能技术(重庆)有限公司高级 Java 工程师杨泰贤《IoTDB 在清安云能源数据集成的解决方案》

Apache IoTDB

灌电流与拉电流的含义及电路解析

攻城狮Wayne

第十周作业

大肚皮狒狒

AI数字人直播系统的作用及如何搭建?

青否数字人

一文搞懂设计模式—门面模式

Java随想录

Java 设计模式

Meta Llama 大模型:强大的 AI 能力支持

测吧(北京)科技有限公司

测试

深入了解 Java 方法和参数的使用方法

小万哥

Java 程序人生 编程语言 软件工程 后端开发

第九周作业

大肚皮狒狒

第十一周作业

大肚皮狒狒

Python雪花代码

百度搜索:蓝易云

Python Linux 算法 运维 云服务器

GIT好习惯助你成为更出色的开发者

南城FE

git 开发者 前端 后端 开发工具

扯淡的DevOps,我们开发根本不想做运维!

京东科技开发者

5分钟教你搭建chatgpt,结合midjourney上线即可运营

aiisai

ChatGPT MidJourney chatgpt app

浅谈iPaaS对企业转型的重要性

RestCloud

应用集成 ipaas

《计算机程序设计艺术(第3卷):排序与查找》PDF

程序员李木子

35岁,走出焦虑

芃篙君

#深度思考

流计算不止Flink

WuKongCoder

flink 流式计算 RisingWave

Java:commons-codec实现byte数组和16进制字符串转换

百度搜索:蓝易云

Java Apache Linux 运维 云服务器

程序员金三银四跳槽指南:时间线&经典面试16问

王中阳Go

面试技巧 金三银四 跳槽 跳槽技巧 面试攻略

GaussDB通信运维:详解stream连接池设计原理

华为云开发者联盟

数据库 华为云 华为云GaussDB 华为云开发者联盟 华为云GaussDB(DWS)

聊聊PowerJob的CleanService

伤感汤姆布利柏

Frappe RestAPI 的filters的写法

麦兜

Linux系统中“sid”是什么意思?

百度搜索:蓝易云

云计算 Linux 运维 云服务器

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