用 Akka 解决 Spark + ElasticSearch 实时计算平台的瓶颈 有更新!

  |   0 评论   |   720 浏览

    应用场景

    假如有这样一个场景:系统每秒钟都会收到大量的事件,每个事件又包含很多参数,用户不仅需要准实时地还需要定期地判断每一种事件、事件的每一种参数值的组合是否超过了系统设定的 阈值

    面对这一场景,用户应该采用什么样的方案呢?最近,来自于 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 给出的第一种方案是使用 SparkElasticSearch

    我们创建了一个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模型更适合处理高并发的问题。

    评论

    发表评论

    validate