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

应用场景

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

面对这一场景，用户应该采用什么样的方案呢？最近，来自于 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模型更适合处理高并发的问题。

大数据杂谈  

ID：BigdataTina2016