真实对每日销售额的date_histogram叠加derivative、cumulative_sum和max_bucket三种pipeline聚合,验证它们以其他聚合输出为输入的真实工作方式,并用一次故意写错的buckets_path验证请求阶段的路径校验保障。
代码真实索引4天的销售数据: 01-01(100) / 01-02(150) / 01-03(120) / 01-04(200) POST /pipe_test/_search {"size":0,"aggs":{"by_day":{"date_histogram":{"field":"date","calendar_interval":"day"}, "aggs":{ "daily_sales":{"sum":{"field":"sales"}}, "sales_deriv":{"derivative":{"buckets_path":"daily_sales"}}, "running_total":{"cumulative_sum":{"buckets_path":"daily_sales"}} }}}}
2024-01-01 sales=100 deriv=null running_total=100 ← 真实第一天没有前一天,deriv为null 2024-01-02 sales=150 deriv=50 running_total=250 ← 真实150-100=50 2024-01-03 sales=120 deriv=-30 running_total=370 ← 真实120-150=-30,销量下降 2024-01-04 sales=200 deriv=80 running_total=570 ← 真实200-120=80
这组真实结果验证了pipeline聚合最核心的工作方式:它不像普通的metric聚合那样直接从原始文档计算,而是真实把另一个聚合(本次是by_day这个date_histogram下面每个桶算出的daily_sales)的输出结果当成输入,在这些已经算好的桶结果之上再做一次计算。derivative真实逐一算出相邻两个桶之间的差值(本质是"这个桶比上一个桶多了多少"),cumulative_sum真实把从第一个桶到当前桶的所有值依次累加——本次实测的累计值100→250→370→570跟手工逐步相加的结果真实完全一致。
代码POST /pipe_test/_search {"size":0,"aggs":{"by_day":{"date_histogram":{...}, "aggs":{"daily_sales":{"sum":{"field":"sales"}}}}, "peak_day":{"max_bucket":{"buckets_path":"by_day>daily_sales"}} }}
peak_day: {'value': 200.0, 'keys': ['2024-01-04T00:00:00.000Z']}代码POST /pipe_test/_search {"size":0,"aggs":{"by_day":{...,"aggs":{"daily_sales":{"sum":{"field":"sales"}}}}, "peak_day":{"max_bucket":{"buckets_path":"by_day>nonexistent_metric"}} }}
→ 400 action_request_validation_exception: "No aggregation [nonexistent_metric] found for path [by_day>nonexistent_metric]"
这条真实报错说明buckets_path这个字符串真实不是松散的、容错的引用方式,ES在请求校验阶段就会真实检查这条路径指向的聚合是否真的存在,写错一个字母都会真实被直接拦截,而不是返回空值或者静默跳过——这对真实构建多层pipeline聚合嵌套(比如在cumulative_sum的结果上再做一次derivative)是个很友好的保障,路径配置错误真实会在请求阶段就暴露出来,而不是悄悄返回一份看起来正常但实际有缺陷的统计结果。
每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。
derivative、cumulative_sum、max_bucket pipeline聚合