ElasticSearch 在滴滴的應用場景
滴滴自 2016 年 4 月開始組建團隊，解決 ElasticSearch 在使用過程中遇到的性能問題。搜索平臺的建設是隨着業務體量的發展逐步演進的，如今已經發展到有超過 3500+ ElasticSearch 實例， 5PB 的數據存儲，峯值寫入 TPS 超過了 2000W/S 的超大規模，每天近 10 億次檢索查詢。
ElasticSearch 在滴滴有着非常豐富的應用場景：
- 爲線上核心搜索業務提供引擎支持；
- 作爲 RDS 從庫，海量數據檢索需求；
- 解決公司海量日誌檢索問題；
- 爲安全場景提供數據分析能力。
不同場景業務方對寫入的及時性、查詢的 RT、整體穩定性的要求都是不一樣的，我們對平臺提供的服務抽象爲索引模板服務，用戶可以自助開通相應的服務。
我們內部經過壓測、線上調優以及引擎的一些優化，已經將最佳實踐，沉澱到標準的 Docker 鏡像中，個性化的需求都在索引模板的服務級別進行設置與管控，部分優化如下：
平臺穩定性面臨的風險與挑戰
超大的集羣規模和豐富的場景給滴滴 ElasticSearch 平臺帶來了極大的風險與挑戰。主有以下幾個方面：
-
線上業務場景
- 穩定性要求至少 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 的存儲計算分離。