2019 年 1 月到 2019 年 7 月滴滴 ElasticSearch 團隊(Arius)將維護國內的 30 多個 ES 叢集，2000 多個 ES 節點，4PB 的資料，從 2.3.3 跨大版本無縫升級到 6.6.1。
圖片來自 Pexels
在對使用者查詢寫入基本零影響和改動的前提下，解決了 ES 跨大版本協議不相容、Mapping 不相容等業內難題，整個過程對絕大部分使用者完全透明。
團隊同學經過 7 個月的奮鬥，完成 ES 版本升級的過程中，也完成了滴滴 ElasticSearch 平臺的架構升級。
取得了單機查詢效能提升 40%，整體叢集 CPU 下降 10%，寫入 TPS 提升 30%，歸還物理機近 400 臺，成本節約 80W /月、0 故障的成績，並在引擎上向社群貢獻了 4 個 PR，一位同學升級為 ES Contributor。
如此大規模的跨大版本升級，在 ES 業內也很少見，從開始準備到實際執行，遇到了很多困難，踩了一些坑，期間也有很多我們的思考。
為此我們準備本期的總結和分享，主要從以下幾個方面展開：
背景：推石頭的西西弗斯困難：拔劍四顧心茫然思考：天生我材必有用實戰：百戰沙場碎鐵衣收益：長風破浪會有時展望：直掛雲帆濟滄海背景：推石頭的西西弗斯
滴滴 ElasticSearch 團隊從 2016 年開始建設 ElasticSearch 平臺，在 2016 年 6 月份的時候開始對外提供服務，當時選擇了 ElasticSearch 最新的 2.3 版本。
現在三年過去了，ElasticSearch 生態經歷了飛速的增長，Elastic 公司完成了上市，ElasticSearch 在 db-engines 的分數從 88 上漲到 148，排名從 11 名上升到第 7 名。
這期間 ES 釋出了 3 個大版本，幾十個中版本，而最近 ElasticSearch 已經發布了 7.x 版本。
在這三年中滴滴 Elasticsearch 平臺基於 ElasticSearch 推出了日誌檢索、MySQL 實時資料庫快照、分散式文件資料庫、搜尋引擎等四大服務，四大業務均快速發展。
目前滴滴 ElasticSearch 平臺服務了集團裡面 1200 個應用，其中：訂單、客服、金融、把脈、新政等業務核心實時場景也執行在 Elasticsearch 之上，運維 ES 叢集 30+，寫入 TPS 峰值到達 1500W，查詢 QPS 達到 2W。
業務的快速發展既是滴滴 ElasticSearch 團隊工作的肯定，但隨之而來也有巨大的挑戰和壓力，其中版本過低是未來 ElasticSearch 平臺發展最大制約因素，其中主要有以下幾點。
①社群不再維護老版本：ElasticSearch 2.3.3 版本過於陳舊，ES 社群早已不再進行維護，在 2.x 上遇到的問題社群不解決，提交的 issue 也不處理，提交程式碼也不被接收。
基於 2.3.3 我們也解決了很多 ES 自身的問題，如：Master 更新元資料超時導致記憶體洩露、TCP 協議欄位溢位等。
由於無法和社群互動，團隊同學的價值也得不到社群的認可，長此以往只會和 ES 生態越來越遠，我們在 ES 技術圈中的聲音也會越來越弱。
②新版本特性很難被使用：最近 3 年是 ES 生態大發展的 3 年，ES 自身在功能、效能上都有非常大提升。
如：預設使用 BM25 評分演算法，效果更佳;lucene docvalues 稀疏區域改進，更節約磁碟空間;新增 Frozen indices 能力，可以顯著降低 ES 記憶體開銷。
很多特性也非常適合 ElasticSearch 平臺的場景，但是版本差距過大一直制約著我們，無法享受技術進步的紅利。
一邊是業務快速發展要求更豐富的功能、更強大的效能、更低的成本、更穩定的服務;一邊離最新的業內技術越來越遠，團隊價值越來越弱，逐漸淪為一支只能做業務的偽引擎團隊，整個團隊的現狀就如同推石頭的西西弗斯。
要麼我們迎難而上，克服困難，一口氣把整個叢集升級到最新的版本，把石頭推過山頂，再輕裝前行;要麼就是繼續獨自勉力支撐，在業務和引擎的雙重壓力下蹣跚而行。
滴滴 ElasticSearch 團隊最終選擇對滴滴 ElasticSearch 平臺進行重構並將維護的所有 ES 叢集升級到最新版本。
困難：拔劍四顧心茫然
理想很豐滿，現實很骨感，下決心很容易，然而實際執行很困難：
2.3.3 和 6.6.1 協議不相容啊，6.6.1 都不支援 TCP 協議了，那些通過 TCP 查的使用者怎麼辦，讓他們一個一個改程式碼，那要改到什麼時候?2.3.3 和 6.6.1 有些返回的欄位都不一樣了，有些查詢語法也不相容，怎麼做到對使用者的透明，還是直接強迫使用者接受改變?2.3.3 和 6.6.1 lucene 檔案格式都不一樣，沒辦法原地直接升級，要再搞個叢集全部雙寫一遍。2.3.3 和 6.6.1 的 Mapping 格式不統一，6.6.1 不支援多 type，現有的那些資料搬遷都沒辦法搬。滴滴 ElasticSearch 平臺現在不支援索引多版本同時查詢，使用者查詢習慣也千奇百怪，很多帶*查詢你根本控制不了。使用者那麼多，使用差異很大，怎麼和使用者進行溝通和宣導，怎麼遮蔽使用者影響和管理用於預期?就算是要搬遷升級，哪裡去找那麼多機器，現在還要機房裁撤，還要往外拿機器。幾十個叢集，幾千個節點都要部署、搭建、重啟，還要騰挪上千臺機器。慢點搞，這得搞到什麼時候，快點搞，萬一出問題怎麼辦?就算是雙寫升級了，怎麼知道中間有沒有問題，資料有沒有丟失，使用者的查詢是不是一致的，功能和效能有沒有達到預期，這個怎麼驗證?這麼多資料，這麼多人在用，這麼點資源，業務穩定壓力又大，估計今年一年都搞不完。…………在剛開始決定進行跨版本升級之後，我們面臨的問題就撲面而來，其中任何一條不解決，都會極大的阻礙升級的程序。
思考：天生我材必有用
在起步階段有很多問題雜糅在一起，需要理清楚每個問題的重要性、緊急程度、影響層面、相互依賴關係，通過分析歸納我們將其總結為四大問題域：
首先進行架構升級：解決引擎側 2.x/6.x 的不相容問題，所有的協議、查詢語法、Mapping 等不相容處理在平臺側進行處理。
同時我們開發了一個 ES java SDK 用來解決 6.x 不支援 TCP 介面的問題，使用方式和原有的 es java client 完全一致，使用者只要修改 pom 即可。
具體包括：Arius 平臺多版本支援、Gateway 的多版本相容、使用者 SDK 開發、AMS 資料採集等，具體見後續詳細說明。
其次解決運維問題：解決運維操作過程中多叢集搭建、部署、重啟的管控問題，提升操作的便利性，提升升級的操作效率，具體見後續詳細說明。
再次解決資源問題：解決搬遷升級所需要的大量機器資源問題，為大量叢集升級做充足準備，同時還要滿足機房裁撤歸還機器的要求。
具體包括：索引儲存週期優化、冷熱資料分離、Mapping 優化、fastIndex 等，具體見後續詳細說明。
最後開始實際推進：在做好前期的所有準備工作之後，開始實際推進升級過程。具體包括：效能壓測、資源評估、批量雙寫、查詢回放，其中還有一些意想不到的採坑和填坑的過程，具體見後續詳細說明。
實戰：白沙戰場碎鐵衣
在理清了整個升級過程中的各個環節的依賴關係、資源消耗、瓶頸點之後，針對架構、資源、實操等三個方面的問題，我們都設計了對應的解決方案，主要如下：
架構
①滴滴 ElasticSearch 平臺 ES 多版本支援的架構改造
首先我們在滴滴 ElasticSearch 平臺上完成了 ES 多版本支援的架構升級，其中重點有：
Arius Gateway 對跨版本查詢差異的相容，以及多叢集下索引跨高低版本叢集訪問，使得在升級過程中對使用者查詢結果透明。Elasticsearch-didi-interanl-client SDK 開發，對使用者遮蔽 ES TCP/HTTP 查詢差異，解決 ES 6.x 版本不支援 TCP 介面的問題，原有 2.x 的使用者只要修改一行 pom 就可以切換到高版本訪問。滴滴 ElasticSearch 平臺架構梳理以及 Arius admin 多版本支援。②基於彈性雲的 ES 多叢集管控方案
目前滴滴 ElasticSearch 團隊運維 30 多個 ES 叢集，5000+ 的 ES 節點，叢集規模大，場景複雜，運維管控成本比較高。
為此我們設計開發了 ECM(ElasticSearch Cluster Manager)系統用於 ES 叢集的部署、重啟、擴容、配置管控等一系列操作。
並且我們 80% 的 ES 節點執行在彈性雲上，結合彈性雲靈活高效的特點，使得我們在進行搬遷升級的過程更加高效。
我們構建了一套 AMS(Arius MetaData Service)服務，用於採集和分析 ES 所有叢集、節點、索引的各種資料。
包括：容量資訊(叢集、節點、模板、索引、租戶)、TPS/QPS 資訊(叢集、節點、模板、索引、租戶)、執行資訊、查詢語句、查詢模板資訊、查詢結果和命中率的分析資訊等等。
在這些基礎的指標資料基礎上，我們構建了全面的 ES 執行指標系統，可以全面的了解和監控叢集、節點、索引、租戶級別的執行資訊。
詳盡的資料為後續的 ES 的成本優化提供了基礎，具體見 —— 基於資料驅動的 ES 分級儲存體系，分級儲存體系的構建使得我們構建了一套體系化的ES成本節約的系統。
詳盡的資料為後續升級時做查詢的流量回放對比提供了基礎，具體見——基於 ES 服務元資料的查詢流量回放對比系統，使得我們在升級過程中可以快速驗證升級結果，提升升級效率和穩定性。
同時 AMS 還對資料的可靠性負責，保證產生的資料是及時並且準確的，這樣依賴 AMS 的資料分析服務。
如：分級儲存、容量規劃、回放系統、成本賬單、叢集健康檢查、索引健康分等，只用專注自身的邏輯的實現即可。
資源
在解決架構和相容性問題之後，我們已經有信心將一個叢集線上升級到新版本。
然而由於版本跨度太大無法在原叢集上直接進行滾動升級，必須要進行資料雙寫的搬遷升級，這樣升級所需要的 buff 資源就成為制約整個升級進度最重要的因素，因此接下來我們把精力放在節省資源提高資源利用率上。
通過內外挖潛和技術改造，不僅支援了版本升級所需要的機器資源(高峰時 3 個叢集同時升級)，最終還歸還了近 400 臺機器，節約成本 80W+ /月。
①基於資料驅動的 ES 分級儲存體系
基於 AMS 對應索引的大小、資料量、查詢量、查詢條件、查詢時間、返回結果的統計和分析，我們能精確的分析出來每個索引被使用的場景以及被查詢的方式。
如：索引的高頻查詢時間區間、索引被檢索的欄位等，在資料分析基礎上我們針對每個索引進行了 Mapping 優化、儲存週期優化、冷熱資料儲存優化。
在不影響使用者使用需求的前提下，累計節省資料 1PB，搬遷冷資料 700TB，不僅保障了升級過程中有充足的 buff 機器，還歸還了近 400 臺物理機，節省成本 70W+ /月。
②ES FastIndex 離線資料匯入體系
ES FastIndex 的初衷是為了解決集團標籤系統的離線匯入的效率和資源問題，集團標籤系統每天有 30 多 TB 的資料需要在短時間內同步到 ES 中，否則將會影響當天的業務結果，之前方案為了滿足效率採用了大量的機器資源。
採用基於 Hadoop 的 ES fastIndex 離線資料匯入系統之後，同樣的資料匯入時間由原來的 8 個小時下降到 2 個小時。
機器成本由原來的 40 臺物理機 (ES 27 臺、Kafka 3 臺、Dsink 10 臺) 下降到 30 臺彈性雲節點(10 臺物理機)，單單在標籤場景就節約成本 7W+ 每月。
提升 ES 叢集資源使用率也是滴滴 ElasticSearch 團隊一直面臨和致力於解決的問題。
滴滴 ElasticSearch 團隊維護的 ES 機器總容量將近 5PB，提升 10% 的資源使用率即可節約 500TB 的空間，或者用於歸還機器，或者用於服務新的需求。
當前 ES 叢集整體磁碟使用率在 50% 左右，高峰期曾經達到 60%，日誌叢集磁碟使用率達到 69.5% (2019.05.01)，但是這個時候叢集資源非常不均，磁碟告警也很嚴重，運維壓力非常大，偶爾還會出現丟資料的問題。
為此我們在原有的 ES 機器容量規劃演算法上，加入了資源 Qutoa 管控，並深入引擎，在引擎層面完善 ES 節點的容量規劃和資源均勻，期望將 ES 叢集的磁碟整體使用率再提升 10%，日均達到 60%，高峰達到 70%，並且沒有磁碟告警和穩定性問題。
實操
在前期準備工作都完成之後，叢集升級就成為一個按部就班的過程，雖然期間也遇到了一些意想不到的情況，踩了一些坑，但整體的過程還是進行的比較順利。
①基於 ES 服務元資料的查詢流量回放對比系統
在前期構建的 AMS(Arius Meta Service)系統上，我們對使用者查詢條件、查詢結果進行記錄和分析。
在雙寫搬遷升級過程中，我們將使用者的查詢條件分別在高低版本的叢集上進行回放，將查詢返回的結果、效能引數進行對比分析。
只有對比一致，並且效能無太大差異的情況下，我們才認為升級有效，這樣做到心中有底。
②基於 ECM 的 ES 多叢集升級過程
由於需要進行雙寫搬遷升級，在實際的升級過程中，需要密集的進行叢集搭建、搬遷、重啟等操作，得益於 ECM 的叢集管控能力，彈性雲靈活的特性，我們和運維同學密切配合才能在短時間內完成多個叢集的升級工作。
ES 6.6.1 提供了很多新的特性，在查詢寫入效能上也有很大的提升，我們升級完成的一些案列也得到了驗證，我們會這些特性和效能提升進行一個詳細的分析並分享給大家。
④ES 版本升級採坑分析
在升級的過程中我們也踩了一些坑，如：高版本 SDK 堆外記憶體無限制使用導致 OOM 的問題，我們把遇到的問題都詳細記錄下來進行並分享給大家。
收穫：長風破浪會有時
經過近半年的開發和重構，在將國內叢集升級到高版本的過程中，我們也在架構、產品、成本、效能、特性、自身能力上都有了很大的提升。
架構更清晰
重構之後整個滴滴 ElasticSearch 平臺的服務體系變得更清晰，主要收斂為四大塊應用：
Gateway 負責查詢寫入請求的接入，使用者的限流、許可權校驗、版本相容在此完成。ECM 負責所有叢集的管控，叢集搭建、升級、重啟、叢集級別監控和運維分析在此完成。AMS 負責所有叢集、節點、索引的執行時資訊採集與分析，保障資料品質，並支援其他資料分析應用，分級儲存、索引健康分、叢集健康檢查、查詢回放等在此完成。Arius Admin 負責索引、許可權、資源管控等核心能力。依賴 Admin 的核心能力以及 AMS 的資料採集能力，還提供了容量規劃和智慧告警兩個設計良好並且可插拔的擴充套件服務。四個應用完成功能抽象、依賴解耦和服務化改造，相比之前下線了 arius-watch、arius-dsl、arius-tools、arius-monitor、arius-mark 等五個小應用，重構之後整體開發效率和可運維性得到了很大的提高。
產品更易用
我們基於 ES 6.5.1 版本，完全重構了滴滴 ElasticSearch 使用者控制檯，其中將使用者的一些高頻操作，如：Mapping 設定/變更、資料清理、索引擴容縮容、索引轉讓、成本賬單等開放給使用者，提升使用者的自助操作性。
未來我們還會對滴滴 ElasticSearch 使用者控制檯中的 Kibana 升級到最新版本並進行定製化開發，提供更豐富和更強大的功能給使用者使用。
成本更低廉
之前滴滴 ElasticSearch 平臺有一套基於索引建立規則的容量規劃演算法，相比完全沒有規劃，老版容量規劃演算法可以將整體的叢集資源使用率由 30% 提升到 50% 左右。
但是也存在著一些問題，如：資源分佈不均、熱點無法快速發現、動態自適應能力低、規劃演算法抽象不夠無法在索引叢集生效、運維便利性差。
下圖展現了一個日誌叢集新老容量規劃的磁碟使用率對比，上線新的容量規劃之後，叢集資源會向著兩個方向發展：
經過一系列的儲存優化和資源使用率改造的完成，在滿足叢集升級和業務需要增長的基礎上，國內 ES 的資源成本從 2019 年 2 月的 339w 下降到 2019 年 6 月的 259w，機器數也從 1658 臺下降到 1321 臺。
隨著國內叢集升級逐漸全部完成，Ceph 冷存的完善，還會逐步歸還更多的機器，滴滴 ElasticSearch 平臺的使用成本也會一步一步下降，在定價上我們也會考慮進一步的進行降價。
效能更強大
新版本升級之後帶來的效能主要體現在以下兩點：
①查詢效能提升
下圖是客服訂單列表查詢語句升級前後的對比，50 分位耗時從 300ms 下降到 50ms。99 分位從 600ms 下降到 300ms。
效能提升的詳細分析見：ES 新版本特性以及升級性能分析。
②叢集寫入效能提升
升級到高版本只會，ES 6.6.1 叢集相對於 ES 2.3.3 叢集同等資源消耗下，整個叢集的寫入能力提升了 30%。
如下圖日誌叢集的寫入 TPS 前後對比，叢集寫入能力從 240w/s 提升到320w/s。
展望：直掛雲帆濟滄海
至此，滴滴 ElasticSearch 團隊已經完成了國內全部日誌叢集、90% 的 vip 叢集的升級，整個滴滴 ElasticSearch 平臺的架構也得以重構和升級，從而在 ES 引擎層面也有了更大的發展空間。
未來我們將更加專注於引擎建設，更多的從根本上解決目前遇到的問題。未來我們將在以下幾個方向持續努力：
①更大的叢集
在日誌場景下嘗試突破 ES 單叢集支援的最大節點數限制，提升單個叢集能支援的節點數量，從目前的單叢集支援的 200 個節點提升到 1000 個節點。
期待在大叢集下能降低我們的叢集數量提升運維效率，同時更大的叢集能更方便和更靈活的提升資源使用率，解決流量突增和資源熱點問題。
②更低的成本
降低 ES 的使用成本，提升資源使用率一直是我們追求的目標，上半年我們在完成叢集升級以及服務好業務的同時也完成節約成本 80w 每月，ES 整體成本下降約 25%，下半年爭取再下降成本 10%。
ES 6.6.1 提供的一些新特性如：Frozen 機制、Indexing sort 都將會進一步降低資源消耗。
ES 叢集內多租戶查詢之間的相互影響一直也是滴滴 ElasticSearch 團隊面臨的一個比較難解決的問題，之前更多的是在平臺層面通過物理資源隔離，查詢稽核和限流來解決，資源利用率不高和人為運維成本太大。
後續我們將構建一套 ES 自身的查詢優化器，類似 MySQL 的 Explain，可以在查詢語句級別進行效能分析和查詢優化，並在引擎層面通過索引模板級別的查詢資源隔離、一般 query 和 heavy query 的分離來保障查詢的穩定。
④更緊密的聯絡
在 ES 新版的基礎上，我們將和社群保持更緊密的聯絡，積極的跟進社群提供的新特性和發展方向，並引入滴滴供大家使用。
也會更積極的參與社群建設，將我們在滴滴內部遇到和解決的問題反饋給社群，貢獻更多的 PR 和產生更多的 ES Contributor。
簡介：滴滴專家工程師 2018 加入滴滴，滴滴搜尋團隊負責人，全面負責滴滴搜尋平臺的建設工作。曾在阿里巴巴工作多年，有豐富的平臺建設經驗。