當前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導讀]來自:滴滴技術 導讀:滴滴 ElasticSearch 團隊經(jīng)過 7 個月的奮斗,將維護國內(nèi)的 30 多個 ES 集群,2000 多個 ES 節(jié)點,4PB 的數(shù)據(jù),從 2.3.3 跨大版本無縫升級到 6.6.1。完成ES版本升級的過程中,也完成了滴滴 ElasticSearch 平臺的架構(gòu)升級,如此大規(guī)模的跨

ich_media_content " id="js_content">

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

來自:滴滴技術

導讀:滴滴 ElasticSearch 團隊經(jīng)過 7 個月的奮斗,將維護國內(nèi)的 30 多個 ES 集群,2000 多個 ES 節(jié)點,4PB 的數(shù)據(jù),從 2.3.3 跨大版本無縫升級到 6.6.1。完成ES版本升級的過程中,也完成了滴滴 ElasticSearch 平臺的架構(gòu)升級,如此大規(guī)模的跨大版本升級,在 ES 業(yè)內(nèi)也很少見,從開始準備到實際執(zhí)行,遇到了很多困難,踩了一些坑,期間也有很多我們的思考,為此我們準備一系列的總結(jié)和分享。



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


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

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


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


1. 背景 - 推石頭的西西弗斯
2. 困難 - 拔劍四顧心茫然
3. 思考 - 天生我材必有用
4. 實戰(zhàn) - 百戰(zhàn)沙場碎鐵衣
5. 收益 - 長風破浪會有時
6. 展望 - 直掛云帆濟滄海



1

背景:推石頭的西西弗斯

滴滴千萬級ElasticSearch平臺發(fā)展之路!
滴滴 ElasticSearch 團隊從 2016 年開始建設 Elasticsearch 平臺,在 16 年 6 月份的時候開始對外提供服務,當時選擇了 Elasticsearch 最新的 2.3 版本。


如今3年過去了,Elasticsearch 生態(tài)經(jīng)歷了飛速的增長,elastic 公司完成了上市,Elasticsearch 在 db-engines 的分數(shù)從 88 上漲到 148,排名從 11 名上升到第 7 名。這期間 ES 發(fā)布了 3 個大版本,幾十個中版本,而最近 Elasticsearch 已經(jīng)發(fā)布了 7.x 版本。


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


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


滴滴千萬級ElasticSearch平臺發(fā)展之路!



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


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

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

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


  • 要么我們迎難而上,克服困難,一口氣把整個集群升級到最新的版本,把石頭推過山頂,再輕裝前行;


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


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




2. 

困難:拔劍四顧心茫然

滴滴千萬級ElasticSearch平臺發(fā)展之路!

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


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


  • "2.3.3 和 6.6.1 有些返回的字段都不一樣了,有些查詢語法也不兼容,怎么做到對用戶的透明,還是直接強迫用戶接受改變?"


  • "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)在不支持索引多版本同時查詢,用戶查詢習慣也千奇百怪,很多帶*查詢你根本控制不了"


  • "用戶那么多,使用差異很大,怎么和用戶進行溝通和宣導,怎么屏蔽用戶影響和管理用于預期?"


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


  • "幾十個集群,幾千個節(jié)點都要部署、搭建、重啟,還要騰挪上千臺機器。慢點搞,這得搞到什么時候,快點搞,萬一出問題怎么辦?"


  • "就算是雙寫升級了,怎么知道中間有沒有問題,數(shù)據(jù)有沒有丟失,用戶的查詢是不是一致的,功能和性能有沒有達到預期,這個怎么驗證?"


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


  • "…………"


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




3. 

思考:天生我材必有用

滴滴千萬級ElasticSearch平臺發(fā)展之路!

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


滴滴千萬級ElasticSearch平臺發(fā)展之路!

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


滴滴千萬級ElasticSearch平臺發(fā)展之路!



  • 首先進行架構(gòu)升級

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


  • 其次解決運維問題

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


  • 再次解決資源問題

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


  • 最后開始實際推進

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

   



4. 

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

滴滴千萬級ElasticSearch平臺發(fā)展之路!

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


滴滴千萬級ElasticSearch平臺發(fā)展之路!



架構(gòu)


1. 架構(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 多版本支持


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


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


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

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


3. ES服務元數(shù)據(jù)體系建設

我們構(gòu)建了一套 AMS(Arius MetaData Service) 服務,用于采集和分析 ES 所有集群、節(jié)點、索引的各種數(shù)據(jù),包括:容量信息(集群、節(jié)點、模板、索引、租戶)、tps/qps 信息(集群、節(jié)點、模板、索引、租戶)、運行信息、查詢語句、查詢模板信息、查詢結(jié)果和命中率的分析信息等等。

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

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

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

同時 AMS 還對數(shù)據(jù)的可靠性負責,保證產(chǎn)生的數(shù)據(jù)是及時并且準確的,這樣依賴 AMS 的數(shù)據(jù)分析服務,如:分級存儲、容量規(guī)劃、回放系統(tǒng)、成本賬單、集群健康檢查、索引健康分等,只用專注自身的邏輯的實現(xiàn)即可。


資源

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


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


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

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


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


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

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


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


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

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


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


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



實操


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


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

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


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

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


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

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

  • ES 版本升級采坑分析

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


   



5. 
收獲:長風破浪會有時
滴滴千萬級ElasticSearch平臺發(fā)展之路!

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


架構(gòu)更清晰


重構(gòu)之后整個滴滴 ElasticSearch 平臺的服務體系變得更清晰,主要收斂為 4 大塊應用:


  • Gateway 負責查詢寫入請求的接入,用戶的限流、權限校驗、版本兼容在此完成。


  • ECM 負責所有集群的管控,集群搭建、升級、重啟、集群級別監(jiān)控和運維分析在此完成。


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


  • Arius Admin 負責索引、權限、資源管控等核心能力。依賴 Admin 的核心能力以及 AMS 的數(shù)據(jù)采集能力,還提供了容量規(guī)劃和智能告警兩個設計良好并且可插拔的擴展服務。


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


滴滴千萬級ElasticSearch平臺發(fā)展之路!


產(chǎn)品更易用


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


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


滴滴千萬級ElasticSearch平臺發(fā)展之路!


成本更低廉

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

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


  • 正在使用的資源更加聚攏,節(jié)點之間資源使用率更平均,整體的資源使用率也更高;

  • 空閑資源完全釋放,基于彈性云部署,可以做到快速從集群摘除,加入后備資源池或者加入其它資源緊張的集群中。


滴滴千萬級ElasticSearch平臺發(fā)展之路!


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


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


滴滴千萬級ElasticSearch平臺發(fā)展之路!


   
性能更強大

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

  • 查詢性能提升

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


    性能提升的詳細分析見:ES 新版本特性以及升級性能分析。


    滴滴千萬級ElasticSearch平臺發(fā)展之路!


  • 集群寫入性能提升

    升級到高版本只會,ES6.6.1 集群相對于 ES2.3.3 集群同等資源消耗下,整個集群的寫入能力提升了 30%。


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

    滴滴千萬級ElasticSearch平臺發(fā)展之路!

    滴滴千萬級ElasticSearch平臺發(fā)展之路!




   
6. 
展望:直掛云帆濟滄海
滴滴千萬級ElasticSearch平臺發(fā)展之路!
至此,滴滴 ElasticSearch 團隊已經(jīng)完成了國內(nèi)全部日志集群、90% 的 vip 集群的升級,整個滴滴 ElasticSearch 平臺的架構(gòu)也得以重構(gòu)和升級,從而在 ES 引擎層面也有了更大的發(fā)展空間,未來我們將更加專注于引擎建設,更多的從根本上解決目前遇到的問題。


未來我們將在以下幾個方向持續(xù)努力



    
  • 更大的集群

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

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


  • 更低的成本

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

    ES 6.6.1 提供的一些新特性如:Frozen 機制、Indexing sort 都將會進一步降低資源消耗。


  • 更快的迭代

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

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

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


本文作者

?


滴滴千萬級ElasticSearch平臺發(fā)展之路!

趙情融
滴滴專家工程師

2018加入滴滴,滴滴搜索團隊負責人,全面負責滴滴搜索平臺的建設工作。曾在阿里巴巴工作多年,有豐富的平臺建設經(jīng)驗。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關注的小伙伴,可以長按關注一下:

滴滴千萬級ElasticSearch平臺發(fā)展之路!

長按訂閱更多精彩▼

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

如有收獲,點個在看,誠摯感謝

免責聲明:本文內(nèi)容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關機構(gòu)授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務連續(xù)性,提升韌性,成...

關鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權最終是由生態(tài)的繁榮決定的。

關鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務引領增長 以科技創(chuàng)新為引領,提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術學會聯(lián)合牽頭組建的NVI技術創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術創(chuàng)新聯(lián)...

關鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關鍵字: BSP 信息技術
關閉
關閉