Elasticsearch聚合完成后如何过滤terms桶，避免前置filter导致关联数据丢失

之前使用的外层全局filter聚合，是在聚合管道最上游执行文档级裁剪：所有不匹配employeeStatus=Permanent条件的文档，会在进入后续分桶环节前就被直接排除。存储employeeA地址的文档因为状态字段为空，自然被过滤掉，最终导致地址聚合无法返回任何数据。

完全可以在terms分桶完成后再执行桶级别的过滤，不需要修改数据集，单条查询即可满足需求。核心逻辑是先全量文档分桶、再桶级筛选合规员工、最后子聚合提取字段值，具体实现逻辑：

• 移除全局层面的前置filter，让所有文档参与第一轮按employeeId的terms分桶
• 在每个员工分桶内部，新增一个子filter聚合，统计当前员工名下存在多少份employeeStatus=Permanent的文档，输出计数类指标
• 在员工terms聚合的层级下，新增pipeline类型的bucket_selector聚合，根据上一步的计数指标做筛选：仅保留存在至少1份Permanent状态文档的员工桶
• 保留原有的employeeStatus、employeeAddr子terms聚合逻辑，所有归属于当前保留员工的文档（包括不带状态的地址文档、不带地址的状态文档）都会参与子聚合计算，完整拿到对应的字段值

{
    "size": 0,
    "aggregations": {
        "Employee": {
            "terms": {
                "field": "employeeID",
                "size": 10000
            },
            "aggregations": {
                // 统计当前员工桶内Permanent状态的文档数，作为后续桶筛选的判断依据
                "permanent_doc_check": {
                    "filter": {
                        "bool": {
                            "must": [
                                {
                                    "match": {
                                        "employeeStatus": "Permanent"
                                    }
                                }
                            ]
                        }
                    }
                },
                // 桶级过滤：仅保留Permanent文档数>0的员工桶，在terms分桶完成后执行
                "filter_permanent_employee": {
                    "bucket_selector": {
                        "buckets_path": {
                            "hasPermanent": "permanent_doc_check>_count"
                        },
                        "script": "params.hasPermanent > 0"
                    }
                },
                // 原有子聚合逻辑保持不变
                "employeeStatus": {
                    "terms": {"field": "employeeStatus"}
                },
                "employeeAddr": {
                    "terms": {"field": "employeeAddr"}
                }
            }
        }
    }
}

• 之前顾虑的「Bucket Selector仅支持指标聚合」的限制完全可以适配：这里传给Bucket Selector的输入是子filter聚合输出的_count内置指标，属于合规的pipeline聚合输入源，不存在兼容性问题
• 这种实现和之前全局前置filter的核心差异：过滤动作发生在文档分桶完成之后，是对已经聚合好的员工桶做筛选，而不是在文档进入分桶前就裁剪数据集，自然不会出现关联字段文档被提前过滤的问题
• 最终返回的员工列表，既满足「员工本人存在Permanent状态」的筛选要求，又能完整关联到该员工所有文档下的状态、地址字段值，不会出现字段缺失的问题

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