滴滴千萬(wàn)級(jí)ElasticSearch平臺(tái)發(fā)展之路！

rc="https://img.21ic.com/weixin/2020/4/6B32au.jpeg">

來(lái)自：滴滴技術(shù)

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

團(tuán)隊(duì)同學(xué)經(jīng)過(guò) 7 個(gè)月的奮斗，完成ES版本升級(jí)的過(guò)程中，也完成了滴滴 ElasticSearch 平臺(tái)的架構(gòu)升級(jí)，取得了單機(jī)查詢(xún)性能提升 40%，整體集群 cpu 下降 10%，寫(xiě)入 tps 提升 30%，歸還物理機(jī)近 400 臺(tái)，成本節(jié)約 80w/月、0 故障的成績(jī)，并在引擎上向社區(qū)貢獻(xiàn)了4 個(gè) PR，一位同學(xué)升級(jí)為 ES Contributor。

如此大規(guī)模的跨大版本升級(jí)，在 ES 業(yè)內(nèi)也很少見(jiàn)，從開(kāi)始準(zhǔn)備到實(shí)際執(zhí)行，遇到了很多困難，踩了一些坑，期間也有很多我們的思考，為此我們準(zhǔn)備本期的總結(jié)和分享，主要從以下幾個(gè)方面展開(kāi)：

1. 

背景：推石頭的西西弗斯

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

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

• 社區(qū)不再維護(hù)老版本
  Elasticsearch 2.3.3版本過(guò)于陳舊，ES 社區(qū)早已不再進(jìn)行維護(hù)，在 2.x 上遇到的問(wèn)題社區(qū)不解決，提交的 issue 也不處理，提交代碼也不被接收。基于 2.3.3 我們也解決了很多 ES 自身的問(wèn)題，如：master 更新元數(shù)據(jù)超時(shí)導(dǎo)致內(nèi)存泄露、tcp 協(xié)議字段溢出等。由于無(wú)法和社區(qū)互動(dòng)，團(tuán)隊(duì)同學(xué)的價(jià)值也得不到社區(qū)的認(rèn)可，長(zhǎng)此以往只會(huì)和 ES 生態(tài)越來(lái)越遠(yuǎn)，我們?cè)?ES 技術(shù)圈中的聲音也會(huì)越來(lái)越弱。
  
  

• 新版本特性很難被使用
  最近 3 年是 ES 生態(tài)大發(fā)展的 3 年，ES 自身在功能、性能上都有非常大提升，如：默認(rèn)使用 BM25 評(píng)分算法，效果更佳；lucene docvalues 稀疏區(qū)域改進(jìn)，更節(jié)約磁盤(pán)空間；新增 Frozen indices 能力，可以顯著降低 ES 內(nèi)存開(kāi)銷(xiāo)。很多特性也非常適合 ElasticSearch 平臺(tái)的場(chǎng)景，但是版本差距過(guò)大一直制約著我們，無(wú)法享受技術(shù)進(jìn)步的紅利。

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

• 要么我們迎難而上，克服困難，一口氣把整個(gè)集群升級(jí)到最新的版本，把石頭推過(guò)山頂，再輕裝前行；

  
  

• 要么就是繼續(xù)獨(dú)自勉力支撐，在業(yè)務(wù)和引擎的雙重壓力下蹣跚而行。

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

2. 

困難：拔劍四顧心茫然

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

• "2.3.3 和 6.6.1 協(xié)議不兼容啊，6.6.1 都不支持 tcp 協(xié)議了，那些通過(guò) tcp 查的用戶怎么辦，讓他們一個(gè)一個(gè)改代碼，那要改到什么時(shí)候？"

  
  

• "2.3.3 和 6.6.1 有些返回的字段都不一樣了，有些查詢(xún)語(yǔ)法也不兼容，怎么做到對(duì)用戶的透明，還是直接強(qiáng)迫用戶接受改變？"

  
  

• "2.3.3 和 6.6.1 lucene 文件格式都不一樣，沒(méi)辦法原地直接升級(jí)，要再搞個(gè)集群全部雙寫(xiě)一遍"

  
  

• "2.3.3 和 6.6.1 的 mapping 格式不統(tǒng)一，6.6.1 不支持多 type，現(xiàn)有的那些數(shù)據(jù)搬遷都沒(méi)辦法搬"

  
  

• "滴滴 ElasticSearch 平臺(tái)現(xiàn)在不支持索引多版本同時(shí)查詢(xún)，用戶查詢(xún)習(xí)慣也千奇百怪，很多帶*查詢(xún)你根本控制不了"

  
  

• "用戶那么多，使用差異很大，怎么和用戶進(jìn)行溝通和宣導(dǎo)，怎么屏蔽用戶影響和管理用于預(yù)期？"

  
  

• "就算是要搬遷升級(jí)，哪里去找那么多機(jī)器，現(xiàn)在還要機(jī)房裁撤，還要往外拿機(jī)器"

  
  

• "幾十個(gè)集群，幾千個(gè)節(jié)點(diǎn)都要部署、搭建、重啟，還要騰挪上千臺(tái)機(jī)器。慢點(diǎn)搞，這得搞到什么時(shí)候，快點(diǎn)搞，萬(wàn)一出問(wèn)題怎么辦？"

  
  

• "就算是雙寫(xiě)升級(jí)了，怎么知道中間有沒(méi)有問(wèn)題，數(shù)據(jù)有沒(méi)有丟失，用戶的查詢(xún)是不是一致的，功能和性能有沒(méi)有達(dá)到預(yù)期，這個(gè)怎么驗(yàn)證？"

  
  

• "這么多數(shù)據(jù)，這么多人在用，這么點(diǎn)資源，業(yè)務(wù)穩(wěn)定壓力又大，估計(jì)今年一年都搞不完"

  
  

• "…………"

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

3. 

思考：天生我材必有用

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

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

• 首先進(jìn)行架構(gòu)升級(jí)

  解決引擎?zhèn)?2.x/6.x 的不兼容問(wèn)題，所有的協(xié)議、查詢(xún)語(yǔ)法、mapping 等不兼容處理在平臺(tái)側(cè)進(jìn)行處理。同時(shí)我們開(kāi)發(fā)了一個(gè) ES java SDK 用來(lái)解決 6.x 不支持 tcp 接口的問(wèn)題，使用方式和原有的 es java client 完全一致，用戶只要修改 pom 即可。具體包括：Arius 平臺(tái)多版本支持、Gateway 的多版本兼容、用戶 SDK 開(kāi)發(fā)、AMS 數(shù)據(jù)采集等，具體見(jiàn)后續(xù)詳細(xì)說(shuō)明。

  
  

• 其次解決運(yùn)維問(wèn)題

  解決運(yùn)維操作過(guò)程中多集群搭建、部署、重啟的管控問(wèn)題，提升操作的便利性，提升升級(jí)的操作效率，具體見(jiàn)后續(xù)詳細(xì)說(shuō)明。

  
  

• 再次解決資源問(wèn)題

  解決搬遷升級(jí)所需要的大量機(jī)器資源問(wèn)題，為大量集群升級(jí)做充足準(zhǔn)備，同時(shí)還要滿足機(jī)房裁撤歸還機(jī)器的要求。具體包括：索引存儲(chǔ)周期優(yōu)化、冷熱數(shù)據(jù)分離、mapping 優(yōu)化、fastIndex 等，具體見(jiàn)后續(xù)詳細(xì)說(shuō)明。

  
  

• 最后開(kāi)始實(shí)際推進(jìn)

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

   

    

   
   

    

   
   

    

   
4. 
實(shí)戰(zhàn)：白沙戰(zhàn)場(chǎng)碎鐵衣
   

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

    

   
   

    
   


▍架構(gòu)

1. 架構(gòu)滴滴 ElasticSearch 平臺(tái) ES 多版本支持的架構(gòu)改造

首先我們?cè)诘蔚?ElasticSearch 平臺(tái)上完成了 ES 多版本支持的架構(gòu)升級(jí)，其中重點(diǎn)有：

• Arius Gateway 對(duì)跨版本查詢(xún)差異的兼容，以及多集群下索引跨高低版本集群訪問(wèn)，使得在升級(jí)過(guò)程中對(duì)用戶查詢(xún)結(jié)果透明。

  
  

• Elasticsearch-didi-interanl-client SDK 開(kāi)發(fā)，對(duì)用戶屏蔽 ES TCP/HTTP 查詢(xún)差異，解決 ES 6.x 版本不支持 TCP 接口的問(wèn)題，原有 2.x 的用戶只要修改一行 pom 就可以切換到高版本訪問(wèn)。

  
  

• 滴滴 ElasticSearch 平臺(tái)架構(gòu)梳理以及 Arius admin 多版本支持

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

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

在解決架構(gòu)和兼容性問(wèn)題之后，我們已經(jīng)有信心將一個(gè)集群在線升級(jí)到新版本。然而由于版本跨度太大無(wú)法在原集群上直接進(jìn)行滾動(dòng)升級(jí)，必須要進(jìn)行數(shù)據(jù)雙寫(xiě)的搬遷升級(jí)，這樣升級(jí)所需要的 buff 資源就成為制約整個(gè)升級(jí)進(jìn)度最重要的因素，因此接下來(lái)我們把精力放在節(jié)省資源提高資源利用率上。

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

• 基于數(shù)據(jù)驅(qū)動(dòng)的ES分級(jí)存儲(chǔ)體系

  基于 AMS 對(duì)應(yīng)索引的大小、數(shù)據(jù)量、查詢(xún)量、查詢(xún)條件、查詢(xún)時(shí)間、返回結(jié)果的統(tǒng)計(jì)和分析，我們能精確的分析出來(lái)每個(gè)索引被使用的場(chǎng)景以及被查詢(xún)的方式，如：索引的高頻查詢(xún)時(shí)間區(qū)間、索引被檢索的字段等，在數(shù)據(jù)分析基礎(chǔ)上我們針對(duì)每個(gè)索引進(jìn)行了 mapping 優(yōu)化、存儲(chǔ)周期優(yōu)化、冷熱數(shù)據(jù)存儲(chǔ)優(yōu)化。
  

  
  

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

  
  

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

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

  
  采用基于 hadoop 的 ES fastIndex 離線數(shù)據(jù)導(dǎo)入系統(tǒng)之后，同樣的數(shù)據(jù)導(dǎo)入時(shí)間由原來(lái)的 8 個(gè)小時(shí)下降到 2 個(gè)小時(shí)，機(jī)器成本由原來(lái)的 40 臺(tái)物理機(jī) (ES27臺(tái)、Kafka 3臺(tái)、Dsink 10臺(tái)) 下降到30臺(tái)彈性云節(jié)點(diǎn)（10臺(tái)物理機(jī)），單單在標(biāo)簽場(chǎng)景就節(jié)約成本 7W+ 每月。

  
  

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

  提升 ES 集群資源使用率也是滴滴 ElasticSearch 團(tuán)隊(duì)一直面臨和致力于解決的問(wèn)題，滴滴 ElasticSearch 團(tuán)隊(duì)維護(hù)的 ES 機(jī)器總?cè)萘繉⒔?5PB，提升 10% 的資源使用率即可節(jié)約 500TB 的空間，或者用于歸還機(jī)器，或者用于服務(wù)新的需求。

  
  

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

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

▍實(shí)操

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

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

  在前期構(gòu)建的 AMS(Arius Meta Service) 系統(tǒng)上，我們對(duì)用戶查詢(xún)條件、查詢(xún)結(jié)果進(jìn)行記錄和分析，在雙寫(xiě)搬遷升級(jí)過(guò)程中，我們將用戶的查詢(xún)條件分別在高低版本的集群上進(jìn)行回放，將查詢(xún)返回的結(jié)果、性能參數(shù)進(jìn)行對(duì)比分析，只有對(duì)比一致，并且性能無(wú)太大差異的情況下，我們才認(rèn)為升級(jí)有效，這樣做到心中有底。

  
  

• 基于 ECM 的 ES 多集群升級(jí)過(guò)程

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

  
  

• ES 新版本特性以及升級(jí)性能分析

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

• ES 版本升級(jí)采坑分析

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

  
  

   

    

   
   

    

   
   

    

   
   

    5. 
   
   

    收獲：長(zhǎng)風(fēng)破浪會(huì)有時(shí)
   
   

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

    

   
   

    ▍架構(gòu)更清晰
   

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

• Gateway 負(fù)責(zé)查詢(xún)寫(xiě)入請(qǐng)求的接入，用戶的限流、權(quán)限校驗(yàn)、版本兼容在此完成。

  
  

• ECM 負(fù)責(zé)所有集群的管控，集群搭建、升級(jí)、重啟、集群級(jí)別監(jiān)控和運(yùn)維分析在此完成。

  
  

• AMS 負(fù)責(zé)所有集群、節(jié)點(diǎn)、索引的運(yùn)行時(shí)信息采集與分析，保障數(shù)據(jù)質(zhì)量，并支持其他數(shù)據(jù)分析應(yīng)用，分級(jí)存儲(chǔ)、索引健康分、集群健康檢查、查詢(xún)回放等在此完成。

  
  

• Arius Admin 負(fù)責(zé)索引、權(quán)限、資源管控等核心能力。依賴(lài) Admin 的核心能力以及 AMS 的數(shù)據(jù)采集能力，還提供了容量規(guī)劃和智能告警兩個(gè)設(shè)計(jì)良好并且可插拔的擴(kuò)展服務(wù)。

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


   

    
    

   
▍產(chǎn)品更易用

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

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


   

    
   


   

    ▍
    成本更低廉
   
   

    

   
   

    之前滴滴 ElasticSearch 平臺(tái)有一套基于索引創(chuàng)建規(guī)則的容量規(guī)劃算法，相比完全沒(méi)有規(guī)劃，老版容量規(guī)劃算法可以將整體的集群資源使用率由 30% 提升到 50% 左右，但是也存在著一些問(wèn)題，如：資源分布不均、熱點(diǎn)無(wú)法快速發(fā)現(xiàn)、動(dòng)態(tài)自適應(yīng)能力低、規(guī)劃算法抽象不夠無(wú)法在索引集群生效、運(yùn)維便利性差。
   
   

    

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

    

   

• 正在使用的資源更加聚攏，節(jié)點(diǎn)之間資源使用率更平均，整體的資源使用率也更高；

• 空閑資源完全釋放，基于彈性云部署，可以做到快速?gòu)募赫?，加入后備資源池或者加入其它資源緊張的集群中。

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

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

   

    ▍
    性能更強(qiáng)大
   
   

    

   
   

    新版本升級(jí)之后帶來(lái)的性能主要體現(xiàn)在一下兩點(diǎn)：
   
   

    

   

• 查詢(xún)性能提升

  下圖是客服訂單列表查詢(xún)語(yǔ)句升級(jí)前后的對(duì)比，50 分位耗時(shí)從 300ms 下降到 50ms。99 分位從 600ms 下降到 300ms。

  
  

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

  
  

  

• 集群寫(xiě)入性能提升

  升級(jí)到高版本只會(huì)，ES6.6.1 集群相對(duì)于 ES2.3.3 集群同等資源消耗下，整個(gè)集群的寫(xiě)入能力提升了 30%。

  
  

  如下圖日志集群的寫(xiě)入 tps 前后對(duì)比，集群寫(xiě)入能力從 240w/s 提升到320w/s。

  

  

   

    

     6. 
    
    

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

     
    
    

     至此，滴滴 ElasticSearch 團(tuán)隊(duì)已經(jīng)完成了國(guó)內(nèi)全部日志集群、90% 的 vip 集群的升級(jí)，整個(gè)滴滴 ElasticSearch 平臺(tái)的架構(gòu)也得以重構(gòu)和升級(jí)，從而在 ES 引擎層面也有了更大的發(fā)展空間，未來(lái)我們將更加專(zhuān)注于引擎建設(shè)，更多的從根本上解決目前遇到的問(wèn)題。
    
    


    
未來(lái)我們將在以下幾個(gè)方向持續(xù)努力：
   
   

    


    

    

     
更大的集群
      

       在日志場(chǎng)景下嘗試突破ES單集群支持的最大節(jié)點(diǎn)數(shù)限制，提升單個(gè)集群能支持的節(jié)點(diǎn)數(shù)量，從目前的單集群支持的 200 個(gè)節(jié)點(diǎn)提升到 1000 個(gè)節(jié)點(diǎn)。
      
期待在大集群下能降低我們的集群數(shù)量提升運(yùn)維效率，同時(shí)更大的集群能更方便和更靈活的提升資源使用率，解決流量突增和資源熱點(diǎn)問(wèn)題。


     
更低的成本
降低 ES 的使用成本，提升資源使用率一直是我們追求的目標(biāo)，上半年我們?cè)谕瓿杉荷?jí)以及服務(wù)好業(yè)務(wù)的同時(shí)也完成節(jié)約成本 80w 每月，ES 整體成本下降約 25%，下半年?duì)幦≡傧陆党杀?10%。
ES 6.6.1 提供的一些新特性如：Frozen 機(jī)制、Indexing sort 都將會(huì)進(jìn)一步降低資源消耗。


     
更快的迭代
      

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

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

       在 ES 新版的基礎(chǔ)上，我們將和社區(qū)保持更緊密的聯(lián)系，積極的跟進(jìn)社區(qū)提供的新特性和發(fā)展方向，并引入滴滴供大家使用，也會(huì)更積極的參與社區(qū)建設(shè)，將我們?cè)诘蔚蝺?nèi)部遇到和解決的問(wèn)題反饋給社區(qū)，貢獻(xiàn)更多的 PR 和產(chǎn)生更多的 ES Contributor。
      
      

       

      
    
   

本文作者

?

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
rc="https://img.21ic.com/weixin/2020/4/jAFvIz.jpeg">
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝