Elasticsearch聚集查询（七）

最新推荐文章于 2024-07-30 15:49:30 发布

融极

最新推荐文章于 2024-07-30 15:49:30 发布

阅读量1.8k

点赞数

分类专栏： ElasticStack 文章标签： elasticsearch 大数据 big data

本文链接：https://blog.csdn.net/tianzhonghaoqing/article/details/124556415

版权

ElasticStack 专栏收录该内容

23 篇文章 6 订阅

订阅专栏

概述

聚集查询（Aggregation）提供了针对多条文档的统计运算功能，它不是针对文档本身内容的检索，而是要将它们聚合到一起运算某些方面的特征值。聚集查询与SQL语言中的聚集函数非常像，聚集函数在Elasticsearch中相当于是聚集查询的一种聚集类型。比如在SQL中的avg函数用于求字段平均值，而在Elasticsearch中要实现相同的功能可以使用avg聚集类型。
聚集查询也是通过_search接口执行，只是在执行聚集查询时使用的参数是aggregations或aggs。所以_search接口可以执行两种类型的查询，一种是通过query参数执行DSL，另一种则是通过aggregations执行聚集查询。这两种查询方式还可以放在一起使用，执行逻辑是先通过DSL检索满足查询条件的文档，然后在使用聚集查询对DSL检索结果做聚集运算。这一规则适用于本章列举的所有聚集查询。聚集查询有着比较规则的请求结果，具体格式如下：7-1 聚集查询格式

"aggregations/aggs":{
	"<聚集名称>":{
		"聚集类型":{
			<聚集体>
		}
		[,"meta":{[<元数据体>]}]?
		[,"aggregations/aggs":{[<子聚集>]+}]?
	}
	[,"<聚集名称>":{...}]*
}

aggregations和aggs都是_search的参数，其中aggs是aggregations的简写。每一个聚集查询都需要定义一个聚集名称，并归属于一种聚集类型。聚集名称是用户自定义的，而聚集类型则是由Elasticsearch预先定义好。聚集名称会在返回结果中标识聚集结果，而聚集类型则决定了聚集将如何运算。比如前面提到的avg就是一种聚集类型。这里要特别强调的是，聚集中可以再包含子聚集，如示例7-1中第7行所示。子聚集位于父聚集的名称中，与聚集类型同级，所以子聚集的运算都是在父聚集的环境中运算。Elasticsearch对子聚集的深度没有做限制，所以理论上说可以包含无限深度的子聚集。
聚集类型总体上被分为四种大类型，即指标聚集（Metrics Aggregation）、桶型聚集（Bucket Aggregation）、管道聚集（Pipeline Aggregation）和矩阵聚集（Matrix Aggregation）。指标聚集是根据文档字段所包含的值运算某些统计特征值，如平均值、总和等，它们的返回结果一般都包含一个或多个数值，前面提到的avg聚集就是指标聚集的一种。桶型聚集是根据一定的分组标准将文档归到不同的组中，这些分组在Elasticsearch中被称为桶（Bucket）。桶型聚集与SQL中group by的作用类似，一般会与指标聚集嵌套使用。管道聚集可以理解为是聚集结果的聚集，它一般以另一个聚集结果作为输入，然后在此基础上再做聚集。矩阵聚集是Elasticsearch中的新功能，由于是针对多字段做多种运算，所以形成的结果类似于矩阵而得名。

7.1指标聚集

指标聚集是根据文档中某一字段做聚集运算，比如计算所有产品销量总和、平均值等等。指标聚集的结果可能是单个值，这种指标聚集称为单值指标聚集；也可能是多个值，称为多值指标聚集。

7.1.1 平均值聚集

平均值聚集是根据文档中数值类型字段计算平均值的聚集查询，包括avg聚集和weighted_avg聚集两种类型。avg聚集直接取字段值后计算平均值，而weighted_avg聚集则会在计算平均值时添加不同的权重。

1.avg聚集

avg聚集计算平均值有两种方式，一种是直接使用字段值参与平均值运算，还有一种是使用脚本运算的结果参与平均值运算。例如在示例7-2中计算航班的平均延误时间：7-2 avg聚集

POST kibana_sample_data_flights/_search?filter_path=aggregations
{
  "aggs":{
    "delay_avg":{
      "avg":{
        "field":"FlightDelayMin"
      }
    }
  }
}

在示例7-2中使用了请求参数filter_path将返回结果的其他字段过滤掉了，否则在查询结果中将包含kibana_sample_data_flights索引中所有的文档。加了filter_path之后返回的结果为：7-3 avg聚集返回结果

{
  "aggregations" : {
    "delay_avg" : {
      "value" : 47.33517114633586
    }
  }
}

在返回结果中，aggregations是关键字，代表这是聚集查询的结果。其中的delay_avg则是在聚集查询中定义的聚集名称，value是聚集运算的结果。在示例7-2中运算算航班延误时间时会将所有文档都包含进来做计算，如果只想其中一部分文档参与运算则可以使用query参数以DSL的形式定义查询条件。例如在示例7-4中就是只计算了飞往中国的航班平均延误时间：7-4 query和aggs同时使用

POST kibana_sample_data_flights/_search?filter_path=aggregations
{
  "query":{
    "match": {
      "DestCountry": "CN"
    }
  },
  "aggs":{
    "delay_avg":{
      "avg":{
        "field":"FlightDelayMin"
      }
    }
  }
}

在示例7-4中请求_search接口时，同时使用了query与aggs参数。在执行检索时会先通过query条件过滤文档，然后再在符合条件的文档中运算平均值聚集。
avg聚集也可以使用Painless脚本指定参与平均值运算的值，可使用script参数设置脚本。例如示例7-5中的请求是用延误时间除以飞行时间的值参与平均值运算，相当于平均每小时延误时间：

POST /kibana_sample_data_flights/_search?filter_path=aggregations
{
  "aggs":{
    "delay_per_hour_avg":{
      "avg":{
        "script": {
          "source":"""
          if(doc.FlightTimeMin.value != 0) 
           doc.FlightDelayMin.value*60/doc.FlightTimeMin.value 
          """
          
        },
        "missing": 0
      }
    }
  }
}

在示例7-5中使用了missing参数，用于设置文档缺失值时的默认值。由于FlightTimeMin的值有些是0，所以在做除数时会报错，因此做了判断以排除。

weighted_avg聚集

weighted_avg聚集在运算平均值时，会给参与平均值运算的值一个权重，权重越高对最终结果的影响越大，而权重越低影响越小。最终平均值遵照下面的公式计算：
在这里插入图片描述
前面介绍的avg聚集可以认为是权重值都为1的加权平均值运算，权重值可以从文档的某一字段中获取，也可以通过脚本运算。例如，根据航班飞行时间调整延误时间的权重值，飞行时间越短权重越高：

weighted_avg使用参数value设置参与平均值运算的值，而weight参数则用于设置这个值的权重。在示例7-6中，参与平均值运算的是延误时间即FlightDelayMin字段，权重值则由飞行时间即FlightTimeMin字段决定，飞行时间大于2h的权重为1，飞行时间小于2h的为2。

7.1.2 计算聚集与极值聚集

计数聚集用于统计字段值的数量，而极值聚集则是查找字段的极大值和极小值，它们都支持使用脚本。

1. 计数聚集

value_count聚集和cardinality聚集可以归入计数聚集中，前者用于统计从字段中取值的总数，而后者则用于统计不重复数值的总数。例如：
在这里插入图片描述
在示例7-7中，cardinality聚集统计了DestCountry字段非重复值的数量，类似于SQL中的distinct。value_count聚集则统计了DestCountry字段所有返回值的数量，类似于SQL中的count。
需要注意的是，cardinality聚集采用HyperLogLog+算法实现基数统计，这个算法使用极小内存实现统计结果的基本准确。所以cardinality在数据量极大的情况下是不能保证完全准确的。

2.极值聚集

极值聚集是在文档中提取某一字段最大值或最小值的聚集，包括max聚集和min聚集。例如：
在这里插入图片描述
示例7-8中的聚集有max_price和min_price两个，它们分别计算了机票价格的最大值和最小值。

7.1.3 统计聚集

统计聚集是一个多值指标聚集，也就是返回结果中会包含多个值，都是一些与统计相关的数据。统计聚集包含stats聚集和extended_stats聚集两种，前者返回的统计数据是一些比较基本的数值，而后者则包含一些比较专业的统计数值。

1.stats聚集

stats聚集返回结果中包括字段的最小值（min）、最大值（max）、总和（sum）、数量（count）及平均值（avg）五项内容。例如，在示例7-9中对机票价格做统计：
在这里插入图片描述
在示例7-9中，stats聚集使用field参数指定参与统计运算的字段为AvgTicketPrice，也可以通过script参数设置脚本计算参与统计的值。

2.extends_stats聚集

extended_stats聚集增加了几项统计数据，这包括平方和、方差、标准方差和标准方差偏移量。从使用的角度来看，extended_stats聚集与stats聚集完全相同，只是聚集类型名称不同。如果将示例7-9中的聚集类型stats替换为extended_stats，则返回的结果为
在这里插入图片描述
新增的字段中，sum_of_squares代表平方和，variance代表方差，std_deviation代表标准方差。std_deviation_bounds包含两个子字段upper和lower，upper代表标准方差偏移量的上限，而lower则代表标准方差偏移量的下限。

7.1.4 百分位聚集

百分位聚集根据文档字段值统计字段值按百分比的分布情况，包括percentiles聚集和percentile_ranks两种。前者统计的是百分比与值的对应关系，而后者正好相反统计值与百分比的对应关系。百分位聚集可以针对字段，也可以使用脚本取值。
在这里插入图片描述
percentiles聚集通过percents参数设置一组百分比，然后按值由小到大的顺序划分不同区间，每个区间对应一个百分比。percentile_ranks聚集则通过values参数设置一组值，然后根据这些值分别计算落在不同值区间的百分比。以示例7-11返回的结果为例：
在这里插入图片描述
在percentiles返回结果price_percentile中，“＂25.0＂：410.0127977258341”代表的含义是25%的机票价格都小于410.0127977258341，其他以此类推。在percentile_ranks返回结果price_percentile_rank中，“＂600.0＂：45.39892372745635”代表的含义是600.0以下的机票占总机票价格的百分比为45.39892372745635%。

7.2使用范围分桶

如果使用SQL语言类比，桶型聚集与SQL语句中的group by子句极为相似。桶型聚集（Bucket Aggregation）是Elasticsearch官方对这种聚集的叫法，它起的作用是根据条件对文档进行分组。读者可以将这里的桶理理解为分组的容器，每个桶都与一个分组标准相关联，满足这个分组标准的文档会落入桶中。所以在默认情况下，桶型聚集会根据分组标准返回所有分组，同时还会通过doc_count字段返回每一桶中的文档数量。
由于单纯使用桶型聚集只返回桶内文档数量，意义并不大，所以多数情况下都是将桶型聚集与指标聚集以父子关系的形式组合在一起使用。桶型聚集作为父聚集起到分组的作用，而指标聚集则以子聚集的形式出现在桶型聚集中，起到分组统计的作用。比如将用户按性别分组，然后统计他们的平均年龄。
按返回桶的数量来看，桶型聚集可以分为单桶聚集和多桶聚集。在多桶聚集中，有些桶的数量是固定的，而有些桶的数量则是在运算时动态决定。由于桶型聚集基本都是将所有桶一次返回，而如果在一个聚集中返回了过多的桶会影响性能，所以单个请求允许返回的最大桶数受search.max_bucket参数限制。这个参数在7.0之前的版本中默认值为-1，代表没有上限。但在Elasticsearch版本7中，这个参数的默认值已经更改为10000。所以在做桶型聚集时要先做好数据验证，防止桶数量过多影响性能。
桶型聚集的种类非常多，为了便于读者记忆，从本节开始将分按照它们的类型分几个小节讲解。本小节主要介绍使用范围分桶的聚集，包括根据数据定义范围和根据间隔定义范围两种，过滤器从某种意义上来说也是一种范围，所以也放在本小节讲解。

7.2.1数值范围

range、date_range与ip_range这三种类型的聚集都用于根据字段的值范围内对文档分桶，字段值在同一范围内的文档归入同一桶中。每个值范围都可通过from和to参数指定，范围包含from值但不包含to值，用数学方法表示就是［from，to)。在设置范围时，可以设置一个也可以设置多个，范围之间并非一定要连续，可以有间隔也可以有重叠。

1.range聚集

range聚集使用ranges参数设置多个数值范围，使用field参数指定一个数值类型的字段。range聚集在执行时会将该字段在不同范围内的文档数量统计出来，并在返回结果的doc_count字段中展示出来。例如统计航班不同范围内的票价数量，可以按示例7-13的方式发送请求：
在这里插入图片描述
在返回结果中，每个范围都会包含一个key字段，代表了这个范围的标识，它的基本格式是“-”。如果觉得返回的这种key格式不容易理解，可以通过在range聚集的请求中添加keyed和key参数定制返回结果的key字段值。其中keyed是ranges的参数，用于标识是否使用key标识范围，所以为布尔类型；key参数则是与from、to参数同级的参数，用于定义返回结果中的key字段值。

2.data_range聚集

date_range聚集与range聚集类似，只是范围和字段的类型为日期而非数值。date_range聚集的范围指定也是通过ranges参数设置，具体的范围也是使用from和to两个子参数，并且可以使用keyed和key定义返回结果的标识。date_range聚集与range聚集不同的是多了一个指定日期格式的参数format，可以用于指定from和to的日期格式。例如：
在这里插入图片描述

3.ip_range聚集

ip_range聚集根据ip类型的字段统计落在指定IP范围的文档数量，使用的聚集类型名称为ip_range。例如在示例7-15中，统计了两个IP地址范围的文档数量：
在这里插入图片描述

7.2.2间隔范围

histogram、date_histogram与auto_date_histogram这三种聚集与上一节中使用数值定义范围的聚集很像，也是统计落在某一范围内的文档数量。但与数值范围聚集不同的是，这三类聚集统计范围由固定的间隔定义，也就是范围的结束值和起始值的差值是固定的。

1.histogram聚集

histogram聚集以数值为间隔定义数值范围，字段值具有相同范围的文档将落入同一桶中。例如示例7-16以100为间隔做分桶，可以通过返回结果的doc_count字段获取票价在每个区间的文档数量：
在这里插入图片描述
其中，interval参数用于指定数值间隔必须为正值，而offset参数则代表起始数值的偏移量，必须位于［0，interval）范围内。order参数用于指定排序字段和顺序，可选字段为_key和_count。当keyed参数设置为true时，返回结果中每个桶会有一个标识，标识的计算公式为bucket_key=Math.floor((value-offset)/interval)*interval+offset。

2.date_histogram聚集

date_histogram聚集以时间为间隔定义日期范围，字段值具有相同日期范围的文档将落入同一桶中。同样，返回结果中也会包含每个间隔范围内的文档数量doc_count。例如统计每月航班数量：
在这里插入图片描述
在示例7-17中使用参数interval指定时间间隔为month，即按月划分范围。时间间隔可以是表7-1中的9种形式之一。

3.auto_date_histogram聚集

前述两种聚集都是指定间隔的具体值是多少，然后再根据间隔值逐一返回每一桶满足条件的文档数。最终会有多少桶取决于两个条件，即间隔值和字段值在所有文档中的实际跨度。反过来，如果预先指定需要返回多少个桶，那么间隔值也可以通过桶的数量以及字段值跨度共同确定。auto_date_histogram聚集就是这样一种聚集，它不是指定时间间隔值，而是指定需要返回桶的数量。例如在示例7-18中定义需要返回10个时间段的桶：
在这里插入图片描述
参数field设置通过哪一个字段做时间分隔，而参数buckets则指明了需要返回多少个桶。默认情况下，buckets的数量为10。需要注意的是，buckets只是设置了期望返回桶的数量，但实际返回桶的数量可能等于也可能小于buckets设置的值。例如示例的请求中期望返回10个桶，但实际可能只返回6个桶。
auto_date_histogram聚集没有精确匹配buckets数量的目的是提升结果的可读性，因为精确匹配buckets数量必然导致间隔时间粒度更精细，这样返回结果中每一桶的范围可能都会具体到每一分钟甚至每一秒。但如如果只是大致满足buckets数量，则会使得间隔时间粒度更大，从而更利于结果的阅读和处理。auto_date_histogram聚集在返回结果中还提供了一个interval字段，用于说明实际采用的间隔时间，例如示例7-18请求结果实际采用的间隔时间可能是7天。
从实现的角度来说，不精确匹配buckets数量也有利于提升检索的性能。Elasticsearch内置了一组时间间隔，以供匹配buckets数量时选择，见表7-2。
在这里插入图片描述
此外，通过buckets参数设置桶数量不要大于10000，即search.max_buckets参数的默认值。

7.2.3 聚集嵌套

前面两个小节介绍的桶型聚集，它们的结果都只是返回满足聚集条件的文档数量。在实际应用中，桶型聚集与SQL中的group by具有相同的意义，用于将文档分桶后计算各桶特定指标值。比如根据用户性别分组，然后分别求他们的平均年龄。Elasticsearch这样的功能通过嵌套聚集来实现，这也是聚集查询真正强大的地方。例如，示例7-19中的请求就是先按月对从中国起飞的航班做了分桶，然后又通过聚集嵌套计算每月平均延误时间：
在这里插入图片描述
在示例7-19中，_search接口共使用了两个参数，query参数以term查询条件将所有OriginCountry字段是CN的文档筛选出来参与聚集运算。aggs参数则定义了一个名称为date_price_histogram的桶型聚集，这个聚集内部又嵌套了一个名称为avg_price的聚集。由于avg_price这个聚集位于date_price_histogram中，所以它会使用这个聚集的分桶结果做运算而不会针对所有文档。所以，最终的效果就是将按月计算从中国出发航班的平均延误时间。
使用嵌套聚集时要注意，嵌套聚集应该位于父聚集名称下而与聚集类型同级，并且需要通过aggs参数再次声明。如果与父聚集一样位于aggs参数下，那么这两个聚集就是平级而非嵌套聚集。嵌套聚集在实际应用中是常态，需要读者认真掌握。

7.3使用词项分桶

使用字段值范围分桶主要针对结构化数据，比如年龄、IP地址等等。但对于字符串类型的字段来说，使用值范围来分桶显然是不合适的。由于字符串类型字段在编入索引时会通过分析器生成词项，所以字符串类型字段的分桶一般通过词项实现。本小节就来介绍这些使用词项实现分桶的聚集，包括terms、significant_terms和significant_text聚集。由于使用词项分桶需要加载所有词项数据，所以它们在执行速度上都会比较慢。为了提升性能，Elasticsearch提供了sampler和diversified_sampler聚集，可通过缩小样本数量减少运算量，本小节也将一并介绍这两个聚集。

7.3.1 terms聚集

terms聚集根据文档字段中的词项做分桶，所有包含同一词项的文档将被归入同一桶中。聚集结果中包含字段中的词项及其词频，在默认情况下还会根据词频排序，所以terms聚集也可以应用于热词展示。由于terms聚集在统计词项的词频数据时需要访问字段的全部词项数据，所以对于text类型的字段来说在使用terms聚集时需要打开它的fielddata机制。fielddata机制对内存消耗较大且有导致内存溢出的可能，所以terms聚集一般针对keyword类型而非text类型。
在第7.1节中介绍的cardinality聚集可以统计字段中不重复词项的数量，而terms聚集则可以将这些词项全部展示出来。与cardinality聚集一样，terms聚集统计出来的词频也不能保证完全精确。例如：
在这里插入图片描述
在示例7-20中定义了两个聚集，由于它们都是定义在aggs下，所以不是第7.2.3节介绍的嵌套聚集。terms聚集的field参数定义了提取词项的字段为DestCountry，它的词项在返回结果中会按词频由高到低依次展示，词频会在返回结果的doc_count字段中展示。另一个参数size则指定了只返回10个词项，这相当把DestCountry字段中词频前10名检索出来。terms聚集返回结果如示例7-21所示，限于篇幅省略了部分词项：
在这里插入图片描述
在本书第2章2.2.1节中曾经介绍过，text类型字段会在编入索引时保存词项的词频，所以统计词项的总词频只需要把这些词项加起来就行了。但由于文档在Elasticsearch中的存储是分片的，所以还需要将每一个分片中的词频都累积起来。由于在每个分片中词项都按词频由高到低排序，所以如果要统计词频前10名的词项，只要将每个分片上前10名的词频分别加到一起就可以了。这在大多数情况下是正确的，而且Elasticsearch也是这么做的。但在一些特殊情况下，这可能是不正确的。例如在上面的例子，假定有四个词项CN、US、IT和CA，它们在两个分片中词频排名分别如下所示：
CN 11
CA 10
IT 9
US 1
US 18
CN 15
IT 14
CA 1
如果在词项聚集时只取前2名做累加，这样会得到3个词项的累加结果，即CN出现26次、US出现18次而CA为10次。而第三位的IT累计词频为23次，比US还要高，但由于它在两个分片中都排在第三位，所以没有机会出现在返回的结果中。可见，terms聚集并不能保证一定是严格按词频排序。但如果terms聚集在计算词频时取到前3名，那么词频累加的结果就跟实际一致了。所以，terms聚集从分片上提取词项的范围越大，返回的结果越接近正确次序，但显然运算量也跟着增加了。在terms聚集中可以使用shard_size参数来控制单个分片上运算的范围，它与size参数值存在着一些关联，比如在设置shard_size时不应该比size参数小，否则将被忽略并取size值为shard_size值。
如果有多个分片则shard_size的默认值为（size*1.5+10），而如果只有一个分片则shard_size值与size值相同。这种默认值策略已经在很大程度上避免了结果的不准确，但依然存在着偏差的可能。所以，在返回结果中doc_count_error_upper_bound字段描述了在最坏情况下错误的上限，而sum_other_doc_count则描述了未出现在统计结果中的词项还有多少个。最坏情况下错误上限的计算也很简单，就是每个分片上提取的最后一位做累加。例如在上面的例子中，每个分片提取了前两名，则最坏情况下的上限是不可能超过第2名的累加，也就是25。
在上面的例子中，US出现的频率返回值为18，但实际上为19。这是因为在第一个分片中US并没有进入前两名，所以丢失了它在第一个分片中统计数量。terms聚集提供了一个show_term_doc_count_error参数，如果将它设置为true时则每个词项的词频统计错误上限就会显示出来。词项的词频统计错误上限计算也很简单，如果词项在所有分片中的数据都已经统计过了，那么错误上限为0；而如果有一些分片中没有统计上，那么错误上限就是这些分片最后一位词项的词频累加。
terms聚集还提供了_count、_key、_term三个虚拟字段用于排序，其中_count是按照词频排序，而_key和_term都是按照词项字母排序，_key是在7.0.0之后版本中用于取代_term的。

7.3.2 significant_terms聚集

terms聚集统计在字段中的词项及其词频，聚集结果会按各词项总的词频排序，并将出现次数最多的词项排在最前面，这非常适合做推荐及热词类的应用。但按词频总数数排序并不总是正确的选择，在一些检索条件已知的情况下，一些词频总数比较低的词项反而有可能是更合适的推荐热词。举例来说，假设在10000篇技术类文章的内容中提到Elasticsearch的只有200篇，占比为2%；但在文章标题含有NoSQL的1000篇文章中，文章内容提到Elasticsearch的为180篇，占比为18%。这种占比显著的提升，说明在文章标题含有NoSQL的条件下，Elasticsearch变得更为重要。换句话说，如果一个词项在某个文档子集中与在文档全集中相比发生了非常显著的变化，就说明这个词项在这个文档子集中是更为重要的词项。
significant_terms聚集就是针对上述情况的一种聚集查询，它将文档和词项分为前景集（Foreground Set）和背景集（Background Set）。前景集对应一个文档子集，而背景集则对应文档全集。significant_terms聚集根据query指定前景集，运算field参数指定字段中的词项在前景集和背景集中的词频总数，并在结果的doc_count和bg_count中保存它们。例如：
在这里插入图片描述
在示例7-22中，query参数使用DSL指定了前景集为出发国家为IE（即爱尔兰）的航班，而聚集查询中则使用significant_terms统计到达国家的前景集词频和背景集词频。来看一下返回结果：

在示例7-23展示的返回结果中，前景集文档数量为119，背景集文档数量为13059。在buckets返回的所有词项中，国家编码为GB的航班排在第一位。它在前景集中的词频为12，占比约为10%（12/119）；而在背景集中的词频为449，占比约为3.4%（445/13059）。词项GB在前景集中的占比是背景集中的3倍左右，发生了显著变化，所以在这个前景集中GB可以被视为热词而排在第一位。GB代表的国家是英国，从爱尔兰出发去英国的航班比较多想来也是合情合理的。
除了按示例7-22中的方式使用query参数指定前景集以外，还可以将terms聚集与significant_terms聚集结合起来使用，这样可以一次性列出一个字段的所有前景集的热词。例如：
在这里插入图片描述
在示例7-24中，使用terms聚集将OriginCountry字段的词项全部查询出来做前景集，然后再与significant_terms聚集一起查询它们的热词。

significant_text聚集

如果参与significant_terms聚集的字段为text类型，那么需要将字段的fielddata机制开启，否则在执行时会返回异常信息。significant_text聚集与significant_terms聚集的作用类型，但不需要开启字段的fielddata机制，所以可以把它当成是一种专门为text类型字段设计的significant_terms聚集。例如在kibana_sample_data_logs中，message字段即为text类型，如果想在这个字段上做词项分析就需要使用significant_text聚集：
在这里插入图片描述
在示例7-25中，前景集为响应状态码response为200的日志，significant_text聚集则查看在这个前景集下message字段中出现异常热度的词项。返回结果片段如示例7-26所示：

通过示例7-26展示的返回结果可以看看出，排在第一位的词项200在前景集和背景集中的数量是一样的，这说明message中完整地记录了200状态码；而排在第二位的词项beats前景集和背景集分别为3462和3732，这说明请求“/beats”地址的成功率要远高于其他地址；最后filebeat排在metricbeat之前，说明请求“/beats/filebeat”的成功率高于“/beats/metricbeat”。
significant_text聚集之所以不需要开启fielddata机制是因为它会在检索时对text字段重新做分析，所以significant_text聚集在执行时速度比其他聚集要慢很多。如果希望提升执行效率，则可以使用sampler聚集通过减少前景集的样本数量降低运算量。