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

共计 2124 个字符，预计需要花费 6 分钟才能阅读完成。

假如有这样一个场景：系统每秒钟都会收到大量的事件，每个事件又包含很多参数，用户不仅需要准实时地还需要定期地判断每一种事件、事件的每一种参数值的组合是否超过了系统设定的阈值。面对这一场景，用户应该采用什么样的方案呢？最近，来自于 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