騰訊萬億級 Elasticsearch 技術解密

作者： johngqjiang，騰訊 TEG 雲架構平臺部研發工程師

Elasticsearch（ES）作為開源首選的分散式搜尋分析引擎，通過一套系統輕鬆滿足使用者的日誌實時分析、全文檢索、結構化資料分析等多種需求，大幅降低大資料時代挖掘資料價值的成本。騰訊在公司內部豐富的場景中大規模使用 ES，同時聯合 Elastic 公司在騰訊雲上提供核心增強版的 ES 雲服務，大規模、豐富多樣的的使用場景推動著騰訊對原生 ES 進行持續的高可用、高效能、低成本優化。今天給大家分享近期在 Elastic 中國開發者大會上的演講內容：騰訊萬億級 Elasticsearch 技術解密。

一、ES 在騰訊的應用場景

本次分享的主要內容包含：首先介紹 ES 在騰訊的豐富應用場景及各種場景的典型特點；然後給出我們在大規模、高壓力、豐富多樣的使用場景下遇到的挑戰；針對這些挑戰，我們重點介紹騰訊在 ES 核心方面進行的高可用性、低成本、高效能等優化實踐；最後簡單分享我們在 ES 未來規劃以及開源貢獻方面的思考。

我們先來看下 ES 在騰訊的應用場景。最初我們使用 ES 於日誌實時分析場景，典型日誌如下：運營日誌，比如慢日誌、異常日誌，用來定位業務問題；業務日誌，比如使用者的點選、訪問日誌，可以用來分析使用者行為；審計日誌，可以用於安全分析。ES 很完美的解決了日誌實時分析的需求，它具有如下特點：

• Elastic 生態提供了完整的日誌解決方案，任何一個開發、運維同學使用成熟元件，通過簡單部署，即可搭建起一個完整的日誌實時分析服務。

• 在 Elastic 生態中，日誌從產生到可訪問一般在 10s 級。相比於傳統大資料解決方案的幾十分鐘、小時級，時效性非常高。

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

• 支援互動式分析，即使在萬億級日誌的情況下，ES 搜尋響應時間也是秒級。

日誌是網際網路行業最基礎、最廣泛的資料形式，ES 非常完美的解決了日誌實時分析場景，這也是近幾年 ES 快速發展的一個重要原因。

第二類使用場景是搜尋服務，典型場景包含：商品搜尋，類似京東、淘寶、拼多多中的商品搜尋；APP 搜尋，支援應用商店裡的應用搜尋；站內搜尋，支援論壇、線上文件等搜尋功能。我們支援了大量搜尋服務，它們主要有以下特點：

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

• 強相關：搜尋體驗主要取決於搜尋結果是否高度匹配使用者意圖，需要通過正確率、召回率等指標進行評估。

• 高可用：搜尋場景通常要求 4 個 9 的可用性，支援單機房故障容災。任何一個電商服務，如淘寶、京東、拼多多，只要故障一個小時就可以上頭條。

第三類使用場景是時序資料分析，典型的時序資料包含：Metrics，即傳統的伺服器監控；APM，應用效能監控；物聯網資料，智慧硬體、工業物聯網等產生的感測器資料。這類場景騰訊很早就開始探索，在這方面積累了非常豐富的經驗。這類場景具有以下特點：

• 高併發寫入：線上單叢集最大規模達到 600+節點、1000w/s 的寫入吞吐。

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

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

二、遇到的挑戰

前面我們介紹了 ES 在騰訊內部的廣泛應用，在如此大規模、高壓力、豐富使用場景的背景下，我們遇到了很多挑戰，總體可以劃分為兩類：搜尋類和時序類。

首先，我們一起看看搜尋類業務的挑戰。以電商搜尋、APP 搜尋、站內搜尋為代表，這類業務非常重視可用性，服務 SLA 達到 4 個 9 以上，需要容忍單機故障、單機房網路故障等；同時要求高效能、低毛刺，例如 20w QPS、平響 20ms、P95 延時 100ms。總之，在搜尋類業務場景下，核心挑戰點在於高可用、高效能。

另一類我們稱之為時序類業務挑戰，包含日誌、Metrics、APM 等場景。相比於搜尋類業務重點關注高可用、高效能，時序類業務會更注重成本、效能。比如時序場景使用者通常要求高寫入吞吐，部分場景可達 1000w/sWPS；在這樣寫入吞吐下，保留 30 天的資料，通常可達到 PB 級的儲存量。而現實是日誌、監控等場景的收益相對較低，很可能使用者用於線上實際業務的機器數量才是 100 臺，而監控、日誌等需要 50 臺，這對多數使用者來說，基本是不可接受的。所以在時序類業務中，主要的挑戰在於儲存成本、計算成本等方面。

前面我們介紹了在搜尋類、時序類業務場景下遇到的高可用、低成本、高效能等挑戰，下面針對這些挑戰，我們重點分享騰訊在 ES 核心方面的深入實踐。

三、ES 優化實踐

首先，我們來看看高可用優化，我們把高可用劃分為三個維度：

• 系統健壯性：是指 ES 核心自身的健壯性，也是分散式系統面臨的共性難題。例如，在異常查詢、壓力過載下叢集的容錯能力；在高壓力場景下，叢集的可擴充套件性；在叢集擴容、節點異常場景下，節點、多硬碟之間的資料均衡能力。

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

• 系統缺陷：這在任何系統發展過程中都會持續產生，比如說 Master 節點堵塞、分散式死鎖、滾動重啟緩慢等。

針對上述問題，下面來介紹我們在高可用方面的解決方案：

系統健壯性方面，我們通過服務限流，容忍機器網路故障、異常查詢等導致的服務不穩定，後面展開介紹。通過優化叢集後設資料管控邏輯，提升叢集擴充套件能力一個數量級，支援千級節點叢集、百萬分片，解決叢集可擴充套件性問題；叢集均衡方面，通過優化節點、多硬碟間的分片均衡，保證大規模叢集的壓力均衡。

容災方案方面，我們通過擴充套件 ES 的外掛機制支援備份回檔，把 ES 的資料備份回檔到廉價儲存，保證資料的可恢復；支援跨可用區容災，使用者可以按需部署多個可用區，以容忍單機房故障。垃圾桶機制，保證使用者在欠費、誤操作等場景下，叢集可快速恢復。

系統缺陷方面，我們修復了滾動重啟、Master 阻塞、分散式死鎖等一系列 Bug。其中滾動重啟優化，可加速節點重啟速度 5+倍，具體可參考 PR ES-46520；Master 堵塞問題，我們在 ES 6.x 版本和官方一起做了優化。

這裡我們展開介紹下服務限流部分。我們做了 4 個層級的限流工作：許可權層級，我們支援 XPack 和自研許可權來防止攻擊、誤操作；佇列層級，通過優化任務執行速度、重複、優先順序等問題，解決使用者常遇到的 Master 任務佇列堆積、任務餓死等問題；記憶體層級，我們從 ES 6.x 開始，支援在 HTTP 入口、協調節點、資料節點等全鏈路上進行記憶體限流，同時使用 JVM 記憶體、梯度統計等方式精準控制；多租戶層級，我們使用 CVM/Cgroups 方案保證多租戶間的資源隔離。

這裡詳細介紹下聚合場景限流問題，使用者在使用 ES 進行聚合分析時，經常遇到因聚合分桶過多打爆記憶體的問題。官方在 ES 6.8 中提供 max_buckets 引數控制聚合的最大分桶數，但這個方式侷限性非常強。在某些場景下，使用者設定 20 萬個分桶可以正常工作，但在另一些場景下，可能 10 萬個分桶記憶體就已經打爆，這主要取決於單分桶的大小，使用者並不能準確把握該引數設定為多少比較合適。我們在聚合分析的過程中，採用梯度演算法進行優化，每分配 1000 個分桶檢查一次 JVM 記憶體，當記憶體不足時及時中斷請求，保證 ES 叢集的高可用。具體可參考 PR ES-46751 /47806。

我們當前的限流方案，能夠大幅提升在異常查詢、壓力過載、單節點故障、網路分割槽等場景下，ES 服務的穩定性問題。但還有少量場景沒有覆蓋完全，所以我們目前也在引入混沌測試，依賴混沌測試來覆蓋更多異常場景。

前面我們介紹了高可用解決方案，下面我們來介紹成本方面的優化實踐。成本方面的挑戰，主要體現在以日誌、監控為代表的時序場景對機器資源的消耗，我們對線上典型的日誌、時序業務進行分析，總體來看，硬碟、記憶體、計算資源的成本比例接近 8:4:1，硬碟、記憶體是主要矛盾，其次是計算成本。

而對時序類場景進行分析，可以發現時序資料有很明顯的訪問特性。一是冷熱特性，時序資料訪問具有近多遠少的特點，最近 7 天資料的訪問量佔比可達到 95%以上；歷史資料訪問較少，且通常都是訪問統計類資訊。

基於這些瓶頸分析和資料訪問特性，我們來介紹成本優化的解決方案。

硬碟成本方面，由於資料具有明顯的冷熱特性，首先我們採用冷熱分離架構，使用混合儲存的方案來平衡成本、效能；其次，既然對歷史資料通常都是訪問統計資訊，那麼以通過預計算來換取儲存和效能，後面會展開介紹；如果歷史資料完全不使用，也可以備份到更廉價的儲存系統；其他一些優化方式包含儲存裁剪、生命週期管理等。

記憶體成本方面，很多使用者在使用大儲存機型時會發現，儲存資源才用了百分之二十，記憶體已經不足。其實基於時序資料的訪問特性，我們可以利用 Cache 進行優化，後面會展開介紹。

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

在大資料領域，傳統的方案是依賴外部離線計算系統，週期性的讀取全量資料進行計算，這種方式計算開銷、維護成本高。谷歌的廣告指標系統 Mesa 採用持續生成方案，資料寫入時系統給每個 Rollup 產生一份輸入資料，並對資料進行排序，底層在 Compact/Merge 過程中通過多路歸併完成 Rollup，這種方式的計算、維護成本相對較低。ES 從 6.x 開始支援資料排序，我們通過流式查詢進行多路歸併生成 Rollup，最終計算開銷小於全量資料寫入時 CPU 開銷的 10%，記憶體使用小於 10MB。我們已反饋核心優化至開源社群，解決開源 Rollup 的計算、記憶體瓶頸，具體可參考 PR ES-48399。

接下來，我們展開介紹記憶體優化部分。前面提到很多使用者在使用大儲存機型時，記憶體優先成為瓶頸、硬碟不能充分利用的問題，主要瓶頸在於索引佔用大量記憶體。但是我們知道時序類場景對歷史資料訪問很少，部分場景下某些欄位基本不使用，所我們可以通過引入 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、執行計劃不優等造成的查詢毛刺。

針對上述問題，我們介紹下騰訊在效能方面的優化實踐：

寫入方面，針對主鍵去重場景，通過利用索引進行裁剪，加速主鍵去重的過程，寫入效能提升 45%，具體可參考 PR Lucene-8980。對於部分壓測場景下 CPU 不能充分利用的問題，通過優化 ES 重新整理 Translog 時的資源搶佔，提升效能提升 20%，具體可參考 PR ES-45765 /47790。我們正在嘗試通過向量化執行優化寫入效能，通過減少分支跳轉、指令 Miss，預期寫入效能可提升 1 倍。

查詢方面，我們通過優化 Merge 策略，提升查詢效能，這部分稍後展開介紹。基於每個 Segment 記錄的 min/max 索引，進行查詢剪枝，提升查詢效能 30%。通過 CBO 策略，避免查詢 Cache 操作導致查詢耗時 10+倍的毛刺，具體可參考Lucene-9002。此外，我們也在嘗試通過一些新硬體來優化效能，比如說英特爾的 AEP、Optane、QAT 等。

接下來我們展開介紹下 Merge 策略優化部分。ES 原生的 Merge 策略主要關注大小相似性和最大上限，大小相似性是指 Merge 時儘量選擇大小相似的 Segments 進行 Merge，最大上限則考慮儘量把 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 核心方面的優化實踐，最後我們來簡單分享下我們在開源貢獻及未來規劃方面的思考。

四、未來規劃及開源貢獻

近半年我們向開源社群提交了 10+PR，涉及到寫入、查詢、叢集管理等各個模組，部分優化是和官方開發同學一起來完成的，前面介紹過程中，已經給出相應的 PR 連結，方便大家參考。我們在公司內部也組建了開源協同的小組，來共建 Elastic 生態。

總體來說，開源的收益利大於弊，我們把相應收益反饋出來，希望更多同學參與到 Elastic 生態的開源貢獻中：首先，開源可以降低分支維護成本，隨著自研的功能越來越多，維護獨立分支的成本越來越高，主要體現在與開源版本同步、快速引入開源新特性方面；其次，開源可以幫助研發同學更深入的把控核心，瞭解最新技術動態，因為在開源反饋的過程中，會涉及與官方開發人員持續的互動。此外，開源有利於建立大家在社群的技術影響力，獲得開源社群的認可。最後 Elastic 生態的快速發展，有利於業務服務、個人技術的發展，希望大家一起參與進來，助力 Elastic 生態持續、快速的發展。

未來規劃方面，這次分享我們重點介紹了騰訊在 ES 核心方面的優化實踐，包含高可用、低成本、高效能等方面。此外，我們也提供了一套管控平臺，支援線上叢集自動化管控、運維，為騰訊雲客戶提供 ES 服務。但是從線上大量的運營經驗分析，我們發現仍然有非常豐富、高價值的方向需要繼續跟進，我們會持續繼續加強對產品、核心的建設。

長期探索方面，我們結合大資料圖譜來介紹。整個大資料領域，按照資料量、延時要求等特點，可以劃分為三部分：第一部分是 Data Engineering，包含我們熟悉的批量計算、流式計算；第二部分是 Data Discovery，包含互動式分析、搜尋等；第三個部分是 Data Apps，主要用於支撐線上服務。

雖然我們把 ES 放到搜尋領域內，但是也有很多使用者使用 ES 支援在線搜尋、文件服務等；另外，我們瞭解到有不少成熟的 OLAP 系統，也是基於倒排索引、行列混存等技術棧，所以我們認為 ES 未來往這兩個領域發展的可行性非常強，我們未來會在 OLAP 分析和線上服務等方向進行重點探索。