Elasticsearch（ES）作為開(kāi)源首選的分布式搜索分析引擎，通過(guò)一套系統(tǒng)輕松滿(mǎn)足用戶(hù)的日志實(shí)時(shí)分析、全文檢索、結(jié)構(gòu)化數(shù)據(jù)分析等多種需求，大幅降低大數(shù)據(jù)時(shí)代挖掘數(shù)據(jù)價(jià)值的成本。騰訊在公司內(nèi)部豐富的場(chǎng)景中大規(guī)模使用 ES，同時(shí)聯(lián)合 Elastic 公司在騰訊云上提供內(nèi)核增強(qiáng)版的 ES 云服務(wù)，大規(guī)模、豐富多樣的的使用場(chǎng)景推動(dòng)著騰訊對(duì)原生 ES 進(jìn)行持續(xù)的高可用、高性能、低成本優(yōu)化。
一、ES 在騰訊的應(yīng)用場(chǎng)景
【ES 在騰訊的應(yīng)用場(chǎng)景】
最初我們使用 ES 于日志實(shí)時(shí)分析場(chǎng)景，典型日志如下：
運(yùn)營(yíng)日志，比如慢日志、異常日志，用來(lái)定位業(yè)務(wù)問(wèn)題；
業(yè)務(wù)日志，比如用戶(hù)的點(diǎn)擊、訪問(wèn)日志，可以用來(lái)分析用戶(hù)行為；
審計(jì)日志，可以用于安全分析。ES 很完美的解決了日志實(shí)時(shí)分析的需求，它具有如下特點(diǎn)：
Elastic 生態(tài)提供了完整的日志解決方案，任何一個(gè)開(kāi)發(fā)、運(yùn)維同學(xué)使用成熟組件，通過(guò)簡(jiǎn)單部署，即可搭建起一個(gè)完整的日志實(shí)時(shí)分析服務(wù)。
在 Elastic 生態(tài)中，日志從產(chǎn)生到可訪問(wèn)一般在 10s 級(jí)。相比于傳統(tǒng)大數(shù)據(jù)解決方案的幾十分鐘、小時(shí)級(jí)，時(shí)效性非常高。
由于支持倒排索引、列存儲(chǔ)等數(shù)據(jù)結(jié)構(gòu)，ES 提供非常靈活的搜索分析能力。
支持交互式分析，即使在萬(wàn)億級(jí)日志的情況下，ES 搜索響應(yīng)時(shí)間也是秒級(jí)。
日志是互聯(lián)網(wǎng)行業(yè)最基礎(chǔ)、最廣泛的數(shù)據(jù)形式，ES 非常完美的解決了日志實(shí)時(shí)分析場(chǎng)景，這也是近幾年 ES 快速發(fā)展的一個(gè)重要原因。
第二類(lèi)使用場(chǎng)景是搜索服務(wù)，典型場(chǎng)景包含：商品搜索，類(lèi)似京東、淘寶、拼多多中的商品搜索；APP 搜索，支持應(yīng)用商店里的應(yīng)用搜索；站內(nèi)搜索，支持論壇、在線文檔等搜索功能。我們支持了大量搜索服務(wù)，它們主要有以下特點(diǎn)：
高性能：?jiǎn)蝹€(gè)服務(wù)最大達(dá)到 10w+ QPS，平響 20ms~，P95 延時(shí)小于 100ms。
強(qiáng)相關(guān)：搜索體驗(yàn)主要取決于搜索結(jié)果是否高度匹配用戶(hù)意圖，需要通過(guò)正確率、召回率等指標(biāo)進(jìn)行評(píng)估。
高可用：搜索場(chǎng)景通常要求 4 個(gè) 9 的可用性，支持單機(jī)房故障容災(zāi)。任何一個(gè)電商服務(wù)，如淘寶、京東、拼多多，只要故障一個(gè)小時(shí)就可以上頭條。
第三類(lèi)使用場(chǎng)景是時(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ù)。這類(lèi)場(chǎng)景騰訊很早就開(kāi)始探索，在這方面積累了非常豐富的經(jīng)驗(yàn)。這類(lèi)場(chǎng)景具有以下特點(diǎn)：
高并發(fā)寫(xiě)入：線上單集群最大規(guī)模達(dá)到 600+節(jié)點(diǎn)、1000w/s 的寫(xiě)入吞吐。
高查詢(xún)性能：要求單條曲線 或者單個(gè)時(shí)間線的查詢(xún)延時(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ī)模、高壓力、豐富使用場(chǎng)景的背景下，我們遇到了很多挑戰(zhàn)，總體可以劃分為兩類(lèi)：搜索類(lèi)和時(shí)序類(lèi)。
首先，我們一起看看搜索類(lèi)業(yè)務(wù)的挑戰(zhàn)。以電商搜索、APP 搜索、站內(nèi)搜索為代表，這類(lèi)業(yè)務(wù)非常重視可用性，服務(wù) SLA 達(dá)到 4 個(gè) 9 以上，需要容忍單機(jī)故障、單機(jī)房網(wǎng)絡(luò)故障等；同時(shí)要求高性能、低毛刺，例如 20w QPS、平響 20ms、P95 延時(shí) 100ms?？傊?，在搜索類(lèi)業(yè)務(wù)場(chǎng)景下，核心挑戰(zhàn)點(diǎn)在于高可用、高性能。
另一類(lèi)我們稱(chēng)之為時(shí)序類(lèi)業(yè)務(wù)挑戰(zhàn)，包含日志、Metrics、APM 等場(chǎng)景。相比于搜索類(lèi)業(yè)務(wù)重點(diǎn)關(guān)注高可用、高性能，時(shí)序類(lèi)業(yè)務(wù)會(huì)更注重成本、性能。比如時(shí)序場(chǎng)景用戶(hù)通常要求高寫(xiě)入吞吐，部分場(chǎng)景可達(dá) 1000w/s
WPS；在這樣寫(xiě)入吞吐下，保留 30 天的數(shù)據(jù)，通?？蛇_(dá)到 PB 級(jí)的存儲(chǔ)量。而現(xiàn)實(shí)是日志、監(jiān)控等場(chǎng)景的收益相對(duì)較低，很可能用戶(hù)用于線上實(shí)際業(yè)務(wù)的機(jī)器數(shù)量才是 100 臺(tái)，而監(jiān)控、日志等需要 50 臺(tái)，這對(duì)多數(shù)用戶(hù)來(lái)說(shuō)，基本是不可接受的。所以在時(shí)序類(lèi)業(yè)務(wù)中，主要的挑戰(zhàn)在于存儲(chǔ)成本、計(jì)算成本等方面。
前面我們介紹了在搜索類(lèi)、時(shí)序類(lèi)業(yè)務(wù)場(chǎng)景下遇到的高可用、低成本、高性能等挑戰(zhàn)，下面針對(duì)這些挑戰(zhàn)，我們重點(diǎn)分享騰訊在 ES 內(nèi)核方面的深入實(shí)踐。
三、ES 優(yōu)化實(shí)踐
首先，我們來(lái)看看高可用優(yōu)化，我們把高可用劃分為三個(gè)維度：
系統(tǒng)健壯性：是指 ES 內(nèi)核自身的健壯性，也是分布式系統(tǒng)面臨的共性難題。例如，在異常查詢(xún)、壓力過(guò)載下集群的容錯(cuò)能力；在高壓力場(chǎng)景下，集群的可擴(kuò)展性；在集群擴(kuò)容、節(jié)點(diǎn)異常場(chǎng)景下，節(jié)點(diǎn)、多硬盤(pán)之間的數(shù)據(jù)均衡能力。
容災(zāi)方案：如果通過(guò)管控系統(tǒng)建設(shè)，保障機(jī)房網(wǎng)絡(luò)故障時(shí)快速恢復(fù)服務(wù)，自然災(zāi)害下防止數(shù)據(jù)丟失，誤操作后快速恢復(fù)等。
系統(tǒng)缺陷：這在任何系統(tǒng)發(fā)展過(guò)程中都會(huì)持續(xù)產(chǎn)生，比如說(shuō) Master 節(jié)點(diǎn)堵塞、分布式死鎖、滾動(dòng)重啟緩慢等。
針對(duì)上述問(wèn)題，下面來(lái)介紹我們?cè)诟呖捎梅矫娴慕鉀Q方案：
系統(tǒng)健壯性方面，我們通過(guò)服務(wù)限流，容忍機(jī)器網(wǎng)絡(luò)故障、異常查詢(xún)等導(dǎo)致的服務(wù)不穩(wěn)定，后面展開(kāi)介紹。通過(guò)優(yōu)化集群元數(shù)據(jù)管控邏輯，提升集群擴(kuò)展能力一個(gè)數(shù)量級(jí)，支持千級(jí)節(jié)點(diǎn)集群、百萬(wàn)分片，解決集群可擴(kuò)展性問(wèn)題；集群均衡方面，通過(guò)優(yōu)化節(jié)點(diǎn)、多硬盤(pán)間的分片均衡，保證大規(guī)模集群的壓力均衡。
容災(zāi)方案方面，我們通過(guò)擴(kuò)展 ES 的插件機(jī)制支持備份回檔，把 ES 的數(shù)據(jù)備份回檔到廉價(jià)存儲(chǔ)，保證數(shù)據(jù)的可恢復(fù)；支持跨可用區(qū)容災(zāi)，用戶(hù)可以按需部署多個(gè)可用區(qū)，以容忍單機(jī)房故障。垃圾桶機(jī)制，保證用戶(hù)在欠費(fèi)、誤操作等場(chǎng)景下，集群可快速恢復(fù)。
系統(tǒng)缺陷方面，我們修復(fù)了滾動(dòng)重啟、Master 阻塞、分布式死鎖等一系列 Bug。其中滾動(dòng)重啟優(yōu)化，可加速節(jié)點(diǎn)重啟速度 5+倍，具體可參考 PR ES-46520；Master 堵塞問(wèn)題，我們?cè)?ES 6.x 版本和官方一起做了優(yōu)化。
這里我們展開(kāi)介紹下服務(wù)限流部分。我們做了 4 個(gè)層級(jí)的限流工作：權(quán)限層級(jí)，我們支持 XPack 和自研權(quán)限來(lái)防止攻擊、誤操作；隊(duì)列層級(jí)，通過(guò)優(yōu)化任務(wù)執(zhí)行速度、重復(fù)、優(yōu)先級(jí)等問(wèn)題，解決用戶(hù)常遇到的 Master 任務(wù)隊(duì)列堆積、任務(wù)餓死等問(wèn)題；內(nèi)存層級(jí)，我們從 ES 6.x 開(kāi)始，支持在 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)控制；多租戶(hù)層級(jí)，我們使用 CVM/Cgroups 方案保證多租戶(hù)間的資源隔離。
這里詳細(xì)介紹下聚合場(chǎng)景限流問(wèn)題，用戶(hù)在使用 ES 進(jìn)行聚合分析時(shí)，經(jīng)常遇到因聚合分桶過(guò)多打爆內(nèi)存的問(wèn)題。官方在 ES 6.8 中提供 max_buckets 參數(shù)控制聚合的最大分桶數(shù)，但這個(gè)方式局限性非常強(qiáng)。在某些場(chǎng)景下，用戶(hù)設(shè)置 20 萬(wàn)個(gè)分桶可以正常工作，但在另一些場(chǎng)景下，可能 10 萬(wàn)個(gè)分桶內(nèi)存就已經(jīng)打爆，這主要取決于單分桶的大小，用戶(hù)并不能準(zhǔn)確把握該參數(shù)設(shè)置為多少比較合適。我們?cè)诰酆戏治龅倪^(guò)程中，采用梯度算法進(jìn)行優(yōu)化，每分配 1000 個(gè)分桶檢查一次 JVM 內(nèi)存，當(dāng)內(nèi)存不足時(shí)及時(shí)中斷請(qǐng)求，保證 ES 集群的高可用。具體可參考 PR ES-46751 /47806。
我們當(dāng)前的限流方案，能夠大幅提升在異常查詢(xún)、壓力過(guò)載、單節(jié)點(diǎn)故障、網(wǎng)絡(luò)分區(qū)等場(chǎng)景下，ES 服務(wù)的穩(wěn)定性問(wèn)題。但還有少量場(chǎng)景沒(méi)有覆蓋完全，所以我們目前也在引入混沌測(cè)試，依賴(lài)混沌測(cè)試來(lái)覆蓋更多異常場(chǎng)景。
前面我們介紹了高可用解決方案，下面我們來(lái)介紹成本方面的優(yōu)化實(shí)踐。成本方面的挑戰(zhàn)，主要體現(xiàn)在以日志、監(jiān)控為代表的時(shí)序場(chǎng)景對(duì)機(jī)器資源的消耗，我們對(duì)線上典型的日志、時(shí)序業(yè)務(wù)進(jìn)行分析，總體來(lái)看，硬盤(pán)、內(nèi)存、計(jì)算資源的成本比例接近 8:4:1，硬盤(pán)、內(nèi)存是主要矛盾，其次是計(jì)算成本。
而對(duì)時(shí)序類(lèi)場(chǎng)景進(jìn)行分析，可以發(fā)現(xiàn)時(shí)序數(shù)據(jù)有很明顯的訪問(wèn)特性。一是冷熱特性，時(shí)序數(shù)據(jù)訪問(wèn)具有近多遠(yuǎn)少的特點(diǎn)，最近 7 天數(shù)據(jù)的訪問(wèn)量占比可達(dá)到 95%以上；歷史數(shù)據(jù)訪問(wèn)較少，且通常都是訪問(wèn)統(tǒng)計(jì)類(lèi)信息。
基于這些瓶頸分析和數(shù)據(jù)訪問(wèn)特性，我們來(lái)介紹成本優(yōu)化的解決方案。
硬盤(pán)成本方面，由于數(shù)據(jù)具有明顯的冷熱特性，首先我們采用冷熱分離架構(gòu)，使用混合存儲(chǔ)的方案來(lái)平衡成本、性能；其次，既然對(duì)歷史數(shù)據(jù)通常都是訪問(wèn)統(tǒng)計(jì)信息，那么以通過(guò)預(yù)計(jì)算來(lái)?yè)Q取存儲(chǔ)和性能，后面會(huì)展開(kāi)介紹；如果歷史數(shù)據(jù)完全不使用，也可以備份到更廉價(jià)的存儲(chǔ)系統(tǒng)；其他一些優(yōu)化方式包含存儲(chǔ)裁剪、生命周期管理等。
內(nèi)存成本方面，很多用戶(hù)在使用大存儲(chǔ)機(jī)型時(shí)會(huì)發(fā)現(xiàn)，存儲(chǔ)資源才用了百分之二十，內(nèi)存已經(jīng)不足。其實(shí)基于時(shí)序數(shù)據(jù)的訪問(wèn)特性，我們可以利用 Cache 進(jìn)行優(yōu)化，后面會(huì)展開(kāi)介紹。
我們展開(kāi)介紹下 Rollup 部分。官方從 ES 6.x 開(kāi)始推出 Rollup，實(shí)際上騰訊在 5.x 已經(jīng)開(kāi)始這部分的實(shí)踐。Rollup 類(lèi)似于大數(shù)據(jù)場(chǎng)景下的 Cube、物化視圖，它的核心思想是通過(guò)預(yù)計(jì)算提前生成統(tǒng)計(jì)信息，釋放掉原始粒度數(shù)據(jù)，從而降低存儲(chǔ)成本、提高查詢(xún)性能，通常會(huì)有數(shù)據(jù)級(jí)的收益。這里舉個(gè)簡(jiǎn)單的例子，比如在機(jī)器監(jiān)控場(chǎng)景下，原始粒度的監(jiān)控?cái)?shù)據(jù)是 10 秒級(jí)的，而一個(gè)月之前的監(jiān)控?cái)?shù)據(jù)，一般只需要查看小時(shí)粒度，這即是一個(gè) Rollup 應(yīng)用場(chǎng)景。
在大數(shù)據(jù)領(lǐng)域，傳統(tǒng)的方案是依賴(lài)外部離線計(jì)算系統(tǒng)，周期性的讀取全量數(shù)據(jù)進(jìn)行計(jì)算，這種方式計(jì)算開(kāi)銷(xiāo)、維護(hù)成本高。谷歌的廣告指標(biāo)系統(tǒng) Mesa 采用持續(xù)生成方案，數(shù)據(jù)寫(xiě)入時(shí)系統(tǒng)給每個(gè) Rollup 產(chǎn)生一份輸入數(shù)據(jù)，并對(duì)數(shù)據(jù)進(jìn)行排序，底層在 Compact/Merge 過(guò)程中通過(guò)多路歸并完成 Rollup，這種方式的計(jì)算、維護(hù)成本相對(duì)較低。ES 從 6.x 開(kāi)始支持?jǐn)?shù)據(jù)排序，我們通過(guò)流式查詢(xún)進(jìn)行多路歸并生成 Rollup，最終計(jì)算開(kāi)銷(xiāo)小于全量數(shù)據(jù)寫(xiě)入時(shí) CPU 開(kāi)銷(xiāo)的 10%，內(nèi)存使用小于 10MB。我們已反饋內(nèi)核優(yōu)化至開(kāi)源社區(qū)，解決開(kāi)源 Rollup 的計(jì)算、內(nèi)存瓶頸，具體可參考 PR ES-48399。
接下來(lái)，我們展開(kāi)介紹內(nèi)存優(yōu)化部分。前面提到很多用戶(hù)在使用大存儲(chǔ)機(jī)型時(shí)，內(nèi)存優(yōu)先成為瓶頸、硬盤(pán)不能充分利用的問(wèn)題，主要瓶頸在于索引占用大量?jī)?nèi)存。但是我們知道時(shí)序類(lèi)場(chǎng)景對(duì)歷史數(shù)據(jù)訪問(wèn)很少，部分場(chǎng)景下某些字段基本不使用，所我們可以通過(guò)引入 Cache 來(lái)提高內(nèi)存利用效率。
在內(nèi)存優(yōu)化方面，業(yè)界的方案是什么樣的呢？ES 社區(qū)從 7.x 后支持索引放于堆外，和 DocValue 一樣按需加載。但這種方式不好的地方在于索引和數(shù)據(jù)的重要性完全不同，一個(gè)大查詢(xún)很容易導(dǎo)致索引被淘汰，后續(xù)查詢(xún)性能倍數(shù)級(jí)的衰減。Hbase 通過(guò)緩存 Cache 緩存索引、數(shù)據(jù)塊，提升熱數(shù)據(jù)訪問(wèn)性能，并且從 HBase 2.0 開(kāi)始，重點(diǎn)介紹其 Off Heap 技術(shù)，重點(diǎn)在于堆外內(nèi)存的訪問(wèn)性能可接近堆內(nèi)。我們基于社區(qū)經(jīng)驗(yàn)進(jìn)行迭代，在 ES 中引入 LFU Cache 以提高內(nèi)存的利用效率，把 Cache 放置在堆外以降低堆內(nèi)存壓力，同時(shí)通過(guò) Weak Reference、減少堆內(nèi)外拷貝等技術(shù)降低損耗。最終效果是內(nèi)存利用率提升 80%，可以充分利用大存儲(chǔ)機(jī)型，查詢(xún)性能損耗不超過(guò) 2%，GC 開(kāi)銷(xiāo)降低 30%。
前面我們介紹了可用性、成本優(yōu)化的解決方案，最后我們來(lái)介紹性能方面的優(yōu)化實(shí)踐。以日志、監(jiān)控為代表的時(shí)序場(chǎng)景，對(duì)寫(xiě)入性能要求非常高，寫(xiě)入并發(fā)可達(dá) 1000w/s。然而我們發(fā)現(xiàn)在帶主鍵寫(xiě)入時(shí)，ES 性能衰減 1+倍，部分壓測(cè)場(chǎng)景下，CPU 無(wú)法充分利用。以搜索服務(wù)為代表的場(chǎng)景，對(duì)查詢(xún)性的要求非常高，要求 20w QPS, 平響 20ms，而且盡量避免 GC、執(zhí)行計(jì)劃不優(yōu)等造成的查詢(xún)毛刺。
針對(duì)上述問(wèn)題，我們介紹下騰訊在性能方面的優(yōu)化實(shí)踐：
寫(xiě)入方面，針對(duì)主鍵去重場(chǎng)景，通過(guò)利用索引進(jìn)行裁剪，加速主鍵去重的過(guò)程，寫(xiě)入性能提升 45%，具體可參考 PR
Lucene-8980。對(duì)于部分壓測(cè)場(chǎng)景下 CPU 不能充分利用的問(wèn)題，通過(guò)優(yōu)化 ES 刷新 Translog 時(shí)的資源搶占，提升性能提升 20%，具體可參考 PR ES-45765 /47790。我們正在嘗試通過(guò)向量化執(zhí)行優(yōu)化寫(xiě)入性能，通過(guò)減少分支跳轉(zhuǎn)、指令 Miss，預(yù)期寫(xiě)入性能可提升 1 倍。
查詢(xún)方面，我們通過(guò)優(yōu)化 Merge 策略，提升查詢(xún)性能，這部分稍后展開(kāi)介紹。基于每個(gè) Segment 記錄的 min/max 索引，進(jìn)行查詢(xún)剪枝，提升查詢(xún)性能 30%。通過(guò) CBO 策略，避免查詢(xún) Cache 操作導(dǎo)致查詢(xún)耗時(shí) 10+倍的毛刺，具體可參考Lucene-9002。此外，我們也在嘗試通過(guò)一些新硬件來(lái)優(yōu)化性能，比如說(shuō)英特爾的 AEP、Optane、QAT 等。
接下來(lái)我們展開(kāi)介紹下 Merge 策略?xún)?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)用戶(hù)查詢(xún) 3 月 1 號(hào)某小時(shí)的數(shù)據(jù)時(shí)，就必須掃描大量無(wú)用數(shù)據(jù)，性能損耗嚴(yán)重。
我們?cè)?ES 中引入了時(shí)序 Merge，在選擇 Segments 進(jìn)行 Merge 時(shí)，重點(diǎn)考慮時(shí)間因素，這樣時(shí)間相近的 Segments 被 Merge 到一起。當(dāng)我們查詢(xún) 3 月 1 號(hào)的數(shù)據(jù)時(shí)，只需要掃描個(gè)別較小的 Segments 就好，其他的 Segments 可以快速裁剪掉。
另外，ES 官方推薦搜索類(lèi)用戶(hù)在寫(xiě)入完成之后，進(jìn)行一次 Force Merge，用意是把所有 Segments 合并為一個(gè)，以提高搜索性能。但這增加了用戶(hù)的使用成本，且在時(shí)序場(chǎng)景下，不利于裁剪，需要掃描全部數(shù)據(jù)。我們?cè)?ES 中引入了冷數(shù)據(jù)自動(dòng) Merge，對(duì)于非活躍的索引，底層 Segments 會(huì)自動(dòng) Merge 到接近 5GB，降低文件數(shù)量的同時(shí)，方便時(shí)序場(chǎng)景裁剪。對(duì)于搜索場(chǎng)景，用戶(hù)可以調(diào)大目標(biāo) Segment 的大小，使得所有 Segments 最終 Merge 為一個(gè)。我們對(duì) Merge 策略的優(yōu)化，可以使得搜索場(chǎng)景性能提升 1 倍。
前面介紹完畢我們?cè)?ES 內(nèi)核方面的優(yōu)化實(shí)踐，最后我們來(lái)簡(jiǎn)單分享下我們?cè)陂_(kāi)源貢獻(xiàn)及未來(lái)規(guī)劃方面的思考。
四、未來(lái)規(guī)劃及開(kāi)源貢獻(xiàn)
近半年我們向開(kāi)源社區(qū)提交了 10+PR，涉及到寫(xiě)入、查詢(xún)、集群管理等各個(gè)模塊，部分優(yōu)化是和官方開(kāi)發(fā)同學(xué)一起來(lái)完成的，前面介紹過(guò)程中，已經(jīng)給出相應(yīng)的 PR 鏈接，方便大家參考。我們?cè)诠緝?nèi)部也組建了開(kāi)源協(xié)同的小組，來(lái)共建 Elastic 生態(tài)。
總體來(lái)說(shuō)，開(kāi)源的收益利大于弊，我們把相應(yīng)收益反饋出來(lái)，希望更多同學(xué)參與到 Elastic 生態(tài)的開(kāi)源貢獻(xiàn)中：首先，開(kāi)源可以降低分支維護(hù)成本，隨著自研的功能越來(lái)越多，維護(hù)獨(dú)立分支的成本越來(lái)越高，主要體現(xiàn)在與開(kāi)源版本同步、快速引入開(kāi)源新特性方面；其次，開(kāi)源可以幫助研發(fā)同學(xué)更深入的把控內(nèi)核，了解最新技術(shù)動(dòng)態(tài)，因?yàn)樵陂_(kāi)源反饋的過(guò)程中，會(huì)涉及與官方開(kāi)發(fā)人員持續(xù)的交互。此外，開(kāi)源有利于建立大家在社區(qū)的技術(shù)影響力，獲得開(kāi)源社區(qū)的認(rèn)可。最后 Elastic 生態(tài)的快速發(fā)展，有利于業(yè)務(wù)服務(wù)、個(gè)人技術(shù)的發(fā)展，希望大家一起參與進(jìn)來(lái)，助力 Elastic 生態(tài)持續(xù)、快速的發(fā)展。
未來(lái)規(guī)劃方面，這次分享我們重點(diǎn)介紹了騰訊在 ES 內(nèi)核方面的優(yōu)化實(shí)踐，包含高可用、低成本、高性能等方面。此外，我們也提供了一套管控平臺(tái)，支持線上集群自動(dòng)化管控、運(yùn)維，為騰訊云客戶(hù)提供 ES 服務(wù)。但是從線上大量的運(yùn)營(yíng)經(jīng)驗(yàn)分析，我們發(fā)現(xiàn)仍然有非常豐富、高價(jià)值的方向需要繼續(xù)跟進(jìn)，我們會(huì)持續(xù)繼續(xù)加強(qiáng)對(duì)產(chǎn)品、內(nèi)核的建設(shè)。
長(zhǎng)期探索方面，我們結(jié)合大數(shù)據(jù)圖譜來(lái)介紹。整個(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)，但是也有很多用戶(hù)使用 ES 支持在線搜索、文檔服務(wù)等；另外，我們了解到有不少成熟的 OLAP 系統(tǒng)，也是基于倒排索引、行列混存等技術(shù)棧，所以我們認(rèn)為 ES 未來(lái)往這兩個(gè)領(lǐng)域發(fā)展的可行性非常強(qiáng)，我們未來(lái)會(huì)在 OLAP 分析和在線服務(wù)等方向進(jìn)行重點(diǎn)探索。
