前言

Elasticsearch（ES）是近年來炙手可熱的開源分散式搜尋分析引擎，通過簡單部署，它可以輕鬆實現日誌實時分析、全文檢索、結構化資料分析等多重訴求，並將挖掘資料價值的成本大幅降低。

一、ES的應用場景1.騰訊內部應用場景

在騰訊內部，ES的應用場景主要有“日誌實時分析、搜尋服務、時序資料分析等

1.1【日誌實時分析場景】

典型場景如下：

運營日誌：如慢日誌、異常日誌（用來定位業務問題）；

審計日誌：可用於安全分析。

ES 完美解決了日誌實時分析的需求，它具有如下特點：

Elastic生態完整：任何一個開發者，可通過簡單部署成熟的元件，搭建起一個完整的日誌實時分析系統。

時效性極高：日誌從產生到可訪問的耗時一般在10S級。相比於傳統大資料解決方案几十分鐘~幾小時的耗時，時效性提高了數百倍。

靈活的搜尋分析能力：由於支援倒排索引、列儲存等資料結構，ES擁有非常靈活的搜尋分析能力。

搜尋響應時間短：ES支援互動式分析，即使有萬億級的日誌，其搜尋響應時間也是秒級。

ES在這幾年的蓬勃發展，離不開它完美地支援“日誌實時分析場景”這一能力。

1.2【搜尋服務場景】

典型場景如下：

商品搜尋：即各大電商平臺中的商品搜尋；

APP 搜尋：即應用商店裡的應用搜索；

站內搜尋：即論壇、線上文件等搜尋功能。

騰訊使用ES支援了大量的搜尋服務，它們主要有以下特點：

高效能：單個服務最大達到 10w+ QPS，平均響應時長約20ms，P95延時小於100ms。

強相關：搜尋體驗主要取決於“搜尋結果”與“使用者意圖”之間的匹配度，可通過正確率、召回率等指標進行評估。

高可用：搜尋場景通常要求4個9的可用性，並支援單機房故障容災。

1.3【時序資料分析場景】

典型的時序資料包含：

Metrics：即傳統的伺服器監控。

APM：應用效能監控。

感測器資料：由物聯網資料，智慧硬體、工業物聯網等產生。

騰訊很早就涉足了這類場景，並積累了深厚的經驗。這類場景具有以下特點：

高併發寫入：線上單叢集最大規模高達 600+節點，寫入吞吐量為1000w/s 。

高查詢效能：要求單條曲線或者單個時間線的查詢延時在10ms級。

多維分析：要求靈活、多維度的統計分析能力，如在檢視監控時，可以按照地域、業務模組等不同維度進行統計分析。

2.業界應用場景

在業界，ES的主要應用場景更多見於電子商務平臺上，比如對商品、標籤、店鋪的搜尋。

年GMV達到200億的電子商務網站M就是一個典型的例子，它在ES的應用場景也非常廣泛，包括商品搜尋推薦、日誌分析監控、統計分析等。其業務團隊執行著幾十個ES叢集，並且規模不斷在增長。

二、遇到的挑戰1.騰訊遇到的挑戰

在騰訊內部如此大規模、高壓力、多場景的業務背景下，ES的應用著實遭到了不少挑戰，這些挑戰基本可以劃分為兩類：搜尋類和時序類。

1.1【搜尋類】

高可用：以電商搜尋、APP 搜尋、站內搜尋為例，它們重視可用性，服務SLA為4個9以上，需要考慮單機故障、單機房網路故障等災備場景。

高效能：它們對效能有極高的標準，如 20w QPS、平響 20ms、P95延時100ms。

總之，在搜尋類業務場景下，核心挑戰點在於高可用、高效能。

2.【時序類】

時序類場景包含日誌、Metrics、APM 等。相比於搜尋類業務聚焦高可用、高效能的問題，時序類業務會更注重成本、效能。

舉個例子，時序場景使用者通常要求高寫入吞吐，部分場景可達 1000w/s；在這樣寫入吞吐下，保留30天的資料，儲存量可達PB級。如果使用者用於線上實際業務的機器數量是 100 臺，而監控、日誌等需要 50 臺，這對多數使用者來說基本是不可接受的（因為監控、日誌的收益相對較低）。所以在時序類業務中，主要的挑戰在於儲存成本、計算成本等方面。

面對如此艱鉅的挑戰，騰訊在ES核心方面進行了深入的優化實踐（這種優化後的成果也通過騰訊雲開放給了外界的使用者，其中就有電子商務網站M）。

2.業界遇到的挑戰

業界也經歷著與騰訊類似的挑戰。還是以電子商務網站M為例，電商經常性的大促，他們不得不關注ES叢集的穩定性和叢集的容災備份。

在叢集穩定性方面，他們經常碰到的問題是“範圍較大的查詢，會導致ES節點的JVM OOM（記憶體溢位），影響叢集穩定性”，以及“索引數或分片數過多時，叢集元陣列變更慢且CPU負載高，從而影響叢集穩定性”。

在容災備份方面，他們經常碰到的問題是“單機房故障時，如何保證服務不中斷”，以及“故障發生後，資料如何恢復”。

三、ES 優化實踐

首先，針對“高可用”的需求，騰訊的開發者們化整為零，各個突破，把高可用劃分為三個維度：

1系統健壯性：指 ES 核心自身的健壯性，這也是分散式系統面臨的共性難題。例如：

在異常查詢、壓力過載下叢集的容錯能力；

在高壓力場景下，叢集的可擴充套件性；

在叢集擴容、節點異常場景下，節點、多硬碟之間的資料均衡能力。

2.容災方案：如通過建設管控系統，保障機房網路故障時快速恢復服務、自然災害下防止資料丟失、誤操作後快速回滾等。

3.系統缺陷：這是任何系統在發展的過程中都不可避免的問題，比如Master 節點堵塞、分散式死鎖、滾動重啟緩慢等。

針對上述問題，騰訊的ES解決方案如下：

1. 系統健壯性：

服務不穩定：通過服務限流，容忍機器網路故障、異常查詢等異常情況。

叢集擴充套件性問題：通過優化叢集元資料管控邏輯，提升了10倍的叢集擴充套件能力，支援千級節點叢集、百萬分片；

叢集均衡問題：通過優化節點、多硬碟間的分片均衡，保證大規模叢集的壓力均衡。

2. 容災方案：

資料可恢復：

通過擴充套件 ES 的外掛機制支援備份回檔，把 ES 的資料備份回檔到廉價儲存，保證資料的可恢復；

故障容忍：

騰訊雲ES支援跨可用區容災，使用者可以按需部署多個可用區，以容忍單機房故障。

此外，騰訊雲ES還支援COS備份的功能，使用者可以通過操作ES的api，直接備份底層的資料檔案到騰訊雲物件儲存COS上，實現了低成本、操作簡便的資料備份功能。

異常恢復：

通過垃圾桶機制，保證使用者在欠費、誤操作等場景下，叢集可快速恢復。

3. 系統缺陷：

騰訊修復了原生ES在滾動重啟、Master 阻塞、分散式死鎖等方面的Bug。其中滾動重啟優化，可加速節點重啟速度5倍以上；Master 堵塞問題，騰訊在ES6.x版本和Elastic官方一起做了優化。

在服務限流部分，騰訊做了 4 個層級的限流工作：

許可權層級：優化後，ES支援 XPack 和自研許可權來防止攻擊和誤操作；

佇列層級：通過優化任務執行速度、重複、優先順序等細節，解決使用者經常遇到的Master 任務佇列堆積、任務餓死等問題；

記憶體層級：從ES 6.x 開始，支援在全鏈路上（ 包括HTTP 入口、協調節點、資料節點等）進行記憶體限流：同時使用 JVM 記憶體、梯度統計等方式進行精準控制；

多租戶層級：使用 CVM/Cgroups 方案保證多租戶間的資源隔離。

這裡展開介紹下聚合場景限流的問題，使用者在使用 ES 進行聚合分析時，經常因聚合分桶過多打爆記憶體。官方在 ES 6.8 中提供 max_buckets 引數控制聚合的最大分桶數，但這個方式侷限性非常強：記憶體是否會被打爆還取決於單分桶的大小（在某些場景下，使用者設定 20 萬個分桶可以正常工作，但在另一些場景下，可能 10 萬個分桶記憶體就已經打爆），因此使用者並不能準確把握該引數應設定為多少。此時騰訊採用梯度演算法進行優化，每分配 1000 個分桶檢查一次 JVM 記憶體，當記憶體不足時及時中斷請求，保證了ES叢集的高可用。

這些限流方案，能夠解決在異常查詢、壓力過載、單節點故障、網路分割槽等場景下，ES 服務的穩定性問題。但還有少量場景沒有觸達，因此騰訊目前正在探索，通過依賴混沌測試覆蓋更多異常場景。

針對“索引數或分片數過多，導致的叢集元資料變更慢且CPU負載高，從而影響叢集穩定性”的問題，在核心上，騰訊優化了shard分配的演算法，利用快取節點routing表和元資料增量更新的方法，加快叢集元資料的變更速度。

解決了高可用和高效能的問題，下面該談談成本優化方面的實踐了。

成本方面的挑戰，主要體現在時序場景（如日誌、監控）對機器資源的消耗，通過對線上典型的日誌、時序業務分析可得，硬碟、記憶體、計算資源的成本比例接近 8:4:1。也就是說，硬碟、記憶體是主要矛盾，其次是計算成本。

時序資料有很明顯的訪問特性：”近多遠少”。最近七天資料的訪問量佔比大於95%；歷史資料訪問較少，且通常都是訪問統計類資訊。

基於這些瓶頸分析和資料訪問特性，成本優化的解決方案如下：

（1）採用冷熱分離架構，使用混合儲存的方案來平衡成本、效能；

（2）既然對歷史資料通常都是訪問統計資訊，那麼通過預計算來換取儲存和效能；

（3）如果歷史資料完全不使用，可以備份到更廉價的儲存系統；

（4）基於時序資料的訪問特性，記憶體成本方面可以利用 Cache 進行優化。

（5）其他一些優化方式：如儲存裁剪、生命週期管理等。

這裡展開介紹下 Rollup 部分。Rollup 類似於大資料場景下的Cube、物化檢視，它的核心思想是通過預計算提前生成統計資訊，釋放原始粒度資料，從而降低儲存成本、提高查詢效能。這裡舉個簡單的例子：在機器監控場景下，原始粒度的監控資料是10 秒級的，而一個月之前的監控資料，一般只需檢視小時粒度，這即是一個 Rollup 應用場景。官方從 ES 6.x 開始推出 Rollup，實際上騰訊在 5.x 已經著手研究。

在大資料領域，傳統的方案是依賴外部離線計算系統，週期性地讀取全量資料進行計算，這種方式計算開銷、維護成本高。

谷歌的廣告指標系統 Mesa 採用持續生成方案，資料寫入時系統給每個 Rollup 產生一份輸入資料，並對資料進行排序，底層在 Compact/Merge 過程中通過多路歸併完成 Rollup，這種方式的計算、維護成本相對較低。

ES 從 6.x 開始支援資料排序，騰訊通過流式查詢進行多路歸併生成 Rollup，最終計算開銷小於全量資料寫入時 CPU 開銷的 10%，記憶體使用小於10MB。這種核心優化方式已被騰訊貢獻給開源社群，以解決開源 Rollup 的計算、記憶體瓶頸。

前文提及很多使用者在使用大儲存機型時，記憶體優先成為瓶頸、硬碟不能充分利用，這類問題主要瓶頸在於索引佔用大量記憶體。考慮到時序類場景很少訪問歷史資料，部分場景下某些欄位基本不使用，所騰訊通過引入 Cache 來提高記憶體利用效率。

在記憶體優化方面，業界有怎樣的方案？

ES 社群從7.x後支援索引放於堆外，和 DocValue 一樣按需載入。這種方式的缺點在於索引和資料的重要性完全不同，一個大查詢容易導致索引被淘汰，後續查詢效能倍數級的衰減。

Hbase 通過Cache 快取索引、資料塊，提升熱資料訪問效能，並從 HBase 2.0 開始，重點介紹其 Off Heap 技術，讓堆外和堆內的記憶體訪問效能接近。基於社群經驗進行迭代，騰訊在ES中引入LFU Cache以提高記憶體利用效率，把 Cache 放置在堆外以降低堆記憶體壓力，同時通過Weak Reference堆內外拷貝等技術降低損耗。通過這種方法，記憶體利用率提升80%，查詢效能損耗不超過 2%，GC 開銷降低 30%。

說到效能方面的優化實踐，以日誌、監控為代表的時序場景為例，它們對寫入效能要求極高，寫入併發高達1000w/s。然而在帶主鍵寫入時，ES 效能衰減 1+倍，部分壓測場景下，CPU 無法充分利用。以搜尋服務為代表的場景對查詢效能的要求非常高，往往要求20w QPS, 平響 20ms，且需避免 GC、執行計劃不優等原因造成的查詢毛刺。

針對上述問題，騰訊亦有對策：

（1）寫入優化：針對主鍵去重場景，利用索引進行裁剪，加速主鍵去重的過程，使寫入效能提升 45%。此外，通過向量化執行優化寫入效能，通過減少分支跳轉、指令 Miss，也是騰訊探索中的方向之一，預計效能可提升1倍。

（2）CPU利用率優化：針對部分壓測場景下 CPU 不能充分利用的問題，通過優化 ES 重新整理 Translog 時的資源搶佔，使效能提升 20%。

（3）查詢優化：通過優化 Merge 策略提升查詢效能。基於每個 Segment 記錄的 min/max 索引進行查詢剪枝，提升了30%的查詢效能 。通過CBO策略，避免查詢 Cache 操作導致查詢耗時10+倍的毛刺。此外，通過一些新硬體（如英特爾的 AEP、Optane、QAT 等）來優化效能也是不錯的探索方向。

下面，詳細談談Merge 策略優化部分：ES 原生的 Merge 策略主要關注大小相似性（Merge 時儘量選擇大小相似的 Segments）和最大上限（考慮儘量把 Segment 拼湊到 5GB）。那麼有可能出現：某個Segment中包含了1月整月、3月1日的資料，當用戶查詢3月1日某小時的資料時，就必須掃描大量無用資料，致使效能損耗嚴重。

針對上述問題，騰訊在ES中引入了時序Merge：在選擇 Segments 進行 Merge 時，重點考慮時間因素，讓時間相近的 Segments 被Merge 到一起。當用戶查詢3月1日的資料時，只需要掃描個別較小的 Segments ，其它的 Segments 可以被快速裁剪。

另外，ES官方推薦搜尋類使用者在寫入完成之後，進行一次 Force Merge：其用意是把所有 Segments 合併為一個，以提高搜尋效能。但這增加了使用者的使用成本，且在時序場景下需要掃描全部資料，不利於裁剪。

由此，騰訊在 ES 中引入了冷資料自動 Merge：對於非活躍的索引，底層 Segments 會自動 Merge 到接近 5GB，降低檔案數量的同時，方便時序場景裁剪。對於搜尋場景，使用者可以調整目標 Segment 的大小，使所有 Segments 最終 Merge 為一個。這種Merge 策略的優化，可使搜尋場景效能提升 1 倍。

在接入騰訊雲ES後，電子商務網站M的ES基礎能力和開發運維效率都得到了顯著的提升：

可靠性：基於騰訊對ES核心優化後的能力，電子商務網站M的ES叢集可靠性有著明顯的提升，扛起了多重流量洪峰，收穫了明顯的經濟效益。

安全容災：多可用區提供了容災保障、X-Pack許可權管理提供了安全保障；

運維效率：雲上提供了高效部署和穩定的彈性伸縮能力，X-Pack提供的SQL能力提升了操作便捷性；運維效率的提高極大地解放了人力。

特別值得一提的是，整個專案在遷移過程中非常平滑穩定：

M原有ES叢集實現了完全不停服遷移；

遷移後仍保持了M自建ES時自研開發的運維繫統的對接；

遷移過程中，M對核心的特殊需求，ES社群版本並不支援，騰訊雲ES專門的核心團隊積極相應，提供了該能力。

四、未來規劃及開源貢獻

目前，國內有很多ES在“查詢範圍較大”和“索引或分片數較多”的應用場景，因此國內社群開發者也格外關注於此。在這兩個領域，騰訊雲ES的優化方案，因其全面性和程式碼整潔性，已被Elastic官方所採納。

近半年騰訊向開源社群提交了 10+PR，涉及寫入、查詢、叢集管理等各個模組（部分優化功能是與Elastic官方開發一同完成）。騰訊內部組建了Elasticsearch開源協同的小組，讓來自騰訊的所有開發者，都能參與到 Elastic 的生態建設中。

目前，騰訊聯合 Elastic 公司，已在騰訊雲上推出了核心增強版的 ES 雲服務，將萬億級搜尋的能力對外輸出。不過，ES的發展仍有非常多有價值的方向可以深入研究，這也是騰訊雲在上線產品後迭代優化產品、持續核心建設的原因。

未來，騰訊還將進行長期探索：

以大資料圖譜為思路，整個大資料領域按照資料量、延時要求等特點，可以分為三部分：

(1) DataEngineering，包含大家熟悉的批量計算、流式計算；

(2) DataDiscovery，包含互動式分析、搜尋等；

(3) DataApps，主要用於支撐線上服務。

雖然 ES 被視為搜尋領域內的技術，但是 ES 也支援線上搜尋、文件服務等場景；另外，有不少成熟的 OLAP 系統，也是基於倒排索引、行列混存等技術棧。由此可以看出， ES 往這兩個領域發展的可行性非常強。因此，騰訊會重點朝“線上服務”和“OLAP 分析”等方向探索ES技術。

看完不要忘記關注小編，後續還會持續更新干貨文章。