1. 背景
日志領域是Elasticsearch（ES）最重要也是規模最大的應用場景之一，這得益于 ES 有高性能倒排索引、靈活的 schema、易用的分布式架構，支持高吞吐寫入、高性能查詢，同時有強大的資料治理生態、端到端的完整解決方案，但原生 ES 在高吞吐寫入、低成本存盤、高性能查詢等方面還有非常大的優化空間，本文重點剖析騰訊云大資料 ES 團隊在這三個方面的內核增強優化，
2. 日志領域的挑戰
我們先來看看日志領域的挑戰有哪些，
首先從日志本身的資料特點來看，主要以半結構化、非結構化為主，傳統的資料庫方案沒法很好的解決決議、存盤等問題，ES 支持 JSON 且支持動態映射，高版本還支持 Runtime Feilds，能在查詢時動態提取欄位，天然支持了日志場景復雜、靈活的資料結構，
日志資料進入 ES 則面臨高并發、高吞吐的寫入性能挑戰，內核層面我們進行了定向路由、物理復制等重磅優化，有效解決日志入口吞吐瓶頸，提升寫入性能一倍+，
日志資料的存盤是另一大挑戰，日志往往是海量的且往往價值不高，存盤成本成為用戶最顧慮的痛點之一，騰訊云 ES 一方面通過壓縮編碼優化來降低單位檔案存盤成本，另一方面我們通過基于云原生環境自研混合存盤方案，實作存盤與計算分離，降低存盤成本 50% 以上，
日志資料的出口，查詢性能也是一大挑戰，海量資料場景下，大查詢對資源的開銷非常高，帶來的查詢延時也非常明顯，ES 原生支持了倒排索引，點查過濾的性能非常好，但無法滿足日志場景大范圍查詢、聚合分析等性能需求，對此，騰訊云 ES 進行了查詢裁剪、查詢并行化等一系列系統性優化，提升查詢性能數十倍，
下面是日志領域的挑戰總結，后面將針對高吞吐寫入、低成本存盤、高性能查詢層面的優化進行詳細分析，
3. 高吞吐寫入
3.1 定向路由
ES 的一個 Bulk 寫入先進到協調節點（任意一個資料節點），會被拆分為若干個分片粒度的子寫入請求，并分發給對應的資料節點，當集群規模較大，索引的分片數較多的場景下，分布式寫入的扇出放大非常嚴重，很容易受到個別長尾節點的 GC、慢盤、網路抖動等影響，導致寫入堆積，資源利用率低，拒絕率高，
騰訊云 ES 內核通過引入寫入定向路由優化，將用戶的一個 Bulk 請求路由到一個分片數可控的分片組，降低寫入請求扇出影響，容忍慢節點，在不可靠的環境中提供可靠的服務，基于定向路由優化，某日志業務場景，寫入吞吐提升一倍多，CPU 資源利用率提升 58%，拒絕率從 3% 降至 0，
定向路由解決了慢節點對寫入的影響，接下來我們看看如何優化寫入層面冗余的計算開銷來提升性能，
3.2 物理復制
ES 單機引擎寫入，底層資料接收到可見分為三個步驟，如上圖所示，
-
資料在記憶體中構建各種資料型別，包括行存、列存、各種索引， -
寫入 Translog，相當于 WAL 確保資料可靠性，機器掛掉資料可重放， -
周期性 refresh 將記憶體中的資料結構 buffer 構建成完整的 segment 并打開 reader 可查，
ES 分布式層的寫入，資料先從協調節點轉發至 Primary，主分片寫完 Lucene 和 Translog 之后并行轉發給多個 Replica，副本分片完成 Lucene 和 Translog 的寫入，這個程序中，副本分片的 Lucene 寫入是冗余的，因為這個寫入堆疊在 Primary 上進行了一遍，在 Replica 上會完整的再來一遍，開銷非常高，
物理復制解決的就是從分片上冗余寫入堆疊的開銷，
如上圖方案所示，第一步當 Primary 產生新的 Segment 之后，會及時通過物理拷貝方式同步至 Replica，使得 Segment 在 Replica 上可見，同時消除 Replica 上記憶體構建 Segment 程序的計算開銷，當 Primary 上產生新的 Commit 檔案之后，也會及時同步至 Replica，同步 Commit 檔案的目的主要是在 Replica 側清理過期的 Translog 和被合并的 Segment，例如在上面第三、四步中就描述了 Primary 側 Segment 合并之后同步到 Replica 側清理的程序，
通過 Segment 物理復制的能力，有效裁剪了 Replica 寫入的計算開銷，在主從副本場景下提升寫入性能接近一倍，
4. 低成本存盤
前面我們重點介紹了海量日志資料高吞吐寫入層面的性能優化，海量的資料流入到 ES 之后，存盤是另一大挑戰，接下來我們來探討一下海量存盤場景如何進行成本優化，我們先來看看背景，
存盤成本的影響面主要分為三個層面：
-
云原生環境下分布式架構層，ES 的主從副本乘以底層云盤、物件存盤等三份副本（EC 編碼優化推出可能在 1.33 左右）， -
單機存盤引擎層，由于 ES 是行列混存，且有豐富的索引結構，應用場景豐富的同時，也導致了單位檔案存盤成本放大較多， -
底層基礎設施，為了應對高吞吐寫入，往往需要引入 SSD 硬碟，其成本高壽命短，如果用冷熱架構，溫層往往會掛多塊 HDD 盤來擴大容量，此時單盤的損壞會導致整個節點替換，存在大量的資料恢復搬遷，代價太大，另外機器運維的人力成本也不低，
從上面幾個維度的成本影響面來看，我們的優化重點一方面是降低單位檔案的存盤成本，另一方面是降低冗余副本、存盤介質的成本，
4.1 壓縮編碼優化
壓縮編碼優化是在原始資料結構不變的前提下，降低單位檔案存盤成本非常有效的方式，上圖中描述了 ES 底層 Lucene 的存盤格式，以及這些格式所用到的壓縮演算法，其中列存壓縮是由騰訊貢獻給社區的，
4.1.1 列存壓縮
Lucene 列存存盤分為兩部分，term dictionary 和 term ords，每個欄位值的原始內容存盤在 term dictionary 中，實際編碼、計算的時候為了避免冗余而采用 term ords，后者會隨著新資料的持續寫入而動態更新，優化的主要內容是對 term dictionary 中的原始欄位字面內容進行壓縮存盤，從優化后的壓縮效果對比來看，寫入、merge 耗時基本不變的情況下，列存存盤下降了 40%+，
4.1.2 擴展基礎壓縮演算法
除了優化列存以外，我們還引入了新的通用壓縮演算法，
Zstandard 演算法在壓縮比上比 LZ4 更優，在性能上比 Deflate 更優，能兼容兩者的優點，我們將該通用壓縮演算法引入到行存、列存、索引檔案壓縮中，實測業務開啟 Zstandard 演算法之后，整體存盤成本下降 30%+，
4.2 混合存盤引擎
前面主要介紹了通過壓縮編碼優化降低單位檔案存盤成本，而單位檔案的存盤優化是有極限的，另一個方向是從存盤架構層面進行優化，在云原生的背景下，我們引入了自研混合存盤引擎方案，
混合存盤引擎的整體設計思路是基于典型的 delta + base 架構，其中 delta 部分我們采用 SSD，主要目的為了扛高并發寫入，以及小 segment 的存盤及合并；而 base 部分采用物件存盤，用于存盤大量不可變的大 segment，一方面其高可用（4 個 9 一個 5）、高可靠（12 個 9）、按量付費、免運維的架構降低了大量運維成本，更重要的是其提供的標準、低頻、歸檔等靈活的低成本存盤方案能大幅降低海量日志的存盤成本，
接下來我們結合索引資料的生命周期看看混合存盤引擎的整體設計，
混合存盤引擎整體分為兩層，上層存盤介質為 SSD，提供高并發的寫入能力，準實時產生的 segment 會通過物理復制的能力從 primary 拷貝至 replica，同時主從副本均寫入 translog，確保主從切換資料無縫對接及重啟資料不丟失，更重要的是主從副本之間的資料、segment 完全一致，這便于我們在 primary 上將資料下沉至底層共享存盤后，replica 可以無縫掛載查詢，每個分片本地都會有一個 RemoteDirectoryWrapper 封裝了對遠程共享存盤資料的訪問，包含了資料快取的邏輯，底層共享存盤采用物件存盤，資料按照索引、分片粒度分目錄存盤，segment 資料檔案一對一映射，方便存取，
下面我們細分流程看看整體方案的設計細節，
如上圖所示，前五個階段，主要是我們之前描述的物理復制的流程，主要目的是為了提升寫入性能，確保 primary 和 replica 資料保持完全一致，為后續的資料共享提供基礎，前面已描述詳細流程，這里不展開分析，
第六個階段，本地 segment 通過 merge 產生了較大的 segment，會被凍結不再參與 merge，并下沉至底層共享存盤，注意這個階段是從熱資料就開始的，并不是資料降溫后才啟動下沉，可以避免資料降溫后整體下沉的排隊擁塞，當然可以根據用戶的需求進行靈活配置，此時，日志場景大量的查詢會集中在本地，本地 primary 和 replica 也能很好的抗住讀寫壓力，
第七個階段，資料的查詢頻次有所降低，一般情況，本地的 primary 即可滿足絕大部分查詢性能需求，此時 replica 會從本地卸載，讀取會走遠端共享存盤，同時本地會有快取機制保存用戶常用查詢資料提升性能，此時的查詢會優先打到 primary，通過卸載本地 replica，我們可以縮減約 50% 的 SSD 容量，
第八個階段，查詢頻率大幅縮減，Primary 上只有部分資料或部分 segment 需要被查詢，此時 primary 上的部分檔案或 segment 會先被卸載，同時本地構建快取體系加速查詢，本階段 SSD 的縮減達到 70% 左右，但仍然能滿足業務的查詢需求，
第九個階段，查詢幾乎沒有了，資料處于歸檔狀態，本地的 primary 徹底實作卸載，依靠本地的快取加速滿足極少量的查詢需求，本階段 SSD 的縮減到達 90% 左右，
在整個資料生命周期中，segment 呈現三種形態：
-
Local Segment，行列存、索引檔案等全部在本地，抗住熱資料高并發讀寫請求， -
Mixed Segment，行列存等資料檔案可能卸載，只有部分索引檔案在本地，滿足少量的查詢請求， -
Remote Segment，行列存、索引檔案等全部在遠程，本地只有少量元資料檔案，滿足冷資料低成本歸檔需求，
上面是完整的索引生命周期中資料的演變程序，存盤重心隨著資料逐漸降溫程序逐步從 SSD 到物件存盤遷移，且用戶無明顯感知，最終整體存盤成本下降 50% - 80%，
日志場景傳統的降本方案一般采用冷熱分層，混合存盤引擎與冷熱分層主要的區別包括：
-
存盤架構差異，1). 傳統冷熱分層索引級別存盤介質固定，2). 混合存盤 SSD 和物件存盤是一個整體，資料可以雙向區域流通， -
副本差異，1). 傳統冷熱分層存在冗余副本，2). 混合存盤底層采用共享存盤，上層分片最終形態為邏輯分片，消除了云原生環境下的冗余副本， -
資料搬遷差異，1). 傳統冷熱分層資料降溫后索引需要整體搬遷，2). 混合存盤支持在熱資料階段 segment 級別的資料下沉， -
配置策略差異，1). 傳統冷熱分層依賴用戶的靜態配置策略，靈活性低、運維成本高，2). 混合存盤除了支持用戶配置外，還可根據用戶訪問統計資訊自動決策資料下沉、卸載時機，實作資料智能分層，
截止目前日志場景海量資料的低成本存盤優化到這里就介紹完畢了，后面繼續介紹查詢性能優化，
5. 高性能查詢
5.1 查詢性能影響面
前面我們分析了日志場景的海量存盤成本優化，資料存盤降本之后，接下來要考慮的是資料流出，如何解決用戶查詢性能問題，因為混合存盤底層采用物件存盤，其和 SSD 的性能差異肯定是有一個量級的區別，我們需要系統性做一些查詢優化、快取優化來找回這種存盤介質的變更帶來的性能損耗，
我們先來看看混合存盤引擎背景下，查詢性能的瓶頸在哪些方面，
5.1.1 大量查詢空轉掃描
ES 有高效的倒排索引，點查的性能是非常強悍的，多索引或通過別名關聯索引查詢也是相對傳統資料庫的一個優勢特性，而這一特性也會帶來一些性能瓶頸問題，如上圖所示，當我們查詢的索引是一個星號，或者一個索引前綴匹配，或是一個別名的時候，底層可能關聯多個物理索引，而我們的查詢可能只有部分索引會有資料命中，而 ES 實際執行查詢會將底層所有匹配的索引、包括每個索引底層的每個分片逐一遍歷查詢，這樣會存在大量的無用索引、分片、segment 的查詢空轉掃描，
5.1.2 Segment 串行化執行
ES 底層分片之間是可以并行化的，但是單個分片內部多個 segment 之間是串行化的，混合存盤引擎的底層是物件存盤，多個 segment 串行化導致 IO 排隊嚴重，查詢效率低下，尤其是在大查詢拉取資料較多的場景下，
5.2 索引分片級時序裁剪優化
基于上面兩大影響面分析，我們針對性的優化思路是查詢裁剪和查詢并行化，下面我們來展開分析，
在日志場景，索引一般是按照一定的時間周期進行滾動，騰訊自研了自治索引，幫助用戶托管索引分片的管理，用戶無需關心底層分片的數量、大小、分布配置，簡化資料接入門檻，在此基礎上，我們維護了索引級別的 Min/Max，當查詢請求進來的時候，可以針對用戶的查詢區間進行精準的物理索引過濾裁剪，大幅降低無用索引的空轉掃描程序，通過索引分片維度的時序裁剪，大幅提升查詢性能，內部視頻日志業務實測查詢性能提升 8 倍，
5.3 Segment 級別查詢裁剪
單個分片包含多個 segment，在查詢程序中會依次遍歷 segment 進行查詢，但往往只有部分 segment 或者 segment 內部部分資料段存在有效資料，因此 segment 維度的查詢裁剪也是優化的重點，
Segment 級別查詢裁剪分為兩個維度：
-
Segment 整體裁剪，社區版本已經支持列存、數值索引等維度的裁剪，對 Terms 維度還缺少整體裁剪，騰訊進行了優化，并提交給了社區，點查性能提升 25.7%， -
Segment 內資料裁剪，1). 流式聚合裁剪，在 Composite Aggregation 場景，支持聚合翻頁，每次翻頁會涉及大量重復資料的查詢，騰訊進行了優化，基于 index sorting，每次翻頁采用起始 doc id 跳轉，加上滿足 size 條件提前結束優化，流式聚合性能提升 7 倍，且支持正、逆序，已反饋給社區，2). 時序裁剪，社區版本，在大的時序范圍查詢場景，構建實踐范圍 posting list 的時候，涉及大量的資料檔案遍歷，產生大量的隨機 IO 影響查詢性能，TencentES OTeam 協作進行了深度優化，基于 index sorting，利用 BKD 做二級索引，實作端點提取裁剪遍歷，逆序采用二分查找，滿足了大范圍的時序查詢性能需求，時序搜索性能提升 40 倍，
5.4 Segment 并行化
原生 ES 單個分片內部多個 segment 查詢為串行化執行，Segment 并行化的思路主要是將多個 segment 的檔案進行統籌規劃，按照多執行緒切分，并行化查詢，對于做完 forcemerge 的場景也能很好的提高并行度，于此同時，我們在拉取底層共享存盤時，并不會整個檔案拉回來，而是結合前面描述的資料裁剪能力，按照查詢需要拉取區域的資料段，大幅提升拉取效率，混合存盤引擎中，開啟并行化查詢優化相較原生版本查詢性能提升 5 倍，
6. 云原生資料平臺
下一階段，騰訊云 ES 將打造云原生資料平臺，倍訓 PB 級資料檢索、分析場景，全面覆寫日志場景低成本、高性能的需求，底層基于共享存盤，消除冗余副本，實作存算分離架構，中間計算層會提供多種維度的集群，實作讀寫分離，檢索、分析場景分離等，上層提供各種免運維的資料服務，實作資源靈活調度，資料跨節點、跨邏輯集群掛載等，
目前騰訊云推出的 Elasticsearch Serverless 服務已覆寫上述大部分能力，后續會持續完善，敬請關注，
作者：daniel
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Elasticsearch-Core-Application-Scenario---Log-Optimization-Practice.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/555847.html
標籤：大數據
上一篇：2-Redis概述
下一篇：返回列表