Elasticsearch之深入聚合查询

1、正排索引

1.1 正排索引（doc values ）和倒排索引

概念：从广义来说，doc values 本质上是一个序列化的列式存储。列式存储适用于聚合、排序、脚本等操作，所有的数字、地理坐标、日期、IP 和不分词（ not_analyzed ）字符类型都会默认开启，不支持text和annotated_text类型

区别：

倒排：倒排索引的优势是可以快速查找包含某个词项的文档有哪些。如果用倒排来确定哪些文档中是否包含某个词项就很鸡肋。
正排：正排索引的优势在于可以快速的查找某个文档里包含哪些词项。同理，正排不适用于查找包含某个词项的文档有哪些。

倒排索引和正排索引均是在index-time时创建，保存在 Lucene文件中（序列化到磁盘）。

1.2 正排索引的数据结构

1.2.1 doc values

doc values是正排索引的基本数据结构之一，其存在是为了提升排序和聚合效率，默认true，如果确定不需要对字段进行排序或聚合，也不需要通过脚本访问字段值，则可以禁用doc values值以节省磁盘空间。

1.2.2 fielddata：

概念：查询时内存数据结构，在首次用当前字段聚合、排序或者在脚本中使用时，需要字段为fielddata数据结构，并且创建倒排索引保存到堆中。与 doc value 不同，当没有doc value的字段需要聚合时，需要打开fielddata，然后临时在内存中建立正排索引，fielddata 的构建和管理发生在 JVM Heap中。Fielddata默认是不启用的，因为text字段比较长，一般只做关键字分词和搜索，很少拿它来进行全文匹配和聚合还有排序。

语法：

json 复制代码

PUT /<index>/_mapping
{
  "properties": {
    "tags": {
      "type": "text",
      "fielddata": true  //true：开启fielddata;		false：关闭fielddata
    }
  }
}

**深层解读（独家）：**doc values是文档到词项的映射 inverted是词项到文档id的映射从原理上讲先说倒排索引为什么不适合聚合，你无法通过倒排索引确定doc的总数量，并且因为倒排索引默认会执行analysis，即使聚合，结果也可能不准确，所以你还要创建not_analyzed字段，徒增磁盘占用，举个最简单的例子：假如有一张商品表，每个商品都有若干标签，我们执行了以下查询

json 复制代码

GET product/_search
{
  "query": {
    "match": {
      "tags": "性价比"
    }
  },
  "aggs": {
    "tag_terms": {
      "terms": {
        "field": "tags.keyword"
      }
    }
  }
}

这段聚合查询的意思查询包含"性价比"这个标签商品的所有标签，在执行agg的时候我们使用倒排索引，那么语义将是这样的：在倒排索引中扫描逐个term，看看这个term对用的倒排表中对应的doc的标签是否包含"性价比"，如果包含，则记录，由于我们不确定下面一个term是否符合条件，所以我们就要一个一个的判断，所以就造成了扫表。如果使用正排索引，而正排索引的指的是，doc中包含了哪些词项，也就是当前doc_id=>当前字段所包含的所有词项的映射，我们要查找的是符合条件的doc中所有的标签，那么我们直接根据key（doc_id）去拿values（all terms）就可以了，所以就不用扫表。所以聚合查询使用正排索引效率高本质是两种数据结构的区别和结不结合倒排索引没有关系，结合倒排索引只是预先进行了数据筛选。以上是正排索引在原理上对聚合查询友好的原因下面我说一下关于两种数据结构在数据压缩上的不同，doc values是一种序列化的列式存储结构，其values其中也包含了词频数据。而这种结构是非常有利于数据压缩的，参考第二版VIP课程中的FOR和RBM压缩算法，因为Lucene底层读取文件的方式是基于mmap的，原理是上是从磁盘读取到OS cache里面进行解码的，使用正排索引的数据结构，由于其列式存储的数据和posting list一样可以被高效压缩，所以这种方式极大的增加了从磁盘中读取的速度，因为体积小了，然后把数据在OS Cache中进行解码

2、三角选择原则

3、基数聚合：Cardinality

3.1 易并行算法和不易并行算法

3.1.1 易并行算法

如：Max、Min、Avg、Sum等指标函数，通常只需要在多个分片中计算一个值进行汇总计算，因此不必消耗过多内存资源。（参考深度分页原理）

3.1.2 不易并行算法

如：Cardinality函数，由于无法在不同分片中保证数据是否重合，因此将消耗更多的内存用于数据汇总进行基数聚合，尤其是高基聚合。

3.2 高基数与低基数聚合

高基数：性能低

低基数：性能高

3.3 Cardinality精度内存换算

3.3.1 precision_threshold参数

ES在执行Cardinality聚合的时候，通过precision_threshold参数以内存换精度，默认3000，最大值40000，设置再大的值，实际也最高只能是4W，当小于precision_threshold设置的时候，精度接近100%，当大于此设置的时候，即使数据量有几百万，误差也只是1-6％。

注意：precision_threshold设置较高阈值对低基数聚合时有显著效果，而对高基数聚合是并无显著效果，反而会占用大量的资源，适得其反。

3.3.2 内存精度换算单位

内存消耗 <=> precision_threshold * 8 个Byte，比如 precision_threshold = 1000，内存消耗约 8KB。

3.4 HyperLogLog++介绍

HyperLogLog++（HLL）算法是依赖于field value计算hash，在做cardinality运算的时候，ES会动态为每一个field value计算hash用于提升聚合性能。

3.5 低基聚合的优化方案：maper-murmur3

3.5.1 作用

提升低基聚合的查询性能，副作用是消耗较大磁盘空间。

3.5.2 原理

maper-murmur3提升低基聚合的原理就是通过预先为字段值计算hash，在做cardinality计算的时候，使用提前准备好的hash值参与计算，避免了动态运算从而节省性能，建议在字段基数较大并且可能会有大量重复值得时候使用，这样可能会产生显著的性能提升，不然可能不但不会带来显著的性能提升，而且会徒增磁盘消耗，得不偿失。

3.5.3 安装与使用

安装

bin/elasticsearch-plugin install mapper-murmur3

使用

PUT <index>
{
  "mappings": {
    "properties": {
      "type": {
        "type": "keyword",
        "doc_values": true,
        "fields": {
          "hash": {
            "type": "murmur3"
          }
        }
      }
    }
  }
}
POST /index/_search?size=0
{
  "aggs": {
    "type_count": {
      "cardinality": {
        "field": "type.hash"
      }
    }
  }
}

4、深度优先（DFS）和广度优先（BFS）

4.1 概念和基本原理

背景：Terms 桶基于我们的数据动态构建桶；它并不知道到底生成了多少桶。大多数时候对单个字段的聚合查询还是非常快的，但是当需要同时聚合多个字段时，就可能会产生大量的分组，最终结果就是占用 es 大量内存，从而导致 OOM 的情况发生。

在Elasticsearch中，对于具有许多唯一术语和少量所需结果的字段，延迟子聚合的计算直到顶部父级聚合被修剪会更有效。通常，聚合树的所有分支都在一次深度优先传递中展开，然后才会发生任何修剪。在某些情况下，这可能非常浪费，并且可能会遇到内存限制。

基本原理即：推迟子聚合的计算

4.2 原理

4.3 适用场景及基本用法

4.3.1 用法：Collect mode

"collect_mode": "{collect_mode.value}"

4.3.2 参数

breadth_first：广度优先模式属于最上层桶的一组文档被缓存以备后续重播，因此执行此操作时内存开销与匹配文档的数量成线性关系。即：先做第一层聚合，逐层修剪。
depth_first：即：先构建完整的树，然后修剪无用节点。

4.4 注意

广度优先仅仅适用于每个组的聚合数量远远小于当前总组数的情况下，因为广度优先会在内存中缓存裁剪后的仅仅需要缓存的每个组的所有数据，以便于它的子聚合分组查询可以复用上级聚合的数据。

广度优先的内存使用情况与裁剪后的缓存分组数据量是成线性的。对于很多聚合来说，每个桶内的文档数量是相当大的。