ElasticSearch Aggregations 分析

承接上篇文章 ElasticSearch Rest/RPC 接口解析,这篇文章我们重点分析让ES步入数据分析领域的Aggregation相关的功能和设计。

前言

我记得有一次到一家公司做内部分享，然后有研发问我，即席分析这块，他们用ES遇到一些问题。我当时直接就否了，我说ES还是个全文检索引擎，如果要做分析，还是应该用Impala,Phenix等这种主打分析的产品。随着ES的发展，我现在对它的看法，也有了比较大的变化。而且我认为ES+Spark SQL组合可以很好的增强即席分析能够处理的数据规模，并且能够实现复杂的逻辑，获得较好的易用性。

需要说明的是，我对这块现阶段的理解也还是比较浅。问题肯定有不少，欢迎指正。

Aggregations的基础

Lucene 有三个比较核心的概念：

1. 倒排索引
2. fieldData/docValue
3. Collector

倒排索引不用我讲了，就是term -> doclist的映射。

fieldData/docValue 你可以简单理解为列式存储,索引文件的所有文档的某个字段会被单独存储起来。 对于这块，Lucene 经历了两阶段的发展。阶段是fieldData ，查询时从倒排索引反向构成doc-term。这里面有两个问题：

• 数据需要全部加载到内存
• 次构建会很慢

这两个问题其实会衍生出很多问题：严重的自然是内存问题。所以lucene后面搞了DocValue，在构建索引的时候就生成这个文件。DocValue可以充分利用操作系统的缓存功能，如果操作系统cache住了，则速度和内存访问是一样的。

另外就是Collector的概念，ES的各个Aggregator 实现都是基于Collector做的。我觉得你可以简单的理解为一个迭代器就好，所有的候选集都会调用Collector.collect(doc)方法，这里collect == iterate 可能会更容易理解些。

ES 能把聚合做快，得益于这两个数据结构，一个迭代器。我们大部分聚合功能，其实都是在fieldData/docValue 上工作的。

Aggregations 分类

Aggregations种类分为:

1. Metrics
2. Bucket

Metrics 是简单的对过滤出来的数据集进行avg,max等操作，是一个单一的数值。

Bucket 你则可以理解为将过滤出来的数据集按条件分成多个小数据集，然后Metrics会分别作用在这些小数据集上。

对于后聚合出来的结果，其实我们还希望能进一步做处理，所以有了Pipline Aggregations,其实就是组合一堆的Aggregations 对已经聚合出来的结果再做处理。

Aggregations 类设计

下面是一个聚合的例子：

{
    "aggregations": {
        "user": {
            "terms": {
                "field": "user",
                "size": 10,
                "order": {
                    "_count": "desc"
                }
            }
        }
    }
}