?點(diǎn)擊上方“方才編程”，即可關(guān)注我！

寫在前面

關(guān)于更新：

其實(shí)持續(xù)不斷的輸出，還是需要點(diǎn)東西的，不僅是知識(shí)點(diǎn)的學(xué)習(xí)和沉淀，更多是內(nèi)驅(qū)力。學(xué)習(xí)一個(gè)知識(shí)點(diǎn)，梳理腦圖，到demo的編寫，格式的調(diào)整，是一個(gè)費(fèi)時(shí)費(fèi)力的活。但很奇怪，在停更的這兩個(gè)月，總感覺缺少點(diǎn)什么，國慶將至，人也閑了下來，決定接著肝下去，能肝多久？不知道！希望自己能一路走下去，From Zero To Hero！今天突然發(fā)現(xiàn)微信官方給了一個(gè)“讀者討論”功能，還是很開心的。【我們最好的關(guān)系就是互相成就，大家的點(diǎn)贊、在看、分享就是我創(chuàng)作的最大動(dòng)力！】留言也是一種鼓勵(lì)喲，期待大家的討論。

關(guān)于本文：

之前詳解介紹了ES的各種聚合操作，關(guān)于Terms聚合的精度問題，本來也打算自己寫的，后來發(fā)現(xiàn)銘毅大佬已經(jīng)解釋得很清楚了，所以就簡單提煉了下，轉(zhuǎn)載了。【ps：國慶節(jié)打算把“ES的Analyzer原理、高亮原理”肝出來，也不知道還沒有小伙伴看】

terms聚合

本文概覽?

1、實(shí)戰(zhàn)開發(fā)遇到聚合問題

請(qǐng)教一個(gè)問題，ES 在聚合的時(shí)候發(fā)生了一個(gè)奇怪的現(xiàn)象聚合的語句里面size設(shè)置為10和大于10導(dǎo)致聚合的數(shù)量不一致，這個(gè)size不就是返回的條數(shù)嗎？會(huì)影響統(tǒng)計(jì)結(jié)果嗎？dsl語句摘要(手機(jī)敲不方便，雙引號(hào)就不寫了)：

aggs:{topcount:{terms:{field:xx,size:10}}}

就是這個(gè)size，設(shè)置10和大于10將會(huì)導(dǎo)致聚合結(jié)果不一樣，難道是es5.x的bug嗎？

以上是實(shí)戰(zhàn)中的真實(shí)問題，基于這個(gè)問題，有了本篇文章。

本文探討的聚合主要指：terms 分桶聚合。下圖為分桶 terms 聚合示意圖。

從一堆多分類的產(chǎn)品中聚合出 TOP 3 的產(chǎn)品分類和數(shù)量。TOP3 結(jié)果：

產(chǎn)品 Y：4
產(chǎn)品 X：3
產(chǎn)品 Z：2

2、前提認(rèn)知：Elasticsearch terms 分桶聚合結(jié)果是不精確的

2.1 Elasticsearch 分片 和 副本

Elasticsearch 索引由一個(gè)或多個(gè)主分片以及零個(gè)或者多個(gè)副本分片組成。

索引的大小超過了單個(gè)節(jié)點(diǎn)的硬件限制，分片就可以解決。

分片包含索引數(shù)據(jù)的一個(gè)子集，并且本身具有完全的功能和獨(dú)立性，你可以將分片視為“獨(dú)立索引”。

分片的核心要義：

• 分片可以拆分并擴(kuò)展數(shù)據(jù)量。如果數(shù)據(jù)量不斷增加，將會(huì)遇到存儲(chǔ)瓶頸。舉例：有1TB的數(shù)據(jù)，但只有兩個(gè)節(jié)點(diǎn)(單節(jié)點(diǎn)512GB存儲(chǔ))？單獨(dú)無法存儲(chǔ)，切分分片后，問題游刃有余的解決。
• 操作可以分布在多個(gè)節(jié)點(diǎn)上，從而可以并行化提高性能。

主分片：寫入過程先寫主分片，寫入成功后再寫入副本分片，恢復(fù)階段也以主分片為主。

副本分片的目的：

• 在節(jié)點(diǎn)或分片發(fā)生故障時(shí)提供高可用性。

副本分片永遠(yuǎn)不會(huì)分配給與主分片相同的節(jié)點(diǎn)。

• 提高搜索查詢的性能。

因?yàn)榭梢栽谒兄鳌⒏北旧喜⑿袌?zhí)行搜索、聚合操作。

2.2 分片的分配機(jī)制

Elasticsearch 如何知道要在哪個(gè)分片上存儲(chǔ)新文檔，以及在通過 ID 檢索它時(shí)如何找到它？

默認(rèn)情況下，文檔應(yīng)在節(jié)點(diǎn)之間平均分配，這樣就不會(huì)有一個(gè)分片包含的文檔比另一個(gè)分片多非常多。

確定給定文檔應(yīng)存儲(chǔ)在哪個(gè)分片的機(jī)制稱為：路由。

為了使 Elasticsearch 盡可能易于使用，默認(rèn)情況下會(huì)自動(dòng)處理路由，并且大多數(shù)用戶不需要手動(dòng) reroute 處理它。

Elasticsearch 使用如下圖的簡單的公式來確定適當(dāng)?shù)姆制?/p>

shard?=?hash(routing)?%?total_primary_shards

• routing: 文檔 id，可以自己指定或者系統(tǒng)生成 UUID。
• total_primary_shards：主分片數(shù)。

這里推演一道面試題：一旦創(chuàng)建索引后，為什么無法更改索引的主分片數(shù)量？

考慮如上路由公式，我們就可以找到答案。

如果我們要更改分片的數(shù)量，那么對(duì)于文檔，運(yùn)行路由公式的結(jié)果將發(fā)生變化。

假設(shè)：設(shè)置有 5 個(gè)分片時(shí)文檔已存儲(chǔ)在分片 A 上，因?yàn)槟鞘钱?dāng)時(shí)路由公式的結(jié)果。

后面我們將主分片更改為7個(gè)，如果再嘗試通過ID查找文檔，則路由公式的結(jié)果可能會(huì)有所不同。

現(xiàn)在，即使文檔實(shí)際上存儲(chǔ)在Shard A上，該公式也可能會(huì)路由到ShardB。這意味著永遠(yuǎn)不會(huì)找到該文檔。

以此可以得出：主分片創(chuàng)建后不能更改的結(jié)論。

較真的同學(xué)，看到這里可能會(huì)說：不是還有 Split 切分分片和 Shrink 壓縮分片機(jī)制嗎？

畢竟Split?和 Shrink? 對(duì)分片的處理是有條件的(如：都需要先將分片設(shè)置為只讀)。

所以，長遠(yuǎn)角度還是建議：提前根據(jù)容量規(guī)模和增量規(guī)模規(guī)劃好主分片個(gè)數(shù)。

2.3 Elasticsearch 如何檢索 / 聚合數(shù)據(jù)？

接收客戶端請(qǐng)求的節(jié)點(diǎn)為：協(xié)調(diào)節(jié)點(diǎn)。如下圖中的節(jié)點(diǎn) 1 。

在協(xié)調(diào)節(jié)點(diǎn)，搜索任務(wù)被分解成兩個(gè)階段：query 和 fetch 。

真正搜索或者聚合任務(wù)的節(jié)點(diǎn)稱為：數(shù)據(jù)節(jié)點(diǎn)。如下圖中的：節(jié)點(diǎn) 2、3、4。

聚合步驟：

• 客戶端發(fā)送請(qǐng)求到協(xié)調(diào)節(jié)點(diǎn)。
• 協(xié)調(diào)節(jié)點(diǎn)將請(qǐng)求推送到各數(shù)據(jù)節(jié)點(diǎn)。
• 各數(shù)據(jù)節(jié)點(diǎn)指定分片參與數(shù)據(jù)匯集工作。
• 協(xié)調(diào)節(jié)點(diǎn)進(jìn)行總結(jié)果匯集。

2.4 示例說明 聚合結(jié)果不精確

集群：3個(gè)節(jié)點(diǎn)，3個(gè)主分片，每個(gè)分片有5個(gè)產(chǎn)品的數(shù)據(jù)。用戶期望返回Top 3結(jié)果如下：

產(chǎn)品X：40
產(chǎn)品A：40
產(chǎn)品Y：35

用戶執(zhí)行如下 terms 聚合，期望返回集群 prodcuts 索引Top3 結(jié)果。

POST?products/_search
{"size":0,"aggs":?{"product_aggs":?{"terms":?{"field":"name.keyword"，"size":3
??????}
????}
??}
}

實(shí)際執(zhí)行如下圖所示：各節(jié)點(diǎn)的分片：取自己的Top3 返回給協(xié)調(diào)節(jié)點(diǎn)。協(xié)調(diào)節(jié)點(diǎn)匯集后結(jié)果為：

產(chǎn)品Y：35，?
產(chǎn)品X:?35，
產(chǎn)品A：30。

這就產(chǎn)生了實(shí)際聚合結(jié)果和預(yù)期聚合結(jié)果不一致，也就是聚合結(jié)果不精確。

導(dǎo)致聚合不精確的原因分析：

• 效率因素：每個(gè)分片的取值Top X，并不是匯總?cè)康?TOP X。
• 性能因素：ES 可以不每個(gè)分片Top X，而是全量聚合，但勢(shì)必這會(huì)有很大的性能問題。

3、如何提高聚合精確度？

思考題——terms 聚合中的 size 和 shard_size 有什么區(qū)別？

• size：是聚合結(jié)果的返回值，客戶期望返回聚合排名前三，size值就是 3。
• shard_size: 每個(gè)分片上聚合的數(shù)據(jù)條數(shù)。shard_size 原則上要大于等于 size(若設(shè)置小于size，實(shí)則沒有意義，elasticsearch 會(huì)默認(rèn)置為size)

請(qǐng)求的size值越高，結(jié)果將越準(zhǔn)確，但計(jì)算最終結(jié)果的成本也將越高。

那到底如何提供聚合精準(zhǔn)度呢？這里提供了四種方案供參考：

方案1：設(shè)置主分片為1

注意7.x版本已經(jīng)默認(rèn)為1。

適用場景：數(shù)據(jù)量小小集群規(guī)模業(yè)務(wù)場景。

方案2：調(diào)大 shard_size 值

設(shè)置 shard_size 為比較大的值，官方推薦：size*1.5+10

適用場景：數(shù)據(jù)量大、分片數(shù)多的集群業(yè)務(wù)場景。

shard_size 值越大，結(jié)果越趨近于精準(zhǔn)聚合結(jié)果值。

此外，還可以通過show_term_doc_count_error參數(shù)顯示最差情況下的錯(cuò)誤值，用于輔助確定 shard_size 大小。

方案3：將size設(shè)置為全量值，來解決精度問題

將size設(shè)置為2的32次方減去1也就是分片支持的最大值，來解決精度問題。

原因：1.x版本，size等于 0 代表全部，高版本取消 0 值，所以設(shè)置了最大值(大于業(yè)務(wù)的全量值)。

全量帶來的弊端就是：如果分片數(shù)據(jù)量極大，這樣做會(huì)耗費(fèi)巨大的CPU 資源來排序，而且可能會(huì)阻塞網(wǎng)絡(luò)。

適用場景：對(duì)聚合精準(zhǔn)度要求極高的業(yè)務(wù)場景，由于性能問題，不推薦使用。

方案4：使用Clickhouse 進(jìn)行精準(zhǔn)聚合

在星球微信群里，張超大佬指出：分析系統(tǒng)里跑全量的 group by 我覺得是合理的需求， clickhouse很擅長做這種事，es如果不在這方面加強(qiáng)，分析場景很多會(huì)被 clickhouse替掉。

騰訊大佬指出：聚合這塊比較看場景。因?yàn)槲疫@邊有一些業(yè)務(wù)是做聚合，也就是 olap 場景，多維分析，ES并不是特別擅長。如果有豐富的多維分析場景，還有比較高的性能要求。我建議可以調(diào)研下clickhouse。我們這邊測(cè)評(píng)過開源和內(nèi)部的 大部分場景 clickhouse 幾十億的級(jí)別，基本也在秒級(jí)返回甚至毫秒級(jí)。

此外，除了 chlickhouse， spark也有類似聚合的功能。

適用場景：數(shù)據(jù)量非常大、聚合精度要求高、響應(yīng)速度快的業(yè)務(wù)場景。

4、小結(jié)

回到開頭提到的問題，設(shè)置10和大于10將會(huì)導(dǎo)致聚合結(jié)果不一樣是由于 Elasticsearch 聚合實(shí)現(xiàn)機(jī)制決定的，不是Bug。Elasticsearch本身不提供精準(zhǔn)分桶聚合。要提高聚合精度，參考文章提到的幾種方案。

大家有更好的精度提升方案，歡迎留言交流。

待續(xù)

●ES系列13：徹底掌握相關(guān)度●ES系列14：Bucket Aggs●ES系列15：ES的指標(biāo)聚合有哪些呢？

你點(diǎn)的每個(gè)贊，我都認(rèn)真當(dāng)成了喜歡

總結(jié)

以上是生活随笔為你收集整理的es 精确查询不模糊_ES系列17：Terms聚合结果不精确，怎么破？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。