作者：京東保險 管順利
開篇
最近使用Elasticsearch實作畫像系統，實作的dmp的資料中臺能力，同時調研了競品的架構選型，以及重溫了redis原理等，特此做一次es的總結和回顧，網上沒看到有人用Elasticsearch來完成畫像的，我來做第一次嘗試，
背景說完，我們先思考一件事，使用記憶體系統做資料庫，他的優點是什么？他的痛點是什么？
一、原理
這里不在闡述全貌，只聊聊通訊、記憶體、持久化三部分，
通訊
es集群最小單元是三個節點，兩個從節點搭配保證其高可用也是集群化的基礎，那么節點之間RPC通訊用的是什么？必然是netty，es基于netty實作了Netty4Transport的通訊包，初始化Transport后建立Bootstrap，通過MessageChannelHandler完成接收和轉發，es里區分server和client，如圖1，序列化使用的json，es在rpc設計上偏向于易用、通用、易理解，而不是單追求性能，
圖1
有了netty的保駕護航使得es放心是使用json序列化，
記憶體
圖2
es記憶體分為兩部分【on heap】和【off heap】，on heap這部分由es的jvm管理，off heap則是由lucene管理，on heap 被分為兩部分，一部分可以回收，一部分不能回收，
能回收的部分index buffer存盤新的索引檔案，當被填滿時，緩沖區的檔案會被寫入到磁盤segment上，node上共享所有shards，
不能被回收的有node query cache、shard request cache、file data cache、segments cache
node query cache是node級快取，過濾后保存在每個node上，被所有shards共享，使用bitset資料結構（布隆優化版）關掉了評分，使用的LRU淘汰策略，GC無法回收，
shard request cache是shard級快取，每個shard都有，默認情況下該快取只存盤request結果size等于0的查詢，所以該快取不會被hits，但卻快取hits.total，aggregations，suggestions，可以通過clear cache api清除，使用的LRU淘汰策略，GC無法回收，
file data cache 是把聚合、排序后的data快取起來，初期es是沒有doc values的，所以聚合、排序后需要有一個file data來快取，避免磁盤IO，如果沒有足夠記憶體存盤file data，es會不斷地從磁盤加載資料到記憶體，并洗掉舊的資料，這些會造成磁盤IO和引發GC，所以2.x之后版本引入doc values特性，把檔案構建在indextime上，存盤到磁盤，通過memory mapped file方式訪問，甚至如果只關心hits.total，只回傳doc id，關掉doc values，doc values支持keyword和數值型別，text型別還是會創建file data，
segments cache是為了加速查詢，FST永駐堆內記憶體，FST可以理解為前綴樹，加速查詢，but！！es 7.3版本開始把FST交給了堆外記憶體，可以讓節點支持更多的資料，FST在磁盤上也有對應的持久化檔案，
off heap 即Segments Memory，堆外記憶體是給Lucene使用的， 所以建議至少留一半的記憶體給lucene，
es 7.3版本開始把tip（terms index）通過mmp方式加載，交由系統的pagecache管理，除了tip，nvd（norms），dvd（doc values）， tim（term dictionary），cfs（compound）型別的檔案都是由mmp方式加載傳輸，其余都是nio方式，tip off heap后的效果jvm占用量下降了78%左右，可以使用_cat/segments API 查看 segments.memory記憶體占用量，
由于對外記憶體是由作業系統pagecache管理記憶體的，如果發生回收時，FST的查詢會牽扯到磁盤IO上，對查詢效率影響比較大，可以參考linux pagecache的回收策略使用雙鏈策略，
持久化
es的持久化分為兩部分，一部分類似快照，把檔案快取中的segments 重繪（fsync）磁盤，另一部分是translog日志，它每秒都會追加操作日志，默認30分鐘刷到磁盤上，es持久化和redis的RDB+AOF模式很像，如下圖
圖3
上圖是一個完整寫入流程，磁盤也是分segment記錄資料，這里濡染跟redis很像，但是內部機制沒有采用COW（copy-on-write），這也是查詢和寫入并行時load被打滿的原因所在，
小結
es記憶體和磁盤的設計上非常巧妙，零拷貝上采用mmap方式，磁盤資料映射到off heap，也就是lucene，為了加速資料的訪問，es每個segment都有會一些索引資料駐留在off heap里；因此segment越多，瓜分掉的off heap也越多，這部分是無法被GC回收！
結合以上兩點可以清楚知道為什么es非常吃記憶體了，
二、應用
用戶畫像系統中有以下難點需要解決，
1.人群預估：根據標簽選出一類人群，如20-25歲的喜歡電商社交的男性，20-25歲∩電商社交∩男性，通過與或非的運算選出符合特征的clientId的個數，這是一組，
我們組與組之前也是可以在做交并差的運算，如既是20-25歲的喜歡電商社交的男性，又是北京市喜歡擼鐵的男性，（20-25歲∩電商社交∩男性）∩（20-25歲∩擼鐵∩男性），對于這樣的遞回要求在17億多的畫像庫中，秒級回傳預估人數，
2.人群包圈選：上述圈選出的人群包， 要求分鐘級構建，
3.人包判定：判斷一個clientId是否存在若干個人群包中，要求10毫秒回傳結果，
我們先嘗試用es來解決以上所有問題，
人群預估，最容易想到方案是在服務端的記憶體中做邏輯運算，但是圈選出千萬級的人群包人數秒級回傳的話在服務端做代價非常大，這時候可以吧計算壓力拋給es存盤端，像查詢資料庫一樣，使用一條陳述句查出我們想要的資料來，
例如mysql
select a.age from a where a.tel in (select b.age from b);
對應的es的dsl類似于
{"query":{"bool":{"must":[{"bool":{"must":[{"term":{"a9aa8uk0":{"value":"age18-24","boost":1.0}}},{"term":{"a9ajq480":{"value":"male","boost":1.0}}}],"adjust_pure_negative":true,"boost":1.0}},{"bool":{"adjust_pure_negative":true,"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}}}
這樣使用es的高檢索性能來滿足業務需求，無論所少組，組內多少的標簽，都打成一條dsl陳述句，來保證秒級回傳結果，
使用官方推薦的RestHighLevelClient，實作方式有三種，一種是拼json字串，第二種呼叫api去拼字串，我使用第三種方式BoolQueryBuilder來實作，比較優雅，它提供了filter、must、should和mustNot方法，如
/**
* Adds a query that <b>must not</b> appear in the matching documents.
* No {@code null} value allowed.
*/
public BoolQueryBuilder mustNot(QueryBuilder queryBuilder) {
if (queryBuilder == null) {
throw new IllegalArgumentException("inner bool query clause cannot be null");
}
mustNotClauses.add(queryBuilder);
return this;
}
/**
* Gets the queries that <b>must not</b> appear in the matching documents.
*/
public List<QueryBuilder> mustNot() {
return this.mustNotClauses;
}
使用api的可以大大的show下編代碼的能力，
構建人群包，目前我們圈出最大的包有7千多萬的clientId，想要分鐘級別構建完（7千萬資料在條件限制下35分鐘構建完）需要注意兩個地方，一個是es深度查詢，另一個是批量寫入，
es分頁有三種方式，深度分頁有兩種，后兩種都是利用游標（scroll和search_after）滾動的方式檢索，
scroll需要維護游標狀態，每一個執行緒都會創建一個32位唯一scroll id，每次查詢都要帶上唯一的scroll id，如果多個執行緒就要維護多個游標狀態，search_after與scroll方式相似，但是它的引數是無狀態的，始侄訓針對對新版本的搜索器進行決議，它的排序順序會在滾動中更改，scroll原理是將doc id結果集保留在協調節點的背景關系里，每次滾動分批獲取，只需要根據size在每個shard內部按照順序取回結果即可，
寫入時使用執行緒池來做，注意使用的阻塞佇列的大小，還要選擇適的拒絕策略（這里不需要拋例外的策略），批量如果還是寫到es中（比如做了讀寫分離）寫入時除了要多執行緒外，還有優化寫入時的refresh policy，
人包判定介面，由于整條業務鏈路非常長，這塊檢索，上游服務設定的熔斷時間是10ms，所以優化要優化es的查詢（也可以redis）畢竟沒負責邏輯處理，使用執行緒池解決IO密集型優化后可以達到1ms，tp99高峰在4ms，
三、優化、瓶頸與解決方案
以上是針對業務需求使用es的解題方式，還需要做回應的優化，同時也遇到es的瓶頸，
1.首先是mapping的優化，畫像的mapping中fields中的type是keyword，index要關掉，人包中的fields中的doc value關掉，畫像是要精確匹配；人包判定只需要結果而不需要取值，es api上人包計算使用filter去掉評分，filter內部使用bitset的布隆資料結構，但是需要對資料預熱，寫入時執行緒不易過多，和核心數相同即可；調整refresh policy等級，手動刷盤，構建時index.refresh_interval 調整-1，需要注意的是停止刷盤會加大堆記憶體，需要結合業務調整刷盤頻率，構建大的人群包可以將index拆分成若干個，分散存盤可以提高回應，目前幾十個人群包還是能支撐，如果日后成長到幾百個的時候，就需要使用bitmap來構建存盤人群包，es對檢索性能很卓越，但是如遇到寫操作和查操作并行時，就不是他擅長的，比如人群包的資料是每天都在變化的，這個時候es的記憶體和磁盤io會非常高，上百個包時我們可以用redis來存，也可以選擇使用MongoDB來存人包資料，
四、總結
以上是我們使用Elasticsearch來解決業務上的難點，同時發現他的持久化沒有使用COW（copy-on-write）方式，導致在實時寫的時候檢索性能降低，
使用記憶體系統做資料源有點非常明顯，就是檢索塊！尤其再實時場景下堪稱利器，同時痛點也很明顯，實時寫會拉低檢索性能，當然我們可以做讀寫分離，拆分index等方案，
除了Elasticsearch，我們還可以選用ClickHouse，ck也是支持bitmap資料結構，甚至可以上Pilosa，pilosa本就是BitMap Database，
參考
貝殼DMP平臺建設實踐
Mapping parameters | Elasticsearch Reference [7.10] | Elastic
Elasticsearch 7.3 的 offheap 原理
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/551815.html
標籤：其他
上一篇：CUDA 的亂數演算法 API
下一篇：返回列表