分享嘉賓：趙情融 滴滴專家工程師

編輯整理：王洪達(dá)

出品平臺(tái)：DataFunTalk

導(dǎo)讀： 前不久，滴滴ES團(tuán)隊(duì)將維護(hù)的30多個(gè)ES集群，3500多個(gè)ES節(jié)點(diǎn)，8PB的數(shù)據(jù)，從2.3.3跨大版本無縫升級(jí)到6.6.1。在對(duì)用戶查詢寫入基本零影響和改動(dòng)的前提下，解決了ES跨大版本協(xié)議不兼容、文件格式不兼容、mapping不兼容等難題，整個(gè)過程對(duì)絕大部分用戶完全透明。同時(shí)還完成了Arius的架構(gòu)升級(jí)，取得了單機(jī)查詢性能提升40%，整體集群cpu下降10%，寫入tps提升30%，集群資源使用率提升20%、0故障、運(yùn)維成本下降60%的成績(jī)。

本文將系統(tǒng)的介紹滴滴在從2.3.3跨大版本升級(jí)到6.6.1過程中的遇到的問題和解決方案，以及在搜索平臺(tái)建設(shè)過程中的體系化思考。

01

背景介紹

1.?集群規(guī)模

目前滴滴使用的ES版本是2.3.3，集群個(gè)數(shù)有40多個(gè)，節(jié)點(diǎn)規(guī)模有3500+，集群總?cè)萘坑?PB。

2.?業(yè)務(wù)規(guī)模

1200多個(gè)平臺(tái)應(yīng)用方在使用ES，30多個(gè)核心應(yīng)用在使用ES，寫入的TPS有1500W，查詢的QPS有25W。

02

問題分析

針對(duì)以上規(guī)模的ES集群，從2.3.3升級(jí)到6.X版本，小版本會(huì)根據(jù)最后分析的結(jié)果確定，需要對(duì)潛在可能的問題進(jìn)行分析和區(qū)分。

1.?問題分析

主要先從四大問題域進(jìn)行區(qū)分分析：

• 引擎?zhèn)龋河捎趶?.3.3升級(jí)到6.X版本，版本差距過大，在文件格式和協(xié)議上都不兼容，因此無法進(jìn)行原地滾動(dòng)直接升級(jí)，需要雙寫搬遷升級(jí)，這樣會(huì)耗費(fèi)大量的機(jī)器去參與其中

• 用戶側(cè)：6.X版本開始逐漸的不支持TCP接口，因此需要用戶適配和升級(jí)；查詢和返回值也有一定差異，如果用戶側(cè)做適配，會(huì)極大影響升級(jí)的進(jìn)度

• 資源側(cè)：由于無法直接原地滾動(dòng)直接升級(jí)，需要雙寫使用大量的機(jī)器，但是無法提供升級(jí)所需要的機(jī)器，如果升級(jí)過程中資源無法得到保障，那也會(huì)極大影響升級(jí)的進(jìn)度

• 操作側(cè)：新版本的多集群如何進(jìn)行運(yùn)維管控？升級(jí)的結(jié)果如何驗(yàn)證？查詢的效率和質(zhì)量如何保障和保證的？這些問題都需要考慮

2.?升級(jí)思路

根據(jù)上一部分問題的匯總和分類，形成了一個(gè)大致的升級(jí)思路并會(huì)根據(jù)這四大步驟來解決具體的問題。

• 架構(gòu)設(shè)計(jì)：平臺(tái)支持多版本支持，查詢網(wǎng)關(guān)上進(jìn)行多版本兼容，在查詢和插入使用SDK時(shí)候要做到SDK接口的透明，最后要做一個(gè)平臺(tái)數(shù)據(jù)采集和分析用于后續(xù)做升級(jí)的分析對(duì)比

• 資源準(zhǔn)備：進(jìn)行合理的多集群容量規(guī)劃來提高資源使用率，盡可能的節(jié)省機(jī)器；設(shè)計(jì)索引分級(jí)存儲(chǔ)來提升資源的利用率；還針對(duì)大索引遷移開發(fā)了一個(gè)插件FastIndex也用來提升資源利用率

• 運(yùn)維績(jī)效：開發(fā)ES集群管控平臺(tái)，將ES集群管控平臺(tái)化和圖表化；通過Docker的方式來提升部署和運(yùn)維的效率

• 實(shí)操：在實(shí)際操作中，需要實(shí)現(xiàn)批量雙寫以及查詢回放的功能；需要對(duì)業(yè)務(wù)進(jìn)行區(qū)分，實(shí)現(xiàn)日志和核心集群的分步推進(jìn)；最后就是升級(jí)過程中會(huì)遇到一些坑，需要把坑都填滿，后續(xù)會(huì)詳細(xì)介紹一下這些坑

3.?升級(jí)方案

上面是升級(jí)思路，接下來介紹一下升級(jí)方案：

• 架構(gòu)：ES多版本支持的架構(gòu)改造，同時(shí)支持2.3.3以及6.X版本；開發(fā)一套多集群管控平臺(tái)，用于滴滴內(nèi)部ES多個(gè)集群的管控；同時(shí)還開發(fā)了一套ES服務(wù)元數(shù)據(jù)體系建設(shè)

• 資源：設(shè)計(jì)ES分級(jí)存儲(chǔ)體系；開發(fā)ES-FastIndex離線數(shù)據(jù)導(dǎo)入的插件；最后構(gòu)建了一套ES集群容量規(guī)劃方案來提升集群的資源使用率，節(jié)約資源成本

• 實(shí)操：通過ES多集群搭建、ES流量回放對(duì)比系統(tǒng)、ES版本升級(jí)采坑分享來完成升級(jí)和對(duì)比的一個(gè)過程

03

方案介紹

1.?架構(gòu)

① 架構(gòu)重構(gòu)

介紹一下滴滴搜索平臺(tái)（Arius）的架構(gòu)，業(yè)務(wù)方使用ES搜索進(jìn)行讀寫請(qǐng)求時(shí)都會(huì)經(jīng)過網(wǎng)關(guān)；運(yùn)維的時(shí)候會(huì)根據(jù)集群的重要程度進(jìn)行劃分，會(huì)將四十多個(gè)集群劃分為VIP、Important、Normal、Backup四類，開發(fā)了一個(gè)DCDR工具用于跨集群的數(shù)據(jù)同步；在ES集群運(yùn)維之上開發(fā)了三大組件，一個(gè)是ES Cluster Manager，用于集群的搭建、重啟和升級(jí)混合操作的平臺(tái)；第二個(gè)是集群ES的數(shù)據(jù)分析構(gòu)建了一個(gè)Arius Metadata Service的元數(shù)據(jù)管理服務(wù)，用于做DSL分析、成本優(yōu)化和查詢回放；在這兩個(gè)系統(tǒng)之上有一套Arius Admin管控系統(tǒng)，包含索引管控、權(quán)限管控、DSL運(yùn)維、多版本支持、資源管控以及容量規(guī)劃等功能；基于Arius Admin，構(gòu)建了兩套面向運(yùn)維和用戶的管控平臺(tái)前端工程。

以上就是滴滴搜索平臺(tái)的整體架構(gòu)，然后基于此來做ES的版本升級(jí)。

② 升級(jí)流程

上圖為升級(jí)的流程，首先是要升級(jí)對(duì)ES集群的管控，要支持2.3.3和6.6.1兩個(gè)版本；對(duì)每個(gè)要升級(jí)的索引要進(jìn)行主備索引的創(chuàng)建，創(chuàng)建完畢后通過雙寫的形式對(duì)主和備都同時(shí)寫入到新的索引中，對(duì)于歷史索引采取的是這樣一個(gè)策略：在雙寫之前，主備創(chuàng)建之后，會(huì)暫停歷史數(shù)據(jù)的寫入，把歷史數(shù)據(jù)通過migration的方式從低版本遷移到高版本中，遷移完后再進(jìn)行雙寫；在遷移完成，雙寫鏈路打開之后，做一個(gè)DSL數(shù)據(jù)回放，由于用戶的讀寫都是通過gateway進(jìn)行的，所以可以拿到用戶的DSL語句和返回?cái)?shù)據(jù)來進(jìn)行一個(gè)高低版本的查詢、對(duì)比和分析，如果最后比對(duì)結(jié)果是數(shù)據(jù)一致、性能也一致，那就認(rèn)為該索引在高低版本中遷移是成功的。如果遷移成功，會(huì)在網(wǎng)關(guān)層完成用戶查詢的向高版本的切換，如果切換完成后，業(yè)務(wù)方運(yùn)行沒有問題就會(huì)將低版本的索引下線掉，最終就完成了索引由低版本向高版本升級(jí)的過程。

③ GateWay兼容性

升級(jí)是一個(gè)比較漫長(zhǎng)的過程，高低版本集群會(huì)并行運(yùn)行一段時(shí)間，用戶使用的SDK也會(huì)高低版本共存，這樣就需要解決高低版本兼容性的問題。查詢可能會(huì)分為上圖六條線標(biāo)識(shí)的六種情況，藍(lán)色線表明不需要進(jìn)行改造直接進(jìn)行查詢的，2.3.3的http和tcp sdk查詢2.3.3ES集群，6.6.1 high sdk查詢6.6.1的ES集群都是沒有問題的；紅色線表明是需要考慮兼容性問題進(jìn)行改造的，例如2.3.3的sdk查詢6.6.1的ES集群時(shí)候語法的差異性問題等，然后ES高版本中會(huì)逐漸取消掉tcp的查詢接口，但是滴滴內(nèi)部還是有很多用戶是使用tcp方式查詢的，如果需要用戶進(jìn)行代碼改造的話流程會(huì)非常漫長(zhǎng)，因此在Gateway層面做了一些兼容性處理：在2.3.3http api和6.6.1 high sdk查詢6.6.1集群和2.3.3集群時(shí)候，做了請(qǐng)求DSL的兼容性處理和響應(yīng)結(jié)果兼容，解決了用戶的痛點(diǎn)；對(duì)于使用tcp方式查詢的用戶，開發(fā)了一個(gè)elasticsearch-didi-java-client的sdk，用戶替換一下pom即可，表面上還是使用tcp的方式，但是在網(wǎng)關(guān)層面已經(jīng)將其轉(zhuǎn)換為了http查詢的方式。這樣就做到了用戶透明。

④ ES集群管控平臺(tái)

同時(shí)搭建了一套ES集群管控平臺(tái)，用于進(jìn)行集群搭建、集群擴(kuò)容、集群升級(jí)、集群監(jiān)控以及集群診斷等工作，為升級(jí)過程中的運(yùn)維賦能，提升升級(jí)推進(jìn)進(jìn)度。

⑤ 元數(shù)據(jù)服務(wù)

前面介紹的時(shí)候有講到元數(shù)據(jù)服務(wù)，該模塊的作用就是提供一個(gè)ES集群和業(yè)務(wù)方的數(shù)據(jù)的分析，然后獲取cluster/stats、node/stats、日志、監(jiān)控?cái)?shù)據(jù)等信息進(jìn)行分析，最后可以得到節(jié)點(diǎn)磁盤使用狀況、DSL查詢情況（慢查、錯(cuò)誤查詢），基于此來做容量規(guī)劃、分級(jí)存儲(chǔ)、查詢回放等數(shù)據(jù)驅(qū)動(dòng)型工作。

⑥ DSL服務(wù)

此處著重介紹一下DSL服務(wù)，用戶所有請(qǐng)求都會(huì)通過網(wǎng)關(guān)，經(jīng)過網(wǎng)關(guān)時(shí)會(huì)收集到kafka，然后用flink做一些分析，如DSL模板提?。ň唧w查詢參數(shù)去掉，抽象為模板）、DSL統(tǒng)計(jì)、DSL慢查分析、DSL異常分析等，然后將分析結(jié)果回寫到ES集群中；然后根據(jù)這些分析的數(shù)據(jù)來做DSL審核（用戶可能會(huì)查詢滴滴的核心索引，此處需要審核才能查詢）、DSL限流（有的DSL里面會(huì)有大量的聚合查詢，此處會(huì)進(jìn)行一定限流）、DSL分析（首先會(huì)對(duì)DSL語句進(jìn)行語法樹的解析，解析后會(huì)生成一個(gè)無參的查詢模板）等。

2. 資源

① 容量規(guī)劃

接下來將一些如何在升級(jí)過程中解決資源問題，為此開發(fā)了一個(gè)容量規(guī)劃的算法，ES缺乏一個(gè)多節(jié)點(diǎn)之間索引均勻分布的功能；在滴滴內(nèi)部最大的集群是在兩百多個(gè)節(jié)點(diǎn)，承載容量在PB級(jí)別，索引有上千個(gè)，在寫入索引時(shí)候可能流量分布式不均勻的，很有可能有索引節(jié)點(diǎn)的熱點(diǎn)存在。

解決思路為將兩百多個(gè)節(jié)點(diǎn)進(jìn)行劃分為五個(gè)region，一個(gè)region都會(huì)有很多節(jié)點(diǎn)組成，如r1、r2、r3組成，劃分之后就可以計(jì)算每個(gè)region中節(jié)點(diǎn)磁盤的使用情況，設(shè)置一個(gè)高水位線和低水位線，通過分析每個(gè)region的數(shù)據(jù)情況，region超過高水位就會(huì)通過rack變更進(jìn)行擴(kuò)容，region內(nèi)部會(huì)監(jiān)控不同節(jié)點(diǎn)的使用情況，通過rack建索引mockShard進(jìn)行均衡，從而整體提升資源利用率，通過該算法后集群磁盤的使用率從百分之四十提升到百分之六十，這樣就節(jié)省了大量的資源。

② 分級(jí)存儲(chǔ)

基于用戶查詢和保存的操作進(jìn)行一個(gè)數(shù)據(jù)分析，開發(fā)了一個(gè)ES分級(jí)存儲(chǔ)的體系，搭建ES集群時(shí)候主要基于兩種磁盤進(jìn)行搭建的，一種是SSD磁盤，另一種是Ceph（可以理解為HDD磁盤組成的網(wǎng)絡(luò)磁盤）；SSD磁盤非常貴，但是查詢性能特別好，會(huì)存儲(chǔ)一些查詢頻繁的數(shù)據(jù)，Ceph磁盤比較便宜，但是查詢IO性能比較低，存儲(chǔ)查詢不是那么頻繁的數(shù)據(jù)；根據(jù)用戶查詢的頻率，將數(shù)據(jù)區(qū)分為冷數(shù)據(jù)和熱數(shù)據(jù)，根絕查詢的DSL來分析索引的保留期限，在滴滴內(nèi)部基本上索引都是按天保存的（舉個(gè)例子：日志都是按天建索引保存的），三天之內(nèi)的放到SSD上保存，三天之前的數(shù)據(jù)會(huì)放到Ceph上存儲(chǔ)，這樣可以大量存儲(chǔ)的成本，同等成本情況下，把集群存儲(chǔ)容量從5PB提升到了8PB。

在分級(jí)存儲(chǔ)之上，還開發(fā)了一些特性，專門開發(fā)了high level和low level的水位線，這是基于冷存和熱存系統(tǒng)消耗是不一樣的，冷存的時(shí)候high level可能會(huì)更高一點(diǎn)，以上就是分級(jí)存儲(chǔ)的內(nèi)容。

③?FastIndex

另外還為離線數(shù)據(jù)導(dǎo)入ES開發(fā)了一個(gè)FastIIndex的組件，該組件開發(fā)主要是基于滴滴內(nèi)部用于分析乘客的標(biāo)簽系統(tǒng)，從離線系統(tǒng)導(dǎo)入ES集群而開發(fā)的；標(biāo)簽系統(tǒng)每天都會(huì)重新計(jì)算，數(shù)據(jù)總量在40TB左右，原始數(shù)據(jù)在hadoop上，計(jì)算好之后通過kafka然后實(shí)時(shí)鏈路寫入到ES，以前把40TB數(shù)據(jù)導(dǎo)入到ES需要40臺(tái)高配物理機(jī)，基于這樣一個(gè)案例開發(fā)了FastIndex組件，利用hive進(jìn)行一個(gè)mapreduce的過程，在reduce階段使用FastIndex組件啟用ES local這樣的模式將數(shù)據(jù)寫到lucene data中，然后再把lucene文件加載到ES集群中，這樣就完成了把離線數(shù)據(jù)導(dǎo)入ES集群的操作，資源從40臺(tái)下降到10臺(tái)高配物理機(jī)，時(shí)間也從6小時(shí)下降到1.5小時(shí)，節(jié)省了大量的成本。

3. 升級(jí)

① 查詢回放

機(jī)器資源優(yōu)化好了之后，開始升級(jí)，升級(jí)過程前面有講過了，這里主要介紹一下查詢回放流程，因?yàn)橐ＷC升級(jí)后對(duì)用戶的查詢是沒有影響的；基于gateway網(wǎng)關(guān)層DSL的分析，將用戶查詢的DSL全部在高低版本上進(jìn)行一個(gè)回放，最后得出一份查詢性能報(bào)告和查詢結(jié)果報(bào)告，通過分析兩篇報(bào)告，如果是一致的就認(rèn)為升級(jí)完成；如果不一致，就分析2.3.3和6.6.1哪些查詢導(dǎo)致的問題，然后做兼容性適配，適配完成后再進(jìn)行查詢回放，循環(huán)往復(fù)直至最后所有的報(bào)告都一致，這樣就認(rèn)為ES集群升級(jí)成功。

② 采坑

接下來介紹一下升級(jí)過程中遇到的坑：

• Mapping：選擇6.6.1的理由是代碼里面暫時(shí)還是支持多type的；還有就是布爾類型數(shù)據(jù)的兼容，分詞不分詞的mapping修改，這些內(nèi)容都會(huì)提前幫助用戶修改好mapping。

• 查詢兼容：聚合查詢term size不能為0，網(wǎng)關(guān)兼容默認(rèn)返回1000條；match不支持type關(guān)鍵字，網(wǎng)關(guān)兼容查詢type處理邏輯；not/or/and關(guān)鍵字不兼容，網(wǎng)關(guān)轉(zhuǎn)換must/should/must_not；不支持關(guān)鍵字fields，網(wǎng)關(guān)轉(zhuǎn)換為store_fields

• 性能：數(shù)值字段改為BKD，枚舉字段會(huì)從Long類型改為keyword類型；否則long類型在BKD查詢時(shí)候還有問題的

• SDK：使用高版本ES會(huì)有堆外內(nèi)存消耗過大的問題，需要開啟jdk,nio.maxCachedBudderSize參數(shù)來保障堆外內(nèi)存不會(huì)消耗過大。

04

升級(jí)收益

1.?平臺(tái)升級(jí)

構(gòu)建了一個(gè)完善的管控的平臺(tái)，大大降低了使用成本。

2. 成本下降

機(jī)器數(shù)量下降了400臺(tái)，每月成本節(jié)約了80萬左右。

3. 性能提升

高版本的ES查詢性能提升還是很明顯的，請(qǐng)求耗時(shí)下降40%，集群寫入提升30%。

4.?特性應(yīng)用

使用了高版本特性帶來的一些優(yōu)勢(shì)：

• Sequence?Number提升了集群升級(jí)速度

• Ingest?Node索引模板和限流從網(wǎng)關(guān)層下放到引擎層

• DCDR滴滴跨集群數(shù)據(jù)同步，相比CCR性能提升2倍

• Cluster reroute冷熱節(jié)點(diǎn)shard搬遷更均勻

• Cluster?allocation?explain降低集群狀態(tài)運(yùn)維成本

05

總結(jié)與展望

1.?總結(jié)

針對(duì)搜索平臺(tái)進(jìn)行大版本的升級(jí)時(shí)，一定要做到：

• 架構(gòu)要可控：服務(wù)化（網(wǎng)關(guān)服務(wù)、管控服務(wù)、元數(shù)據(jù)服務(wù)、FastIndex服務(wù)）、高內(nèi)聚、一定優(yōu)先保證穩(wěn)定性

• 平臺(tái)要易用：平臺(tái)化、自動(dòng)化、可視化

• 成本要低廉：數(shù)據(jù)驅(qū)動(dòng)、技術(shù)改造、業(yè)務(wù)配合

• 引擎要深入：深入理解版本差異、深入理解ES原理、深入定位問題根因

2.?規(guī)劃

最后對(duì)滴滴搜索平臺(tái)做一個(gè)整體的規(guī)劃：

• 更大的集群：在滴滴現(xiàn)有的目前40多個(gè)集群的規(guī)模下，做得更大，由于master元數(shù)據(jù)管理的限制導(dǎo)致對(duì)集群的管控是無法做到非常大的，目前滴滴希望做到單集群支持50萬下載、1500節(jié)點(diǎn)的支撐；同時(shí)需要做好多租戶能力的支持

• 更易用的平臺(tái)：ES云平臺(tái)建設(shè)、ES專家服務(wù)

• 更強(qiáng)的引擎：CBO/RBO查詢優(yōu)化、提升寫入性能

• 更多的貢獻(xiàn)：加強(qiáng)和開源社區(qū)的互動(dòng)、深入引擎開發(fā)

---

嘉賓介紹：

趙情融

滴滴出行 |?專家工程師

2018年加入滴滴，負(fù)責(zé)滴滴搜索平臺(tái)建設(shè)工作，曾在阿里工作多年，有豐富平臺(tái)建設(shè)經(jīng)驗(yàn)。

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

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝