Elasticsearch与hadoop比较

过去的几年的日志分析领域，开源搜索引擎Elasticsearch已经变得越来越流行。它与其开源的服务器端的日志收集产品Logstash，其开源可视化工具kibana一起组成了ELK分析组合。这个功能强大的组合正蓄势待发。

 

Elasticsearch是一个基于Lucene的分布式搜索服务器。它存储json格式的文档数据，有基于RESTful的操作接口。利用Elasticsearch可以方便的在任何Web应用中集成搜索应用。另外它更有出色的聚合功能（aggregation），能轻松的对数据进行统计分析 ，这一点上Elasticsearch已经超越了其最初的纯搜索引擎的角色，但是如果真正用它来做为复杂的数据分析工具，它能打败hadoop或spark吗？

 

Elasticsearch流行的原因

 

1. Elasticsearch集群实例很容易搭建。

2. 基于json格式的查询语言比开发MapReduce或spark系统更容易掌握。

3. 开发人员可以很方便的将Elasticsearch集成到Hadoop中。

 

这些都是非常引人注目的特性，利用Elasticsearch能快速搭建起一套分析系统。但是否可以认为Elasticsearch就是一个高度可用的数据分析平台了?要成为一个成熟的高可用的数据分析平台，一个高可用的数据存储系统和一套可以支撑复杂数据的计算框架是必不可少的。

 

对于分布式数据存储，Elasticsearch集群中的数据一致性，正是我们担心的问题之一。正常情况下，集群中所有的节点，应该对集群中master的选择是一致的，这样获得的状态信息也应该是一致的，由于Elasticsearch集群中每个节点都是状态维护者，在集群中网络不稳定的情况下就有可能出现集群脑裂（不同的节点对master节点的选择出现了异常）。如图所示正常环境下的Elasticsearch集群。

 

 

当出现网络异常时，主节点丢失，不同的节点对master节点的选择出现了异常。

 

 

这意味着如果要保证数据的一致性和完整性，我们必须把数据储存在一个更可靠的数据库中。

 

与Elasticsearch不同，在Hadoop 里中有效的避免了脑裂情况的出现。如下图

 

 

主namenode维护datanode状态，主备namenode同步信息；保证任何时刻保证只使用一个主namenode来管理集群中的datanode状态。

 

Elasticsearch拥有功能强大的聚合统计和全文搜索功能，可以轻松的用于网络问题分析，如404错误计数，页面浏览量，用户访问统计信息等。但它缺少类似标准SQL中的join或子查询的功能。Elasticsearch不支持查询结果的额外处理或分析的中间数据的输出，也不支持数据集的转换（即一个100万行的表，使用分析处理后，成为另一个100万行的表），故不太适合处理复杂的计算逻辑。

 

相反利用Hadoop的mapreduce或者spark计算框架，我们可以支持处理任何数据聚合和转换工作；我们还可以使用hive或spark SQL来降低我们的开发难度。

 

虽然Elasticsearch存在这些问题，但是它仍然是一个非常优秀的分布式计算框架，而且Elasticsearch可以非常方便的集成在hadoop中，我们也可以用它优秀的数据检索能力来构造自己的查询系统；同时Elasticsearch仍然在不停的版本迭代中，相信未来的版本中Elasticsearch会一步步解决这些问题。