作者介紹

李猛，數據領域專家，Elastic Stack國內頂尖實戰專家，國內首批Elastic官方認證工程師21人之一。2012年入手Elasticsearch，對Elastic Stack技術棧開發、架構、運維、源碼、算法等方面有深入實戰經驗。負責過多種Elastic Stack項目，包括大數據分析領域、機器學習預測領域、業務查詢加速領域、日志分析領域、基礎指標監控領域等。十余年技術實戰從業經驗，擅長大數據多種技術棧混合，系統架構領域。

序言

圖示：Elasticsearch在DB-Engine綜合排名第8

Elasticsearch除了在查詢搜索領域非常強悍之外，在聚合統計分析領域也頗有造詣，且在業務應用場景特別受歡迎。ES提供了3大類型的聚合統計，Bucket分桶聚合（雷同MySQL分組Group）是應用最廣泛的。

圖示：分桶統計示意圖

一、案例描述

既然要探討ES聚合統計分析應用場景的造詣，當然得先從實戰優化開始，下面就從一些實戰案例展開。

1、背景描述

某ES集群采用幾十臺物理機，單物理機部署多個ES實例，單集群總實例數不過百，單物理機內存與計算資源充足；集群總數據量在數百TB，索引總數量超過數千個，單索引采用單分片設計，單分片不超過50~70GB，屬于官方建議的合理性范圍。

集群數據實時寫入，按照一定規則進行分流存儲到各個索引，此處并沒有什么問題，且性能一直表現很好。

業務場景需求，單次需要基于多個索引進行查詢過濾，單次查詢索引數量控制在10個以內，需要同時完成聚合分桶統計，且需要非常高的并發度，支持日均幾千萬次以上并發聚合統計，注意這里需要的高并發，是按照TP系統要求的，對于外部應用來說，幾乎不能感知到AP的存在。

單次查詢過濾，符合條件的明細數據也就幾十條，上限不過百，然后基于這些明細結果進行嵌套多層的分桶聚合統計。由于需要支持非常高的并發，且做到極快應用響應時間，工程師在應用中做了一些性能埋點，經過統計分析，發現一些很奇怪的疑點，約近一半的查詢聚合數據量多的執行得更快，數據條數越少反而執行得更慢，且相當不穩定，按正常理解，這顯然很不符合常識邏輯。

圖示：集群案例架構查詢示意圖

2、優化設置

經過來回多次溝通了解，基本很快確定了性能優化點，增加一個分桶屬性設置即可。

圖示：DSL模擬聚會語法，案例基于官方數據編寫

二、ES技術原理

本次案例排查與解決，涉及到一些ES內部實現的原理，常規情況下，如果不注意或者對于性能不是特別敏感，就直接忽略了，下面就借此簡單聊聊ES一些內部原理與實現。

1、global ordinals

global_ordinals，直譯“全局序號”，簡言之此特性是為了提升“高基數”聚合統計性能的。當向ES寫入"keyword”類型數據時，ES會內部生成一個內存映射表，來映射term詞項與編號關系，故而叫“全局序號”，默認情況下，ES假定term在聚合統計下是“高基數”場景，默認會開啟。初衷是好的，為了提升海量數據分桶統計性能，相反在少量數據統計聚合時，由于需要詞項與編號之間的映射關系轉換，性能反而會下降；再加上實時寫入數據，詞項的基數一直不穩定不固定，詞項與序號映射關系也需要重建更新，故而就會出現上面案例的情況，部分數據量少的統計聚合性能執行時間反而更長。

為了解決少量“基數”數據統計性能問題，設計了一種無需“全局序號”的策略，直接基于詞項分桶統計即可，設置統計屬性“execution_hint=map”，通過在上面案例中增加改屬性設置，聚合統計性能與業務需求明顯符合期望認知。

{"aggs": {"tags": {"terms": {"field": "tags",/* 啟用map統計模式*/"execution_hint": "map"}}} }

2、doc values

doc_values，中文意思“列式存儲”，ES核心實現基于“倒排索引“”構建，擅長多條件搜索檢索，但是反向過來，自定義排序非常不方便，為了解決此問題，設計了一種列式數據存儲，通常簡單的認為就是“正排索引”，與倒排剛好相反，也可以認為ES默認內部至少有兩種不同的索引結構。我們都知道，列式存儲特別擅長數據統計場景，所以在對比行式數據庫與列式數據庫時，一眼便知，哪種數據庫產品更加適合數據統計。上面案例需求中，正式借助于ES強大的列式存儲，實現了高效的聚合統計，面對日均千萬次的聚合統計，既能保持高的執行速度，也能支持高的并發數。

默認情況下，doc_values是開啟的，若不需要基于此字段聚合統計，也可以選擇關閉，順便節約一些資源消耗，同理ES提供了很多默認屬性設置，如果足夠了解，可以設置很多，優化性能的點多數源于這些細節。

{"mappings": {"properties": {"status_code": {"type": "keyword",/*默認開啟*/"doc_values": true},"session_id": {"type": "keyword",/*顯示關閉*/"doc_values": false}}} }

3、cross index search

cross index search，直譯“跨索引查詢”，Elasticsearch核心基于Lucene，相比原始Lucene實現，最大的創新改進就是加入了“Shard”分片設計。一個索引就是一個或者多個分片組成，獨立的分片實際就是一個獨立的Lucene完整數據，搜索一個索引時，實際搜索的是承載索引的分片，搜索蓋索引所有分片；同理，搜索多個索引也等同于搜索多個分片，與搜索單個索引多分片本質上一樣。上面的案例中，需要基于業務條件選擇幾個索引進行查詢統計，需要非常高的靈活性，正是利用了ES此種設計特性。

圖示：跨多個索引查詢語法示意圖，來自官方案例

同比在傳統數據庫應用場景，為了解決海量數據存儲，需要進行分庫分表，但是分庫分表之后需要進行組合查詢，就非常麻煩，多數解決方案選擇的正是ES，傳統數據庫的表轉換可以映射到ES領域的索引或者分片，查詢時，可以靈活組合，ES內部會自動進行路由。如果是異構的數據源，ES照樣也可以執行多索引或者多分片查詢。

圖示：跨多個索引查詢與多分片查詢示意圖

三、OLTP與OLAP

進入了數據時代，人人都在談大數據，人人都在進行大數據，各種數據廠家也紛紛為了展示自己的肌肉，各種性能比較碾壓的文章特別多，給很多人帶來了一些誤導，特別是一些剛剛入行的工程師，以為xx性能特別好，只要掌握了就可以獨步天下，其實不然。剛好借助上面的案例場景，來談談個人對于OLTP與OLAP的認知與觀點。

圖示：OLTP與OLAP比對，來自知乎某文章。

1、應用形態之爭

在企業項目實踐中，到底是“TP”項目需求多還是“AP”項目需求多？答案顯而易見，TP項目需求更多，而且是碾壓式的。據一些專家統計，TP與AP項目需求比例約為9:1。

如上案例描述，表面看起來是個AP統計分析項目，有海量數據存儲，有實時更新，更有實時分析統計訴求，實際上由業務部門開發落地，并不由大數據部門負責，業務部門選擇了Elasticsearch，非常輕松快捷就實現了業務目標。

如上案例描述，業務單次查詢與聚合，首先需要在單個或多個索引中基于篩選條件過濾，篩選前的數據量超過千萬級甚至億級，篩選后的數據量才幾十條，聚合統計后更少，這種數據量級根本就不需要純粹的OLAP產品來實現，或者說純粹的OLAP產品也不能滿足當下高并發查詢需求。在純粹的AP場景中，實際單次分析篩選過濾后還需要千萬級或者億級以上數據量的需求應該更少，多數都是案例所述場景。如下圖所示：

圖示：案例查詢過濾示意圖，原始數據量很大，篩選之后結果數據極小。

嚴格意義上看，企業應用中所謂的數據分析型項目，都是為了滿足業務應用需求，只是由于AP需求復雜度高，需要的技術棧復雜度提高，需要專業的技術棧來做，不能簡單的采用常規的TP技術棧實現，但本質上都是應用系統，是業務需要的應用系統。如果按照TP與AP嚴格界定，那么項目的架構方案就會不一樣，相應的技術棧選擇也不一樣，實施的復雜度與周期也就不一樣，這應該不是企業需要的。

2、技術形態之爭

經常看到各種數據產品的性能比較文章，有的是一些在線培訓機構，有的是一些產品廠家，多數都是參考價值不高的對比。純粹的技術性能比較是毫無意義的，一定要基于業務需求前提。如，clickhouse、doris等，經常出現在各種性能對比的場景中，強調各自性能強悍，等你真上了船，發現一堆坑等著，填完一個接一個，實際使用為什么不是如文所示，到底哪里錯了？

如上案例描述，集群數據量數百TB，又是查詢聚合統計需求，參考一些性能對比文章，似乎應該采用clickhosue/doris，因為它們在數億以上數據量聚合性能表現極快，但是相應的會帶來更多的問題，如實時寫入、復雜篩選條件查詢、高并發等，從數據量上來看，它應該是AP場景，應該選擇純粹的AP數據產品，但從上游對接的業務系統，它又屬于TP。

如上案例描述，業務系統需要實時寫入，業務系統需要實時查詢統計，按照大數據領域的技術流派，似乎應該采用Flink+來搞定，上游實時寫入到kafka，中間采用Flink實時聚合計算，下游寫入到某個數據產品里面供查詢。看起來相當完美，實際上非常不合時宜，首先海量數據數百TB存儲是個大問題，Flink不解決；其次業務系統數據實時寫入更新，kafka只能解決實時寫入，不能解決實時更新，Flink更不擅長數據存儲；再次，業務系統實時查詢聚合數據，依據多種篩選條件，需要基于歷史數據與實時數據，Flink做不到此類型場景；最后，聚合結果實時查詢，基于Flink的架構需要數據輸出到某些數據產品，多數會選擇Elasticsearch，因為其支持極高的寫入與查詢，若是這樣，幾乎就是宣告，數據走了一圈又回到了原點。

圖示：Flink實現的實時計算示意圖與Elasticsearch實時查詢示意圖

結語

以上從一次ES案例性能優化，談到了ES的一些技術原理，談到了業務形態與技術形態，僅代表個人觀點認知，若有異議，歡迎討論。

>>>>

參考資料

• terms-aggregation? 分桶聚合統計

  https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html

• term 性能優化提升??來自es官方性能優化提升博客

• https://www.elastic.co/cn/blog/improving-the-performance-of-high-cardinality-terms-aggregations-in-elasticsearch

dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：editor@dbaplus.cn

總結

以上是生活随笔為你收集整理的一次ES性能优化，我发现了搞大数据的真相……的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。