滴滴基於 ElasticSearch 的一站式搜索中臺實踐

ElasticSearch 在滴滴的應用場景

滴滴自 2016 年 4 月開始組建團隊,解決 ElasticSearch 在使用過程當中遇到的性能問題。搜索平臺的建設是隨着業務體量的發展逐步演進的,現在已經發展到有超過 3500+ ElasticSearch 實例, 5PB 的數據存儲,峯值寫入 TPS 超過了 2000W/S 的超大規模,天天近 10 億次檢索查詢。後端

ElasticSearch 在滴滴有着很是豐富的應用場景:安全

  • 爲線上核心搜索業務提供引擎支持;微信

  • 做爲 RDS 從庫,海量數據檢索需求;restful

  • 解決公司海量日誌檢索問題;架構

  • 安全場景提供數據分析能力。app

不一樣場景業務方對寫入的及時性、查詢的 RT、總體穩定性的要求都是不同的,咱們對平臺提供的服務抽象爲索引模板服務,用戶能夠自助開通相應的服務。運維

咱們內部通過壓測、線上調優以及引擎的一些優化,已經將最佳實踐,沉澱到標準的 Docker 鏡像中,個性化的需求都在索引模板的服務級別進行設置與管控,部分優化以下:性能

平臺穩定性面臨的風險與挑戰

超大的集羣規模和豐富的場景給滴滴 ElasticSearch 平臺帶來了極大的風險與挑戰。主有如下幾個方面:優化

  • 線上業務場景spa

    • 穩定性要求至少 99.99%,對查詢的 90 分位性能抖動敏感;

    • 架構層面須要支持多活的需求,對數據的一致性與及時性都有要求,必須保證數據的最終一致性,數據更新秒級可見;

    • 不一樣線上業務,插件需求、索引分片規則都是多樣化的;

    • 衆多獨立集羣如何快速平滑地進行滾動升級,保障的線上業務無影響。

  • 準線上業務場景

    • 離線快速導入時效性要求分鐘級,實時導入 10 億條數據須要 5 個小時,導入時在線資源消耗嚴重,線上服務基本不可用,導入成本消耗過大;

    • 查詢的多樣性,14W+ 查詢模板,單索引最高有 100+ 應用同時查詢,在多租戶場景下,如何保證查詢的穩定性。

  • 安全與日誌場景

    • 千萬級別數據每秒的實時寫入,PB 級日誌數據的存儲,對大規模 ElasticSearch 的集羣提出訴求,但 ElasticSearch 有本身的元信息瓶頸,詳見團隊同窗的分享:https://www.infoq.cn/article/SbfS6uOcF_gW6FEpQlLK ;

    • 查詢場景不固定,單個索引幾百億級別的數據體量,須要保障不合理查詢對集羣與索引的穩定性風險可控;

    • PB 級存儲,查詢頻率低,但查詢的時效性要求 S 級別返回,所有基於 SSD 盤,成本過高,須要在查詢體驗沒有太大變化的狀況下,下降總體的存儲成本。

那麼,如何解決這些問題呢?歡迎到 QCon 全球軟件開發大會(廣州站)現場與我面對面交流。

如何打造「存儲成本低」的搜索中臺

目前,在日誌與安全分析場景下,存儲成本壓力很大,屬於典型的「寫多查少」的場景,咱們對存儲成本的耗散點進行了深刻的分析,總體狀況以下:

針對資源耗散點,咱們在架構層面進行了優化,總體成本下降了 30%,累積節省了 2PB 的存儲,分別從如下幾個方面進行了優化

  • 存儲索引分離:日誌原文與索引進行分開存儲

  • 不合理的索引字段 Mapping 自動優化

  • 冷熱數據進行了分級存儲

  • ES On Docker&Ceph 改造

將來發展規劃

基於 ElasticSearch 的搜索中臺給用戶帶來的收益

  • 服務了超過 1200+ 平臺業務方,其中 20+ 線上 P0 級應用,200+ 準實時應用;

  • 索引服務接入效率從原來的兩週下降到 5 分鐘;

  • 服務穩定性有保障:線上場景 99.99%,日誌場景 99.95%;

  • 高頻運維操做一鍵自助完成,90% 的問題,5 分鐘完成定位;

  • 總體存儲成本是業內雲廠商的 1/3。

不足點

  • 目前滴滴 90% 的集羣仍是在 ElasticSearch 2.3.3 版本,內部修復的 BUG 與優化,沒法跟社區進行同步;

  • 目前經過 ES-GateWay 的方式支持了多集羣方案很好的知足了業務發展的需求,可是集羣變多以後的,版本維護與升級、總體資源利用率提高、容量規劃都變得很是艱難。

發展規劃

  • 解架構之「熵」

    • 突破引擎元數據瓶頸,提高運維效率,下降成本 ->ES - Federation;

    • GateWay 能力插件式下沉引擎,減小中間環節,與社區融合,優化性能。

  • 提引擎迭代效率

    • 100 個節點集羣滾動重啓時長從 2 天提高至 1 小時;

    • 架構層面解決跨大版本升級之「痛」 2.2.3 -> 6.6.1 http restful。

  • 聚焦價值問題

    • 多租戶查詢、CBO、RBO 的查詢優化器建設;

    • 數據體系化 -> 數據智能化;

    • 基於 Ceph、Docker 改造 ElasticSeach,支持 Cloud Native 的存儲計算分離。


本文分享自微信公衆號 - 互聯網後端架構(fullstack888)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索