作者：johngqjiang，騰訊 TEG 云架構(gòu)平臺(tái)部研發(fā)工程師

Elasticsearch（ES）作為開源首選的分布式搜索分析引擎，通過一套系統(tǒng)輕松滿足用戶的日志實(shí)時(shí)分析、全文檢索、結(jié)構(gòu)化數(shù)據(jù)分析等多種需求，大幅降低大數(shù)據(jù)時(shí)代挖掘數(shù)據(jù)價(jià)值的成本。騰訊在公司內(nèi)部豐富的場景中大規(guī)模使用 ES，同時(shí)聯(lián)合 Elastic 公司在騰訊云上提供內(nèi)核增強(qiáng)版的 ES 云服務(wù)，大規(guī)模、豐富多樣的的使用場景推動(dòng)著騰訊對(duì)原生 ES 進(jìn)行持續(xù)的高可用、高性能、低成本優(yōu)化。今天給大家分享近期在 Elastic 中國開發(fā)者大會(huì)上的演講內(nèi)容：騰訊萬億級(jí) Elasticsearch 技術(shù)解密。

?

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

?

本次分享的主要內(nèi)容包含：首先介紹 ES 在騰訊的豐富應(yīng)用場景及各種場景的典型特點(diǎn)；然后給出我們?cè)诖笠?guī)模、高壓力、豐富多樣的使用場景下遇到的挑戰(zhàn)；針對(duì)這些挑戰(zhàn)，我們重點(diǎn)介紹騰訊在 ES 內(nèi)核方面進(jìn)行的高可用性、低成本、高性能等優(yōu)化實(shí)踐；最后簡單分享我們?cè)?ES 未來規(guī)劃以及開源貢獻(xiàn)方面的思考。

我們先來看下 ES 在騰訊的應(yīng)用場景。最初我們使用 ES 于日志實(shí)時(shí)分析場景，典型日志如下：運(yùn)營日志，比如慢日志、異常日志，用來定位業(yè)務(wù)問題；業(yè)務(wù)日志，比如用戶的點(diǎn)擊、訪問日志，可以用來分析用戶行為；審計(jì)日志，可以用于安全分析。ES 很完美的解決了日志實(shí)時(shí)分析的需求，它具有如下特點(diǎn)：

• Elastic 生態(tài)提供了完整的日志解決方案，任何一個(gè)開發(fā)、運(yùn)維同學(xué)使用成熟組件，通過簡單部署，即可搭建起一個(gè)完整的日志實(shí)時(shí)分析服務(wù)。

• 在 Elastic 生態(tài)中，日志從產(chǎn)生到可訪問一般在 10s 級(jí)。相比于傳統(tǒng)大數(shù)據(jù)解決方案的幾十分鐘、小時(shí)級(jí)，時(shí)效性非常高。

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

• 支持交互式分析，即使在萬億級(jí)日志的情況下，ES 搜索響應(yīng)時(shí)間也是秒級(jí)。

日志是互聯(lián)網(wǎng)行業(yè)最基礎(chǔ)、最廣泛的數(shù)據(jù)形式，ES 非常完美的解決了日志實(shí)時(shí)分析場景，這也是近幾年 ES 快速發(fā)展的一個(gè)重要原因。

第二類使用場景是搜索服務(wù)，典型場景包含：商品搜索，類似京東、淘寶、拼多多中的商品搜索；APP 搜索，支持應(yīng)用商店里的應(yīng)用搜索；站內(nèi)搜索，支持論壇、在線文檔等搜索功能。我們支持了大量搜索服務(wù)，它們主要有以下特點(diǎn)：

• 高性能：單個(gè)服務(wù)最大達(dá)到 10w+ QPS，平響 20ms~，P95 延時(shí)小于 100ms。

• 強(qiáng)相關(guān)：搜索體驗(yàn)主要取決于搜索結(jié)果是否高度匹配用戶意圖，需要通過正確率、召回率等指標(biāo)進(jìn)行評(píng)估。

• 高可用：搜索場景通常要求 4 個(gè) 9 的可用性，支持單機(jī)房故障容災(zāi)。任何一個(gè)電商服務(wù)，如淘寶、京東、拼多多，只要故障一個(gè)小時(shí)就可以上頭條。

第三類使用場景是時(shí)序數(shù)據(jù)分析，典型的時(shí)序數(shù)據(jù)包含：Metrics，即傳統(tǒng)的服務(wù)器監(jiān)控；APM，應(yīng)用性能監(jiān)控；物聯(lián)網(wǎng)數(shù)據(jù)，智能硬件、工業(yè)物聯(lián)網(wǎng)等產(chǎn)生的傳感器數(shù)據(jù)。這類場景騰訊很早就開始探索，在這方面積累了非常豐富的經(jīng)驗(yàn)。這類場景具有以下特點(diǎn)：

• 高并發(fā)寫入：線上單集群最大規(guī)模達(dá)到 600+節(jié)點(diǎn)、1000w/s 的寫入吞吐。

• 高查詢性能：要求單條曲線 或者單個(gè)時(shí)間線的查詢延時(shí)在 10ms~。

• 多維分析：要求靈活、多維度的統(tǒng)計(jì)分析能力，比如我們?cè)诓榭幢O(jiān)控的時(shí)候，可以按照地域、業(yè)務(wù)模塊等靈活的進(jìn)行統(tǒng)計(jì)分析。

?

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

?

前面我們介紹了 ES 在騰訊內(nèi)部的廣泛應(yīng)用，在如此大規(guī)模、高壓力、豐富使用場景的背景下，我們遇到了很多挑戰(zhàn)，總體可以劃分為兩類：搜索類和時(shí)序類。

?

首先，我們一起看看搜索類業(yè)務(wù)的挑戰(zhàn)。以電商搜索、APP 搜索、站內(nèi)搜索為代表，這類業(yè)務(wù)非常重視可用性，服務(wù) SLA 達(dá)到 4 個(gè) 9 以上，需要容忍單機(jī)故障、單機(jī)房網(wǎng)絡(luò)故障等；同時(shí)要求高性能、低毛刺，例如 20w QPS、平響 20ms、P95 延時(shí) 100ms。總之，在搜索類業(yè)務(wù)場景下，核心挑戰(zhàn)點(diǎn)在于高可用、高性能。

另一類我們稱之為時(shí)序類業(yè)務(wù)挑戰(zhàn)，包含日志、Metrics、APM 等場景。相比于搜索類業(yè)務(wù)重點(diǎn)關(guān)注高可用、高性能，時(shí)序類業(yè)務(wù)會(huì)更注重成本、性能。比如時(shí)序場景用戶通常要求高寫入吞吐，部分場景可達(dá) 1000w/sWPS；在這樣寫入吞吐下，保留 30 天的數(shù)據(jù)，通常可達(dá)到 PB 級(jí)的存儲(chǔ)量。而現(xiàn)實(shí)是日志、監(jiān)控等場景的收益相對(duì)較低，很可能用戶用于線上實(shí)際業(yè)務(wù)的機(jī)器數(shù)量才是 100 臺(tái)，而監(jiān)控、日志等需要 50 臺(tái)，這對(duì)多數(shù)用戶來說，基本是不可接受的。所以在時(shí)序類業(yè)務(wù)中，主要的挑戰(zhàn)在于存儲(chǔ)成本、計(jì)算成本等方面。

前面我們介紹了在搜索類、時(shí)序類業(yè)務(wù)場景下遇到的高可用、低成本、高性能等挑戰(zhàn)，下面針對(duì)這些挑戰(zhàn)，我們重點(diǎn)分享騰訊在 ES 內(nèi)核方面的深入實(shí)踐。

?

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

?

首先，我們來看看高可用優(yōu)化，我們把高可用劃分為三個(gè)維度：

• 系統(tǒng)健壯性：是指 ES 內(nèi)核自身的健壯性，也是分布式系統(tǒng)面臨的共性難題。例如，在異常查詢、壓力過載下集群的容錯(cuò)能力；在高壓力場景下，集群的可擴(kuò)展性；在集群擴(kuò)容、節(jié)點(diǎn)異常場景下，節(jié)點(diǎn)、多硬盤之間的數(shù)據(jù)均衡能力。

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

• 系統(tǒng)缺陷：這在任何系統(tǒng)發(fā)展過程中都會(huì)持續(xù)產(chǎn)生，比如說 Master 節(jié)點(diǎn)堵塞、分布式死鎖、滾動(dòng)重啟緩慢等。

針對(duì)上述問題，下面來介紹我們?cè)诟呖捎梅矫娴慕鉀Q方案：

系統(tǒng)健壯性方面，我們通過服務(wù)限流，容忍機(jī)器網(wǎng)絡(luò)故障、異常查詢等導(dǎo)致的服務(wù)不穩(wěn)定，后面展開介紹。通過優(yōu)化集群元數(shù)據(jù)管控邏輯，提升集群擴(kuò)展能力一個(gè)數(shù)量級(jí)，支持千級(jí)節(jié)點(diǎn)集群、百萬分片，解決集群可擴(kuò)展性問題；集群均衡方面，通過優(yōu)化節(jié)點(diǎn)、多硬盤間的分片均衡，保證大規(guī)模集群的壓力均衡。

容災(zāi)方案方面，我們通過擴(kuò)展 ES 的插件機(jī)制支持備份回檔，把 ES 的數(shù)據(jù)備份回檔到廉價(jià)存儲(chǔ)，保證數(shù)據(jù)的可恢復(fù)；支持跨可用區(qū)容災(zāi)，用戶可以按需部署多個(gè)可用區(qū)，以容忍單機(jī)房故障。垃圾桶機(jī)制，保證用戶在欠費(fèi)、誤操作等場景下，集群可快速恢復(fù)。

系統(tǒng)缺陷方面，我們修復(fù)了滾動(dòng)重啟、Master 阻塞、分布式死鎖等一系列 Bug。其中滾動(dòng)重啟優(yōu)化，可加速節(jié)點(diǎn)重啟速度 5+倍，具體可參考 PR ES-46520；Master 堵塞問題，我們?cè)?ES 6.x 版本和官方一起做了優(yōu)化。

這里我們展開介紹下服務(wù)限流部分。我們做了 4 個(gè)層級(jí)的限流工作：權(quán)限層級(jí)，我們支持 XPack 和自研權(quán)限來防止攻擊、誤操作；隊(duì)列層級(jí)，通過優(yōu)化任務(wù)執(zhí)行速度、重復(fù)、優(yōu)先級(jí)等問題，解決用戶常遇到的 Master 任務(wù)隊(duì)列堆積、任務(wù)餓死等問題；內(nèi)存層級(jí)，我們從 ES 6.x 開始，支持在 HTTP 入口、協(xié)調(diào)節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)等全鏈路上進(jìn)行內(nèi)存限流，同時(shí)使用 JVM 內(nèi)存、梯度統(tǒng)計(jì)等方式精準(zhǔn)控制；多租戶層級(jí)，我們使用 CVM/Cgroups 方案保證多租戶間的資源隔離。

這里詳細(xì)介紹下聚合場景限流問題，用戶在使用 ES 進(jìn)行聚合分析時(shí)，經(jīng)常遇到因聚合分桶過多打爆內(nèi)存的問題。官方在 ES 6.8 中提供 max_buckets 參數(shù)控制聚合的最大分桶數(shù)，但這個(gè)方式局限性非常強(qiáng)。在某些場景下，用戶設(shè)置 20 萬個(gè)分桶可以正常工作，但在另一些場景下，可能 10 萬個(gè)分桶內(nèi)存就已經(jīng)打爆，這主要取決于單分桶的大小，用戶并不能準(zhǔn)確把握該參數(shù)設(shè)置為多少比較合適。我們?cè)诰酆戏治龅倪^程中，采用梯度算法進(jìn)行優(yōu)化，每分配 1000 個(gè)分桶檢查一次 JVM 內(nèi)存，當(dāng)內(nèi)存不足時(shí)及時(shí)中斷請(qǐng)求，保證 ES 集群的高可用。具體可參考 PR ES-46751 /47806。

我們當(dāng)前的限流方案，能夠大幅提升在異常查詢、壓力過載、單節(jié)點(diǎn)故障、網(wǎng)絡(luò)分區(qū)等場景下，ES 服務(wù)的穩(wěn)定性問題。但還有少量場景沒有覆蓋完全，所以我們目前也在引入混沌測試，依賴混沌測試來覆蓋更多異常場景。

前面我們介紹了高可用解決方案，下面我們來介紹成本方面的優(yōu)化實(shí)踐。成本方面的挑戰(zhàn)，主要體現(xiàn)在以日志、監(jiān)控為代表的時(shí)序場景對(duì)機(jī)器資源的消耗，我們對(duì)線上典型的日志、時(shí)序業(yè)務(wù)進(jìn)行分析，總體來看，硬盤、內(nèi)存、計(jì)算資源的成本比例接近 8:4:1，硬盤、內(nèi)存是主要矛盾，其次是計(jì)算成本。

而對(duì)時(shí)序類場景進(jìn)行分析，可以發(fā)現(xiàn)時(shí)序數(shù)據(jù)有很明顯的訪問特性。一是冷熱特性，時(shí)序數(shù)據(jù)訪問具有近多遠(yuǎn)少的特點(diǎn)，最近 7 天數(shù)據(jù)的訪問量占比可達(dá)到 95%以上；歷史數(shù)據(jù)訪問較少，且通常都是訪問統(tǒng)計(jì)類信息。

基于這些瓶頸分析和數(shù)據(jù)訪問特性，我們來介紹成本優(yōu)化的解決方案。

硬盤成本方面，由于數(shù)據(jù)具有明顯的冷熱特性，首先我們采用冷熱分離架構(gòu)，使用混合存儲(chǔ)的方案來平衡成本、性能；其次，既然對(duì)歷史數(shù)據(jù)通常都是訪問統(tǒng)計(jì)信息，那么以通過預(yù)計(jì)算來換取存儲(chǔ)和性能，后面會(huì)展開介紹；如果歷史數(shù)據(jù)完全不使用，也可以備份到更廉價(jià)的存儲(chǔ)系統(tǒng)；其他一些優(yōu)化方式包含存儲(chǔ)裁剪、生命周期管理等。

內(nèi)存成本方面，很多用戶在使用大存儲(chǔ)機(jī)型時(shí)會(huì)發(fā)現(xiàn)，存儲(chǔ)資源才用了百分之二十，內(nèi)存已經(jīng)不足。其實(shí)基于時(shí)序數(shù)據(jù)的訪問特性，我們可以利用 Cache 進(jìn)行優(yōu)化，后面會(huì)展開介紹。

我們展開介紹下 Rollup 部分。官方從 ES 6.x 開始推出 Rollup，實(shí)際上騰訊在 5.x 已經(jīng)開始這部分的實(shí)踐。Rollup 類似于大數(shù)據(jù)場景下的 Cube、物化視圖，它的核心思想是通過預(yù)計(jì)算提前生成統(tǒng)計(jì)信息，釋放掉原始粒度數(shù)據(jù)，從而降低存儲(chǔ)成本、提高查詢性能，通常會(huì)有數(shù)據(jù)級(jí)的收益。這里舉個(gè)簡單的例子，比如在機(jī)器監(jiān)控場景下，原始粒度的監(jiān)控?cái)?shù)據(jù)是 10 秒級(jí)的，而一個(gè)月之前的監(jiān)控?cái)?shù)據(jù)，一般只需要查看小時(shí)粒度，這即是一個(gè) Rollup 應(yīng)用場景。

在大數(shù)據(jù)領(lǐng)域，傳統(tǒng)的方案是依賴外部離線計(jì)算系統(tǒng)，周期性的讀取全量數(shù)據(jù)進(jìn)行計(jì)算，這種方式計(jì)算開銷、維護(hù)成本高。谷歌的廣告指標(biāo)系統(tǒng) Mesa 采用持續(xù)生成方案，數(shù)據(jù)寫入時(shí)系統(tǒng)給每個(gè) Rollup 產(chǎn)生一份輸入數(shù)據(jù)，并對(duì)數(shù)據(jù)進(jìn)行排序，底層在 Compact/Merge 過程中通過多路歸并完成 Rollup，這種方式的計(jì)算、維護(hù)成本相對(duì)較低。ES 從 6.x 開始支持?jǐn)?shù)據(jù)排序，我們通過流式查詢進(jìn)行多路歸并生成 Rollup，最終計(jì)算開銷小于全量數(shù)據(jù)寫入時(shí) CPU 開銷的 10%，內(nèi)存使用小于 10MB。我們已反饋內(nèi)核優(yōu)化至開源社區(qū)，解決開源 Rollup 的計(jì)算、內(nèi)存瓶頸，具體可參考 PR ES-48399。

接下來，我們展開介紹內(nèi)存優(yōu)化部分。前面提到很多用戶在使用大存儲(chǔ)機(jī)型時(shí)，內(nèi)存優(yōu)先成為瓶頸、硬盤不能充分利用的問題，主要瓶頸在于索引占用大量內(nèi)存。但是我們知道時(shí)序類場景對(duì)歷史數(shù)據(jù)訪問很少，部分場景下某些字段基本不使用，所我們可以通過引入 Cache 來提高內(nèi)存利用效率。

在內(nèi)存優(yōu)化方面，業(yè)界的方案是什么樣的呢？ES 社區(qū)從 7.x 后支持索引放于堆外，和 DocValue 一樣按需加載。但這種方式不好的地方在于索引和數(shù)據(jù)的重要性完全不同，一個(gè)大查詢很容易導(dǎo)致索引被淘汰，后續(xù)查詢性能倍數(shù)級(jí)的衰減。Hbase 通過緩存 Cache 緩存索引、數(shù)據(jù)塊，提升熱數(shù)據(jù)訪問性能，并且從 HBase 2.0 開始，重點(diǎn)介紹其 Off Heap 技術(shù)，重點(diǎn)在于堆外內(nèi)存的訪問性能可接近堆內(nèi)。我們基于社區(qū)經(jīng)驗(yàn)進(jìn)行迭代，在 ES 中引入 LFU Cache 以提高內(nèi)存的利用效率，把 Cache 放置在堆外以降低堆內(nèi)存壓力，同時(shí)通過 Weak Reference、減少堆內(nèi)外拷貝等技術(shù)降低損耗。最終效果是內(nèi)存利用率提升 80%，可以充分利用大存儲(chǔ)機(jī)型，查詢性能損耗不超過 2%，GC 開銷降低 30%。

前面我們介紹了可用性、成本優(yōu)化的解決方案，最后我們來介紹性能方面的優(yōu)化實(shí)踐。以日志、監(jiān)控為代表的時(shí)序場景，對(duì)寫入性能要求非常高，寫入并發(fā)可達(dá) 1000w/s。然而我們發(fā)現(xiàn)在帶主鍵寫入時(shí)，ES 性能衰減 1+倍，部分壓測場景下，CPU 無法充分利用。以搜索服務(wù)為代表的場景，對(duì)查詢性的要求非常高，要求 20w QPS, 平響 20ms，而且盡量避免 GC、執(zhí)行計(jì)劃不優(yōu)等造成的查詢毛刺。

針對(duì)上述問題，我們介紹下騰訊在性能方面的優(yōu)化實(shí)踐：

寫入方面，針對(duì)主鍵去重場景，通過利用索引進(jìn)行裁剪，加速主鍵去重的過程，寫入性能提升 45%，具體可參考 PR Lucene-8980。對(duì)于部分壓測場景下 CPU 不能充分利用的問題，通過優(yōu)化 ES 刷新 Translog 時(shí)的資源搶占，提升性能提升 20%，具體可參考 PR ES-45765 /47790。我們正在嘗試通過向量化執(zhí)行優(yōu)化寫入性能，通過減少分支跳轉(zhuǎn)、指令 Miss，預(yù)期寫入性能可提升 1 倍。

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

接下來我們展開介紹下 Merge 策略優(yōu)化部分。ES 原生的 Merge 策略主要關(guān)注大小相似性和最大上限，大小相似性是指 Merge 時(shí)盡量選擇大小相似的 Segments 進(jìn)行 Merge，最大上限則考慮盡量把 Segment 拼湊到 5GB。那么有可能出現(xiàn)某個(gè) Segment 中包含了 1 月整月、3 月 1 號(hào)的數(shù)據(jù)，當(dāng)用戶查詢 3 月 1 號(hào)某小時(shí)的數(shù)據(jù)時(shí)，就必須掃描大量無用數(shù)據(jù)，性能損耗嚴(yán)重。

我們?cè)?ES 中引入了時(shí)序 Merge，在選擇 Segments 進(jìn)行 Merge 時(shí)，重點(diǎn)考慮時(shí)間因素，這樣時(shí)間相近的 Segments 被 Merge 到一起。當(dāng)我們查詢 3 月 1 號(hào)的數(shù)據(jù)時(shí)，只需要掃描個(gè)別較小的 Segments 就好，其他的 Segments 可以快速裁剪掉。

另外，ES 官方推薦搜索類用戶在寫入完成之后，進(jìn)行一次 Force Merge，用意是把所有 Segments 合并為一個(gè)，以提高搜索性能。但這增加了用戶的使用成本，且在時(shí)序場景下，不利于裁剪，需要掃描全部數(shù)據(jù)。我們?cè)?ES 中引入了冷數(shù)據(jù)自動(dòng) Merge，對(duì)于非活躍的索引，底層 Segments 會(huì)自動(dòng) Merge 到接近 5GB，降低文件數(shù)量的同時(shí)，方便時(shí)序場景裁剪。對(duì)于搜索場景，用戶可以調(diào)大目標(biāo) Segment 的大小，使得所有 Segments 最終 Merge 為一個(gè)。我們對(duì) Merge 策略的優(yōu)化，可以使得搜索場景性能提升 1 倍。

前面介紹完畢我們?cè)?ES 內(nèi)核方面的優(yōu)化實(shí)踐，最后我們來簡單分享下我們?cè)陂_源貢獻(xiàn)及未來規(guī)劃方面的思考。

?

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

?

近半年我們向開源社區(qū)提交了 10+PR，涉及到寫入、查詢、集群管理等各個(gè)模塊，部分優(yōu)化是和官方開發(fā)同學(xué)一起來完成的，前面介紹過程中，已經(jīng)給出相應(yīng)的 PR 鏈接，方便大家參考。我們?cè)诠緝?nèi)部也組建了開源協(xié)同的小組，來共建 Elastic 生態(tài)。

總體來說，開源的收益利大于弊，我們把相應(yīng)收益反饋出來，希望更多同學(xué)參與到 Elastic 生態(tài)的開源貢獻(xiàn)中：首先，開源可以降低分支維護(hù)成本，隨著自研的功能越來越多，維護(hù)獨(dú)立分支的成本越來越高，主要體現(xiàn)在與開源版本同步、快速引入開源新特性方面；其次，開源可以幫助研發(fā)同學(xué)更深入的把控內(nèi)核，了解最新技術(shù)動(dòng)態(tài)，因?yàn)樵陂_源反饋的過程中，會(huì)涉及與官方開發(fā)人員持續(xù)的交互。此外，開源有利于建立大家在社區(qū)的技術(shù)影響力，獲得開源社區(qū)的認(rèn)可。最后 Elastic 生態(tài)的快速發(fā)展，有利于業(yè)務(wù)服務(wù)、個(gè)人技術(shù)的發(fā)展，希望大家一起參與進(jìn)來，助力 Elastic 生態(tài)持續(xù)、快速的發(fā)展。

未來規(guī)劃方面，這次分享我們重點(diǎn)介紹了騰訊在 ES 內(nèi)核方面的優(yōu)化實(shí)踐，包含高可用、低成本、高性能等方面。此外，我們也提供了一套管控平臺(tái)，支持線上集群自動(dòng)化管控、運(yùn)維，為騰訊云客戶提供 ES 服務(wù)。但是從線上大量的運(yùn)營經(jīng)驗(yàn)分析，我們發(fā)現(xiàn)仍然有非常豐富、高價(jià)值的方向需要繼續(xù)跟進(jìn)，我們會(huì)持續(xù)繼續(xù)加強(qiáng)對(duì)產(chǎn)品、內(nèi)核的建設(shè)。

長期探索方面，我們結(jié)合大數(shù)據(jù)圖譜來介紹。整個(gè)大數(shù)據(jù)領(lǐng)域，按照數(shù)據(jù)量、延時(shí)要求等特點(diǎn)，可以劃分為三部分：第一部分是 Data Engineering，包含我們熟悉的批量計(jì)算、流式計(jì)算；第二部分是 Data Discovery，包含交互式分析、搜索等；第三個(gè)部分是 Data Apps，主要用于支撐在線服務(wù)。

雖然我們把 ES 放到搜索領(lǐng)域內(nèi)，但是也有很多用戶使用 ES 支持在線搜索、文檔服務(wù)等；另外，我們了解到有不少成熟的 OLAP 系統(tǒng)，也是基于倒排索引、行列混存等技術(shù)棧，所以我們認(rèn)為 ES 未來往這兩個(gè)領(lǐng)域發(fā)展的可行性非常強(qiáng)，我們未來會(huì)在 OLAP 分析和在線服務(wù)等方向進(jìn)行重點(diǎn)探索。

總結(jié)

以上是生活随笔為你收集整理的听腾讯 TEG 大佬谈腾讯万亿级 Elasticsearch 技术解密的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。