騰訊如何用Elasticsearch挖掘萬億數據價值？

時間 2020-01-16

標籤騰訊如何 elasticsearch 挖掘萬億數據價值欄目騰訊简体版

原文原文鏈接

原文：https://mp.weixin.qq.com/s/FVbjGTvZP97u5CAydDx7dwjava

前言

Elasticsearch（ES）是近年來煊赫一時的開源分佈式搜索分析引擎，經過簡單部署，它能夠輕鬆實現日誌實時分析、全文檢索、結構化數據分析等多重訴求，並將挖掘數據價值的成本大幅下降。程序員

ES在騰訊內部和騰訊雲用戶中擁有豐富的大規模落地場景，它們持續地推進着原生ES朝着高可用、高性能、低成本的方向優化。本文即將介紹騰訊在ES的應用落地過程當中，遇到的挑戰、優化思路、優化成果和將來探索方向，但願能爲開發者們提供參考。面試

1、ES的應用場景

1.騰訊內部應用場景

在騰訊內部，ES的應用場景主要有「日誌實時分析、搜索服務、時序數據分析等。

1.【日誌實時分析場景】

典型場景以下：

運營日誌：如慢日誌、異常日誌（用來定位業務問題）；
算法

業務日誌：如用戶的點擊、訪問日誌（用來分析用戶行爲）；
api

審計日誌：可用於安全分析。
數組

ES 完美解決了日誌實時分析的需求，它具備以下特色：

Elastic生態完整：任何一個開發者，可經過簡單部署成熟的組件，搭建起一個完整的日誌實時分析系統。
緩存

時效性極高：日誌從產生到可訪問的耗時通常在10S級。相比於傳統大數據解決方案几十分鐘~幾小時的耗時，時效性提升了數百倍。
安全

靈活的搜索分析能力：因爲支持倒排索引、列存儲等數據結構，ES擁有很是靈活的搜索分析能力。
服務器

搜索響應時間短：ES支持交互式分析，即便有萬億級的日誌，其搜索響應時間也是秒級。
網絡

ES在這幾年的蓬勃發展，離不開它完美地支持「日誌實時分析場景」這一能力。

2.【搜索服務場景】

典型場景以下：

商品搜索：即各大電商平臺中的商品搜索；

APP 搜索：即應用商店裏的應用搜索；

站內搜索：即論壇、在線文檔等搜索功能。

騰訊使用ES支持了大量的搜索服務，它們主要有如下特色：

高性能：單個服務最大達到 10w+ QPS，平均響應時長約20ms，P95延時小於100ms。

強相關：搜索體驗主要取決於「搜索結果」與「用戶意圖」之間的匹配度，可經過正確率、召回率等指標進行評估。

高可用：搜索場景一般要求4個9的可用性，並支持單機房故障容災。

3.【時序數據分析場景】

典型的時序數據包含：

Metrics：即傳統的服務器監控。

APM：應用性能監控。

傳感器數據：由物聯網數據，智能硬件、工業物聯網等產生。

騰訊很早就涉足了這類場景，並積累了深厚的經驗。這類場景具備如下特色：

高併發寫入：線上單集羣最大規模高達 600+節點，寫入吞吐量爲1000w/s 。

高查詢性能：要求單條曲線或者單個時間線的查詢延時在10ms級。

多維分析：要求靈活、多維度的統計分析能力，如在查看監控時，能夠按照地域、業務模塊等不一樣維度進行統計分析。

2.業界應用場景

在業界，ES的主要應用場景更多見於電子商務平臺上，好比對商品、標籤、店鋪的搜索。

年GMV達到200億的電子商務網站M就是一個典型的例子，它在ES的應用場景也很是普遍，包括商品搜索推薦、日誌分析監控、統計分析等。其業務團隊運行着幾十個ES集羣，而且規模不斷在增加。

2、遇到的挑戰

1.騰訊遇到的挑戰

在騰訊內部如此大規模、高壓力、多場景的業務背景下，ES的應用着實遭到了很多挑戰，這些挑戰基本能夠劃分爲兩類：搜索類和時序類。

1.【 搜索類】

高可用：以電商搜索、APP 搜索、站內搜索爲例，它們重視可用性，服務SLA爲4個9以上，須要考慮單機故障、單機房網絡故障等災備場景。

高性能：它們對性能有極高的標準，如 20w QPS、平響 20ms、P95延時100ms。

總之，在搜索類業務場景下，核心挑戰點在於 高可用、高性能。

2.【 時序類】

時序類場景包含日誌、Metrics、APM 等。相比於搜索類業務聚焦高可用、高性能的問題，時序類業務會更注重成本、性能。

舉個例子，時序場景用戶一般要求高寫入吞吐，部分場景可達 1000w/s；在這樣寫入吞吐下，保留30天的數據，存儲量可達PB級。若是用戶用於線上實際業務的機器數量是 100 臺，而監控、日誌等須要 50 臺，這對多數用戶來講基本是不可接受的（由於監控、日誌的收益相對較低）。因此在時序類業務中，主要的挑戰在於存儲成本、計算成本等方面。

面對如此艱鉅的挑戰，騰訊在ES內核方面進行了深刻的優化實踐（這種優化後的成果也經過騰訊雲開放給了外界的用戶，其中就有電子商務網站M）。

2.業界遇到的挑戰

業界也經歷着與騰訊相似的挑戰。仍是以電子商務網站M爲例，電商常常性的大促，他們不得不關注ES集羣的 穩定性和集羣的 容災備份。

在集羣穩定性方面，他們常常碰到的問題是「範圍較大的查詢，會致使ES節點的JVM OOM（內存溢出），影響集羣穩定性」，以及「索引數或分片數過多時，集羣元數組變動慢且CPU負載高，從而影響集羣穩定性」。

在容災備份方面，他們常常碰到的問題是「單機房故障時，如何保證服務不中斷」，以及「故障發生後，數據如何恢復」。

3、ES 優化實踐

首先，針對「高可用」的需求，騰訊的開發者們化整爲零，各個突破，把高可用劃分爲三個維度：

1系統健壯性：指 ES 內核自身的健壯性，這也是分佈式系統面臨的共性難題。例如：

在異常查詢、壓力過載下集羣的容錯能力；

在高壓力場景下，集羣的可擴展性；

在集羣擴容、節點異常場景下，節點、多硬盤之間的數據均衡能力。

2.容災方案：如經過建設管控系統，保障機房網絡故障時快速恢復服務、天然災害下防止數據丟失、誤操做後快速回滾等。

3.系統缺陷：這是任何系統在發展的過程當中都不可避免的問題，好比Master 節點堵塞、分佈式死鎖、滾動重啓緩慢等。

針對上述問題，騰訊的ES解決方案以下：

1. 系統健壯性：

服務不穩定：經過服務限流，容忍機器網絡故障、異常查詢等異常狀況。

集羣擴展性問題：經過優化集羣元數據管控邏輯，提高了10倍的集羣擴展能力，支持千級節點集羣、百萬分片；

集羣均衡問題：經過優化節點、多硬盤間的分片均衡，保證大規模集羣的壓力均衡。

2. 容災方案：

數據可恢復：

經過擴展 ES 的插件機制支持備份回檔，把 ES 的數據備份回檔到廉價存儲，保證數據的可恢復；

故障容忍：

騰訊雲ES支持跨可用區容災，用戶能夠按需部署多個可用區，以容忍單機房故障。

此外，騰訊雲ES還支持COS備份的功能，用戶能夠經過操做ES的api，直接備份底層的數據文件到騰訊雲對象存儲COS上，實現了低成本、操做簡便的數據備份功能。

異常恢復：

經過垃圾桶機制，保證用戶在欠費、誤操做等場景下，集羣可快速恢復。

3. 系統缺陷：

騰訊修復了原生ES在滾動重啓、Master 阻塞、分佈式死鎖等方面的Bug。其中滾動重啓優化，可加速節點重啓速度5倍以上；Master 堵塞問題，騰訊在ES6.x版本和Elastic官方一塊兒作了優化。

在服務限流部分，騰訊作了 4 個層級的限流工做：

權限層級：優化後，ES支持 XPack 和自研權限來防止攻擊和誤操做；

隊列層級：經過優化任務執行速度、重複、優先級等細節，解決用戶常常遇到的Master 任務隊列堆積、任務餓死等問題；

內存層級：從ES 6.x 開始，支持在全鏈路上（包括HTTP 入口、協調節點、數據節點等）進行內存限流：同時使用 JVM 內存、梯度統計等方式進行精準控制；

多租戶層級：使用 CVM/Cgroups 方案保證多租戶間的資源隔離。

這裏展開介紹下聚合場景限流的問題，用戶在使用 ES 進行聚合分析時，常常因聚合分桶過多打爆內存。官方在 ES 6.8 中提供 max_buckets 參數控制聚合的最大分桶數，但這個方式侷限性很是強：內存是否會被打爆還取決於單分桶的大小（在某些場景下，用戶設置 20 萬個分桶能夠正常工做，但在另外一些場景下，可能 10 萬個分桶內存就已經打爆），所以用戶並不能準確把握該參數應設置爲多少。此時騰訊採用梯度算法進行優化，每分配 1000 個分桶檢查一次 JVM 內存，當內存不足時及時中斷請求，保證了ES集羣的高可用。

這些限流方案，可以解決在異常查詢、壓力過載、單節點故障、網絡分區等場景下，ES 服務的穩定性問題。但還有少許場景沒有觸達，所以騰訊目前正在探索，經過依賴混沌測試覆蓋更多異常場景。

針對「索引數或分片數過多，致使的集羣元數據變動慢且CPU負載高，從而影響集羣穩定性」的問題，在內核上，騰訊優化了shard分配的算法，利用緩存節點routing表和元數據增量更新的方法，加快集羣元數據的變動速度。

解決了高可用和高性能的問題，下面該談談成本優化方面的實踐了。

成本方面的挑戰，主要體如今時序場景（如日誌、監控）對機器資源的消耗，經過對線上典型的日誌、時序業務分析可得，硬盤、內存、計算資源的成本比例接近 8:4:1。也就是說，硬盤、內存是主要矛盾，其次是計算成本。

時序數據有很明顯的訪問特性：」近多遠少」。最近七天數據的訪問量佔比大於95%；歷史數據訪問較少，且一般都是訪問統計類信息。

基於這些瓶頸分析和數據訪問特性，成本優化的解決方案以下：

（1）採用冷熱分離架構，使用混合存儲的方案來平衡成本、性能；

（2）既然對歷史數據一般都是訪問統計信息，那麼經過預計算來換取存儲和性能；

（3）若是歷史數據徹底不使用，能夠備份到更廉價的存儲系統；

（4）基於時序數據的訪問特性，內存成本方面能夠利用 Cache 進行優化。

（5）其餘一些優化方式：如存儲裁剪、生命週期管理等。

這裏展開介紹下 Rollup 部分。Rollup 相似於大數據場景下的Cube、物化視圖，它的核心思想是經過預計算提早生成統計信息，釋放原始粒度數據，從而下降存儲成本、提升查詢性能。這裏舉個簡單的例子：在機器監控場景下，原始粒度的監控數據是10 秒級的，而一個月以前的監控數據，通常只需查看小時粒度，這便是一個 Rollup 應用場景。官方從 ES 6.x 開始推出 Rollup，實際上騰訊在 5.x 已經着手研究。

在大數據領域，傳統的方案是依賴外部離線計算系統，週期性地讀取全量數據進行計算，這種方式計算開銷、維護成本高。

谷歌的廣告指標系統 Mesa 採用持續生成方案，數據寫入時系統給每一個 Rollup 產生一份輸入數據，並對數據進行排序，底層在 Compact/Merge 過程當中經過多路歸併完成 Rollup，這種方式的計算、維護成本相對較低。

ES 從 6.x 開始支持數據排序，騰訊經過流式查詢進行多路歸併生成 Rollup，最終計算開銷小於全量數據寫入時 CPU 開銷的 10%，內存使用小於10MB。這種內核優化方式已被騰訊貢獻給開源社區，以解決開源 Rollup 的計算、內存瓶頸。

前文說起不少用戶在使用大存儲機型時，內存優先成爲瓶頸、硬盤不能充分利用，這類問題主要瓶頸在於索引佔用大量內存。考慮到時序類場景不多訪問歷史數據，部分場景下某些字段基本不使用，所騰訊經過引入 Cache 來提升內存利用效率。

在內存優化方面，業界有怎樣的方案？

ES 社區從7.x後支持索引放於堆外，和 DocValue 同樣按需加載。這種方式的缺點在於索引和數據的重要性徹底不一樣，一個大查詢容易致使索引被淘汰，後續查詢性能倍數級的衰減。

Hbase 經過Cache 緩存索引、數據塊，提高熱數據訪問性能，並從 HBase 2.0 開始，重點介紹其 Off Heap 技術，讓堆外和堆內的內存訪問性能接近。基於社區經驗進行迭代，騰訊在ES中引入LFU Cache以提升內存利用效率，把 Cache 放置在堆外以下降堆內存壓力，同時經過Weak Reference堆內外拷貝等技術下降損耗。經過這種方法，內存利用率提高80%，查詢性能損耗不超過 2%，GC 開銷下降 30%。

說到性能方面的優化實踐，以日誌、監控爲表明的時序場景爲例，它們對寫入性能要求極高，寫入併發高達1000w/s。然而在帶主鍵寫入時，ES 性能衰減 1+倍，部分壓測場景下，CPU 沒法充分利用。以搜索服務爲表明的場景對查詢性能的要求很是高，每每要求20w QPS, 平響 20ms，且需避免 GC、執行計劃不優等緣由形成的查詢毛刺。

針對上述問題，騰訊亦有對策：

（1）寫入優化：針對主鍵去重場景，利用索引進行裁剪，加速主鍵去重的過程，使寫入性能提高 45%。此外，經過向量化執行優化寫入性能，經過減小分支跳轉、指令 Miss，也是騰訊探索中的方向之一，預計性能可提高1倍。

（2）CPU利用率優化：針對部分壓測場景下 CPU 不能充分利用的問題，經過優化 ES 刷新 Translog 時的資源搶佔，使性能提高 20%。

（3）查詢優化：經過優化 Merge 策略提高查詢性能。基於每一個 Segment 記錄的 min/max 索引進行查詢剪枝，提高了30%的查詢性能。經過CBO策略，避免查詢 Cache 操做致使查詢耗時10+倍的毛刺。此外，經過一些新硬件（如英特爾的 AEP、Optane、QAT 等）來優化性能也是不錯的探索方向。

下面，詳細談談Merge 策略優化部分：ES 原生的 Merge 策略主要關注大小類似性（Merge 時儘可能選擇大小類似的 Segments）和最大上限（考慮儘可能把 Segment 拼湊到 5GB）。那麼有可能出現：某個Segment中包含了1月整月、3月1號的數據，當用戶查詢3月1號某小時的數據時，就必須掃描大量無用數據，導致性能損耗嚴重。

針對上述問題，騰訊在ES中引入了時序Merge：在選擇 Segments 進行 Merge 時，重點考慮時間因素，讓時間相近的 Segments 被Merge 到一塊兒。當用戶查詢3月1號的數據時，只須要掃描個別較小的 Segments ，其它的 Segments 能夠被快速裁剪。

另外，ES官方推薦搜索類用戶在寫入完成以後，進行一次 Force Merge：其用意是把全部 Segments 合併爲一個，以提升搜索性能。但這增長了用戶的使用成本，且在時序場景下須要掃描所有數據，不利於裁剪。

由此，騰訊在 ES 中引入了冷數據自動 Merge：對於非活躍的索引，底層 Segments 會自動 Merge 到接近 5GB，下降文件數量的同時，方便時序場景裁剪。對於搜索場景，用戶能夠調整目標 Segment 的大小，使全部 Segments 最終 Merge 爲一個。這種Merge 策略的優化，可以使搜索場景性能提高 1 倍。

在接入騰訊雲ES後，電子商務網站M的ES基礎能力和開發運維效率都獲得了顯著的提高：

可靠性：基於騰訊對ES內核優化後的能力，電子商務網站M的ES集羣可靠性有着明顯的提高，扛起了多重流量洪峯，收穫了明顯的經濟效益。

安全容災：多可用區提供了容災保障、X-Pack權限管理提供了安全保障；

運維效率：雲上提供了高效部署和穩定的彈性伸縮能力，X-Pack提供的SQL能力提高了操做便捷性；運維效率的提升極大地解放了人力。

特別值得一提的是，整個項目在遷移過程當中很是平滑穩定：

M原有ES集羣實現了徹底不停服遷移；

遷移後仍保持了M自建ES時自研開發的運維繫統的對接；

遷移過程當中，M對內核的特殊需求，ES社區版本並不支持，騰訊雲ES專門的內核團隊積極相應，提供了該能力。