### 歡迎訪問我的GitHub
> 這裡分類和彙總了欣宸的全部原創(含配套原始碼)：[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blog_demos)

### 本篇概覽
- Elasticsearch上的索引如果有多個分片，那麼在聚合排序後取TopN時，返回的結果可能是不準的，今天我們就透過實戰來研究分析此問題，並驗證解決方法；

### 環境資訊
- 以下是本次實戰的環境資訊，請確保您的Elasticsearch可以正常執行：

1. 作業系統：Ubuntu 18.04.2 LTS
2. JDK：1.8.0_191
3. Elasticsearch：6.7.1
4. Kibana：6.7.1

### 系列文章列表
1. [《Elasticsearch聚合學習之一：基本操作》](https://blog.csdn.net/boling_cavalry/article/details/89735952)；
2. [《Elasticsearch聚合學習之二：區間聚合》](https://xinchen.blog.csdn.net/article/details/89763684)；
3. [《Elasticsearch聚合學習之三：範圍限定》](https://xinchen.blog.csdn.net/article/details/89785223);
4. [《Elasticsearch聚合學習之四：結果排序》](https://xinchen.blog.csdn.net/article/details/89812169)；
5.  [《Elasticsearch聚合學習之五：排序結果不準的問題分析》](https://xinchen.blog.csdn.net/article/details/90319399);

### 復現問題第一步：建立索引
- 首先是將問題復現，這裡我做了個簡單的索引，只有兩個欄位，將索引分為兩個分片，然後準備了一些資料寫入這兩個分片；

- 在Kibana的Dev Tools執行以下命令，即可建立名為taskcase的索引，該索引有兩個分片，只有兩個欄位：name和value：

```shell
PUT /testcase
{
  "settings": {
    "number_of_replicas": 1,
    "number_of_shards": 2
  },
  "mappings" : {
      "t1" : {
        "properties" : {
          "name" : {
            "type" : "keyword"
          },
          "value" : {
            "type" : "long"
          }
        }
      }
    }
}
```
- 接下來是匯入資料了。

### 復現問題第二步：匯入資料
- 為了測試的準確性，按照以下要求來製造測試資料：
1. 按照name欄位聚合，name的值不宜太多，否則會有過多的桶不好分析結果；
2. 能精確的指定哪些資料到分片1，哪些到分片2；

- 對於這份測試資料，這裡先給出聚合結果（在生成資料的時候計算出來的），有了這些結果，我們就能和es聚合結果做對比，發現問題所在：
**分片一，按name聚合後，name相同的文件value欄位之和：**

```shell
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欄位之和：**

```shell
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欄位之和：**

```shell
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命令匯入這些資料：

```shell
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欄位的值相加：

```shell
GET /testcase/t1/_search
{
  "size":0,
  "aggs":{
   "names":{
     "terms": {
       "field": "name",
       "size" :5,
       "order": {
         "values": "desc"
       }
     },
     "aggs": {
       "values": {
         "sum": {
           "field": "value"
         }
       }
     }
   }
  }
}
```

- 得到的結果如下：

```json
"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 ，如下圖：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190518231906194.png)

- 如果請求只發往一個分片，就返回前5條，如果發往多個分片，每個分片返回的條數是：5*1.5+10=17

- 用一幅圖來描述，如下圖，彙總資料中的紫色，是由分片一和分片二中的紫色合成的：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190519001304306.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)

- 如上圖所示，分片一的前17條記錄中，沒有name等於19的記錄（因為該記錄在分片一的排名是28），所以兩個分片的資料聚合後，name等於19的記錄只有分片二的資料中有，即**19:168589**，這個值在彙總資料中是排不上前5的，於是ES返回的Top5與真實資料的Top5就不一樣了，這就是Elasticsearch聚合後排序不準的原因。

- 接下來看看如何解決此問題
### 解決辦法之一

- 知道問題的原因解決起來就容易了：如果每個分片返回的不是前17名，而是前28名，那麼兩個分片中都含有name等於19的記錄，這個指定分片返回數量的引數是**shard_size**，加上shard_size引數的整個請求如下：

```shell
GET /testcase/t1/_search
{
  "size":0,
  "aggs":{
   "names":{
     "terms": {
       "field": "name",
       "size" :5,
       "shard_size": 28, 
       "order": {
         "values": "desc"
       }
     },
     "aggs": {
       "values": {
         "sum": {
           "field": "value"
         }
       }
     }
   }
  }
}
```

- 得到結果如下，與真實排名一致：

```shell
"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，這些方法您可以自行驗證，建立一個分片的索引的指令碼如下：

```shell
PUT /testcase
{
  "settings": {
    "number_of_replicas": 1,
    "number_of_shards": 1
  },
  "mappings" : {
      "t1" : {
        "properties" : {
          "name" : {
            "type" : "keyword"
          },
          "value" : {
            "type" : "long"
          }
        }
      }
    }
}
```

- 至此，關於聚合排序不準的實戰和分析就全部完成了，在您使用es的聚合後TopN時如果遇到類似問題，希望此文能夠給您提供一些參考；

### 歡迎關注ITpub：程式設計師欣宸
> [學習路上，你不孤單，欣宸原創一路相伴...](http://blog.itpub.net/70017844/)

Elasticsearch聚合學習之五：排序結果不準的問題分析

相關文章