背景介绍
需要对索引中的做聚合，但是聚合的条件会比较复杂，并非从单一字段进行聚合。参考如下数据结构
{
//空格分词字段
"feild_a": "1 2 3 4 5",
//keyword字段
"feild_b": "2"
}
要做的事：我们有 1 2 3 …… 等id，需要统计索引里面，a和b字段分别含有1 2 3对应的数量。文字难以表述的需求我们转化成数据结构来看
{
"data": [{
"id": "1",
"count": 1
}, {
"id": "2",
"count": 2
}, {
"id": "3",
"count": 1
}]
}
如果只有上面那一条数据的话，那么应该得出下面这个统计结果。
问题分析
从表面剖析这个需求的话，似乎是个多字段的聚合。相对于单字段聚合来说问题还是比较棘手的。并不能简单的通过单字段的聚合来解决问题，我们先从最简单的情况开始处理问题。以统计1 2 3这3个id来举例子。
1.单字段情况下聚合
假设只需要对一个字段聚合，比如b字段，b字段是keyword类型，需要考虑的情况最为简单，当要对b字段聚合时语句很好写，如下即可
{
"from": 0,
"size": 0,
"query": {
"bool": {
"must": [{
"bool": {
"should": [{
"terms": {
"field_a": ["1", "2", "3"],
"boost": 1.0
}
}, {
"terms": {
"field_b": ["1", "2", "3"],
"boost": 1.0
}
}],
"adjust_pure_negative": true,
"minimum_should_match": "1",
"boost": 1.0
}
}],
"adjust_pure_negative": true,
"boost": 1.0
}
},
"aggregations": {
"my_agg": {
"terms": {
"field": "field_b"
}
}
}
}
这是完整的query，后面的查询会省略掉query部分。query部分的用处也很明显：只把需要做聚合的部分过滤出来做聚合，我们需要统计的数据就在这部分中，而不是整个索引库。这样有两个好处：
1.提高效率，减少需要聚合的数据的数量
2.剔除需要考虑的意外情况，降低语句的复杂度
而聚合部分就非常简单了，仅仅对field_b聚合即可，但是很遗憾，离我们最终目标很远，这样只能统计出b字段的数据分布情况。
2.多字段情况的聚合
相对于上面的那种，接下来把另外一个字段也考虑进来看看。所以我们写下了这样的请求语句：
"aggregations": {
"my_agg1": {
"terms": {
"field": "tag_brand_id"
}
},
"my_agg2": {
"terms": {
"field": "brand_cid_array"
}
}
}
勉强的可以看到确实也是“统计了两个字段的情况”，但是是分开的，意味着要自己去解析返回结果并做计算来得到最终的返回结果。这确实是很令人恶心的事，那还有没有其他办法呢。但是观察语句的结构发现，似乎并没有过多可以更改的余地，所以需要寻求其他灵活的解决办法。
3.script agg的聚合
简单的单聚合无法表达出多字段聚合的需求，在谷歌过后我寻找到了这样一种解决方案：使用script，即脚本来描述我的需求。下面这段agg就是为了表达我想要根据我的需求灵活处理的一个方式：
"aggregations": {
"my_agg1": {
"terms": {
"script": " if (doc['field_a'].values.contains('1') || doc['field_b'].values.contains('1')){1};if (doc['field_a'].values.contains('2') || doc['field_b'].values.contains('2')){2};
if (doc['field_a'].values.contains('3') || doc['field_b'].values.contains('3')){3};"
}
}
}
这一段脚本的作用很明显，就是告诉es：当a字段或者b字段包括1的时候，扔到桶1；当a字段或者b字段包括2的时候，扔到桶2；……以此类推。看上去确实似乎完全解决了开头提出来的问题，验证后效率还能接受，不是特别慢。但是正当我沾沾自喜以为解决了问题的时候，随手验证了另外一个case，就直接冷水泼头了：
a字段和b字段是可能包含同一个id比如2，但是对于统计结果来说要求算作一条。
用上面这个脚本并无法体现出这个区别，而且还会有一个问题：
请求123和请求321时会返回不同统计结果
因为ifelse语句的关系，和||的性质，在满足条件1后便会扔到桶1，而无法在去后续条件中判断。这个脚本有很明显的bug存在。但是painless毕竟是脚本，可以使用的API和关键字都非常有限，写的复杂了还会很严重影响效率，无奈这个方案也只能pass，即使它看上去差点解决了我的问题。
4.filter agg的聚合
在重新看了官方文档后，我发现了agg中的一个用法，filter agg。
filter agg的用法其实很简单，但是全意外的和我的需求很契合。之前忽视掉这个用法的主要原因是看到的示例都是对单字段做聚合。那如何同时聚合多个字段呢？从API入手验证是否可以使用比较灵活的写法
public KeyedFilter(String key, QueryBuilder filter) {
if (key == null) {
throw new IllegalArgumentException("[key] must not be null");
}
if (filter == null) {
throw new IllegalArgumentException("[filter] must not be null");
}
this.key = key;
this.filter = filter;
}
这是es提供的javaapi中filter agg的构造函数，key就是过滤名称，filter就是过滤条件。而且很友好的是，filter类型为QueryBuilder，也就是说，可以做成比较复杂的过滤方式。
"aggregations": {
"batch_count": {
"filters": {
"filters": {
"1": {
"bool": {
"should": [{
"term": {
"field_a": {
"value": "1",
"boost": 1.0
}
}
}, {
"term": {
"field_b": {
"value": "1",
"boost": 1.0
}
}
}],
"adjust_pure_negative": true,
"boost": 1.0
}
},
"2": {
"bool": {
"should": [{
"term": {
"field_a": {
"value": "2",
"boost": 1.0
}
}
}, {
"term": {
"field_b": {
"value": "2",
"boost": 1.0
}
}
}],
"adjust_pure_negative": true,
"boost": 1.0
}
},
"3": {
"bool": {
"should": [{
"term": {
"field_a": {
"value": "3",
"boost": 1.0
}
}
}, {
"term": {
"field_b": {
"value": "3",
"boost": 1.0
}
}
}],
"adjust_pure_negative": true,
"boost": 1.0
}
}
},
"other_bucket": false,
"other_bucket_key": "-1"
}
}
}
这就是最后成型的agg块
问题总结
agg模块的开发是比较麻烦的，首先性能问题比较困扰，其次语句编写远没有query模块的灵活。这次顺利解决需求，记录。