騰訊如何用Elasticsearch挖掘萬億數(shù)據(jù)價值？

Elasticsearch（ES）是近年來炙手可熱的開源分布式搜索分析引擎，通過簡單部署，它可以輕松實現(xiàn)日志實時分析、全文檢索、結(jié)構(gòu)化數(shù)據(jù)分析等多重訴求，并將挖掘數(shù)據(jù)價值的成本大幅降低。

ES在騰訊內(nèi)部和騰訊云用戶中擁有豐富的大規(guī)模落地場景，它們持續(xù)地推動著原生ES朝著高可用、高性能、低成本的方向優(yōu)化。本文即將介紹騰訊在ES的應(yīng)用落地過程中，遇到的挑戰(zhàn)、優(yōu)化思路、優(yōu)化成果和未來探索方向，希望能為開發(fā)者們提供參考。

一、ES的應(yīng)用場景

1.騰訊內(nèi)部應(yīng)用場景

在騰訊內(nèi)部，ES的應(yīng)用場景主要有“日志實時分析、搜索服務(wù)、時序數(shù)據(jù)分析等。

1.【日志實時分析場景】

典型場景如下：

運營日志：如慢日志、異常日志（用來定位業(yè)務(wù)問題）；

業(yè)務(wù)日志：如用戶的點擊、訪問日志（用來分析用戶行為）；

審計日志：可用于安全分析。

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

Elastic生態(tài)完整：任何一個開發(fā)者，可通過簡單部署成熟的組件，搭建起一個完整的日志實時分析系統(tǒng)。

時效性極高：日志從產(chǎn)生到可訪問的耗時一般在10S級。相比于傳統(tǒng)大數(shù)據(jù)解決方案幾十分鐘~幾小時的耗時，時效性提高了數(shù)百倍。

靈活的搜索分析能力：由于支持倒排索引、列存儲等數(shù)據(jù)結(jié)構(gòu)，ES擁有非常靈活的搜索分析能力。

搜索響應(yīng)時間短：ES支持交互式分析，即使有萬億級的日志，其搜索響應(yīng)時間也是秒級。

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

2.【搜索服務(wù)場景】

典型場景如下：

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

APP搜索：即應(yīng)用商店里的應(yīng)用搜索；

站內(nèi)搜索：即論壇、在線文檔等搜索功能。

騰訊使用ES支持了大量的搜索服務(wù)，它們主要有以下特點：

高性能：單個服務(wù)最大達到10w+QPS，平均響應(yīng)時長約20ms，P95延時小于100ms。

強相關(guān)：搜索體驗主要取決于“搜索結(jié)果”與“用戶意圖”之間的匹配度，可通過正確率、召回率等指標進行評估。

高可用：搜索場景通常要求4個9的可用性，并支持單機房故障容災(zāi)。

3.【時序數(shù)據(jù)分析場景】

典型的時序數(shù)據(jù)包含：

Metrics：即傳統(tǒng)的服務(wù)器監(jiān)控。

APM：應(yīng)用性能監(jiān)控。

傳感器數(shù)據(jù)：由物聯(lián)網(wǎng)數(shù)據(jù)，智能硬件、工業(yè)物聯(lián)網(wǎng)等產(chǎn)生。

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

高并發(fā)寫入：線上單集群最大規(guī)模高達600+節(jié)點，寫入吞吐量為1000w/s。

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

多維分析：要求靈活、多維度的統(tǒng)計分析能力，如在查看監(jiān)控時，可以按照地域、業(yè)務(wù)模塊等不同維度進行統(tǒng)計分析。

2.業(yè)界應(yīng)用場景

在業(yè)界，ES的主要應(yīng)用場景更多見于電子商務(wù)平臺上，比如對商品、標簽、店鋪的搜索。

年GMV達到200億的電子商務(wù)網(wǎng)站M就是一個典型的例子，它在ES的應(yīng)用場景也非常廣泛，包括商品搜索推薦、日志分析監(jiān)控、統(tǒng)計分析等。其業(yè)務(wù)團隊運行著幾十個ES集群，并且規(guī)模不斷在增長。

二、遇到的挑戰(zhàn)

1.騰訊遇到的挑戰(zhàn)

在騰訊內(nèi)部如此大規(guī)模、高壓力、多場景的業(yè)務(wù)背景下，ES的應(yīng)用著實遭到了不少挑戰(zhàn)，這些挑戰(zhàn)基本可以劃分為兩類：搜索類和時序類。

1.【搜索類】

高可用：以電商搜索、APP搜索、站內(nèi)搜索為例，它們重視可用性，服務(wù)SLA為4個9以上，需要考慮單機故障、單機房網(wǎng)絡(luò)故障等災(zāi)備場景。

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

總之，在搜索類業(yè)務(wù)場景下，核心挑戰(zhàn)點在于高可用、高性能。

2.【時序類】

時序類場景包含日志、Metrics、APM等。相比于搜索類業(yè)務(wù)聚焦高可用、高性能的問題，時序類業(yè)務(wù)會更注重成本、性能。舉個例子，時序場景用戶通常要求高寫入吞吐，部分場景可達1000w/s；在這樣寫入吞吐下，保留30天的數(shù)據(jù)，存儲量可達PB級。如果用戶用于線上實際業(yè)務(wù)的機器數(shù)量是100臺，而監(jiān)控、日志等需要50臺，這對多數(shù)用戶來說基本是不可接受的（因為監(jiān)控、日志的收益相對較低）。所以在時序類業(yè)務(wù)中，主要的挑戰(zhàn)在于存儲成本、計算成本等方面。

面對如此艱巨的挑戰(zhàn)，騰訊在ES內(nèi)核方面進行了深入的優(yōu)化實踐（這種優(yōu)化后的成果也通過騰訊云開放給了外界的用戶，其中就有電子商務(wù)網(wǎng)站M）。

2.業(yè)界遇到的挑戰(zhàn)

業(yè)界也經(jīng)歷著與騰訊類似的挑戰(zhàn)。還是以電子商務(wù)網(wǎng)站M為例，電商經(jīng)常性的大促，他們不得不關(guān)注ES集群的穩(wěn)定性和集群的容災(zāi)備份。

在集群穩(wěn)定性方面，他們經(jīng)常碰到的問題是“范圍較大的查詢，會導(dǎo)致ES節(jié)點的JVM OOM（內(nèi)存溢出），影響集群穩(wěn)定性”，以及“索引數(shù)或分片數(shù)過多時，集群元數(shù)組變更慢且CPU負載高，從而影響集群穩(wěn)定性”。

在容災(zāi)備份方面，他們經(jīng)常碰到的問題是“單機房故障時，如何保證服務(wù)不中斷”，以及“故障發(fā)生后，數(shù)據(jù)如何恢復(fù)”。

三、ES優(yōu)化實踐

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

1.系統(tǒng)健壯性：指ES內(nèi)核自身的健壯性，這也是分布式系統(tǒng)面臨的共性難題。例如：

在異常查詢、壓力過載下集群的容錯能力；在高壓力場景下，集群的可擴展性；在集群擴容、節(jié)點異常場景下，節(jié)點、多硬盤之間的數(shù)據(jù)均衡能力。

2.容災(zāi)方案：如通過建設(shè)管控系統(tǒng)，保障機房網(wǎng)絡(luò)故障時快速恢復(fù)服務(wù)、自然災(zāi)害下防止數(shù)據(jù)丟失、誤操作后快速回滾等。

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

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

1.系統(tǒng)健壯性：

服務(wù)不穩(wěn)定：通過服務(wù)限流，容忍機器網(wǎng)絡(luò)故障、異常查詢等異常情況。

集群擴展性問題：通過優(yōu)化集群元數(shù)據(jù)管控邏輯，提升了10倍的集群擴展能力，支持千級節(jié)點集群、百萬分片；

集群均衡問題：通過優(yōu)化節(jié)點、多硬盤間的分片均衡，保證大規(guī)模集群的壓力均衡。

2.容災(zāi)方案：

數(shù)據(jù)可恢復(fù)：通過擴展ES的插件機制支持備份回檔，把ES的數(shù)據(jù)備份回檔到廉價存儲，保證數(shù)據(jù)的可恢復(fù)；

故障容忍：騰訊云ES支持跨可用區(qū)容災(zāi)，用戶可以按需部署多個可用區(qū)，以容忍單機房故障。

此外，騰訊云ES還支持COS備份的功能，用戶可以通過操作ES的api，直接備份底層的數(shù)據(jù)文件到騰訊云對象存儲COS上，實現(xiàn)了低成本、操作簡便的數(shù)據(jù)備份功能。

異?；謴?fù)：通過垃圾桶機制，保證用戶在欠費、誤操作等場景下，集群可快速恢復(fù)。

3.系統(tǒng)缺陷：

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

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

權(quán)限層級：優(yōu)化后，ES支持XPack和自研權(quán)限來防止攻擊和誤操作；

隊列層級：通過優(yōu)化任務(wù)執(zhí)行速度、重復(fù)、優(yōu)先級等細節(jié)，解決用戶經(jīng)常遇到的Master任務(wù)隊列堆積、任務(wù)餓死等問題；

內(nèi)存層級：從ES 6.x開始，支持在全鏈路上（包括HTTP入口、協(xié)調(diào)節(jié)點、數(shù)據(jù)節(jié)點等）進行內(nèi)存限流：同時使用JVM內(nèi)存、梯度統(tǒng)計等方式進行精準控制；

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

這里展開介紹下聚合場景限流的問題，用戶在使用ES進行聚合分析時，經(jīng)常因聚合分桶過多打爆內(nèi)存。官方在ES 6.8中提供max_buckets參數(shù)控制聚合的最大分桶數(shù)，但這個方式局限性非常強：內(nèi)存是否會被打爆還取決于單分桶的大?。ㄔ谀承﹫鼍跋?，用戶設(shè)置20萬個分桶可以正常工作，但在另一些場景下，可能10萬個分桶內(nèi)存就已經(jīng)打爆），因此用戶并不能準確把握該參數(shù)應(yīng)設(shè)置為多少。此時騰訊采用梯度算法進行優(yōu)化，每分配1000個分桶檢查一次JVM內(nèi)存，當內(nèi)存不足時及時中斷請求，保證了ES集群的高可用。這些限流方案，能夠解決在異常查詢、壓力過載、單節(jié)點故障、網(wǎng)絡(luò)分區(qū)等場景下，ES服務(wù)的穩(wěn)定性問題。但還有少量場景沒有觸達，因此騰訊目前正在探索，通過依賴混沌測試覆蓋更多異常場景。

針對“索引數(shù)或分片數(shù)過多，導(dǎo)致的集群元數(shù)據(jù)變更慢且CPU負載高，從而影響集群穩(wěn)定性”的問題，在內(nèi)核上，騰訊優(yōu)化了shard分配的算法，利用緩存節(jié)點routing表和元數(shù)據(jù)增量更新的方法，加快集群元數(shù)據(jù)的變更速度。解決了高可用和高性能的問題，下面該談?wù)劤杀緝?yōu)化方面的實踐了。

成本方面的挑戰(zhàn)，主要體現(xiàn)在時序場景（如日志、監(jiān)控）對機器資源的消耗，通過對線上典型的日志、時序業(yè)務(wù)分析可得，硬盤、內(nèi)存、計算資源的成本比例接近8:4:1。也就是說，硬盤、內(nèi)存是主要矛盾，其次是計算成本。時序數(shù)據(jù)有很明顯的訪問特性：”近多遠少”。最近七天數(shù)據(jù)的訪問量占比大于95%；歷史數(shù)據(jù)訪問較少，且通常都是訪問統(tǒng)計類信息。

基于這些瓶頸分析和數(shù)據(jù)訪問特性，成本優(yōu)化的解決方案如下：

（1）采用冷熱分離架構(gòu)，使用混合存儲的方案來平衡成本、性能；

（2）既然對歷史數(shù)據(jù)通常都是訪問統(tǒng)計信息，那么通過預(yù)計算來換取存儲和性能；

（3）如果歷史數(shù)據(jù)完全不使用，可以備份到更廉價的存儲系統(tǒng)；

（4）基于時序數(shù)據(jù)的訪問特性，內(nèi)存成本方面可以利用Cache進行優(yōu)化。

（5）其他一些優(yōu)化方式：如存儲裁剪、生命周期管理等。

這里展開介紹下Rollup部分。Rollup類似于大數(shù)據(jù)場景下的Cube、物化視圖，它的核心思想是通過預(yù)計算提前生成統(tǒng)計信息，釋放原始粒度數(shù)據(jù)，從而降低存儲成本、提高查詢性能。這里舉個簡單的例子：在機器監(jiān)控場景下，原始粒度的監(jiān)控數(shù)據(jù)是10秒級的，而一個月之前的監(jiān)控數(shù)據(jù)，一般只需查看小時粒度，這即是一個Rollup應(yīng)用場景。官方從ES 6.x開始推出Rollup，實際上騰訊在5.x已經(jīng)著手研究。在大數(shù)據(jù)領(lǐng)域，傳統(tǒng)的方案是依賴外部離線計算系統(tǒng)，周期性地讀取全量數(shù)據(jù)進行計算，這種方式計算開銷、維護成本高。

谷歌的廣告指標系統(tǒng)Mesa采用持續(xù)生成方案，數(shù)據(jù)寫入時系統(tǒng)給每個Rollup產(chǎn)生一份輸入數(shù)據(jù)，并對數(shù)據(jù)進行排序，底層在Compact/Merge過程中通過多路歸并完成Rollup，這種方式的計算、維護成本相對較低。

ES從6.x開始支持數(shù)據(jù)排序，騰訊通過流式查詢進行多路歸并生成Rollup，最終計算開銷小于全量數(shù)據(jù)寫入時CPU開銷的10%，內(nèi)存使用小于10MB。這種內(nèi)核優(yōu)化方式已被騰訊貢獻給開源社區(qū)，以解決開源Rollup的計算、內(nèi)存瓶頸。

前文提及很多用戶在使用大存儲機型時，內(nèi)存優(yōu)先成為瓶頸、硬盤不能充分利用，這類問題主要瓶頸在于索引占用大量內(nèi)存?？紤]到時序類場景很少訪問歷史數(shù)據(jù)，部分場景下某些字段基本不使用，所騰訊通過引入Cache來提高內(nèi)存利用效率。在內(nèi)存優(yōu)化方面，業(yè)界有怎樣的方案？

ES社區(qū)從7.x后支持索引放于堆外，和DocValue一樣按需加載。這種方式的缺點在于索引和數(shù)據(jù)的重要性完全不同，一個大查詢?nèi)菀讓?dǎo)致索引被淘汰，后續(xù)查詢性能倍數(shù)級的衰減。Hbase通過Cache緩存索引、數(shù)據(jù)塊，提升熱數(shù)據(jù)訪問性能，并從HBase 2.0開始，重點介紹其Off Heap技術(shù)，讓堆外和堆內(nèi)的內(nèi)存訪問性能接近?；谏鐓^(qū)經(jīng)驗進行迭代，騰訊在ES中引入LFU Cache以提高內(nèi)存利用效率，把Cache放置在堆外以降低堆內(nèi)存壓力，同時通過Weak Reference堆內(nèi)外拷貝等技術(shù)降低損耗。通過這種方法，內(nèi)存利用率提升80%，查詢性能損耗不超過2%，GC開銷降低30%。

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

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

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

（2）CPU利用率優(yōu)化：針對部分壓測場景下CPU不能充分利用的問題，通過優(yōu)化ES刷新Translog時的資源搶占，使性能提升20%。

（3）查詢優(yōu)化：通過優(yōu)化Merge策略提升查詢性能?；诿總€Segment記錄的min/max索引進行查詢剪枝，提升了30%的查詢性能。通過CBO策略，避免查詢Cache操作導(dǎo)致查詢耗時10+倍的毛刺。此外，通過一些新硬件（如英特爾的AEP、Optane、QAT等）來優(yōu)化性能也是不錯的探索方向。

下面，詳細談?wù)凪erge策略優(yōu)化部分：ES原生的Merge策略主要關(guān)注大小相似性（Merge時盡量選擇大小相似的Segments）和最大上限（考慮盡量把Segment拼湊到5GB）。那么有可能出現(xiàn)：某個Segment中包含了1月整月、3月1號的數(shù)據(jù)，當用戶查詢3月1號某小時的數(shù)據(jù)時，就必須掃描大量無用數(shù)據(jù)，致使性能損耗嚴重。針對上述問題，騰訊在ES中引入了時序Merge：在選擇Segments進行Merge時，重點考慮時間因素，讓時間相近的Segments被Merge到一起。當用戶查詢3月1號的數(shù)據(jù)時，只需要掃描個別較小的Segments，其它的Segments可以被快速裁剪。另外，ES官方推薦搜索類用戶在寫入完成之后，進行一次Force Merge：其用意是把所有Segments合并為一個，以提高搜索性能。但這增加了用戶的使用成本，且在時序場景下需要掃描全部數(shù)據(jù)，不利于裁剪。由此，騰訊在ES中引入了冷數(shù)據(jù)自動Merge：對于非活躍的索引，底層Segments會自動Merge到接近5GB，降低文件數(shù)量的同時，方便時序場景裁剪。對于搜索場景，用戶可以調(diào)整目標Segment的大小，使所有Segments最終Merge為一個。這種Merge策略的優(yōu)化，可使搜索場景性能提升1倍。

在接入騰訊云ES后，電子商務(wù)網(wǎng)站M的ES基礎(chǔ)能力和開發(fā)運維效率都得到了顯著的提升：

可靠性：基于騰訊對ES內(nèi)核優(yōu)化后的能力，電子商務(wù)網(wǎng)站M的ES集群可靠性有著明顯的提升，扛起了多重流量洪峰，收獲了明顯的經(jīng)濟效益。

安全容災(zāi)：多可用區(qū)提供了容災(zāi)保障、X-Pack權(quán)限管理提供了安全保障；

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

特別值得一提的是，整個項目在遷移過程中非常平滑穩(wěn)定：

M原有ES集群實現(xiàn)了完全不停服遷移；

遷移后仍保持了M自建ES時自研開發(fā)的運維系統(tǒng)的對接；

遷移過程中，M對內(nèi)核的特殊需求，ES社區(qū)版本并不支持，騰訊云ES專門的內(nèi)核團隊積極相應(yīng)，提供了該能力。

四、未來規(guī)劃及開源貢獻

目前，國內(nèi)有很多ES在“查詢范圍較大”和“索引或分片數(shù)較多”的應(yīng)用場景，因此國內(nèi)社區(qū)開發(fā)者也格外關(guān)注于此。在這兩個領(lǐng)域，騰訊云ES的優(yōu)化方案，因其全面性和代碼整潔性，已被Elastic官方所采納。

近半年騰訊向開源社區(qū)提交了10+PR，涉及寫入、查詢、集群管理等各個模塊（部分優(yōu)化功能是與Elastic官方開發(fā)一同完成）。騰訊內(nèi)部組建了Elasticsearch開源協(xié)同的小組，讓來自騰訊的所有開發(fā)者，都能參與到Elastic的生態(tài)建設(shè)中。

目前，騰訊聯(lián)合Elastic公司，已在騰訊云上推出了內(nèi)核增強版的ES云服務(wù)，將萬億級搜索的能力對外輸出。不過，ES的發(fā)展仍有非常多有價值的方向可以深入研究，這也是騰訊云在上線產(chǎn)品后迭代優(yōu)化產(chǎn)品、持續(xù)內(nèi)核建設(shè)的原因。

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

以大數(shù)據(jù)圖譜為思路，整個大數(shù)據(jù)領(lǐng)域按照數(shù)據(jù)量、延時要求等特點，可以分為三部分：

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

(2)DataDiscovery，包含交互式分析、搜索等；

(3)DataApps，主要用于支撐在線服務(wù)。

雖然ES被視為搜索領(lǐng)域內(nèi)的技術(shù)，但是ES也支持在線搜索、文檔服務(wù)等場景；另外，有不少成熟的OLAP系統(tǒng)，也是基于倒排索引、行列混存等技術(shù)棧。由此可以看出，ES往這兩個領(lǐng)域發(fā)展的可行性非常強。因此，騰訊會重點朝“在線服務(wù)”和“OLAP分析”等方向探索ES技術(shù)。