干貨 | 拆解一個 Elasticsearch Nested 類型復(fù)雜查詢問題
1、線上實戰(zhàn)問題
前置說明：本文是線上環(huán)境的實戰(zhàn)問題拆解，涉及復(fù)雜 DSL，看著會很長，但強(qiáng)烈建議您耐心讀完。
問題描述：
有個復(fù)雜的場景涉及到按照求和后過濾，user_id是用戶編號，gender是性別，time_label是時間標(biāo)簽，時間標(biāo)簽是nested結(jié)構(gòu)，intent_order_count是意向訂單數(shù)量，time是對應(yīng)時間。
現(xiàn)在要篩選出在20210510~20210610，意向訂單數(shù)總和為26的男性用戶，請問應(yīng)該怎么寫dsl語句？
感覺這個場景很復(fù)雜，涉及到array判斷后求和，然后求和結(jié)果做篩選條件。
請幫忙看看有什么好的dsl語句，或者改變現(xiàn)有mapping結(jié)構(gòu)。
這個是mapping結(jié)構(gòu) 如下：
PUT index_personal
{
"mappings": {
"properties": {
"time_label": {
"type": "nested",
"properties": {
"intent_order_count": {
"type": "long"
},
"time": {
"type": "long"
}
}
},
"user_id": {
"type": "keyword"
},
"gender": {
"type": "keyword"
}
}
}
}
下面是我構(gòu)造的數(shù)據(jù)：
PUT index_personal/_doc/1
{
"user_id": "1",
"gender": "male",
"time_label": [
{
"time": 20210601,
"intent_order_count": 3
},
{
"time": 20210602,
"intent_order_count": 2
},
{
"time": 20210605,
"intent_order_count": 20
},
{
"time": 20210606,
"intent_order_count": 1
},
{
"time": 20210611,
"intent_order_count": 15
}
]
}
PUT index_personal/_doc/2
{
"user_id": "2",
"gender": "female"
}
PUT index_personal/_doc/3
{
"user_id": "3",
"gender": "male",
"time_label": [
{
"time": 20210102,
"intent_order_count": 12
},
{
"time": 20210202,
"intent_order_count": 33
}
]
}
問題擴(kuò)展解釋：
1、"intent_order_count"代表：是訂單數(shù)，不過都可以抽象成這個用戶某個時間買了幾個。
比如第三條數(shù)據(jù)，表示用戶編號為 3 的用戶，是男性用戶，曾經(jīng)在 20210102 時有12個意向訂單（跟訂單一個意思），在 20210202 有 33 個意向訂單，
2、每個用戶除了性別還有很多屬性，篇幅受限，沒有列出。
問題來源：https://t.zsxq.com/FmEeaIY
2、數(shù)據(jù)建模探討
2.1 原問題 Nested 模型
原有數(shù)據(jù)，以 Nested 建模，存儲結(jié)構(gòu)如下：
| user_id | gender | time_label {time:intent_order_count} |
|---|---|---|
| 1 | male | [ {20210601:3} {20210602:2}{20210605:20}{20210606:1}{20210611:15}] |
| 2 | female | |
| 3 | male | { 20210102:12}{20210202:33} |
以上表示并不嚴(yán)謹(jǐn)，僅是為了更直觀的闡述問題。
2.2 寬表建模方案
拿到問題后，我的第一反應(yīng)：建?？赡苡袉栴}。
第一：time 存儲的是日期，應(yīng)該是日期類型：date。
第二：寬表拉平存儲是不是更好？！也就是說：針對：“user_id” 的用戶，一個時間數(shù)據(jù)，對應(yīng)一個 document 文檔。
原有的 nested 結(jié)構(gòu)，改成如下的一條條的記錄，也就是“寬表”，類似簡化存儲如下：
| user_id | gender | time | intent_order_count |
|---|---|---|---|
| 1 | male | 20210601 | 3 |
| 1 | male | 20210602 | 2 |
| 1 | male | 20210605 | 20 |
| 1 | male | 20210606 | 1 |
| 1 | male | 20210611 | 15 |
| 2 | female | ||
| 3 | male | 20210102 | 12 |
| 3 | male | 20210202 | 33 |
“寬表”是典型的以空間換時間的方案，我們?nèi)庋劭吹降模簩τ?user_id=1 的 用戶，user_id, gender 信息會存儲 N 份（每多一次 time，就多存儲一次）。
如前所述，每個用戶除了性別還有很多屬性，也就是屬性非常多的話，會產(chǎn)生大量的冗余存儲。
寬表方案優(yōu)缺點(diǎn)如下：
優(yōu)點(diǎn)：更利用用戶理解，寫入和更新非常方便且效率高。 缺點(diǎn)：存在大量冗余存儲，耗費(fèi)空間大。
針對“寬表”方案，問題提出者球友的反饋如下：
“這確實也是個思路。但是我的這個場景下，每個用戶除了性別還有很多屬性，這樣會每天都會產(chǎn)生大量的冗余數(shù)據(jù)。
是否有辦法將一個用戶的時間信息聚集到一個文檔下，然后也能夠查詢，對查詢效率要求不高?！?/span>
所以，還得從 Nested 建模角度基礎(chǔ)上，考慮如何實現(xiàn)查詢？
2.3 Nested 建模方案
原有建模問題無大礙，只需將：time 字段由 long 類型改為 date 類型，其他保持不變。
# 新的 Mapping 結(jié)構(gòu)（微調(diào)）
PUT index_personal_02
{
"mappings": {
"properties": {
"time_label": {
"type": "nested",
"properties": {
"intent_order_count": {
"type": "long"
},
"time": {
"type": "date"
}
}
},
"user_id": {
"type": "keyword"
},
"gender": {
"type": "keyword"
}
}
}
}
# 還是原來的構(gòu)造數(shù)據(jù)，改成bulk，占據(jù)行數(shù)更少
PUT index_personal_02/_bulk
{"index":{"_id":1}}
{"user_id":"1","gender":"male","time_label":[{"time":20210601,"intent_order_count":3},{"time":20210602,"intent_order_count":2},{"time":20210605,"intent_order_count":20},{"time":20210606,"intent_order_count":1},{"time":20210611,"intent_order_count":15}]}
{"index":{"_id":2}}
{"user_id":"2","gender":"female"}
{"index":{"_id":3}}
{"user_id":"3","gender":"male","time_label":[{"time":20210102,"intent_order_count":12},{"time":20210202,"intent_order_count":33}]}
良好的數(shù)據(jù)建模就好比蓋大樓的地基，地基自然是越穩(wěn)、越實、越牢靠越好！
3、查詢方案拆解
3.1 分步驟拆解用戶查詢需求
問題拆解成如下幾個部分：
3.1.1 篩選出在20210510~20210610
DSL 寫法如下：
{
"nested": {
"path": "time_label",
"query": {
"bool": {
"must": [
{
"range": {
"time_label.time": {
"gte": 20210510,
"lte": 20210601
}
}
}
]
}
}
}
}
正常寫 Query 不會涉及 Nested，只有涉及 Nested 數(shù)據(jù)類型，才必須在檢索的前半部分加上 Nested 聲明，其目的無非告訴 Elasticsearch 后臺，這是針對 Nested 類型的檢索。
Path 指定的Nested 最外層，在本文指定的是：time_label。
3.1.2 意向訂單數(shù)總和為26的男性用戶
銘毅拆解：
關(guān)于男性用戶，這里可以基于性別檢索做過濾。
DSL 寫法如下：
{
"term": {
"gender": {
"value": "male"
}
}
}
關(guān)于意向訂單:對于 user_id = 1 的用戶，意向訂單總數(shù)就等于 3 + 2 + 20 + 1 + 15 = 41。
要實現(xiàn)類似的求和，得需要借助 sum Metric 指標(biāo)聚合實現(xiàn)。
sum Metric 聚合的前提是：針對某一特定用戶形成一個結(jié)果，所以其外層是基于用戶維度（本文使用：user_id）層面的terms聚合。
為了顯示出除了聚合結(jié)果之外的其他屬性列，需要借助 top_hits 的 _source 中的 include 實現(xiàn)。
DSL 寫法大致如下：
"aggs": {
"user_id_aggs": {
"terms": {
"field": "user_id"
},
"aggs": {
"top_sales_hits": {
"top_hits": {
"_source": {
"includes": [
"user_id",
"gender"
]
}
}
},
"resellers": {
"nested": {
"path": "time_label"
},
"aggs": {
"sum_count": {
"sum": {
"field": "time_label.intent_order_count"
}
}
}
}
如上：
最外層 terms 聚合：是基于 user_id 的分桶聚合，每個 user_id 的結(jié)果聚成一桶。
內(nèi)層的聚合包含兩個，兩個是平級的。
其一：top_hits 指標(biāo)聚合，用于顯示聚合結(jié)果之外的字段。
其二：sum 指標(biāo)聚合，用于對“time_label.intent_order_count”統(tǒng)計結(jié)果求和。
除了上面的兩層聚合，又涉及總和結(jié)果和 26 進(jìn)行比較，所以要基于聚合的聚合，也就是子聚合的實現(xiàn)。
DSL 寫法如下：
"count_bucket_filter": {
"bucket_selector": {
"buckets_path": {
"totalcount": "resellers.sum_count"
},
"script": "params.totalcount >= 26"
}
}
文中給的實際例子沒有滿足 26 的文檔，所以，這里為了直觀顯示結(jié)果，使用了 >= 26 實現(xiàn)。
3.1.3 應(yīng)該怎么寫dsl語句？
銘毅拆解：
基于上面幾個步驟整合到一起，即可實現(xiàn)。
查詢 DSL ——即用戶最終期望。查詢 DSL 就類似“圖紙”、“導(dǎo)航”或“路徑”，給出了達(dá)到給定目的的可行性路徑，后面無非就是：java 或者 Python 代碼的“堆砌”實現(xiàn)。
3.2 最終 DSL
POST index_personal_02/_search
{
"size": 0,
"query": {
"bool": {
"must": [
{
"nested": {
"path": "time_label",
"query": {
"bool": {
"must": [
{
"range": {
"time_label.time": {
"gte": 20210510,
"lte": 20210601
}
}
}
]
}
}
}
},
{
"term": {
"gender": {
"value": "male"
}
}
}
]
}
},
"aggs": {
"user_id_aggs": {
"terms": {
"field": "user_id"
},
"aggs": {
"top_sales_hits": {
"top_hits": {
"_source": {
"includes": [
"user_id",
"gender"
]
}
}
},
"resellers": {
"nested": {
"path": "time_label"
},
"aggs": {
"sum_count": {
"sum": {
"field": "time_label.intent_order_count"
}
}
}
},
"count_bucket_filter": {
"bucket_selector": {
"buckets_path": {
"totalcount": "resellers.sum_count"
},
"script": "params.totalcount >= 26"
}
}
}
}
}
}
要強(qiáng)調(diào)的點(diǎn)是：
第一：涉及 Nested 的 query 檢索 以及 aggs 聚合，都需要明確指定 Nested Path。
第二：復(fù)雜檢索和聚合出錯多數(shù)是：子聚合的位置放的不對、后括號和前括弧不匹配等，需要多在 Kibana 測試驗證。
第三：Kibana 的一鍵 DSL 美化快捷鍵：“ctrl + i” 要掌握和靈活使用。
相信經(jīng)過上面的拆解，這個相對“復(fù)雜”的 DSL 會變得非但不那么“復(fù)雜”，反而非常容易讀懂。
3.3 查詢后結(jié)果
"aggregations" : {
"user_id_aggs" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "1",
"doc_count" : 1,
"top_sales_hits" : {
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 1.4418328,
"hits" : [
{
"_index" : "index_personal_02",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.4418328,
"_source" : {
"gender" : "male",
"user_id" : "1"
}
}
]
}
},
"resellers" : {
"doc_count" : 5,
"sum_count" : {
"value" : 41.0
}
}
}
]
}
}
由于檢索 size = 0，所以，只返回了聚合結(jié)果，沒有返回檢索結(jié)果。
由于二層聚合設(shè)置了 top_hits,所以返回結(jié)果里除了sum_count的聚合結(jié)果，還包含的其下鉆數(shù)據(jù)字段：“gender”、“user_id” 信息，如果實際業(yè)務(wù)還有更多需要召回字段，可以一并 include 包含后返回即可。
4、有沒有更簡單的方案？
第 3 小節(jié)的實現(xiàn)是基于聚合，但實際文檔是 Nested 類型的，基于 userr_id 聚合顯得非常的多余。
這里自然想到，用檢索能否實現(xiàn)？
如果簡單檢索不行，那么腳本檢索呢？
4.1 擴(kuò)展方案 1：腳本檢索實戰(zhàn)
搞一把試試。
GET index_personal_02/_search
{
"query": {
"bool": {
"must": [
{
"nested": {
"path": "time_label",
"query": {
"bool": {
"must": [
{
"range": {
"time_label.time": {
"gte": 20210510,
"lte": 20210613
}
}
},
{
"script": {
"script": """
int sum = 0;
for (obj in doc['time_label.intent_order_count']) {
sum += obj;
}
sum >= 10;"""
}
}
]
}
}
}
},
{
"term": {
"gender": {
"value": "male"
}
}
}
]
}
}
}
如上邏輯看似非常嚴(yán)謹(jǐn)?shù)哪_本，實際是行不通的。
sum += obj; 本質(zhì)上只求了一個值。
Elastic 官方工程師給出了詳細(xì)的解釋：“無法在查詢時訪問腳本中所有嵌套對象的值。腳本查詢一次僅適用于一個嵌套對象?！?/span>
詳細(xì)討論參見：
https://stackoverflow.com/questions/64140179/elasticsearch-sum-up-nested-object-field
https://discuss.elastic.co/t/help-for-painless-iterate-nested-fields/162394
結(jié)論：腳本檢索不適用 Nested 嵌套對象求和。
官方推薦用 Ingest pipeline 預(yù)處理方式實現(xiàn)，那就再搞一把。
4.2 擴(kuò)展方案 2：Ingest pipeline 方式實戰(zhàn)
4.2.1 步驟 1——設(shè)置求和的 pipeline。
sum_pipeline 用途：將 nested 嵌套的 intent_order_count 字段進(jìn)行求和。
# 設(shè)定pipeline，統(tǒng)計計數(shù)總和
PUT _ingest/pipeline/sum_pipeline
{
"processors": [
{
"script": {
"source": """
ctx.sum_count = ctx.time_label.stream()
.mapToInt(thing -> thing.intent_order_count)
.sum()
"""
}
}
]
}
4.2.2 步驟 2——結(jié)合 pipeline 更新數(shù)據(jù)
注意一下：nested 添加數(shù)據(jù)需要借助 script 實現(xiàn)，不能直接指定 id 插入。
若指定 id 插入數(shù)據(jù)會覆蓋掉之前的數(shù)據(jù)。
# 新插入數(shù)據(jù)
POST index_personal_02/_update_by_query?pipeline=sum_pipeline
{
"query":{
"term": {
"user_id": {
"value": "1"
}
}
},
"script": {
"source": "ctx._source.time_label.add(params.newlabel)",
"params": {
"newlabel": {
"time": 20210702,
"intent_order_count": 88
}
}
}
}
4.2.3 步驟 3——結(jié)合文章開頭要求進(jìn)行檢索
借助 pipeline 新增的字段 sum_count 可以檢索條件之一。
# 檢索結(jié)果
GET index_personal_02/_search
{
"query": {
"bool": {
"must": [
{
"nested": {
"path": "time_label",
"query": {
"bool": {
"must": [
{
"range": {
"time_label.time": {
"gte": 20210510,
"lte": 20210601
}
}
}
]
}
}
}
},
{
"term": {
"gender": {
"value": "male"
}
}
},
{
"range": {
"sum_count": {
"gte": 26
}
}
}
]
}
}
}
Ingest pipeline 方案小結(jié)：
通過預(yù)處理管道新增字段，以空間換時間。 新增的字段作為檢索的條件之一，不再需要聚合。
5、小結(jié)
分解是計算思維的核心思想之一，“大事化小，逐個擊破”。本文的拆解思路也是基于分解的思想一步步拆解。
本文針對線上問題，拋轉(zhuǎn)引玉，給出了方案拆解和完整的步驟實現(xiàn)。
共探索出兩種可行的方案：
方案一：聚合實現(xiàn)。
方案一本質(zhì)：兩重嵌套聚合（terms分桶 + 分桶內(nèi) sum 指標(biāo)聚合）+ 子聚合（基于聚合的聚合 bucket_selector）實現(xiàn)。
方案二：預(yù)處理管道 pipeline 實現(xiàn)。
方案二本質(zhì)：新增求和字段，以空間換時間。
實戰(zhàn)環(huán)境類似本文問題，銘毅推薦使用方案二。
細(xì)節(jié)問題待進(jìn)一步結(jié)合線上需求進(jìn)行擴(kuò)展修改 DSL。
歡迎就問題及方案進(jìn)行留言，說一下您的思考和思路反饋。
https://discuss.elastic.co/t/script-processor-ingest-pipelines-on-nested-fields/172092/2
推薦
如何系統(tǒng)的學(xué)習(xí) Elasticsearch ？ 全網(wǎng)首發(fā)！《 Elasticsearch 最少必要知識教程 V1.0 》低調(diào)發(fā)布 從實戰(zhàn)中來，到實戰(zhàn)中去——Elasticsearch 技能更快提升方法論 刻意練習(xí) Elasticsearch 10000 個小時，鬼知道經(jīng)歷了什么？！ 干貨 | Elasticsearch Nested類型深入詳解 基于兒童積木玩具圖解 Elasticsearch 聚合 干貨 | 通透理解Elasticsearch聚合 Elasticsearch 如何實現(xiàn)查詢/聚合不區(qū)分大小寫？
比同事搶先一步！