Elasticsearch聚合分析怎么用？从基础概念到实战示例详解

Elasticsearch的聚合（Aggregation）功能是它最强大的能力之一。很多人把Elasticsearch仅仅当作一个搜索引擎来用，其实它同时也是一个实时的分析引擎。通过聚合，你可以在秒级甚至毫秒级完成对上亿条文档的统计分析，比如统计每个城市的订单总量、计算每天的平均销售额、找出访问量最高的十个页面等。本文将系统介绍Elasticsearch聚合分析的核心概念、三大聚合类型以及实战用法。

一、聚合分析的基本原理

聚合分析的本质是对满足查询条件的数据集进行统计计算。它与普通的query返回文档列表不同，聚合返回的是统计结果。在Elasticsearch中，一次搜索请求可以同时携带query和aggs两部分：query先筛选出符合条件的数据，聚合再基于这批数据做计算，两者在一次请求中完成，这是聚合性能优秀的重要原因之一。

Elasticsearch的聚合建立在倒排索引和列式存储Doc Values之上。倒排索引让关键词匹配非常快，而Doc Values则是聚合速度的关键保障。Doc Values在索引阶段就把字段值以列式结构存储在磁盘上，聚合时可以顺序读取，避免了大量随机IO，同时也不会像加载fielddata那样占用大量JVM堆内存。这也是为什么数值类型、日期类型和keyword类型的字段默认开启Doc Values，而text类型字段默认无法直接用于聚合的原因。

一个需要注意的点是，聚合是在搜索上下文中执行的，每次请求都是实时计算，不会像预聚合那样有延迟。这种设计让你可以随时以任意维度组合进行灵活分析，代价是当数据量特别大、聚合嵌套特别深时，可能消耗较多CPU和内存资源。

二、三大聚合类型详解

Elasticsearch的聚合分为三大类：桶聚合（Bucket）、指标聚合（Metric）和管道聚合（Pipeline），理解这三类的分工是掌握聚合的基础。

桶聚合负责分组，它把文档按照某种规则划分到不同的桶里，类似SQL中的group by。常用的桶聚合包括terms（按字段值分组）、range（按数值范围分组）、date_histogram（按时间间隔分组）、filter（按条件分组）等。桶本身只负责收集文档，通常需要在桶内再嵌套指标聚合来计算数值。

指标聚合负责计算，它在文档集合上算出一个或多个数值，类似SQL中的count、avg、sum、max、min。常用的有avg、sum、max、min、stats、cardinality（去重计数）等。stats一次性返回count、min、max、avg、sum五个值，非常实用。

管道聚合则以其他聚合的输出作为输入做二次计算，比如求各分组平均值的最大值、计算环比增长率等，适合更复杂的分析场景。

下面用一个订单数据的例子演示，需求是按城市统计订单总数和平均金额：

GET /orders/_search
{
  "size": 0,
  "aggs": {
    "group_by_city": {
      "terms": {
        "field": "city.keyword",
        "size": 10
      },
      "aggs": {
        "avg_amount": {
          "avg": {
            "field": "amount"
          }
        }
      }
    }
  }
}

这个例子中有几个细节值得注意。第一，size设为0表示不需要返回文档列表，只要聚合结果，能明显减少响应体积。第二，text类型字段要使用它的keyword子字段做terms聚合，因为text分词后的结果通常不是我们想要的分组维度。第三，外层的桶聚合内嵌套了avg指标聚合，这样每个城市桶里都会附带平均金额，这就是聚合的嵌套能力，也是它强大之处。

三、常见实战场景与示例

第一个常见场景是按时间维度做趋势分析，使用date_histogram聚合。比如统计每天的订单总额：

GET /orders/_search
{
  "size": 0,
  "aggs": {
    "daily_sales": {
      "date_histogram": {
        "field": "order_time",
        "calendar_interval": "day",
        "format": "yyyy-MM-dd",
        "min_doc_count": 0
      },
      "aggs": {
        "total_amount": {
          "sum": {
            "field": "amount"
          }
        }
      }
    }
  }
}

其中min_doc_count设为0可以让没有数据的天数也出现在结果里，补全时间轴，这对画趋势图非常重要。如果数据跨时区，还应通过time_zone参数指定时区，否则日期边界可能与业务预期不一致。

第二个场景是范围分组与去重统计。比如把用户按年龄分成几段，并统计每段的去重用户数：

GET /users/_search
{
  "size": 0,
  "aggs": {
    "age_groups": {
      "range": {
        "field": "age",
        "ranges": [
          { "to": 18 },
          { "from": 18, "to": 30 },
          { "from": 30, "to": 50 },
          { "from": 50 }
        ]
      },
      "aggs": {
        "unique_users": {
          "cardinality": {
            "field": "user_id"
          }
        }
      }
    }
  }
}

cardinality聚合采用的是HyperLogLog++算法，它以极小的内存开销近似计算去重值，默认精度误差约在百分之一以内，对绝大多数业务统计来说完全够用。如果要求绝对精确，可以考虑使用composite聚合分页遍历所有桶后自行统计，但代价是性能开销大幅增加。

第三个场景是使用管道聚合做二次计算。比如想知道各城市平均订单金额中的最大值是多少，可以结合stats_bucket实现：

GET /orders/_search
{
  "size": 0,
  "aggs": {
    "group_by_city": {
      "terms": { "field": "city.keyword" },
      "aggs": {
        "avg_amount": {
          "avg": { "field": "amount" }
        }
      }
    },
    "max_avg_amount": {
      "max_bucket": {
        "buckets_path": "group_by_city>avg_amount"
      }
    }
  }
}

buckets_path指定了管道聚合读取的路径，用大于号连接父子关系。这种写法把分桶计算和二次计算合并在一次请求中，避免了多次往返查询。

四、聚合性能优化的实用技巧

聚合虽然强大，但用不好也会拖垮集群。第一个建议是合理设置分片数。聚合在每个分片上并行执行，再由协调节点合并结果。分片太少无法利用多节点算力，分片太多则合并开销大，一般让单分片文档量控制在千万级以内比较稳妥。

第二个建议是控制terms聚合的size参数和返回桶的数量。如果只需要前十条，就不要把size设成一百，因为Elasticsearch需要在每个分片上维护候选桶，桶数量越多内存消耗越大。对于需要遍历全部分桶的场景，优先使用composite聚合进行分页拉取，而不是把size设置成一个巨大的值。

第三个建议是注意聚合深度。嵌套聚合的层级越多，需要维护的桶数量呈乘积关系增长，很容易触发桶数量上限导致数据不完整。默认的搜索上下文桶上限可以通过合理调整，但更重要的是从业务上精简聚合维度，必要时可以把高频统计结果提前物化到专门的分析索引中。

第四个建议是利用执行提示。对于date_histogram等聚合，可以在映射中设置eager_global_ordinals来预加载全局序号，减少查询时的准备时间；对keyword字段的高频聚合场景，这个优化能带来明显的延迟降低。同时，务必确保参与聚合的字段有Doc Values支持，避免在text字段上强行开启fielddata，那会带来严重的堆内存压力甚至导致节点崩溃。

总的来说，Elasticsearch聚合分析的学习曲线并不陡峭，关键是理解桶、指标、管道三类聚合的组合方式，再结合实际的业务数据多加练习。从简单的分组统计开始，逐步尝试嵌套聚合和管道聚合，你就能体会到它在大数据实时分析上的巨大价值。

Elasticsearch聚合分析aggregation修改时间：2026-08-31 05:24:35