ES 7.10 composite聚合date_histogram位置差异致doc_count不同

核心差异原因 #

两种查询的计数差异，本质是ES聚合框架对多值字段的两层处理逻辑不一致导致的，和过滤条件无关：

• Query1 计数为2的底层逻辑
  你把rate_over_time的date_histogram直接放到了Composite聚合的sources维度列表里，属于Composite的顶层聚合源。
  ES处理普通object数组类型的字段时，会自动做扁平化存储，同一文档内的数组元素值会被拆解为独立的字段条目，不存在数组内对象的关联关系。当date_histogram作为Composite源时，ES会遍历文档的每一个opens.time值，直接对对应组合键的doc_count做累加，不做文档级去重：
  比如某文档的domain/msp/fromaddress/tags四个维度值固定，opens.time有两个同属15点小时区间的值，哪怕两个值生成的时间桶key完全一致，也会累计加2次计数，最终得到doc_count=2的结果。
• Query2 计数为1的底层逻辑
  你把rate_over_time的date_histogram挪到了Composite聚合桶的子聚合层级。
  此时ES会先基于前面4个terms维度把文档做归桶：同一文档只要命中某一组维度组合，就只会被归到父桶1次。后续在父桶下做date_histogram计算时，遵循普通聚合的通用规则——基于独立文档ID做去重统计：哪怕一个文档有多个opens.time值落在同一个小时区间，整个文档也只会被记1次，最终得到的doc_count=1。

修改Query1达到Query2统计结果的方案 #

根据你的实际业务需求，有两种可落地的改法：

1. 标准对齐方案（性能最优，和Query2结果100%一致）
   直接把rate_over_time的date_histogram从Composite的sources数组中移除，移动到my_buckets（即Composite聚合本身）的同级aggs节点下，结构和Query2完全对齐。
   这种方式没有额外计算开销，完全复用Composite聚合的文档归桶逻辑，避免多值字段累加导致的重复计数。
   核心结构调整示例（仅展示aggs部分）：

   "aggs":{
     "my_buckets":{
       "composite":{
         "sources":[
           {"from_domain_wise":{"terms":{"field":"domain"}}},
           {"msp_wise":{"terms":{"field":"msp"}}},
           {"fromaddress_wise":{"terms":{"field":"fromaddress"}}},
           {"tag_wise":{"terms":{"field":"tags"}}}
         ]
       },
       // 将date_histogram作为composite桶的子聚合
       "aggs":{
         "rate_over_time":{
           "date_histogram":{"field":"opens.time","interval":"1h"}
         }
       }
     }
   }
   

2. 保留date_histogram为Composite源的去重方案
   如果你的业务场景需要把date_histogram作为Composite的source维度（比如需要基于「维度+时间」的组合键做深度分页），又想避免重复计数，不能直接使用桶自带的doc_count：
   • 需要在每个Composite桶下新增基于文档唯一标识的去重逻辑，比如通过terms聚合收集文档ID、或通过cardinality做基数统计，最终以去重后的文档数作为统计值。
   • 这种方案会带来额外的计算开销，仅在有强分页需求时使用。

内容的提问来源于stack exchange，提问作者flixy