ElasticSearch的一站式搜索實例分析

本篇內(nèi)容主要講解“ElasticSearch的一站式搜索實例分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“ElasticSearch的一站式搜索實例分析”吧!

ElasticSearch 在滴滴的應(yīng)用場景

滴滴自 2016 年 4 月開始組建團隊，解決 ElasticSearch 在使用過程中遇到的性能問題。搜索平臺的建設(shè)是隨著業(yè)務(wù)體量的發(fā)展逐步演進的，如今已經(jīng)發(fā)展到有超過 3500+ ElasticSearch 實例， 5PB 的數(shù)據(jù)存儲，峰值寫入 TPS 超過了 2000W/S 的超大規(guī)模，每天近 10 億次檢索查詢。

ElasticSearch 在滴滴有著非常豐富的應(yīng)用場景：

• 為線上核心搜索業(yè)務(wù)提供引擎支持；

• 作為 RDS 從庫，海量數(shù)據(jù)檢索需求；

• 解決公司海量日志檢索問題；

• 為安全場景提供數(shù)據(jù)分析能力。

不同場景業(yè)務(wù)方對寫入的及時性、查詢的 RT、整體穩(wěn)定性的要求都是不一樣的，我們對平臺提供的服務(wù)抽象為索引模板服務(wù)，用戶可以自助開通相應(yīng)的服務(wù)。

我們內(nèi)部經(jīng)過壓測、線上調(diào)優(yōu)以及引擎的一些優(yōu)化，已經(jīng)將最佳實踐，沉淀到標準的 Docker 鏡像中，個性化的需求都在索引模板的服務(wù)級別進行設(shè)置與管控，部分優(yōu)化如下：

平臺穩(wěn)定性面臨的風險與挑戰(zhàn)

超大的集群規(guī)模和豐富的場景給滴滴 ElasticSearch 平臺帶來了極大的風險與挑戰(zhàn)。主有以下幾個方面：

• 線上業(yè)務(wù)場景

• 穩(wěn)定性要求至少 99.99%，對查詢的 90 分位性能抖動敏感；

• 架構(gòu)層面需要支持多活的需求，對數(shù)據(jù)的一致性與及時性都有要求，必須保證數(shù)據(jù)的最終一致性，數(shù)據(jù)更新秒級可見；

• 不同線上業(yè)務(wù)，插件需求、索引分片規(guī)則都是多樣化的；

• 眾多獨立集群如何快速平滑地進行滾動升級，保障的線上業(yè)務(wù)無影響。

• 準線上業(yè)務(wù)場景

• 離線快速導(dǎo)入時效性要求分鐘級，實時導(dǎo)入 10 億條數(shù)據(jù)需要 5 個小時，導(dǎo)入時在線資源消耗嚴重，線上服務(wù)基本不可用，導(dǎo)入成本消耗過大；

• 查詢的多樣性，14W+ 查詢模板，單索引最高有 100+ 應(yīng)用同時查詢，在多租戶場景下，如何保證查詢的穩(wěn)定性。

• 安全與日志場景

• 千萬級別數(shù)據(jù)每秒的實時寫入，PB 級日志數(shù)據(jù)的存儲，對大規(guī)模 ElasticSearch 的集群提出訴求，但 ElasticSearch 有自己的元信息瓶頸，詳見團隊同學的分享：https://www.infoq.cn/article/SbfS6uOcF_gW6FEpQlLK ；

• 查詢場景不固定，單個索引幾百億級別的數(shù)據(jù)體量，需要保障不合理查詢對集群與索引的穩(wěn)定性風險可控；

• PB 級存儲，查詢頻率低，但查詢的時效性要求 S 級別返回，全部基于 SSD 盤，成本太高，需要在查詢體驗沒有太大變化的情況下，降低整體的存儲成本。

那么，如何解決這些問題呢？歡迎到 QCon 全球軟件開發(fā)大會（廣州站）現(xiàn)場與我面對面交流。

如何打造“存儲成本低”的搜索中臺

目前，在日志與安全分析場景下，存儲成本壓力很大，屬于典型的“寫多查少”的場景，我們對存儲成本的耗散點進行了深入的分析，整體情況如下：

針對資源耗散點，我們在架構(gòu)層面進行了優(yōu)化，整體成本降低了 30%，累積節(jié)省了 2PB 的存儲，分別從以下幾個方面進行了優(yōu)化

• 存儲索引分離：日志原文與索引進行分開存儲

• 不合理的索引字段 Mapping 自動優(yōu)化

• 冷熱數(shù)據(jù)進行了分級存儲

• ES On Docker&Ceph 改造

未來發(fā)展規(guī)劃

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

• 服務(wù)了超過 1200+ 平臺業(yè)務(wù)方，其中 20+ 線上 P0 級應(yīng)用，200+ 準實時應(yīng)用；

• 索引服務(wù)接入效率從原來的兩周降低到 5 分鐘；

• 服務(wù)穩(wěn)定性有保障：線上場景 99.99%，日志場景 99.95%；

• 高頻運維操作一鍵自助完成，90% 的問題，5 分鐘完成定位；

• 整體存儲成本是業(yè)內(nèi)云廠商的 1/3。

不足點

• 目前滴滴 90% 的集群還是在 ElasticSearch 2.3.3 版本，內(nèi)部修復(fù)的 BUG 與優(yōu)化，無法跟社區(qū)進行同步；

• 目前通過 ES-GateWay 的方式支持了多集群方案很好的滿足了業(yè)務(wù)發(fā)展的需求，但是集群變多之后的，版本維護與升級、整體資源利用率提升、容量規(guī)劃都變得非常艱難。

發(fā)展規(guī)劃

• 解架構(gòu)之“熵”

• 突破引擎元數(shù)據(jù)瓶頸，提升運維效率，降低成本 ->ES - Federation;

• GateWay 能力插件式下沉引擎，減少中間環(huán)節(jié)，與社區(qū)融合，優(yōu)化性能。

• 提引擎迭代效率

• 100 個節(jié)點集群滾動重啟時長從 2 天提升至 1 小時；

• 架構(gòu)層面解決跨大版本升級之“痛” 2.2.3 -> 6.6.1 http restful。

• 聚焦價值問題

• 多租戶查詢、CBO、RBO 的查詢優(yōu)化器建設(shè)；

• 數(shù)據(jù)體系化 -> 數(shù)據(jù)智能化；

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

到此，相信大家對“ElasticSearch的一站式搜索實例分析”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！