2019 年 1 月到 2019 年 7 月，滴滴 ElasticSearch 團(tuán)隊(Arius)將維護(hù)國內(nèi)的 30 多個 ES 集群，2000 多個 ES 節(jié)點，4PB 的數(shù)據(jù)，從 2.3.3 跨大版本無縫升級到 6.6.1。

[[322032]]
圖片來自 Pexels

在對用戶查詢寫入基本零影響和改動的前提下，解決了 ES 跨大版本協(xié)議不兼容、Mapping 不兼容等業(yè)內(nèi)難題，整個過程對絕大部分用戶完全透明。

團(tuán)隊同學(xué)經(jīng)過 7 個月的奮斗，完成 ES 版本升級的過程中，也完成了滴滴 ElasticSearch 平臺的架構(gòu)升級。

取得了單機(jī)查詢性能提升 40%，整體集群 CPU 下降 10%，寫入 TPS 提升 30%，歸還物理機(jī)近 400 臺，成本節(jié)約 80W /月、0 故障的成績，并在引擎上向社區(qū)貢獻(xiàn)了 4 個 PR，一位同學(xué)升級為 ES Contributor。

如此大規(guī)模的跨大版本升級，在 ES 業(yè)內(nèi)也很少見，從開始準(zhǔn)備到實際執(zhí)行，遇到了很多困難，踩了一些坑，期間也有很多我們的思考。

為此我們準(zhǔn)備本期的總結(jié)和分享，主要從以下幾個方面展開：

• 背景：推石頭的西西弗斯
• 困難：拔劍四顧心茫然
• 思考：天生我材必有用
• 實戰(zhàn)：百戰(zhàn)沙場碎鐵衣
• 收益：長風(fēng)破浪會有時
• 展望：直掛云帆濟(jì)滄海

背景：推石頭的西西弗斯

滴滴 ElasticSearch 團(tuán)隊從 2016 年開始建設(shè) ElasticSearch 平臺，在 2016 年 6 月份的時候開始對外提供服務(wù)，當(dāng)時選擇了 ElasticSearch 最新的 2.3 版本。

如今三年過去了，ElasticSearch 生態(tài)經(jīng)歷了飛速的增長，Elastic 公司完成了上市，ElasticSearch 在 db-engines 的分?jǐn)?shù)從 88 上漲到 148，排名從 11 名上升到第 7 名。

這期間 ES 發(fā)布了 3 個大版本，幾十個中版本，而最近 ElasticSearch 已經(jīng)發(fā)布了 7.x 版本。

在這三年中滴滴 Elasticsearch 平臺基于 ElasticSearch 推出了日志檢索、MySQL 實時數(shù)據(jù)庫快照、分布式文檔數(shù)據(jù)庫、搜索引擎等四大服務(wù)，四大業(yè)務(wù)均快速發(fā)展。

目前滴滴 ElasticSearch 平臺服務(wù)了集團(tuán)里面 1200 個應(yīng)用，其中：訂單、客服、金融、把脈、新政等業(yè)務(wù)核心實時場景也運(yùn)行在 Elasticsearch 之上，運(yùn)維 ES 集群 30+，寫入 TPS 峰值到達(dá) 1500W，查詢 QPS 達(dá)到 2W。

業(yè)務(wù)的快速發(fā)展既是滴滴 ElasticSearch 團(tuán)隊工作的肯定，但隨之而來也有巨大的挑戰(zhàn)和壓力，其中版本過低是未來 ElasticSearch 平臺發(fā)展最大制約因素，其中主要有以下幾點。

①社區(qū)不再維護(hù)老版本：ElasticSearch 2.3.3 版本過于陳舊，ES 社區(qū)早已不再進(jìn)行維護(hù)，在 2.x 上遇到的問題社區(qū)不解決，提交的 issue 也不處理，提交代碼也不被接收。

基于 2.3.3 我們也解決了很多 ES 自身的問題，如：Master 更新元數(shù)據(jù)超時導(dǎo)致內(nèi)存泄露、TCP 協(xié)議字段溢出等。

由于無法和社區(qū)互動，團(tuán)隊同學(xué)的價值也得不到社區(qū)的認(rèn)可，長此以往只會和 ES 生態(tài)越來越遠(yuǎn)，我們在 ES 技術(shù)圈中的聲音也會越來越弱。

②新版本特性很難被使用：最近 3 年是 ES 生態(tài)大發(fā)展的 3 年，ES 自身在功能、性能上都有非常大提升。

如：默認(rèn)使用 BM25 評分算法，效果更佳;lucene docvalues 稀疏區(qū)域改進(jìn)，更節(jié)約磁盤空間;新增 Frozen indices 能力，可以顯著降低 ES 內(nèi)存開銷。

很多特性也非常適合 ElasticSearch 平臺的場景，但是版本差距過大一直制約著我們，無法享受技術(shù)進(jìn)步的紅利。

一邊是業(yè)務(wù)快速發(fā)展要求更豐富的功能、更強(qiáng)大的性能、更低的成本、更穩(wěn)定的服務(wù);一邊離最新的業(yè)內(nèi)技術(shù)越來越遠(yuǎn)，團(tuán)隊價值越來越弱，逐漸淪為一支只能做業(yè)務(wù)的偽引擎團(tuán)隊，整個團(tuán)隊的現(xiàn)狀就如同推石頭的西西弗斯。

要么我們迎難而上，克服困難，一口氣把整個集群升級到最新的版本，把石頭推過山頂，再輕裝前行;要么就是繼續(xù)獨(dú)自勉力支撐，在業(yè)務(wù)和引擎的雙重壓力下蹣跚而行。

滴滴 ElasticSearch 團(tuán)隊最終選擇對滴滴 ElasticSearch 平臺進(jìn)行重構(gòu)并將維護(hù)的所有 ES 集群升級到最新版本。

困難：拔劍四顧心茫然

理想很豐滿，現(xiàn)實很骨感，下決心很容易，然而實際執(zhí)行很困難：

• 2.3.3 和 6.6.1 協(xié)議不兼容啊，6.6.1 都不支持 TCP 協(xié)議了，那些通過 TCP 查的用戶怎么辦，讓他們一個一個改代碼，那要改到什么時候?
• 2.3.3 和 6.6.1 有些返回的字段都不一樣了，有些查詢語法也不兼容，怎么做到對用戶的透明，還是直接強(qiáng)迫用戶接受改變?
• 2.3.3 和 6.6.1 lucene 文件格式都不一樣，沒辦法原地直接升級，要再搞個集群全部雙寫一遍。
• 2.3.3 和 6.6.1 的 Mapping 格式不統(tǒng)一，6.6.1 不支持多 type，現(xiàn)有的那些數(shù)據(jù)搬遷都沒辦法搬。
• 滴滴 ElasticSearch 平臺現(xiàn)在不支持索引多版本同時查詢，用戶查詢習(xí)慣也千奇百怪，很多帶*查詢你根本控制不了。
• 用戶那么多，使用差異很大，怎么和用戶進(jìn)行溝通和宣導(dǎo)，怎么屏蔽用戶影響和管理用于預(yù)期?
• 就算是要搬遷升級，哪里去找那么多機(jī)器，現(xiàn)在還要機(jī)房裁撤，還要往外拿機(jī)器。
• 幾十個集群，幾千個節(jié)點都要部署、搭建、重啟，還要騰挪上千臺機(jī)器。慢點搞，這得搞到什么時候，快點搞，萬一出問題怎么辦?
• 就算是雙寫升級了，怎么知道中間有沒有問題，數(shù)據(jù)有沒有丟失，用戶的查詢是不是一致的，功能和性能有沒有達(dá)到預(yù)期，這個怎么驗證?
• 這么多數(shù)據(jù)，這么多人在用，這么點資源，業(yè)務(wù)穩(wěn)定壓力又大，估計今年一年都搞不完。
• …………

在剛開始決定進(jìn)行跨版本升級之后，我們面臨的問題就撲面而來，其中任何一條不解決，都會極大的阻礙升級的進(jìn)程。

思考：天生我材必有用

在起步階段有很多問題雜糅在一起，需要理清楚每個問題的重要性、緊急程度、影響層面、相互依賴關(guān)系，通過分析歸納我們將其總結(jié)為四大問題域：

在對問題域進(jìn)行歸總之后，我們討論了具體的實施方案和步驟，將其歸納以下四個可以實際推進(jìn)的環(huán)節(jié)：

首先進(jìn)行架構(gòu)升級：解決引擎?zhèn)?2.x/6.x 的不兼容問題，所有的協(xié)議、查詢語法、Mapping 等不兼容處理在平臺側(cè)進(jìn)行處理。

同時我們開發(fā)了一個 ES java SDK 用來解決 6.x 不支持 TCP 接口的問題，使用方式和原有的 es java client 完全一致，用戶只要修改 pom 即可。

具體包括：Arius 平臺多版本支持、Gateway 的多版本兼容、用戶 SDK 開發(fā)、AMS 數(shù)據(jù)采集等，具體見后續(xù)詳細(xì)說明。

其次解決運(yùn)維問題：解決運(yùn)維操作過程中多集群搭建、部署、重啟的管控問題，提升操作的便利性，提升升級的操作效率，具體見后續(xù)詳細(xì)說明。

再次解決資源問題：解決搬遷升級所需要的大量機(jī)器資源問題，為大量集群升級做充足準(zhǔn)備，同時還要滿足機(jī)房裁撤歸還機(jī)器的要求。

具體包括：索引存儲周期優(yōu)化、冷熱數(shù)據(jù)分離、Mapping 優(yōu)化、fastIndex 等，具體見后續(xù)詳細(xì)說明。

最后開始實際推進(jìn)：在做好前期的所有準(zhǔn)備工作之后，開始實際推進(jìn)升級過程。具體包括：性能壓測、資源評估、批量雙寫、查詢回放，其中還有一些意想不到的采坑和填坑的過程，具體見后續(xù)詳細(xì)說明。

實戰(zhàn)：白沙戰(zhàn)場碎鐵衣

在理清了整個升級過程中的各個環(huán)節(jié)的依賴關(guān)系、資源消耗、瓶頸點之后，針對架構(gòu)、資源、實操等三個方面的問題，我們都設(shè)計了對應(yīng)的解決方案，主要如下：

架構(gòu)

①滴滴 ElasticSearch 平臺 ES 多版本支持的架構(gòu)改造

首先我們在滴滴 ElasticSearch 平臺上完成了 ES 多版本支持的架構(gòu)升級，其中重點有：

• Arius Gateway 對跨版本查詢差異的兼容，以及多集群下索引跨高低版本集群訪問，使得在升級過程中對用戶查詢結(jié)果透明。
• Elasticsearch-didi-interanl-client SDK 開發(fā)，對用戶屏蔽 ES TCP/HTTP 查詢差異，解決 ES 6.x 版本不支持 TCP 接口的問題，原有 2.x 的用戶只要修改一行 pom 就可以切換到高版本訪問。
• 滴滴 ElasticSearch 平臺架構(gòu)梳理以及 Arius admin 多版本支持。

②基于彈性云的 ES 多集群管控方案

目前滴滴 ElasticSearch 團(tuán)隊運(yùn)維 30 多個 ES 集群，5000+ 的 ES 節(jié)點，集群規(guī)模大，場景復(fù)雜，運(yùn)維管控成本比較高。

為此我們設(shè)計開發(fā)了 ECM(ElasticSearch Cluster Manager)系統(tǒng)用于 ES 集群的部署、重啟、擴(kuò)容、配置管控等一系列操作。

并且我們 80% 的 ES 節(jié)點運(yùn)行在彈性云上，結(jié)合彈性云靈活高效的特點，使得我們在進(jìn)行搬遷升級的過程更加高效。

③ES 服務(wù)元數(shù)據(jù)體系建設(shè)

我們構(gòu)建了一套 AMS(Arius MetaData Service)服務(wù)，用于采集和分析 ES 所有集群、節(jié)點、索引的各種數(shù)據(jù)。

包括：容量信息(集群、節(jié)點、模板、索引、租戶)、TPS/QPS 信息(集群、節(jié)點、模板、索引、租戶)、運(yùn)行信息、查詢語句、查詢模板信息、查詢結(jié)果和命中率的分析信息等等。

在這些基礎(chǔ)的指標(biāo)數(shù)據(jù)基礎(chǔ)上，我們構(gòu)建了全面的 ES 運(yùn)行指標(biāo)系統(tǒng)，可以全面的了解和監(jiān)控集群、節(jié)點、索引、租戶級別的運(yùn)行信息。

詳盡的數(shù)據(jù)為后續(xù)的 ES 的成本優(yōu)化提供了基礎(chǔ)，具體見 —— 基于數(shù)據(jù)驅(qū)動的 ES 分級存儲體系，分級存儲體系的構(gòu)建使得我們構(gòu)建了一套體系化的ES成本節(jié)約的系統(tǒng)。

詳盡的數(shù)據(jù)為后續(xù)升級時做查詢的流量回放對比提供了基礎(chǔ)，具體見——基于 ES 服務(wù)元數(shù)據(jù)的查詢流量回放對比系統(tǒng)，使得我們在升級過程中可以快速驗證升級結(jié)果，提升升級效率和穩(wěn)定性。

同時 AMS 還對數(shù)據(jù)的可靠性負(fù)責(zé)，保證產(chǎn)生的數(shù)據(jù)是及時并且準(zhǔn)確的，這樣依賴 AMS 的數(shù)據(jù)分析服務(wù)。

如：分級存儲、容量規(guī)劃、回放系統(tǒng)、成本賬單、集群健康檢查、索引健康分等，只用專注自身的邏輯的實現(xiàn)即可。

資源

在解決架構(gòu)和兼容性問題之后，我們已經(jīng)有信心將一個集群在線升級到新版本。

然而由于版本跨度太大無法在原集群上直接進(jìn)行滾動升級，必須要進(jìn)行數(shù)據(jù)雙寫的搬遷升級，這樣升級所需要的 buff 資源就成為制約整個升級進(jìn)度最重要的因素，因此接下來我們把精力放在節(jié)省資源提高資源利用率上。

通過內(nèi)外挖潛和技術(shù)改造，不僅支持了版本升級所需要的機(jī)器資源(高峰時 3 個集群同時升級)，最終還歸還了近 400 臺機(jī)器，節(jié)約成本 80W+ /月。

①基于數(shù)據(jù)驅(qū)動的 ES 分級存儲體系

基于 AMS 對應(yīng)索引的大小、數(shù)據(jù)量、查詢量、查詢條件、查詢時間、返回結(jié)果的統(tǒng)計和分析，我們能精確的分析出來每個索引被使用的場景以及被查詢的方式。

如：索引的高頻查詢時間區(qū)間、索引被檢索的字段等，在數(shù)據(jù)分析基礎(chǔ)上我們針對每個索引進(jìn)行了 Mapping 優(yōu)化、存儲周期優(yōu)化、冷熱數(shù)據(jù)存儲優(yōu)化。

在不影響用戶使用需求的前提下，累計節(jié)省數(shù)據(jù) 1PB，搬遷冷數(shù)據(jù) 700TB，不僅保障了升級過程中有充足的 buff 機(jī)器，還歸還了近 400 臺物理機(jī)，節(jié)省成本 70W+ /月。

②ES FastIndex 離線數(shù)據(jù)導(dǎo)入體系

ES FastIndex 的初衷是為了解決集團(tuán)標(biāo)簽系統(tǒng)的離線導(dǎo)入的效率和資源問題，集團(tuán)標(biāo)簽系統(tǒng)每天有 30 多 TB 的數(shù)據(jù)需要在短時間內(nèi)同步到 ES 中，否則將會影響當(dāng)天的業(yè)務(wù)結(jié)果，之前方案為了滿足效率采用了大量的機(jī)器資源。

采用基于 Hadoop 的 ES fastIndex 離線數(shù)據(jù)導(dǎo)入系統(tǒng)之后，同樣的數(shù)據(jù)導(dǎo)入時間由原來的 8 個小時下降到 2 個小時。

機(jī)器成本由原來的 40 臺物理機(jī) (ES 27 臺、Kafka 3 臺、Dsink 10 臺) 下降到 30 臺彈性云節(jié)點(10 臺物理機(jī))，單單在標(biāo)簽場景就節(jié)約成本 7W+ 每月。

③基于資源 Quota 管控的 ES 集群容量規(guī)劃方案

提升 ES 集群資源使用率也是滴滴 ElasticSearch 團(tuán)隊一直面臨和致力于解決的問題。

滴滴 ElasticSearch 團(tuán)隊維護(hù)的 ES 機(jī)器總?cè)萘繉⒔?5PB，提升 10% 的資源使用率即可節(jié)約 500TB 的空間，或者用于歸還機(jī)器，或者用于服務(wù)新的需求。

當(dāng)前 ES 集群整體磁盤使用率在 50% 左右，高峰期曾經(jīng)達(dá)到 60%，日志集群磁盤使用率達(dá)到 69.5% (2019.05.01)，但是這個時候集群資源非常不均，磁盤告警也很嚴(yán)重，運(yùn)維壓力非常大，偶爾還會出現(xiàn)丟數(shù)據(jù)的問題。

為此我們在原有的 ES 機(jī)器容量規(guī)劃算法上，加入了資源 Qutoa 管控，并深入引擎，在引擎層面完善 ES 節(jié)點的容量規(guī)劃和資源均勻，期望將 ES 集群的磁盤整體使用率再提升 10%，日均達(dá)到 60%，高峰達(dá)到 70%，并且沒有磁盤告警和穩(wěn)定性問題。

實操

在前期準(zhǔn)備工作都完成之后，集群升級就成為一個按部就班的過程，雖然期間也遇到了一些意想不到的情況，踩了一些坑，但整體的過程還是進(jìn)行的比較順利。

①基于 ES 服務(wù)元數(shù)據(jù)的查詢流量回放對比系統(tǒng)

在前期構(gòu)建的 AMS(Arius Meta Service)系統(tǒng)上，我們對用戶查詢條件、查詢結(jié)果進(jìn)行記錄和分析。

在雙寫搬遷升級過程中，我們將用戶的查詢條件分別在高低版本的集群上進(jìn)行回放，將查詢返回的結(jié)果、性能參數(shù)進(jìn)行對比分析。

只有對比一致，并且性能無太大差異的情況下，我們才認(rèn)為升級有效，這樣做到心中有底。

②基于 ECM 的 ES 多集群升級過程

由于需要進(jìn)行雙寫搬遷升級，在實際的升級過程中，需要密集的進(jìn)行集群搭建、搬遷、重啟等操作，得益于 ECM 的集群管控能力，彈性云靈活的特性，我們和運(yùn)維同學(xué)密切配合才能在短時間內(nèi)完成多個集群的升級工作。

③ES 新版本特性以及升級性能分析

ES 6.6.1 提供了很多新的特性，在查詢寫入性能上也有很大的提升，我們升級完成的一些案列也得到了驗證，我們會這些特性和性能提升進(jìn)行一個詳細(xì)的分析并分享給大家。

④ES 版本升級采坑分析

在升級的過程中我們也踩了一些坑，如：高版本 SDK 堆外內(nèi)存無限制使用導(dǎo)致 OOM 的問題，我們把遇到的問題都詳細(xì)記錄下來進(jìn)行并分享給大家。

收獲：長風(fēng)破浪會有時

經(jīng)過近半年的開發(fā)和重構(gòu)，在將國內(nèi)集群升級到高版本的過程中，我們也在架構(gòu)、產(chǎn)品、成本、性能、特性、自身能力上都有了很大的提升。

架構(gòu)更清晰

重構(gòu)之后整個滴滴 ElasticSearch 平臺的服務(wù)體系變得更清晰，主要收斂為四大塊應(yīng)用：

• Gateway 負(fù)責(zé)查詢寫入請求的接入，用戶的限流、權(quán)限校驗、版本兼容在此完成。
• ECM 負(fù)責(zé)所有集群的管控，集群搭建、升級、重啟、集群級別監(jiān)控和運(yùn)維分析在此完成。
• AMS 負(fù)責(zé)所有集群、節(jié)點、索引的運(yùn)行時信息采集與分析，保障數(shù)據(jù)質(zhì)量，并支持其他數(shù)據(jù)分析應(yīng)用，分級存儲、索引健康分、集群健康檢查、查詢回放等在此完成。
• Arius Admin 負(fù)責(zé)索引、權(quán)限、資源管控等核心能力。依賴 Admin 的核心能力以及 AMS 的數(shù)據(jù)采集能力，還提供了容量規(guī)劃和智能告警兩個設(shè)計良好并且可插拔的擴(kuò)展服務(wù)。

四個應(yīng)用完成功能抽象、依賴解耦和服務(wù)化改造，相比之前下線了 arius-watch、arius-dsl、arius-tools、arius-monitor、arius-mark 等五個小應(yīng)用，重構(gòu)之后整體開發(fā)效率和可運(yùn)維性得到了很大的提高。

產(chǎn)品更易用

我們基于 ES 6.5.1 版本，完全重構(gòu)了滴滴 ElasticSearch 用戶控制臺，其中將用戶的一些高頻操作，如：Mapping 設(shè)置/變更、數(shù)據(jù)清理、索引擴(kuò)容縮容、索引轉(zhuǎn)讓、成本賬單等開放給用戶，提升用戶的自助操作性。

未來我們還會對滴滴 ElasticSearch 用戶控制臺中的 Kibana 升級到最新版本并進(jìn)行定制化開發(fā)，提供更豐富和更強(qiáng)大的功能給用戶使用。

成本更低廉

之前滴滴 ElasticSearch 平臺有一套基于索引創(chuàng)建規(guī)則的容量規(guī)劃算法，相比完全沒有規(guī)劃，老版容量規(guī)劃算法可以將整體的集群資源使用率由 30% 提升到 50% 左右。

但是也存在著一些問題，如：資源分布不均、熱點無法快速發(fā)現(xiàn)、動態(tài)自適應(yīng)能力低、規(guī)劃算法抽象不夠無法在索引集群生效、運(yùn)維便利性差。

下圖展現(xiàn)了一個日志集群新老容量規(guī)劃的磁盤使用率對比，上線新的容量規(guī)劃之后，集群資源會向著兩個方向發(fā)展：

• 正在使用的資源更加聚攏，節(jié)點之間資源使用率更平均，整體的資源使用率也更高。
• 空閑資源完全釋放，基于彈性云部署，可以做到快速從集群摘除，加入后備資源池或者加入其它資源緊張的集群中。

經(jīng)過一系列的存儲優(yōu)化和資源使用率改造的完成，在滿足集群升級和業(yè)務(wù)需要增長的基礎(chǔ)上，國內(nèi) ES 的資源成本從 2019 年 2 月的 339w 下降到 2019 年 6 月的 259w，機(jī)器數(shù)也從 1658 臺下降到 1321 臺。

隨著國內(nèi)集群升級逐漸全部完成，Ceph 冷存的完善，還會逐步歸還更多的機(jī)器，滴滴 ElasticSearch 平臺的使用成本也會一步一步下降，在定價上我們也會考慮進(jìn)一步的進(jìn)行降價。

性能更強(qiáng)大

新版本升級之后帶來的性能主要體現(xiàn)在以下兩點：

①查詢性能提升

下圖是客服訂單列表查詢語句升級前后的對比，50 分位耗時從 300ms 下降到 50ms。99 分位從 600ms 下降到 300ms。

性能提升的詳細(xì)分析見：ES 新版本特性以及升級性能分析。

②集群寫入性能提升

升級到高版本只會，ES 6.6.1 集群相對于 ES 2.3.3 集群同等資源消耗下，整個集群的寫入能力提升了 30%。

如下圖日志集群的寫入 TPS 前后對比，集群寫入能力從 240w/s 提升到320w/s。

展望：直掛云帆濟(jì)滄海

至此，滴滴 ElasticSearch 團(tuán)隊已經(jīng)完成了國內(nèi)全部日志集群、90% 的 vip 集群的升級，整個滴滴 ElasticSearch 平臺的架構(gòu)也得以重構(gòu)和升級，從而在 ES 引擎層面也有了更大的發(fā)展空間。

未來我們將更加專注于引擎建設(shè)，更多的從根本上解決目前遇到的問題。未來我們將在以下幾個方向持續(xù)努力：

①更大的集群

在日志場景下嘗試突破 ES 單集群支持的最大節(jié)點數(shù)限制，提升單個集群能支持的節(jié)點數(shù)量，從目前的單集群支持的 200 個節(jié)點提升到 1000 個節(jié)點。

期待在大集群下能降低我們的集群數(shù)量提升運(yùn)維效率，同時更大的集群能更方便和更靈活的提升資源使用率，解決流量突增和資源熱點問題。

②更低的成本

降低 ES 的使用成本，提升資源使用率一直是我們追求的目標(biāo)，上半年我們在完成集群升級以及服務(wù)好業(yè)務(wù)的同時也完成節(jié)約成本 80w 每月，ES 整體成本下降約 25%，下半年爭取再下降成本 10%。

ES 6.6.1 提供的一些新特性如：Frozen 機(jī)制、Indexing sort 都將會進(jìn)一步降低資源消耗。

③更快的迭代

ES 集群內(nèi)多租戶查詢之間的相互影響一直也是滴滴 ElasticSearch 團(tuán)隊面臨的一個比較難解決的問題，之前更多的是在平臺層面通過物理資源隔離，查詢審核和限流來解決，資源利用率不高和人為運(yùn)維成本太大。

后續(xù)我們將構(gòu)建一套 ES 自身的查詢優(yōu)化器，類似 MySQL 的 Explain，可以在查詢語句級別進(jìn)行性能分析和查詢優(yōu)化，并在引擎層面通過索引模板級別的查詢資源隔離、一般 query 和 heavy query 的分離來保障查詢的穩(wěn)定。

④更緊密的聯(lián)系

在 ES 新版的基礎(chǔ)上，我們將和社區(qū)保持更緊密的聯(lián)系，積極的跟進(jìn)社區(qū)提供的新特性和發(fā)展方向，并引入滴滴供大家使用。

也會更積極的參與社區(qū)建設(shè)，將我們在滴滴內(nèi)部遇到和解決的問題反饋給社區(qū)，貢獻(xiàn)更多的 PR 和產(chǎn)生更多的 ES Contributor。

作者：趙情融

簡介：滴滴專家工程師 2018 加入滴滴，滴滴搜索團(tuán)隊負(fù)責(zé)人，全面負(fù)責(zé)滴滴搜索平臺的建設(shè)工作。曾在阿里巴巴工作多年，有豐富的平臺建設(shè)經(jīng)驗。