作者： 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（https://github.com/elastic/elasticsearch/pull/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 (https://github.com/elastic/elasticsearch/pull/46751) / 47806 (https://github.com/elastic/elasticsearch/pull/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 (https://github.com/elastic/elasticsearch/pull/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 (https://github.com/apache/lucene-solr/pull/884)。對於部分壓測場景下 CPU 不能充分利用的問題，通過優化 ES 刷新 Translog 時的資源搶佔，提升性能提升 20%，具體可參考 PR ES-45765 (https://github.com/elastic/elasticsearch/pull/45765) /47790 (https://github.com/elastic/elasticsearch/pull/47790)。我們正在嘗試通過向量化執行優化寫入性能，通過減少分支跳轉、指令 Miss，預期寫入性能可提升 1 倍。
查詢方面，我們通過優化 Merge 策略，提升查詢性能，這部分稍後展開介紹。基於每個 Segment 記錄的 min/max 索引，進行查詢剪枝，提升查詢性能 30%。通過 CBO 策略，避免查詢 Cache 操作導致查詢耗時 10+倍的毛刺，具體可參考 LUCENE-9002 (https://github.com/apache/lucene-solr/pull/940)。此外，我們也在嘗試通過一些新硬件來優化性能，比如說英特爾的 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 分析和在線服務等方向進行重點探索。
閱讀更多 騰訊技術工程 的文章
