欢迎访问我的GitHub
这里分类和汇总了欣宸的全部原创(含配套源码)： https://github.com/zq2599/blog_demos
本篇概览
- Elasticsearch上的索引如果有多个分片，那么在聚合排序后取TopN时，返回的结果可能是不准的，今天我们就通过实战来研究分析此问题，并验证解决方法；
环境信息
- 以下是本次实战的环境信息，请确保您的Elasticsearch可以正常运行：
- 操作系统：Ubuntu 18.04.2 LTS
- JDK：1.8.0_191
- Elasticsearch：6.7.1
- Kibana：6.7.1
系列文章列表
- 《Elasticsearch聚合学习之一：基本操作》；
- 《Elasticsearch聚合学习之二：区间聚合》；
- 《Elasticsearch聚合学习之三：范围限定》;
- 《Elasticsearch聚合学习之四：结果排序》；
- 《Elasticsearch聚合学习之五：排序结果不准的问题分析》;
复现问题第一步：创建索引
- 首先是将问题复现，这里我做了个简单的索引，只有两个字段，将索引分为两个分片，然后准备了一些数据写入这两个分片；
- 在Kibana的Dev Tools执行以下命令，即可创建名为taskcase的索引，该索引有两个分片，只有两个字段：name和value：
PUT /testcase
{
"settings": {
"number_of_replicas": 1,
"number_of_shards": 2
},
"mappings" : {
"t1" : {
"properties" : {
"name" : {
"type" : "keyword"
},
"value" : {
"type" : "long"
}
}
}
}
}- 接下来是导入数据了。
复现问题第二步：导入数据
- 为了测试的准确性，按照以下要求来制造测试数据：
- 按照name字段聚合，name的值不宜太多，否则会有过多的桶不好分析结果；
- 能精确的指定哪些数据到分片1，哪些到分片2；
- 对于这份测试数据，这里先给出聚合结果（在生成数据的时候计算出来的），有了这些结果，我们就能和es聚合结果做对比，发现问题所在：
分片一，按name聚合后，name相同的文档value字段之和：
14 : 22491 //14是name，22491是所有name等于14的文档的value字段之和
8 : 21632
4 : 21502
15 : 21234
26 : 20731
10 : 20306
17 : 19942
9 : 19418
25 : 19191
16 : 18797
6 : 18306
3 : 18166
22 : 17669
24 : 16971
27 : 16911
18 : 16758
23 : 16527
13 : 15705
7 : 15251
11 : 15019
12 : 14387
2 : 14329
30 : 14023
5 : 13421
29 : 13309
1 : 12574
28 : 12189
19 : 11673
21 : 11460
20 : 10576- 分片二，按name聚合后，name相同的文档value字段之和：
19 : 168589
21 : 164705
16 : 162088
9 : 161579
8 : 160459
28 : 159775
15 : 158124
26 : 156609
24 : 156208
11 : 153976
4 : 153479
23 : 152833
12 : 152052
20 : 150718
29 : 150320
17 : 149352
10 : 148473
2 : 147812
5 : 147791
3 : 146158
6 : 145604
7 : 145439
18 : 144984
13 : 144784
14 : 144004
27 : 143564
30 : 140984
22 : 140309
25 : 133879
1 : 133233- 所有数据，按name聚合后，name相同的文档value字段之和：
8 : 182091
9 : 180997
16 : 180885
19 : 180262
15 : 179358
26 : 177340
21 : 176165
4 : 174981
24 : 173179
28 : 171964
23 : 169360
17 : 169294
11 : 168995
10 : 168779
14 : 166495
12 : 166439
3 : 164324
6 : 163910
29 : 163629
2 : 162141
18 : 161742
20 : 161294
5 : 161212
7 : 160690
13 : 160489
27 : 160475
22 : 157978
30 : 155007
25 : 153070
1 : 145807- 这份数据集保存在bulk.json文件中，您可以在此下载：
https://raw.githubusercontent.com/zq2599/blog_demos/master/files/bulk.json
- 下载后，用curl命令导入这些数据：
curl -H 'Content-Type: application/x-ndjson' -s -XPOST http://192.168.50.75:9200/testcase/t1/_bulk --data-binary @bulk.json- 在bulk.json中，由routing的值来决定数据会存在哪个分片中，已经验证过routing=a时会写入第一个分片，routing=b时写入第二个分片，因此整个bulk.json中的routing的值只有a和b两种；
- 上述数据和统计结果都是用java生成的，对应的源码地址在此：
https://raw.githubusercontent.com/zq2599/blog_demos/master/files/GenerateESAggSortData.java
- 现在数据已经准备好了，可以复现问题了；
复现问题
- 导入数据成功后，执行以下命令，按照name做聚合，将name相同的文档的value字段的值相加：
GET /testcase/t1/_search
{
"size":0,
"aggs":{
"names":{
"terms": {
"field": "name",
"size" :5,
"order": {
"values": "desc"
}
},
"aggs": {
"values": {
"sum": {
"field": "value"
}
}
}
}
}
}- 得到的结果如下：
"buckets" : [
{
"key" : "8",
"doc_count" : 356,
"values" : {
"value" : 182091.0
}
},
{
"key" : "9",
"doc_count" : 356,
"values" : {
"value" : 180997.0
}
},
{
"key" : "16",
"doc_count" : 351,
"values" : {
"value" : 180885.0
}
},
{
"key" : "15",
"doc_count" : 347,
"values" : {
"value" : 179358.0
}
},
{
"key" : "26",
"doc_count" : 353,
"values" : {
"value" : 177340.0
}
}
]- 问题已经出现了，返回的数据中，第四名的name是15，但实际上19才是第四名，对比列表如下：
| 排名 | 真实数据 | Elasticsearch返回 |
|---|---|---|
| 1 | 8 : 182091 | 8:182091 |
| 2 | 9 : 180997 | 9:180997 |
| 3 | 16 : 180885 | 16:180885 |
| 4 | 19 : 180262 | 15:179358 |
| 5 | 15 : 179358 | 26:177340 |
分析问题
- 在聚合排序的操作中，实际上是每个分片自身先做排序，然后将每个分片的前17名放在一起再次聚合，再排序，将排序后的前5条记录作为结果返回；
- 为什么用每个分片的前17名？这是用官方给出的算式得来的，地址是：https://www.elastic.co/guide/en/elasticsearch/reference/6.1/search-aggregations-bucket-terms-aggregation.html ，如下图：
- 如果请求只发往一个分片，就返回前5条，如果发往多个分片，每个分片返回的条数是：5*1.5+10=17
- 用一幅图来描述，如下图，汇总数据中的紫色，是由分片一和分片二中的紫色合成的：
- 如上图所示，分片一的前17条记录中，没有name等于19的记录（因为该记录在分片一的排名是28），所以两个分片的数据聚合后，name等于19的记录只有分片二的数据中有，即19:168589，这个值在汇总数据中是排不上前5的，于是ES返回的Top5与真实数据的Top5就不一样了，这就是Elasticsearch聚合后排序不准的原因。
- 接下来看看如何解决此问题
解决办法之一
- 知道问题的原因解决起来就容易了：如果每个分片返回的不是前17名，而是前28名，那么两个分片中都含有name等于19的记录，这个指定分片返回数量的参数是shard_size，加上shard_size参数的整个请求如下：
GET /testcase/t1/_search
{
"size":0,
"aggs":{
"names":{
"terms": {
"field": "name",
"size" :5,
"shard_size": 28,
"order": {
"values": "desc"
}
},
"aggs": {
"values": {
"sum": {
"field": "value"
}
}
}
}
}
}- 得到结果如下，与真实排名一致：
"buckets" : [
{
"key" : "8",
"doc_count" : 356,
"values" : {
"value" : 182091.0
}
},
{
"key" : "9",
"doc_count" : 356,
"values" : {
"value" : 180997.0
}
},
{
"key" : "16",
"doc_count" : 351,
"values" : {
"value" : 180885.0
}
},
{
"key" : "19",
"doc_count" : 348,
"values" : {
"value" : 180262.0
}
},
{
"key" : "15",
"doc_count" : 347,
"values" : {
"value" : 179358.0
}
}
]- 由此可以看出：shard_size越大，得到的结果准确率越高，如果shard_size不低于桶的数量，那么就是准确值了。
- 但实际生产环境中需要结合实际情况来设置shard_size，因为该值越大汇总的数据量就越大，对网络、内存等资源的消耗都会增加，会影响整体性能；
解决办法之二
- 第二种解决方式就是所有的数据都在一个分片上，具体的方法是创建索引时分片数设置为1，或者在增加数据时指定routing，并且查询的时候也使用该routing，这些方法您可以自行验证，创建一个分片的索引的脚本如下：
PUT /testcase
{
"settings": {
"number_of_replicas": 1,
"number_of_shards": 1
},
"mappings" : {
"t1" : {
"properties" : {
"name" : {
"type" : "keyword"
},
"value" : {
"type" : "long"
}
}
}
}
}- 至此，关于聚合排序不准的实战和分析就全部完成了，在您使用es的聚合后TopN时如果遇到类似问题，希望此文能够给您提供一些参考；
欢迎关注阿里云开发者社区博客：程序员欣宸
学习路上，你不孤单，欣宸原创一路相伴...
