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

本文主要是介绍使用Akka来优化Spark+ElasticSearch的准实时系统，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

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

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

Linux上安装部署ElasticSearch全程记录  http://www.linuxidc.com/Linux/2015-09/123241.htm

Elasticsearch安装使用教程 http://www.linuxidc.com/Linux/2015-02/113615.htm

ElasticSearch 配置文件译文解析 http://www.linuxidc.com/Linux/2015-02/114244.htm

ElasticSearch集群搭建实例  http://www.linuxidc.com/Linux/2015-02/114243.htm

分布式搜索ElasticSearch单机与服务器环境搭建  http://www.linuxidc.com/Linux/2012-05/60787.htm

ElasticSearch的工作机制  http://www.linuxidc.com/Linux/2014-11/109922.htm 

Akka 的详细介绍：请点这里
Akka 的下载地址：请点这里

本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-12/126439.htm

这篇关于使用Akka来优化Spark+ElasticSearch的准实时系统的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---