日志數據的處理與分析是最典型的大數據分析場景之一,過去業內以 Elasticsearch 和 Grafana Loki 為代表的兩類架構難以同時兼顧高吞吐實時寫入、低成本海量存儲、實時文本檢索的需求。Apache Doris 借鑒了信息檢索的核心技術,在存儲引擎上實現了面向 AP 場景優化的高性能倒排索引,對于字符串類型的全文檢索和普通數值、日期等類型的等值、范圍檢索具有更高效的支持,相較于 Elasticsearch 實現性價比 10 余倍的提升,以此為日志存儲與分析場景提供了更優的選擇。
日志數據在企業大數據中非常普遍,其體量往往在企業大數據體系中占據非常高的比重,包括服務器、數據庫、網絡設備、IoT 物聯網設備產生的系統運維日志,與此同時還包含了用戶行為埋點等業務日志。
日志數據對于保障系統穩定運行和業務發展至關重要:基于日志的監控告警可以發現系統運行風險,及時預警;在故障排查過程中,實時日志檢索能幫助工程師快速定位到問題,盡快恢復服務;日志報表能通過長歷史統計發現潛在趨勢。而用戶埋點日志數據則是用戶行為分析以及智能推薦業務所依賴的決策基礎,有助于用戶需求洞察與體驗優化以及后續的業務流程改進。由于其在業務中能發揮的重要意義,因此構建統一的日志分析平臺,提供對日志數據的存儲、高效檢索以及快速分析能力,成為企業挖掘日志數據價值的關鍵一環。而日志數據和應用場景往往呈現如下的特點:- 數據增長快:每一次用戶操作、系統事件都會觸發新的日志產生,很多企業每天新增日志達到幾十甚至幾百億條,對日志平臺的寫入吞吐要求很高;
- 數據總量大:由于自身業務和監管等需要,日志數據經常要存儲較長的周期,因此累積的數據量經常達到幾百 TB 甚至 PB 級,而較老的歷史數據訪問頻率又比較低,面臨沉重的存儲成本壓力;
- 時效性要求高:在故障排查等場景需要能快速查詢到最新的日志,分鐘級的數據延遲往往無法滿足業務極高的時效性要求,因此需要實現日志數據的實時寫入與實時查詢。
- 高吞吐實時寫入:即需要保證日志流量的大規模寫入,又要支持低延遲可見;
- 低成本大規模存儲:系統自身可以存儲海量數據,且通過數據壓縮、冷熱分離等多種機制降低存儲成本;
- 高性能交互式分析且支持文本檢索:日志檢索的隨機性很強、很難提前預測模式,因此要求支持靈活的文本檢索,通過實時交互式查詢滿足分析需求。
當前業界有兩種比較典型的日志存儲與分析架構,分別是以 Elasticsearch 為代表的倒排索引檢索架構以及以 Loki 為代表的輕量索引/無索引架構,如果我們從實時寫入吞吐、存儲規模和成本、實時交互式查詢性能等幾方面進行對比,不難發現以下結論:
- 以 ES 為代表的倒排索引檢索架構,支持全文檢索、查詢性能好,因此在日志場景中被業內大規模應用,但其仍存在一些不足,包括實時寫入吞吐低、消耗大量資源構建索引,且需要消耗巨大存儲成本;
- 以 Loki 為代表的輕量索引或無索引架構,實時寫入吞吐高、存儲成本較低,但是檢索性能慢、關鍵時候查詢響應跟不上,性能成為制約業務分析的最大掣肘。
倒排索引原理示意倒排索引為 ES 帶來快速檢索能力的同時,也付出了寫入速度吞吐低和存儲空間占用高的代價——由于數據寫入時倒排索引需要進行分詞、詞典排序、構建倒排表等 CPU 和內存密集型操作,導致寫入吞吐大幅下降。而從存儲成本角度考慮,ES 會存儲原始數據和倒排索引,為了加速分析可能還需要額外存儲一份列存數據,因此 3 份冗余也會導致更高的存儲空間占用。Loki 則放棄了倒排索引,雖然帶來來寫入吞吐和存儲空間的優勢,但是損失了日志檢索的用戶體驗,在關鍵時刻不能發揮快速查日志的作用。成本雖然有所降低,但是沒有真正解決用戶的問題。
從以上方案對比可知,以 Elasticsearch 為代表的倒排索引檢索架構以及以 Loki 為代表的輕量索引/無索引架構無法同時兼顧 高吞吐、低存儲成本和實時高性能的要求,只能在某一方面或某幾方面做權衡取舍。如果在保持倒排索引的文本檢索性能優勢的同時,大幅提升系統的寫入速度與吞吐量并降低存儲資源成本,是否日志場景所面臨的困境就迎刃而解呢?答案是肯定的。如果我們希望使用 Apache Doris 來更好解決日志存儲與分析場景的痛點,其實現路徑也非常清晰——在數據庫內部增加倒排索引、以滿足字符串類型的全文檢索和普通數值/日期等類型的等值、范圍檢索,同時進一步優化倒排索引的查詢性能、使其更加契合日志數據分析的場景需求。在同樣實現倒排索引的情況下,相較于 ES, Apache Doris 怎么做到更高的性能表現呢?或者說現有倒排索引的優化空間有哪些呢?
- ES 基于 Apache Lucene 構建倒排索引,Apache Lucene 自 2000 年開源至今已有超過 20 年的歷史,設計之初主要面向信息檢索領域、功能豐富且復雜,而日志和大多數 OLAP 場景只需要其核心功能,包括分詞、倒排表等,而相關度排序等并非強需求,因此存在進一步功能簡化和性能提升的空間;
- ES 和 Apache Lucene 均采用 Java 實現,而 Apache Doris 存儲引擎和執行引擎采用 C++ 開發并且實現了全面向量化,相對于 Java 實現具有更好的性能;
- 倒排索引并不能決定性能表現的全部,作為一個高性能、實時的 OLAP 數據庫,Apache Doris 的列式存儲引擎、MPP 分布式查詢框架、向量化執行引擎以及智能 CBO 查詢優化器,相較于 ES 更為高效。
- 數據寫入兩個系統,異常有數據不一致的問題,也存在一定冗余存儲;
- 查詢需在兩個系統進行網絡交互有額外開銷,數據量大時用 ID 集合去原系統查性能比較低;
- 維護兩套系統的復雜度高,將系統的復雜性從開發測轉移到運維測;
數據庫內置倒排索引
在選擇了在數據庫內核中內置倒排索引后,我們需要進一步對 Apache Doris 索引結構進行分析,判斷能否通過在已有索引基礎上進行拓展來實現。Apache Doris 現有的索引存儲在 Segment 文件的 Index Region 中,按照適用場景可以分為跳數索引和點查索引兩類:1. 跳數索引:包括 ZoneMap 索引和 Bloom Filter 索引。
- ZoneMap 索引對每一個數據塊和文件保存 Min/Max/isnull 等匯總信息,可以用于等值、范圍查詢的粗粒度過濾,只能排除不滿足查詢條件的數據塊和文件,不能定位到行,也不支持文本分詞。
- BloomFilter 索引也是數據塊和文件級別的索引,通過 Bloom Filter 判斷某個值是否在數據塊和文件中,同樣不能定位到行、不支持文本分詞;
- ShortKey 在排序的基礎上,根據給定的前綴列實現快速查詢數據的索引方式,能夠對前綴索引的列進行等值、范圍查詢,但不支持文本分詞,另外由于數據要按前綴索引排序、因此一個表只允許一組前綴索引。
- Bitmap 索引記錄數據值 -> 行號 Bitmap 的有序映射,是一種很基礎的倒排索引,但是索引結構比較簡單、查詢效率不高、不支持文本分詞。
- 數據寫入和 Compaction 階段:在寫 Segment 文件的同時,同步寫入一個 Inverted Index 文件,文件路徑由 Segment ID + Index ID 決定。寫入 Segment 的 Row 和 Index 中的 Doc 一一對應,由于同步順序寫入,Segment 中的 Rowid 和 Index 中的 Docid 完全對應。
- 查詢階段:如果查詢 Where 條件中有建了倒排索引的列,會自動去 Index 文件中查詢,返回滿足條件的 Docid List,將 Docid List 一一對應的轉成 Rowid Bitmap,然后走 Doris 通用的 Rowid 過濾機制只讀取滿足條件的行,達到查詢加速的效果。
Doris倒排索引架構圖
這個設計的好處是已有的數據文件無需修改,可以做到兼容升級,而且增減索引不影響數據文件和其他索引,用戶增建索引沒有負擔。
通用倒排索引優化
C++和向量化實現Apache Doris 使用 CLucene(https://clucene.sourceforge.net/) 作為底層的倒排索引庫,CLucene 是一個用 C++ 實現的高性能、穩定的 Lucene 倒排索引庫,它的功能比較完整,支持分詞和自定義分詞算法,支持全文檢索查詢和等值、范圍查詢。Apache Doris 的存儲模塊和 CLucene 都用 C++ 實現,避免了Java Lucene 的 JVM GC 等開銷,同樣的計算 C++ 實現相對于 Java 性能優勢明顯,而且更利于做向量化加速。Doris 倒排索引進行了向量化優化,包括分詞、倒排表構建、查詢等,性能得到進一步提升。整體來看 Doris 的倒排索引寫入速度可以超過單核 20MB/s,而 ES 的單核寫入速度不到 5MB/s,有 4 倍的性能優勢。列式存儲和壓縮Lucene 本身是文檔存儲模型,主數據采用行存,而 Doris 中不同列的倒排索引是相互獨立的,因此倒排索引文件也采用列式存儲,有利于向量化構建索引和提高壓縮率。采用壓縮比高且速度快的 ZSTD,通常可以達到 5 ~10倍的壓縮比,與常用的GZIP壓縮相比有50%以上的空間節省且速度更快。BKD 索引與數值、日期類型列優化針對數值、日期類型的列,我們還實現了 BKD 索引,可以對范圍查詢提高性能,存儲空間也相對于轉成定長字符串更加高效,具有以下主要特性和優勢:- 高效范圍查詢:BKD 索引采用多維數據結構,為范圍查詢帶來高效率。它能迅速定位數值或日期類型列中所需的數據范圍,降低查詢時間復雜度。
- 存儲空間優化:與其他索引方法相比,BKD 索引在存儲空間使用上更高效。通過聚合并壓縮相鄰數據塊,減少索引所需存儲空間,降低存儲成本。
- 多維數據支持:BKD 索引具備良好擴展性,支持多維數據類型,如地理坐標(GEO point)和范圍(Range),使其在處理復雜數據類型時具有高適應性。
- 優化低基數場景:針對數值分布集中、單個數值倒排列表較多的低基數場景,我們調整了針對性的壓縮算法,降低大量倒排表解壓縮和反序列化所帶來的CPU性能消耗。
- 預查詢技術:針對查詢結果命中數較高的場景,我們采用預查詢技術進行命中數預估。若命中數顯著超過閾值,可跳過索引查詢,直接利用Doris在大數據量查詢下的技術優勢進行數據過濾。
面向 OLAP 的倒排索引優化
日志存儲和分析場景對檢索的需求很簡單,不需要特別復雜的功能(比如相關性排序),更需要降低存儲成本和快速按照條件查出數據。因此,在面對海量數據的寫入和查詢時,Apache Doris 還針對 OLAP 數據庫的特點優化了倒排索引的結構,使其更加簡潔高效。例如:- 在寫入流程保證不會多個線程寫入一個索引,從而避免寫入時多線程鎖競爭的開銷;
- 在存儲結構上去掉了不必要的正排、norm 等文件,減少寫入 IO 開銷和存儲空間占用;
- 查詢過程中簡化相關性打分和排序邏輯,降低不必要的開銷,提升查詢性能。
- 指定分區構建倒排索引,比如新增一個索引的時候指定最近7天的日志構建索引,歷史數據不建索引
- 指定分區刪除倒排索引,比如刪除超過1個月的日志的索引,釋放訪問頻度低的索引存儲空間
vs Elasticsearch
我們采用了 ES 官方的性能測試 Benchmark esrally 并使用其中的 HTTP Logs 日志,在同樣的硬件資源、數據、測試Case 以及測試工具下,記錄并對比各自的數據寫入時間、吞吐以及查詢延遲。- 測試數據:esrally HTTP Logs track 中自帶測試數據集,1998 年 World Cup HTTP Server Logs,未壓縮前 32G、共 2.47 億行、單行平均長度 134 字節;
- 測試查詢:esrally HTTP Logs 測試關鍵詞檢索、范圍查詢、聚合、排序等 11 個 Query,所有查詢跑 100 次串行執行;
- 測試環境:3 臺 16C 64G 云主機組成的集群。
vs Clickhouse
Clickhouse 近期的 v23.1 版本也引入了類似 Feature,將倒排索引作為實驗性功能發布,因此我們同樣進行了跟 Clickhouse 倒排索引的性能對比。在本次測試中,我們采用了 Clickhouse 官方 Inverted Index 介紹博客中使用的 Hacker News 樣例數據以及查詢 SQL ,同樣保持相同的物理資源、數據、測試 Case 以及測試工具。(參考文章:https://clickhouse.com/blog/clickhouse-search-with-inverted-indices)- 測試數據:Hacker News 2873 萬條數據,6.7G,Parquet 格式;
- 測試查詢:3 個查詢,分別查詢 'clickhouse'、'olap' OR 'oltp'、'avx' AND 'sve' 等關鍵字出現的次數;
- 測試機器:1 臺 16C 64G 云主機
下面以一個 Hacker News 100 萬條測試數據的示例展示 Doris 如何利用倒排索引實現高效的日志分析:1. 建表時指定索引
-
INDEX idx_comment (`comment`)
指定對 comment 列建一個名為idx_comment的索引 -
USING INVERTED
指定索引類型為倒排索引 -
PROPERTIES("parser" = "english")
指定分詞類型為英文分詞
CREATETABLEhackernews_1m ( `id`BIGINT, `deleted`TINYINT, `type`String, `author`String, `timestamp`DateTimeV2, `comment`String, `dead`TINYINT, `parent`BIGINT, `poll`BIGINT, `children`Array<BIGINT>, `url`String, `score`INT, `title`String, `parts`Array<INT>, `descendants`INT, INDEXidx_comment(`comment`)USINGINVERTEDPROPERTIES("parser"="english")COMMENT'invertedindexforcomment' ) DUPLICATEKEY(`id`) DISTRIBUTEDBYHASH(`id`)BUCKETS10 PROPERTIES("replication_num"="1");注:對于已經存在的表,也可以通過ADD INDEX idx_comment ON hackernews_1m(`comment`) USING INVERTED PROPERTIES("parser" = "english")來增加索引。值得一提的是,和 Doris 原先存儲在 Segment 數據文件中的智能索引和二級索引相比,增加倒排索引的過程只會讀 comment 列構建新的倒排索引文件,不會讀寫原有的其他數據,效率有明顯提升。2. 導入數據后查詢,使用
MATCH_ALL
在comment
這一列上匹配 OLAP 和 OLTP 兩個詞,和LIKE
掃描硬匹配相比,查詢性能有十余倍的提升。(這僅是 100 萬條數據下的測試效果,而隨著數據量增大、性能提升越明顯)mysql>SELECTcount()FROMhackernews_1mWHEREcommentLIKE'%OLAP%'ANDcommentLIKE'%OLTP%'; +---------+ |count()| +---------+ |15| +---------+ 1rowinset(0.13sec) mysql>SELECTcount()FROMhackernews_1mWHEREcommentMATCH_ALL'OLAPOLTP'; +---------+ |count()| +---------+ |15| +---------+ 1rowinset(0.01sec)更多詳細功能介紹和測試步驟可以參考Apache Doris 倒排索引官方文檔:https://doris.apache.org/zh-CN/docs/dev/data-table/index/inverted-index/
通過內置高性能倒排索引,Apache Doris 對于字符串類型的全文檢索和普通數值、日期等類型的等值、范圍檢索具有更高效的支持,進一步提升了數據查詢的效率和準確性,對于大規模日志數據查詢分析有了更好的性能表現,為需要檢索能力的用戶提供了更高性價比的選擇。目前倒排索引已經支持了 String、Int、Decimal、Datetime 等常用 Scalar 數據類型和 Array 數組類型,后續還會增加對 JSONB、Map 等復雜數據類型的支持。而 BKD 索引可以支持多維度類型的索引,為未來 Doris 增加 GEO 地理位置數據類型和索引打下了基礎。與此同時 Apache Doris 在半結構化數據分析方面還有更多能力擴展,比如自動根據導入數據擴展表結構的 Dynamic Table、豐富的復雜數據類型(Array、Map、Struct、JSONB)以及高性能字符串匹配算法等。除倒排索引以外,Apache Doris 在 2.0.0 Alpha 版本(https://github.com/apache/doris/releases/tag/2.0.0-alpha1)中還實現了單節點數萬 QPS 的高并發點查詢能力、基于對象存儲的冷熱數據分離、基于代價模型的全新查詢優化器以及 Pipeline 執行引擎等,歡迎大家下載體驗。
審核編輯 :李倩
-
日志
+關注
關注
0文章
138瀏覽量
10655 -
數據類型
+關注
關注
0文章
236瀏覽量
13637 -
數組
+關注
關注
1文章
417瀏覽量
25975
原文標題:從 Elasticsearch 到 Apache Doris,10 倍性價比的新一代日志存儲分析平臺|新版本揭秘
文章出處:【微信號:OSC開源社區,微信公眾號:OSC開源社區】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論