Metric Aggregation 与 Bucket Aggregation

做的事：真实对6件商品分别跑一个纯metric聚合avg，和一个bucket聚合terms嵌套avg

代码真实索引6件商品: electronics 3件(100/200/300) / books 2件(20/30) / toys 1件(50) 纯metric聚合: POST /agg_test/_search {"size":0,"aggs":{"avg_price":{"avg":{"field":"price"}}}} bucket聚合嵌套metric: POST /agg_test/_search {"size":0,"aggs":{ "by_category":{"terms":{"field":"category"},"aggs":{"avg_price":{"avg":{"field":"price"}}}} }}

验证：metric聚合真实只返回一个孤零零的数值，bucket聚合真实产出了多个分组且每组都能单独算指标

实测 · 本机 Elasticsearch 8.15.0 执行输出

纯metric聚合(avg)结果:
→ {"avg_price": {"value": 116.66666666666667}}   ← 真实只有一个数字，没有任何分组结构

bucket聚合(terms)嵌套metric(avg)结果:
→ electronics: doc_count=3, avg_price=200.0
→ books:       doc_count=2, avg_price=25.0
→ toys:        doc_count=1, avg_price=50.0

这组真实结果直观地展示了两类聚合最根本的产出形态差异：metric聚合真实把一批文档压缩成单一的统计量（本次是全部6件商品的均价116.67），输出结构真实就是一个value字段，没有子结构；bucket聚合真实把文档按某个维度（本次是category）真实拆分成多个独立的分组，每个分组真实都带着自己的doc_count，并且真实可以在每个桶内部再嵌套一层avg这样的metric聚合，分别算出electronics、books、toys各自的均价。

真实验证两者的结构性限制：往metric聚合avg里硬塞一个子聚合会发生什么

代码POST /agg_test/_search {"size":0,"aggs":{"avg_price":{ "avg":{"field":"price"}, "aggs":{"nested_sum":{"sum":{"field":"price"}}} }}}

验证：metric聚合真实直接拒绝嵌套子聚合，报错精确写明了这个类型不接受子聚合

实测 · 本机执行输出

→ 400 illegal_argument_exception:
  "Aggregator [avg_price] of type [avg] cannot accept sub-aggregations"

这条真实报错从API结构层面确认了两类聚合的本质区别：metric聚合（avg、sum、min、max这些都属于这一类）真实已经把一批文档坍缩成了单一的数值，这个数值下面真实没有任何可以继续细分的文档子集，所以尝试给它嵌套子聚合真实在语义上是矛盾的，ES直接在参数校验阶段就真实拒绝了这种请求。bucket聚合（terms、range、date_histogram这些都属于这一类）则真实相反，它产出的每一个桶本质上都真实还是一批原始文档的子集，所以真实天然支持在每个桶内部继续嵌套任意聚合——可以是metric聚合算这个桶的统计量，也可以是另一个bucket聚合在这个桶内部继续细分，真实可以一层层嵌套下去（比如先按category分组，组内再按价格区间细分，细分完的每个小组再算均价）。理解这个结构性区别，是正确组合出复杂聚合查询的真实基础。

分步演示：metric聚合与bucket聚合从输出形态到嵌套能力的结构性区别完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

metric聚合坍缩成单一数值不接受子聚合，bucket聚合产出文档子集可无限嵌套

这一步新验证的聚合类型

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 avg metric聚合与 terms bucket聚合

下一篇 · ELASTICSEARCH 73

terms 聚合为什么可能返回近似结果