Elasticsearch 7.7.0 高阶篇-聚合技术
前言
本篇內(nèi)容是es的最后一篇，主要講解聚合技術(shù)，以及與其相關(guān)的算法和原理，最后結(jié)合實(shí)際應(yīng)用，簡(jiǎn)單說(shuō)明了一些常用的數(shù)據(jù)建模。
一 聚合分析之 bucket(分組)&meteric(統(tǒng)計(jì))
這一節(jié)內(nèi)容主要是介紹下 bucket(分組)的概念 以及 meteric(聚合統(tǒng)計(jì))概念，其實(shí)我們做過(guò)開(kāi)發(fā)寫過(guò)sql的就很容易理解了。然后我們結(jié)合案例進(jìn)行練習(xí)和體會(huì)不同的bucket，以及不同的meteric，強(qiáng)化我們對(duì)分組和聚合統(tǒng)計(jì)的理解和記憶。
1.1 原理 bucket(分組)與metric(聚合統(tǒng)計(jì))概念理解
bucket 它是指對(duì)一組數(shù)據(jù)進(jìn)行分組
假設(shè)一組數(shù)據(jù)為：
city name
北京 小李
北京 小王
上海 小張
上海 小麗
上海 小陳
那么基于city劃分buckets，劃分出來(lái)兩個(gè)bucket，一個(gè)是北京bucket，一個(gè)是上海bucket
則：
北京bucket：包含了2個(gè)人，小李，小王
上海bucket：包含了3個(gè)人，小張，小麗，小陳
其實(shí) sql中的分組，就是我們這里的bucket。
?
metric：對(duì)一個(gè)數(shù)據(jù)分組執(zhí)行的統(tǒng)計(jì)
當(dāng)我們有了一堆bucket之后，就可以對(duì)每個(gè)bucket中的數(shù)據(jù)進(jìn)行聚合分詞了，比如說(shuō)計(jì)算一個(gè)bucket內(nèi)所有數(shù)據(jù)的數(shù)量，或者計(jì)算一個(gè)bucket內(nèi)所有數(shù)據(jù)的平均值，最大值，最小值
metric，就是對(duì)一個(gè)bucket執(zhí)行的某種聚合分析的操作，比如說(shuō)求平均值，求最大值，求最小值
1.2 實(shí)戰(zhàn) 各種bucket(分組)與各種metric(聚合統(tǒng)計(jì)）
以一個(gè)家電賣場(chǎng)中的電視銷售數(shù)據(jù)為背景，來(lái)對(duì)各種品牌，各種顏色的電視的銷量和銷售額，進(jìn)行各種各樣角度的分析
1.2.1 準(zhǔn)備初始化數(shù)據(jù)
PUT /tvs {"mappings": {"properties": {"price": {"type": "long"},"color": {"type": "keyword"},"brand": {"type": "keyword"},"sold_date": {"type": "date"}}} } POST /tvs/_bulk {"index":{}} {"price":1000,"color":"紅色","brand":"長(zhǎng)虹","sold_date":"2016-10-28"} {"index":{}} {"price":2000,"color":"紅色","brand":"長(zhǎng)虹","sold_date":"2016-11-05"} {"index":{}} {"price":3000,"color":"綠色","brand":"小米","sold_date":"2016-05-18"} {"index":{}} {"price":1500,"color":"藍(lán)色","brand":"TCL","sold_date":"2016-07-02"} {"index":{}} {"price":1200,"color":"綠色","brand":"TCL","sold_date":"2016-08-19"} {"index":{}} {"price":2000,"color":"紅色","brand":"長(zhǎng)虹","sold_date":"2016-11-05"} {"index":{}} {"price":8000,"color":"紅色","brand":"三星","sold_date":"2017-01-01"} {"index":{}} {"price":2500,"color":"藍(lán)色","brand":"小米","sold_date":"2017-02-12"}1.2.2 按顏色分組統(tǒng)計(jì)電視銷量
size：=0只獲取聚合結(jié)果，而不要執(zhí)行聚合的原始數(shù)據(jù)
aggs：固定語(yǔ)法，要對(duì)一份數(shù)據(jù)執(zhí)行分組聚合操作
popular_colors：就是對(duì)每個(gè)aggs，都要起一個(gè)名字，這個(gè)名字是隨機(jī)的，你隨便取什么都o(jì)k
terms：根據(jù)字段的值進(jìn)行分組
field：根據(jù)指定的字段的值進(jìn)行分組
GET /tvs/_search {"size": 0,"aggs": {"popular_colors": {"terms": {"field": "color"}}} }獲取結(jié)果
{"took" : 142,"timed_out" : false,"_shards" : {"total" : 1,"successful" : 1,"skipped" : 0,"failed" : 0},"hits" : {"total" : {"value" : 8,"relation" : "eq"},"max_score" : null,"hits" : [ ]},"aggregations" : {"popular_colors" : {"doc_count_error_upper_bound" : 0,"sum_other_doc_count" : 0,"buckets" : [{"key" : "紅色","doc_count" : 4},{"key" : "綠色","doc_count" : 2},{"key" : "藍(lán)色","doc_count" : 2}]}} }1.2.3 按顏色分組metric（統(tǒng)計(jì)）平均(avg)價(jià)格
除了bucket操作，分組，還要對(duì)每個(gè)bucket執(zhí)行一個(gè)metric聚合統(tǒng)計(jì)操作
在一個(gè)aggs執(zhí)行的bucket操作（terms），平級(jí)的json結(jié)構(gòu)下，再加一個(gè)aggs，這個(gè)第二個(gè)aggs內(nèi)部，同樣取個(gè)名字，執(zhí)行一個(gè)metric操作，avg，對(duì)之前的每個(gè)bucket中的數(shù)據(jù)的指定的field，price field，求一個(gè)平均值
GET /tvs/_search {"size": 0,"aggs": {"colors": {"terms": {"field": "color"},"aggs": {"avg_price": {"avg": {"field": "price"}}}}} }buckets，除了key和doc_count
avg_price：我們自己取的metric aggs的名字
value：我們的metric計(jì)算的結(jié)果，每個(gè)bucket中的數(shù)據(jù)的price字段求平均值后的結(jié)果
1.2.4 按顏色分組metric（統(tǒng)計(jì)）最大(max) 最小（min）價(jià)格
max：求一個(gè)bucket內(nèi)，指定field值最大的那個(gè)數(shù)據(jù)
min：求一個(gè)bucket內(nèi)，指定field值最小的那個(gè)數(shù)據(jù)
sum：求一個(gè)bucket內(nèi)，指定field值的總和
一般來(lái)說(shuō)，90%的常見(jiàn)的數(shù)據(jù)分析的操作，metric，無(wú)非就是count，avg，max，min，sum
求總和，就可以拿到一個(gè)顏色下的所有電視的銷售總額
GET /tvs/_search {"size": 0,"aggs": {"colors": {"terms": {"field": "color"},"aggs": {"avg_price": {"avg": {"field": "price"}},"min_price": {"min": {"field": "price"}},"max_price": {"max": {"field": "price"}},"sum_price": {"sum": {"field": "price"}}}}} }1.2.5 按價(jià)格區(qū)間(histogram&interval) 統(tǒng)計(jì)銷售量和銷售額
histogram 也是bucket ，他按照某個(gè)值指定的interval(步長(zhǎng))，劃分一個(gè)一個(gè)的bucket
interval：2000，劃分范圍，0~2000，2000~4000，4000~6000，6000~8000，8000~10000，buckets
去根據(jù)price的值，比如2500，看落在哪個(gè)區(qū)間內(nèi)，比如2000~4000，此時(shí)就會(huì)將這條數(shù)據(jù)放入2000~4000對(duì)應(yīng)的那個(gè)bucket中。
GET /tvs/_search {"size": 0,"aggs": {"price": {"histogram": {"field": "price","interval": 2000},"aggs": {"revenue": {"sum": {"field": "price"}}}}} }1.2.6 按日期區(qū)間（histogram&calendar_interval） 統(tǒng)計(jì)電視銷量
date histogram，按照我們指定的某個(gè)date類型的日期field，以及日期calendar_interval，按照一定的日期間隔，去劃分bucket。
假設(shè)：
calendar_interval = 1m，
則：
2017-01-01~2017-01-31，就是一個(gè)bucket
2017-02-01~2017-02-28，就是一個(gè)bucket
然后會(huì)去掃描每個(gè)數(shù)據(jù)的date field，判斷date落在哪個(gè)bucket中，就將其放入那個(gè)bucket，2017-01-05，就將其放入2017-01-01~2017-01-31，就是一個(gè)bucket。
min_doc_count：即使某個(gè)日期interval，2017-01-01~2017-01-31中，一條數(shù)據(jù)都沒(méi)有，那么這個(gè)區(qū)間也是要返回的，不然默認(rèn)是會(huì)過(guò)濾掉這個(gè)區(qū)間的
extended_bounds，min，max：劃分bucket的時(shí)候，會(huì)限定在這個(gè)起始日期，和截止日期內(nèi)
GET /tvs/_search {"size": 0,"aggs": {"price": {"histogram": {"field": "price","interval": 2000},"aggs": {"revenue": {"sum": {"field": "price"}}}}} }1.2.7 按顏色+生產(chǎn)商多層分組(bucket)嵌套下鉆分析
下鉆分析，就要對(duì)bucket進(jìn)行多層嵌套，多次分組。
舉例理解：
比如說(shuō)，現(xiàn)在紅色的電視有4臺(tái)，同時(shí)這4臺(tái)電視中，有3臺(tái)是屬于長(zhǎng)虹的，1臺(tái)是屬于小米的
紅色電視中的3臺(tái)長(zhǎng)虹的平均價(jià)格是多少？
紅色電視中的1臺(tái)小米的平均價(jià)格是多少？
下鉆的意思是，已經(jīng)分了一個(gè)組，比如說(shuō)顏色的分組，然后還要繼續(xù)對(duì)這個(gè)分組內(nèi)的數(shù)據(jù)，再分組，比如一 ? ? ? ? ?個(gè)顏色內(nèi)，還可以分成多個(gè)不同的品牌的組，最后對(duì)每個(gè)最小粒度的分組執(zhí)行聚合分析操作，這就叫做下鉆 ? ? ? ? ? ?分析
按照多個(gè)維度（顏色+品牌）多層下鉆分析，都可以對(duì)每個(gè)維度分別執(zhí)行一次metric聚合操作
GET /tvs/_search {"size": 0,"aggs": {"group_by_color": {"terms": {"field": "color"},"aggs": {"color_avg_price": {"avg": {"field": "price"}},"group_by_brand": {"terms": {"field": "brand"},"aggs": {"brand_avg_price": {"avg": {"field": "price"}}}}}}} }1.2.8 按季度+品牌多層分組下鉆分析售額
GET /tvs/_search {"size": 0,"aggs": {"group_by_sold_date": {"date_histogram": {"field": "sold_date","calendar_interval": "quarter","format": "yyyy-MM-dd","min_doc_count": 0,"extended_bounds": {"min": "2016-01-01","max": "2017-12-31"}},"aggs": {"group_by_brand": {"terms": {"field": "brand"},"aggs": {"sum_price": {"sum": {"field": "price"}}}},"total_sum_price": {"sum": {"field": "price"}}}}} }二 聚合分析之縮小數(shù)據(jù)范圍&數(shù)據(jù)排序
2.1 先縮小數(shù)據(jù)范圍再聚合分析
2.1.1 按小米品牌搜索 統(tǒng)計(jì)銷售額
先查詢 品牌為小米的數(shù)據(jù) 后聚合
GET /tvs/_search {"size": 0,"query": {"term": {"brand": {"value": "小米"}}},"aggs": {"group_by_color": {"terms": {"field": "color"}}} }2.1.2 單品牌長(zhǎng)虹與所有品牌(global bucket)銷量對(duì)比
global就是global bucket，就是將所有數(shù)據(jù)納入聚合的scope，他不關(guān)心過(guò)濾的范圍，他是統(tǒng)計(jì)所有的數(shù)據(jù)
GET /tvs/_search {"size": 0,"query": {"term": {"brand": {"value": "長(zhǎng)虹"}}},"aggs": {"single_brand_avg_price": {"avg": {"field": "price"}},"all": {"global": {},"aggs": {"all_brand_avg_price": {"avg": {"field": "price"}}}}} }single_brand_avg_price：就是針對(duì)query搜索結(jié)果，執(zhí)行的，拿到的，就是長(zhǎng)虹品牌的平均價(jià)格
all.all_brand_avg_price：拿到所有品牌的平均價(jià)格
2.1.3 按價(jià)格大于1200過(guò)濾(filter) 計(jì)算平均價(jià)格
先搜索過(guò)濾出價(jià)格大于1200 的數(shù)據(jù)，然后再計(jì)算avg價(jià)格
GET /tvs/_search {"size": 0,"query": {"constant_score": {"filter": {"range": {"price": {"gte": 1200}}}}},"aggs": {"avg_price": {"avg": {"field": "price"}}} }2.1.4 按時(shí)間段+品牌過(guò)濾統(tǒng)計(jì)銷售額
GET /tvs/_search {"size": 0,"query": {"term": {"brand": {"value": "長(zhǎng)虹"}}},"aggs": {"recent_150d": {"filter": {"range": {"sold_date": {"gte": "now-150d"}}},"aggs": {"recent_150d_avg_price": {"avg": {"field": "price"}}}},"recent_140d": {"filter": {"range": {"sold_date": {"gte": "now-140d"}}},"aggs": {"recent_140d_avg_price": {"avg": {"field": "price"}}}},"recent_130d": {"filter": {"range": {"sold_date": {"gte": "now-130d"}}},"aggs": {"recent_130d_avg_price": {"avg": {"field": "price"}}}}} }bucket filter：對(duì)不同的bucket下的aggs，進(jìn)行filter
2.2 對(duì)分組數(shù)據(jù)進(jìn)行排序
2.2.1 按顏色分組對(duì)銷售額排序
每個(gè)顏色的電視的銷售額，需要按照銷售額降序排序
GET /tvs/_search {"size": 0,"aggs": {"group_by_color": {"terms": {"field": "color","order": {"avg_price": "asc"}},"aggs": {"avg_price": {"avg": {"field": "price"}}}}} }2.2.2 按顏色+品牌多層分組下鉆排序
就是先顏色分組 ?然后品牌里分組且排序(平均價(jià)格降序)
GET /tvs/_search {"size": 0,"aggs": {"group_by_color": {"terms": {"field": "color"},"aggs": {"group_by_brand": {"terms": {"field": "brand","order": {"avg_price": "desc"}},"aggs": {"avg_price": {"avg": {"field": "price"}}}}}}} }三 聚合分析之百分比統(tǒng)計(jì)
3.1 percentiles百分比統(tǒng)計(jì)
需求：比如有一個(gè)網(wǎng)站，記錄下了每次請(qǐng)求的訪問(wèn)的耗時(shí)，需要統(tǒng)計(jì)tp50，tp90，tp99
tp50：50%的請(qǐng)求的耗時(shí)最長(zhǎng)在多長(zhǎng)時(shí)間
tp90：90%的請(qǐng)求的耗時(shí)最長(zhǎng)在多長(zhǎng)時(shí)間
tp99：99%的請(qǐng)求的耗時(shí)最長(zhǎng)在多長(zhǎng)時(shí)間
3.1.1 初始化數(shù)據(jù)
DELETE website PUT /website {"mappings": {"properties": {"latency": {"type": "long"},"province": {"type": "keyword"},"timestamp": {"type": "date"}}} }POST /website/_bulk {"index":{}} {"latency":105,"province":"江蘇","timestamp":"2016-10-28"} {"index":{}} {"latency":83,"province":"江蘇","timestamp":"2016-10-29"} {"index":{}} {"latency":92,"province":"江蘇","timestamp":"2016-10-29"} {"index":{}} {"latency":112,"province":"江蘇","timestamp":"2016-10-28"} {"index":{}} {"latency":68,"province":"江蘇","timestamp":"2016-10-28"} {"index":{}} {"latency":76,"province":"江蘇","timestamp":"2016-10-29"} {"index":{}} {"latency":101,"province":"新疆","timestamp":"2016-10-28"} {"index":{}} {"latency":275,"province":"新疆","timestamp":"2016-10-29"} {"index":{}} {"latency":166,"province":"新疆","timestamp":"2016-10-29"} {"index":{}} {"latency":654,"province":"新疆","timestamp":"2016-10-28"} {"index":{}} {"latency":389,"province":"新疆","timestamp":"2016-10-28"} {"index":{}} {"latency":302,"province":"新疆","timestamp":"2016-10-29"}3.1.2 百分比統(tǒng)計(jì)
GET /website/_search {"size": 0,"aggs": {"latency_percentiles": {"percentiles": {"field": "latency","percents": [50,95,99]}},"latency_avg": {"avg": {"field": "latency"}}} }50%的請(qǐng)求，數(shù)值的最大的值是多少，不是完全準(zhǔn)確的
3.1.3 按照省份分組 算百分比
GET /website/_search {"size": 0,"aggs": {"group_by_province": {"terms": {"field": "province"},"aggs": {"latency_percentiles": {"percentiles": {"field": "latency","percents": [50,95,99]}},"latency_avg": {"avg": {"field": "latency"}}}}} }3.2 ?percentile rank&SLA統(tǒng)計(jì)
SLA：就是你提供的服務(wù)的標(biāo)準(zhǔn)
我們的網(wǎng)站的提供的訪問(wèn)延時(shí)的SLA，確保所有的請(qǐng)求100%，都必須在200ms以內(nèi)，大公司內(nèi)，一般都是要求100%在200ms以內(nèi)，如果超過(guò)1s，則需要升級(jí)到A級(jí)故障，代表網(wǎng)站的訪問(wèn)性能和用戶體驗(yàn)急劇下降。
需求：在200ms以內(nèi)的，有百分之多少，在1000毫秒以內(nèi)的有百分之多少，percentile ranks metric
GET /website/_search {"size": 0,"aggs": {"group_by_province": {"terms": {"field": "province"},"aggs": {"latency_percentile_ranks": {"percentile_ranks": {"field": "latency","values": [200,1000]}}}}} }percentile的優(yōu)化
如果你想要percentile算法越精準(zhǔn)，compression可以設(shè)置的越大
四 聚合分析相關(guān)算法原理及優(yōu)化
4.1 易并行&不易并行算法
易并行：max
不易并行：count(distinct)，并不是說(shuō)，在每個(gè)node上，直接就出一些count(distinct) value，就可以的，因?yàn)閿?shù)據(jù)可能會(huì)很多。
es會(huì)采取近似聚合算法，就是采用在每個(gè)node上進(jìn)行近估計(jì)的方式，得到最終的結(jié)論。
?
如果采取近似估計(jì)的算法：延時(shí)在100ms左右（一般會(huì)達(dá)到完全精準(zhǔn)的算法的性能的數(shù)十倍），0.5%錯(cuò)誤
如果采取100%精準(zhǔn)的算法：延時(shí)一般在5s~幾十s，甚至幾十分鐘，幾小時(shí)， 0%錯(cuò)誤
4.2 精準(zhǔn)+實(shí)時(shí)+大數(shù)據(jù)三角選擇原則
4.3 cartinality(去重)算法
cartinality metric，對(duì)每個(gè)bucket中的指定的field進(jìn)行去重，取去重后的count，類似于count(distcint)
GET /tvs/_search {"size": 0,"aggs": {"months": {"date_histogram": {"field": "sold_date","calendar_interval": "month"},"aggs": {"distinct_colors": {"cardinality": {"field": "brand"}}}}} }4.4 cardinality&precision_threshold優(yōu)化準(zhǔn)確率和內(nèi)存開(kāi)銷
GET /tvs/_search {"size": 0,"aggs": {"distinct_brand": {"cardinality": {"field": "brand","precision_threshold": 100}}} }brand去重，如果brand的unique value，precision_threshold=100 ,即 在100個(gè)以內(nèi)，小米，長(zhǎng)虹，三星，TCL，HTL......則cardinality，幾乎保證100%準(zhǔn)確。
precision_threshold：
- 會(huì)占用precision_threshold * 8 byte 內(nèi)存消耗，100 * 8 = 800個(gè)字節(jié)（占用內(nèi)存很小）
- 而且unique value如果的確在值以內(nèi)，那么可以確保100%準(zhǔn)確
precision_threshold，值設(shè)置的越大，占用內(nèi)存越大，1000 * 8 = 8000 / 1000 = 8KB，可以確保更多unique value的場(chǎng)景下，100%的準(zhǔn)確。
4.5 HyperLogLog++ (HLL)算法index-time性能優(yōu)化
cardinality底層算法：HLL算法會(huì)對(duì)所有的uqniue value取hash值，通過(guò)hash值近似去求distcint count。
默認(rèn)情況下，發(fā)送一個(gè)cardinality請(qǐng)求的時(shí)候，會(huì)動(dòng)態(tài)地對(duì)所有的field value 取hash值;
優(yōu)化方法：將取hash值的操作，前移到建立索引的時(shí)候，即我們灌入數(shù)據(jù)的時(shí)候建好hash值，但是提升性能不大，了解即可
PUT /tvs {"mappings": {"properties": {"brand": {"type": "text","fields": {"hash": {"type": "murmur3"}}}}} }GET /tvs/_search {"size": 0,"aggs": {"distinct_brand": {"cardinality": {"field": "brand.hash","precision_threshold": 100}}} }五 聚合分析的內(nèi)部原理
5.1 doc value 正排原理
聚合分析的內(nèi)部原理是什么？aggs，term，metric avg max，執(zhí)行一個(gè)聚合操作的時(shí)候，內(nèi)部原理是怎樣的呢？用了什么樣的數(shù)據(jù)結(jié)構(gòu)去執(zhí)行聚合？是不是用的倒排索引？
GET /test_index/_search {"query": {"match": {"search_field": "test"}},"aggs": {"group_by_agg_field": {"terms": {"field": "agg_field"}}} }模擬解釋
查詢操作
doc1: hello world test1, test2 、doc2: hello test、doc3: world test
創(chuàng)建倒排索引
| word? | doc1 | doc2 | doc3 |
| hello | * | * | ? |
| world | * | ? | * |
| test1 | * | ? | ? |
| test2 | * | ? | ? |
| test | ? | * | * |
執(zhí)行全文檢索
"query": {"match": {"search_field": "test"} }結(jié)果為 doc2,doc3
聚合操作
doc2: agg1 hello world
doc3: agg2 test hello
正排索引
5.2 doc value 核心原理
正排索引，也會(huì)寫入磁盤文件中，然后os cache先進(jìn)行緩存，以提升訪問(wèn)doc value正排索引的性能
如果os cache內(nèi)存大小不足夠放得下整個(gè)正排索引，doc value，就會(huì)將doc value的數(shù)據(jù)寫入磁盤文件中。
es官方是建議，es大量是基于os cache來(lái)進(jìn)行緩存和提升性能的，不建議用jvm內(nèi)存來(lái)進(jìn)行緩存，那樣會(huì)導(dǎo)致一定的gc開(kāi)銷和oom問(wèn)題。即給jvm更少的內(nèi)存，給os cache更大的內(nèi)存。
64g服務(wù)器，給jvm最多16g，幾十個(gè)g的內(nèi)存給os cache，os cache可以提升doc value和倒排索引的緩存和查詢效率。
?
提升 doc value 性能之 column壓縮 合并相同值
doc1: 550
doc2: 550
doc3: 500
doc1和doc2都保留一個(gè)550的標(biāo)識(shí)即可
disable doc value
如果的確不需要doc value，比如聚合等操作，那么可以禁用，減少磁盤空間占用
PUT my_index12 {"mappings": {"properties": {"my_field": {"type": "keyword","doc_values": false}}} }5.3 ?fielddata 原理
5.3.1 對(duì)分詞的field 如何聚合操作
對(duì)于分詞的field執(zhí)行aggregation（聚合操作），發(fā)現(xiàn)報(bào)錯(cuò)。。。
GET /test_index/_search {"aggs": {"group_by_test_field": {"terms": {"field": "test_field"}}} }對(duì)分詞的field，直接執(zhí)行聚合操作會(huì)報(bào)錯(cuò)，提示說(shuō)必須要打開(kāi)fielddata，然后將正排索引數(shù)據(jù)加載到內(nèi)存中，才可以對(duì)分詞的field執(zhí)行聚合操作，而且會(huì)消耗很大的內(nèi)存。
給分詞的field，設(shè)置fielddata=true
POST /test_index/_mapping {"properties": {"test_field": {"type": "text","fielddata": true}} }測(cè)試聚合操作
GET /test_index/_search {"size": 0,"aggs": {"group_by_test_field": {"terms": {"field": "test_field"}}} }如果要對(duì)分詞的field執(zhí)行聚合操作，必須將fielddata設(shè)置為true
5.3.2 使用內(nèi)置field不分詞進(jìn)行聚合
GET /test_index/_search {"size": 0,"aggs": {"group_by_test_field": {"terms": {"field": "test_field.keyword"}}} }如果對(duì)不分詞的field執(zhí)行聚合操作，直接就可以執(zhí)行，不需要設(shè)置fieldata=true
5.3.3 分詞field+fielddata的工作原理
不分詞的field，可以執(zhí)行聚合操作 ， 如果你的某個(gè)field不分詞，那么在index-time，就會(huì)自動(dòng)生成doc value ，針對(duì)這些不分詞的field執(zhí)行聚合操作的時(shí)候，自動(dòng)就會(huì)用doc value來(lái)執(zhí)行。
分詞field，是沒(méi)有doc value的。在index-time 是不會(huì)給它建立doc value正排索引的，因?yàn)榉衷~后，占用的空間過(guò)于大，所以默認(rèn)是不支持分詞field進(jìn)行聚合的。所以直接對(duì)分詞field執(zhí)行聚合操作，是會(huì)報(bào)錯(cuò)的。
如果一定要對(duì)分詞的field執(zhí)行聚合，那么必須將fielddata=true，然后es就會(huì)在執(zhí)行聚合操作的時(shí)候，現(xiàn)場(chǎng)將field對(duì)應(yīng)的數(shù)據(jù)，建立一份fielddata正排索引，fielddata正排索引的結(jié)構(gòu)跟doc value是類似的，但是只會(huì)將fielddata正排索引加載到內(nèi)存中來(lái)，然后基于內(nèi)存中的fielddata正排索引執(zhí)行分詞field的聚合操作。
5.4 fielddata 內(nèi)存控制 & circuit breajer 斷路器
fielddata加載到內(nèi)存的過(guò)程是lazy加載的，對(duì)一個(gè)analzyed field執(zhí)行聚合時(shí)，才會(huì)加載，而且是field-level加載的。它不是index-time創(chuàng)建，是query-time創(chuàng)建。
5.4.1 fielddata內(nèi)存限制
在配置文件中配置
indices.fielddata.cache.size: 20%，超出限制，清除內(nèi)存已有fielddata數(shù)據(jù)
fielddata占用的內(nèi)存超出了這個(gè)比例的限制，那么就清除掉內(nèi)存中已有的fielddata數(shù)據(jù)
默認(rèn)無(wú)限制，限制內(nèi)存使用，但是會(huì)導(dǎo)致頻繁evict和reload，大量IO性能損耗，以及內(nèi)存碎片和gc
5.4.2 監(jiān)控fielddata內(nèi)存使用
GET /_stats/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?level=indices&fields=*
5.4.3 circuit breaker
如果一次query load的feilddata超過(guò)總內(nèi)存，就會(huì)oom內(nèi)存溢出
circuit breaker會(huì)估算query要加載的fielddata大小，如果超出總內(nèi)存，就短路，query直接失敗
indices.breaker.fielddata.limit：fielddata的內(nèi)存限制，默認(rèn)60%
indices.breaker.request.limit：執(zhí)行聚合的內(nèi)存限制，默認(rèn)40%
indices.breaker.total.limit：綜合上面兩個(gè)，限制在70%以內(nèi)
5.5 原理 fielddata預(yù)加載 全局標(biāo)記
如果真的要對(duì)分詞的field執(zhí)行聚合，那么每次都在query-time現(xiàn)場(chǎng)生產(chǎn)fielddata并加載到內(nèi)存中來(lái)，速度可能會(huì)比較慢，我們是不是可以預(yù)先生成加載fielddata到內(nèi)存中來(lái)？？？
global ordinal
PUT my_index/_mapping {"properties": {"tags": {"type": "keyword","eager_global_ordinals": false}} }原理解釋
假設(shè)：
doc1: status1
doc2: status2
doc3: status2
doc4: status1
有很多重復(fù)值的情況，會(huì)進(jìn)行g(shù)lobal ordinal標(biāo)記
status1 --> 0
status2 --> 1
doc1: 0
doc2: 1
doc3: 1
doc4: 0
建立的fielddata也會(huì)是這個(gè)樣子的，這樣的好處就是減少重復(fù)字符串的出現(xiàn)的次數(shù)，減少內(nèi)存的消耗
5.6 原理 bucket 深度優(yōu)先到廣度優(yōu)先
我們的數(shù)據(jù)：
根據(jù)演員分桶： ? ? ? ? ? ? 每個(gè)演員的評(píng)論的數(shù)量
根據(jù)每個(gè)演員電影分桶： 每個(gè)演員的每個(gè)電影的評(píng)論的數(shù)量
評(píng)論數(shù)量排名前10個(gè)的演員,每個(gè)演員的電影取到評(píng)論數(shù)量排名前5的電影
{"aggs" : {"actors" : {"terms" : {"field" : "actors","size" : 10,},"aggs" : {"costars" : {"terms" : {"field" : "films","size" : 5}}}}} }默認(rèn)是 深度優(yōu)先的方式去執(zhí)行聚合操作的。它是把所有人的所有電影都查詢出來(lái)數(shù)據(jù)量很大。因此我們要考慮廣度優(yōu)先，即我們先過(guò)濾出評(píng)論前10的演員，然后再去查詢他下面的電影，這樣數(shù)據(jù)少很多。我們要使用一個(gè)參數(shù)
collect_mode=breadth_first
{"aggs" : {"actors" : {"terms" : {"field" : "actors","size" : 10,"collect_mode" : "breadth_first"},"aggs" : {"costars" : {"terms" : {"field" : "films","size" : 5}}}}} }六 數(shù)據(jù)建模實(shí)戰(zhàn)
6.1 用戶+博客數(shù)據(jù)建模 應(yīng)用層join關(guān)聯(lián)
我們?cè)跇?gòu)造數(shù)據(jù)模型的時(shí)候，還是將有關(guān)聯(lián)關(guān)系的數(shù)據(jù)，然后分割為不同的實(shí)體，類似于關(guān)系型數(shù)據(jù)庫(kù)中的模型。
6.1.1 用戶+博客建模
案例背景：博客網(wǎng)站，我們會(huì)模擬各種用戶發(fā)表各種博客，然后針對(duì)用戶和博客之間的關(guān)系進(jìn)行數(shù)據(jù)建模，同時(shí)針對(duì)建模好的數(shù)據(jù)執(zhí)行各種搜索/聚合的操作
一個(gè)用戶對(duì)應(yīng)多個(gè)博客，一對(duì)多的關(guān)系，做了建模
POST website_users/_doc/1 {"name": "小魚(yú)兒","email": "xiaoyuer@sina.com","birthday": "1980-01-01" } POST website_blogs/_doc/1 {"title": "我的第一篇博客","content": "這是我的第一篇博客，開(kāi)通啦！！！","userId": 1 }6.1.2 搜索小魚(yú)兒發(fā)表的所有博客
GET /website_users/_search {"query": {"term": {"name.keyword": {"value": "小魚(yú)兒"}}} }我們一般在java程序里查詢出 userIds 集合 然后再去查詢blog
GET /website_blogs/_search {"query": {"constant_score": {"filter": {"terms": {"userId": [1]}}}} }上面的操作，就屬于應(yīng)用層的join，在應(yīng)用層先查出一份數(shù)據(jù)，然后再查出一份數(shù)據(jù)，進(jìn)行關(guān)聯(lián)
優(yōu)點(diǎn)：數(shù)據(jù)不冗余，維護(hù)方便
缺點(diǎn)：應(yīng)用層join，如果關(guān)聯(lián)數(shù)據(jù)過(guò)多，導(dǎo)致查詢過(guò)大，性能很差
6.2 用戶+博客數(shù)據(jù)建模 冗余數(shù)據(jù)
用冗余數(shù)據(jù)，采用文檔數(shù)據(jù)模型，進(jìn)行數(shù)據(jù)建模，實(shí)現(xiàn)用戶和博客的關(guān)聯(lián)
6.2.1 準(zhǔn)備數(shù)據(jù)
冗余數(shù)據(jù)，就是說(shuō)，將可能會(huì)進(jìn)行搜索的條件和要搜索的數(shù)據(jù)，放在一個(gè)doc中
POST /website_users/_doc/1 {"name": "小魚(yú)兒","email": "xiaoyuer@sina.com","birthday": "1980-01-01" } POST /website_blogs/_doc/1 {"title": "小魚(yú)兒的第一篇博客","content": "大家好，我是小魚(yú)兒。。。","userInfo": {"userId": 1,"username": "小魚(yú)兒"} }6.2.2 冗余用戶數(shù)據(jù)搜索博客
不需要走應(yīng)用層的join，先搜一個(gè)數(shù)據(jù)，找到id，再去搜另一份數(shù)據(jù)
GET /website_blogs/_search {"query": {"term": {"userInfo.username.keyword": {"value": "小魚(yú)兒"}}} }優(yōu)點(diǎn)：性能高，不需要執(zhí)行兩次搜索
缺點(diǎn)：數(shù)據(jù)冗余，維護(hù)成本高 --> 每次如果你的username變化了，同時(shí)要更新user type和blog type
一般來(lái)說(shuō)，對(duì)于es這種NoSQL類型的數(shù)據(jù)存儲(chǔ)來(lái)講，都是冗余模式....
6.3 nested object 博客+評(píng)論嵌套
冗余數(shù)據(jù)方式的來(lái)建模，其實(shí)用的就是object類型，我們這里又要引入一種新的object類型，nested object類型
博客，評(píng)論，做的這種數(shù)據(jù)模型
6.3.1 準(zhǔn)備數(shù)據(jù)
POST website_blogs/_doc/6 {"title": "花無(wú)缺發(fā)表的一篇帖子","content": "我是花無(wú)缺，大家要不要考慮一下投資房產(chǎn)和買股票的事情啊。。。","tags": ["投資","理財(cái)"],"comments": [{"name": "小魚(yú)兒","comment": "什么股票啊？推薦一下唄","age": 28,"stars": 4,"date": "2016-09-01"},{"name": "黃藥師","comment": "我喜歡投資房產(chǎn)，風(fēng)，險(xiǎn)大收益也大","age": 31,"stars": 5,"date": "2016-10-22"}] }年齡是28歲的黃藥師評(píng)論過(guò)的博客，搜索
GET website_blogs/_search {"query": {"bool": {"must": [{"match": {"comments.name": "黃藥師"}},{"match": {"comments.age": 28}}]}} }結(jié)果顯然是不對(duì)的，應(yīng)該不能查詢到數(shù)據(jù)才對(duì)。
分析 object類型數(shù)據(jù)結(jié)構(gòu)的底層存儲(chǔ)
{"title": [ "花無(wú)缺", "發(fā)表", "一篇", "帖子" ],"content": [ "我", "是", "花無(wú)缺", "大家", "要不要", "考慮", "一下", "投資", "房產(chǎn)", "買", "股票", "事情" ],"tags": [ "投資", "理財(cái)" ],"comments.name": [ "小魚(yú)兒", "黃藥師" ],"comments.comment": [ "什么", "股票", "推薦", "我", "喜歡", "投資", "房產(chǎn)", "風(fēng)險(xiǎn)", "收益", "大" ],"comments.age": [ 28, 31 ],"comments.stars": [ 4, 5 ],"comments.date": [ 2016-09-01, 2016-10-22 ] }object類型底層數(shù)據(jù)結(jié)構(gòu)，會(huì)將一個(gè)json數(shù)組中的數(shù)據(jù)，進(jìn)行扁平化
所以，直接命中了這個(gè)document，name=黃藥師，age=28，正好符合
6.3.2 nested object 按對(duì)象拆分扁平化數(shù)據(jù)
修改mapping，將comments的類型從object設(shè)置為nested
DELETE website_blogs PUT /website_blogs {"mappings": {"properties": {"comments": {"type": "nested","properties": {"name": {"type": "text"},"comment": {"type": "text"},"age": {"type": "short"},"stars": {"type": "short"},"date": {"type": "date"}}}}} }插入數(shù)據(jù)
POST website_blogs/_doc/6 {"title": "花無(wú)缺發(fā)表的一篇帖子","content": "我是花無(wú)缺，大家要不要考慮一下投資房產(chǎn)和買股票的事情啊。。。","tags": ["投資","理財(cái)"],"comments": [{"name": "小魚(yú)兒","comment": "什么股票啊？推薦一下唄","age": 28,"stars": 4,"date": "2016-09-01"},{"name": "黃藥師","comment": "我喜歡投資房產(chǎn)，風(fēng)，險(xiǎn)大收益也大","age": 31,"stars": 5,"date": "2016-10-22"}] }他的數(shù)據(jù)結(jié)構(gòu)，就不是那么扁平化了
{"comments.name": [ "小魚(yú)兒" ],"comments.comment": [ "什么", "股票", "推薦" ],"comments.age": [ 28 ],"comments.stars": [ 4 ],"comments.date": [ 2014-09-01 ] } {"comments.name": [ "黃藥師" ],"comments.comment": [ "我", "喜歡", "投資", "房產(chǎn)", "風(fēng)險(xiǎn)", "收益", "大" ],"comments.age": [ 31 ],"comments.stars": [ 5 ],"comments.date": [ 2014-10-22 ] } {"title": [ "花無(wú)缺", "發(fā)表", "一篇", "帖子" ],"body": [ "我", "是", "花無(wú)缺", "大家", "要不要", "考慮", "一下", "投資", "房產(chǎn)", "買", "股票", "事情" ],"tags": [ "投資", "理財(cái)" ] }再次搜索，成功了
GET website_blogs/_search {"query": {"bool": {"must": [{"match": {"title": "花無(wú)缺"}},{"nested": {"path": "comments","query": {"bool": {"must": [{"match": {"comments.name": "黃藥師"}},{"match": {"comments.age": 31}}]}}}}]}} }6.3.3 nested object的聚合分析
聚合數(shù)據(jù)分析的需求1：按照評(píng)論日期進(jìn)行bucket劃分，然后拿到每個(gè)月的評(píng)論的評(píng)分的平均值
GET website_blogs/_search {"size": 0,"aggs": {"comments_path": {"nested": {"path": "comments"},"aggs": {"group_by_comments_date": {"date_histogram": {"field": "comments.date","calendar_interval": "month","format": "yyyy-MM"},"aggs": {"avg_stars": {"avg": {"field": "comments.stars"}}}}}}} }根據(jù)年齡和tag 劃分
GET website_blogs/_search {"size": 0,"aggs": {"comments_path": {"nested": {"path": "comments"},"aggs": {"group_by_comments_age": {"histogram": {"field": "comments.age","interval": 10},"aggs": {"reverse_path": {"reverse_nested": {},"aggs": {"group_by_tags": {"terms": {"field": "tags.keyword"}}}}}}}}} }6.4 ?parent child join
nested object的建模，有個(gè)不好的地方，就是采取的是類似冗余數(shù)據(jù)的方式，將多個(gè)數(shù)據(jù)都放在一起了，維護(hù)成本就比較高
parent child建模方式，采取的是類似于關(guān)系型數(shù)據(jù)庫(kù)的三范式類的建模，多個(gè)實(shí)體都分割開(kāi)來(lái)，每個(gè)實(shí)體之間都通過(guò)一些關(guān)聯(lián)方式，進(jìn)行了父子關(guān)系的關(guān)聯(lián)，各種數(shù)據(jù)不需要都放在一起，父doc和子doc分別在進(jìn)行更新的時(shí)候，都不會(huì)影響對(duì)方。
一對(duì)多關(guān)系的建模，維護(hù)起來(lái)比較方便，而且我們之前說(shuō)過(guò)，類似關(guān)系型數(shù)據(jù)庫(kù)的建模方式，應(yīng)用層join的方式，會(huì)導(dǎo)致性能比較差，因?yàn)樽龆啻嗡阉鳌８缸雨P(guān)系的數(shù)據(jù)模型，不會(huì)，性能很好。因?yàn)殡m然數(shù)據(jù)實(shí)體之間分割開(kāi)來(lái)，但是我們?cè)谒阉鞯臅r(shí)候，由es自動(dòng)為我們處理底層的關(guān)聯(lián)關(guān)系，并且通過(guò)一些手段保證搜索性能。
父子關(guān)系數(shù)據(jù)模型，相對(duì)于nested數(shù)據(jù)模型來(lái)說(shuō)，優(yōu)點(diǎn)是父doc和子doc互相之間不會(huì)影響
要點(diǎn)：父子關(guān)系元數(shù)據(jù)映射，用于確保查詢時(shí)候的高性能，但是有一個(gè)限制，就是父子數(shù)據(jù)必須存在于一個(gè)shard中
父子關(guān)系數(shù)據(jù)存在一個(gè)shard中，而且還有映射其關(guān)聯(lián)關(guān)系的元數(shù)據(jù)，那么搜索父子關(guān)系數(shù)據(jù)的時(shí)候，不用跨分片，一個(gè)分片本地自己就搞定了，性能當(dāng)然高咯
案例背景：研發(fā)中心員工管理案例，一個(gè)IT公司有多個(gè)研發(fā)中心，每個(gè)研發(fā)中心有多個(gè)員工
6.5 ?類似文件系統(tǒng)多層級(jí)關(guān)系數(shù)據(jù)建模
path_hierarchy tokenizer 也就是：/a/b/c/d --> path_hierarchy -> /a/b/c/d, /a/b/c, /a/b, /a
6.5.1 準(zhǔn)備數(shù)據(jù)
創(chuàng)建分詞器
PUT /fs {"settings": {"analysis": {"analyzer": {"paths": {"tokenizer": "path_hierarchy"}}}} }設(shè)置mapping
PUT /fs/_mapping {"properties": {"name": {"type": "keyword"},"path": {"type": "keyword","fields": {"tree": {"type": "text","analyzer": "paths"}}}} }插入數(shù)據(jù)
POST /fs/_doc/1 {"name": "README.txt","path": "/workspace/projects/helloworld","contents": "這是我的第一個(gè)elasticsearch程序" }6.5.2 對(duì)文件系統(tǒng)執(zhí)行搜索
文件搜索需求：查找一份，內(nèi)容包括elasticsearch，在/workspace/projects/hellworld這個(gè)目錄下的文件
GET /fs/_search {"query": {"bool": {"must": [{"match": {"contents": "elasticsearch"}},{"constant_score": {"filter": {"term": {"path": "/workspace/projects/helloworld"}}}}]}} }搜索需求2：搜索/workspace目錄下，內(nèi)容包含elasticsearch的所有的文件
GET /fs/_search {"query": {"bool": {"must": [{"match": {"contents": "elasticsearch"}},{"constant_score": {"filter": {"term": {"path.tree": "/workspace"}}}}]}} }6.6 全局鎖+悲觀鎖 并發(fā)控制
第一種鎖：全局鎖，直接鎖掉整個(gè)fs index,此時(shí)就只有你能執(zhí)行各種各樣的操作了，其他人不能執(zhí)行操作
PUT /fs/_doc/global/_create {}fs: 你要上鎖的那個(gè)index
lock: 就是你指定的一個(gè)對(duì)這個(gè)index上全局鎖的一個(gè)type
global: 就是你上的全局鎖對(duì)應(yīng)的這個(gè)doc的id
_create：強(qiáng)制必須是創(chuàng)建，如果/fs/lock/global這個(gè)doc已經(jīng)存在，那么創(chuàng)建失敗，報(bào)錯(cuò)
POST fs/_update/1 {"doc": {"name": "README1.txt"} }刪除鎖? ?DELETE /fs/_doc/global
優(yōu)點(diǎn)：操作非常簡(jiǎn)單，非常容易使用，成本低
缺點(diǎn)：你直接就把整個(gè)index給上鎖了，這個(gè)時(shí)候?qū)ndex中所有的doc的操作，都會(huì)被block住，導(dǎo)致整個(gè)系統(tǒng)的并發(fā)能力很低
6.7 ?document+ 悲觀鎖
document鎖，顧名思義，每次就鎖你要操作的，你要執(zhí)行增刪改的那些doc，doc鎖了，其他線程就不能對(duì)這些doc執(zhí)行增刪改操作了，但是你只是鎖了部分doc，其他線程對(duì)其他的doc還是可以上鎖和執(zhí)行增刪改操作的。
document鎖，是用腳本進(jìn)行上鎖
POST _scripts/document-lock {"script": {"lang": "painless","source": "if ( ctx._source.process_id != params.process_id ) { Debug.explain('already locked by other thread'); } ctx.op = 'noop';"} }POST /fs/_update/1 {"upsert": {"process_id": "123"},"script": {"id": "document-lock","params": {"process_id": "123"}} }DELETE /fs/_doc/1PUT /fs/_doc/_bulk { "delete": { "_id": 1}}update+upsert操作，如果該記錄沒(méi)加鎖（此時(shí)document為空），執(zhí)行upsert操作，設(shè)置process_id，如果已加鎖，執(zhí)行script
script內(nèi)的邏輯是：判斷傳入?yún)?shù)與當(dāng)前doc的process_id，如果不相等，說(shuō)明有別的線程嘗試對(duì)有鎖的doc進(jìn)行加鎖操作，Debug.explain表示拋出一個(gè)異常。
process_id可以由Java應(yīng)用系統(tǒng)里生成，如UUID。
如果兩個(gè)process_id相同，說(shuō)明當(dāng)前執(zhí)行的線程與加鎖的線程是同一個(gè)，ctx.op = 'noop'表示什么都不做，返回成功的響應(yīng)，Java客戶端拿到成功響應(yīng)的報(bào)文，就可以繼續(xù)下一步的操作，一般這里的下一步就是執(zhí)行事務(wù)方法。
POST /fs/_update/1 {"doc": {"name": "README1.txt"} }6.8 共享鎖&排它鎖 并發(fā)控制
共享鎖：這份數(shù)據(jù)是共享的，然后多個(gè)線程過(guò)來(lái)，都可以獲取同一個(gè)數(shù)據(jù)的共享鎖，然后對(duì)這個(gè)數(shù)據(jù)執(zhí)行讀操作
排他鎖：是排他的操作，只能一個(gè)線程獲取排他鎖，然后執(zhí)行增刪改操作
如果只是要讀取數(shù)據(jù)的話，那么任意個(gè)線程都可以同時(shí)進(jìn)來(lái)然后讀取數(shù)據(jù)，每個(gè)線程都可以上一個(gè)共享鎖
但是這個(gè)時(shí)候，如果有線程要過(guò)來(lái)修改數(shù)據(jù)，那么會(huì)嘗試加上排他鎖，排他鎖會(huì)跟共享鎖互斥，也就是說(shuō)，如果有人已經(jīng)上了共享鎖了，那么排他鎖就不能上。即 如果有人在讀數(shù)據(jù)，就不允許別人來(lái)修改數(shù)據(jù)。反之，也是一樣的。
6.8.1 共享鎖
POST _scripts/shared-lock {"script": {"lang": "painless","source": "if (ctx._source.lock_type == 'exclusive') { Debug.explain('already locked'); } ctx._source.lock_count++"} }POST /fs/_update/1 {"upsert": {"lock_type": "shared","lock_count": 1},"script": {"id": "shared-lock"} }GET /fs/_doc/1上共享鎖，你還是要上共享鎖，直接上就行了，沒(méi)問(wèn)題，只是lock_count加1。
6.8.2 排他鎖
排他鎖用的不是upsert語(yǔ)法，create語(yǔ)法，要求lock必須不能存在，直接自己是第一個(gè)上鎖的人，上的是排他鎖
PUT /fs/_create/1 { "lock_type": "exclusive" }如果已經(jīng)有人上了共享鎖，create語(yǔ)法去上排他鎖，肯定會(huì)報(bào)錯(cuò)
6.9.3 對(duì)共享鎖進(jìn)行解鎖
POST _scripts/unlock-shared {"script": {"lang": "painless","source": "if (--ctx._source.lock_count == 0) {ctx.op='delete'}" } }POST /fs/_update/1 {"script": {"id": "unlock-shared"} }每次解鎖一個(gè)共享鎖，就對(duì)lock_count先減1，如果減了1之后，是0，那么說(shuō)明所有的共享鎖都解鎖完了，此時(shí)就就將/fs/_doc/1刪除，就徹底解鎖所有的共享鎖
總結(jié)
以上是生活随笔為你收集整理的Elasticsearch 7.7.0 高阶篇-聚合技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 太原计算机短期培训,计算机短期培训课计划
- 下一篇： python操作excel并封装成exe