Elasticsearch 5.6.1 带分区的terms聚合不遵循size值且分桶丢失问题咨询

核心运行逻辑澄清 #

对带include.partition参数的terms聚合，需要先明确两个和直觉不符的底层规则，这也是两类异常出现的根本原因：

• 分区的本质是基于term值的哈希值取模，将索引内所有符合查询条件的term划分为指定数量的独立桶集合，每个分区的term成员是固定的，不会随请求参数、分片分布动态变化；哈希取模的分配结果不保证每个分区的term数量严格平均。
• 无论是否开启分区，terms聚合的size参数从来不是“每个请求固定返回N个桶直到取完全量”的分页语义，而是两层截断规则：
  • 分片级：每个数据分片在本地统计时，当前分区内最多返回和size相关数量的候选term到协调节点（5.x版本默认shard_size = size）
  • 协调节点级：汇总所有分片返回的候选term，去重、计算全量文档数、按指定规则排序后，最多截断size个term返回给客户端。

两类异常的具体原因说明 #

1. num_partitions=4、size=200时丢失26个分桶的原因 #

这种丢桶是5.x版本terms聚合分片截断机制的典型表现：

• 当某个term在单个分片上的统计值没有进入当前分片本地分区的top size排名时，这个term就不会被分片返回给协调节点。哪怕这个term跨多个分片的总文档数达到了min_doc_count=1的要求，协调节点收不到对应的候选数据，就会直接把这个term从最终结果里剔除。
• 当前查询场景叠加了三个容易放大丢桶概率的因素：嵌套字段的独立分片统计、match_phrase_prefix模糊匹配导致的term分片分布不均、默认shard_size和size相等没有冗余候选额度，最终导致26个跨分片存在的低频term在分片级筛选阶段就被过滤，没有进入协调节点的汇总流程，最终四个分区返回的总桶数低于实际值。
• 当前配置的shard_min_doc_count=0没有给分片筛选加基础阈值，没法抵消分片级截断带来的候选缺失。

2. num_partitions=3、size=300时分桶数量不符合300/300/161预期的原因 #

这个现象本质是对分区模式的行为预期偏差：

• 哈希分区的term分配本身不保证严格均匀，三个分区的实际全量term总数就是246、261、254（加总刚好761），不存在“前两个分区各凑满300个、最后一个拿剩余161”的分配规则。
• 设置的size=300比每个分区实际包含的term总数都大，因此协调节点在做结果截断的时候，根本触发不了截断逻辑——因为每个分区从分片拉回来的候选已经凑不齐300个，自然就把每个分区所有符合条件的term都返回了。
• 只有当某个分区的实际term总数大于size值时，才会触发截断：比如某个分区总共有400个term，设置size=300，这个分区才会只返回文档数最高的300个term，剩余100个会被过滤。

5.6.1版本无升级条件下的优化方向 #

受限于5.6.1版本没有composite聚合的逐桶分页能力，可以通过以下参数调整大幅降低丢桶概率：

• 显式设置shard_size为size的2~3倍，比如当前size=200的场景设置shard_size=600，提升分片返回的候选term数量，减少低频term被分片过滤的概率。
• 适当调整shard_min_doc_count的值，不要固定设置为0，给分片级的term筛选加一个基础的文档数阈值，减少无意义的跨分片汇总开销。
• 不要对分区模式下的返回数量做严格的分页预期，分区模式的设计初衷是拆分全量terms的拉取压力，降低单请求的堆内存占用，不是用来做精准逐页分页的。

注意：如果需要100%无丢失的全量terms拉取，在5.6.1版本没有完美的替代方案，只要存在分片级截断，就有概率出现候选不足导致的丢桶问题。

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