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

本帖最后由不会飞的小凯凯于 2016-6-24 16:34 编辑
问题导读：
1.Spark和ElasticSearch怎么解决实时计算瓶颈？
2.Akka和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通过[url=]环形缓冲区[/url]存储最近30分钟的事件数（单位为秒），每过一秒，该缓冲区就滚动一个位置，同时该Actor会计算事件的频率，检查该频率是否超过了系统设定的阈值，并将结果发送到ElasticSearch Actor
ElasticSearch Actor仅仅是一个ActorPublisher，负责将数据发送到[url=]ElasticSearch流驱动[/url]

第二种方案的流程如下：

环形缓冲区的结构如下：

你可能会问，为每一种组合创建一个Actor会不会导致Actor太多？André Camilo告诉我们，对Akka这个超轻量级的事件驱动框架来说这都不是问题。

使用该方案André Camilo在一个i7 4GB的笔记本上轻松解决了800个事件的分离处理。更为重要的是，Akka支持水平扩展，如果系统有更多的参数值组合，或者需要更大的吞吐量，那么只需要增加更多的机器即可。

结论

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