博客 / 詳情

返回

查詢提速 11 倍、資源節省 70%，Apache Doris 在網易日誌和時序場景的實踐

作者｜隱形（邢穎）， 網易資深數據庫內核工程師

編輯整理｜SelectDB 技術團隊

導讀：作為網易重要的業務線，靈犀辦公和雲信針對大規模日誌/時序數據處理和分析的挑戰，分別構建了靈犀 Eagle 監控平台和雲信數據平台。本文將重點介紹 Apache Doris 在網易日誌和時序場景中的應用，如何使用 Apache Doris 替換 Elasticsearch 和 InfluxDB，從而實現更低的服務器資源以及更高的查詢性能體驗，相較於 Elasticsearch，Apache Doris 查詢速度至少提升 11 倍，存儲資源的節省高達 70%。

隨着信息技術的飛速發展，企業數據量呈現爆炸式增長。對於像網易這樣規模龐大的互聯網公司，無論是內部辦公系統還是外部提供的服務，每天都會產生大量的日誌和時序數據。這些數據已成為故障排查、問題診斷、安全監測、風險預警以及用户行為分析及體驗優化的重要基石。充分挖掘這些數據的價值，有利於提升產品的可靠性、性能、安全性以及用户滿意度。

靈犀辦公和雲信作為網易重要的業務線，分別構建了靈犀 Eagle 監控平台、雲信數據平台來應對大規模日誌/時序數據在處理分析時帶來的挑戰。而隨着業務的持續擴張，日誌/時序數據也呈井噴式增長，隨之帶來的是存儲成本增高，查詢時間延長、系統穩定性變差等問題。早期的平台已難以為繼，這促使網易尋找更加優質的解決方案。

本文將聚焦於 Apache Doris 在網易日誌和時序類場景中的落地，分別介紹 Apache Doris 在網易靈犀辦公、網易雲信業務中的架構升級實踐，並結合實際場景分享建表、導入、查詢等方面的調優方案。

早期架構及痛點

01 靈犀 - Eagle 監控平台

網易靈犀辦公是全新一代郵件協同辦公平台。整合了郵箱、日曆、雲文檔、即時消息、客户管理等模塊。Eagle 監控平台是一個全鏈路 APM 系統，可為網易靈犀辦公提供多維度、不同粒度的性能分析。

Eagle 監控平台主要對靈犀辦公、企業郵、有道雲筆記、靈犀文檔等業務日誌數據進行存儲分析，日誌數據首先通過 Logstash 採集並處理，然後存儲到 Elasticsearch 中，由 Elasticsearch 進行實時日誌檢索及分析，併為靈犀辦公提供日誌搜索以及全鏈路日誌查詢等服務。

靈犀 - Eagle 監控平台.png

隨着時間的推移、日誌數據的增長，在使用 Elasticsearch 的過程中逐漸暴露出一些問題：

  • 查詢延遲高：在日常查詢中，Elasticsearch 平均響應延遲較高，影響使用體驗。這主要受到數據的規模、索引設計的合理性以及硬件資源等因素的制約。
  • 存儲成本高：在降本增效的大背景下，業務對降低存儲成本的需求日益迫切。但由於 Elasticsearch 存在正排、倒排、列存等多份數據存儲，數據冗餘程度較高，給降本提效帶來了一定的挑戰。

02 雲信 - 數據平台

網易雲信是集網易 26 年技術打造的融合通信與雲原生PaaS 服務專家，提供融合通信與雲原生核心產品及解決方案，包含 IM 即時通訊、視頻雲、短信，及輕舟微服務、中間件 PaaS 等。

雲信數據平台主要是對 IM、RTC、短信等服務所產生的時序數據進行分析。早期數據架構主要基於時序數據庫 InfluxDB 搭建，數據源首先通過 Kafka 消息隊列進行上報 ，經字段解析和清洗之後，存儲到時序數據庫 InfluxDB 中，以提供在線和離線查詢。離線側支持離線 T+1 數據分析，實時側需提供指標監控報表及賬單的實時生成。

雲信 - 數據平台.png

在客户規模的快速覆蓋下，上報的數據源也持續增加，InfluxDB 同樣面臨一系列新的挑戰：

  • 內存溢出 OOM：隨着數據源的增多，需要基於多個數據源進行離線分析，分析難度隨之增加。受限於 InfluxDB 的查詢能力，當前架構在面對多個數據源的複雜查詢時，可能會導致內存溢出（ OOM），這給業務的可用性及系統的穩定性帶來巨大的挑戰。
  • 存儲成本高：業務的發展也帶來集羣數據量的不斷增長，而集羣中較大比例數據為冷數據，冷熱數據採用同一種方式進行存儲，導致了高昂的存儲成本，這與降本增效的企業目標相悖。

核心引擎的選型

為此網易開始尋找新的數據庫解決方案，旨在解決上述兩大業務在日誌時序類場景所面臨的挑戰。同時，網易期望只用一個數據庫，能夠適配兩大應用場景的業務體系及技術架構，滿足極簡易用、低成本投入的升級需求。在這方面，Apache Doris 符合我們的選型要求，具體表現在以下幾個方面：

  • 存儲成本優化：Apache Doris 在存儲結構上面進行了許多優化，減少了冗餘存儲。具有更高的壓縮比，且支持基於 S3、NOS （網易對象存儲服務 Netease Object Storage）的冷熱分層存儲，可有效降低存儲成本，提高數據存儲效率。
  • 高吞吐高性能：Apache Doris 支持列式存儲高性能磁盤寫入、時序 Compaction 以及 Stream Load 高效流式導入，能夠支持每秒數十 GB 的數據寫入。這樣既能保證日誌數據的大規模寫入，同時還能夠提供低延遲的查詢可見性。
  • 實時日誌檢索：Apache Doris 不僅能夠支持日誌文本的全文檢索，還能夠實現實時查詢響應。Doris 支持在內部增加倒排索引，可以滿足字符串類型的全文檢索和普通數值/日期等類型的等值、範圍檢索，同時可進一步優化倒排索引的查詢性能、使其更加契合日誌數據分析的場景需求。
  • 支持大規模租户隔離： Doris 可承載數千數據庫以及數萬數據表，並能夠實現一個租户獨立使用一個數據庫，滿足多租户數據隔離的需求，保證了數據的隱私性和安全性。

除此之外，近一年以來， Apache Doris 在日誌場景持續深耕，推出了一系列核心能力，如高效的倒排索引、靈活的 Variant 數據類型等，為日誌/時序數據的處理分析提供了更高效、靈活的解決方案。綜合以上優勢，網易最終決定引入 Apache Doris 作為全新架構核心引擎。

基於 Apache Doris 的統一日誌存儲和分析平台

01 靈犀 - Eagle 監控平台

基於 Doris 的靈犀 - Eagle 監控平台.png

首先，在靈犀辦公 - Eagle 監控平台中，網易成功將 Elasticsearch 全面升級為 Apache Doris，從而構建了統一的日誌存儲和分析平台。這一架構升級不僅顯著提升了平台的性能與穩定性，更為其提供了強大且高效的日誌檢索服務。具體收益體現在：

  • 存儲資源節省 70%：得益於 Doris 列式存儲和 ZSTD 高壓縮比，存儲同樣的日誌數據，Elasticsearch 需要 100T 存儲空間，而存儲到 Doris 中僅需要 30T 存儲空間，存儲資源節省 70%。由於存儲空間大幅節省，在同樣的成本下可以使用 SSD 代替 HDD 存儲熱數據，又帶來更大的查詢性能提升。
  • 查詢提速 11 倍：新架構以更低的 CPU 資源消耗帶來了數十倍的查詢效率提升。從下方示意圖可知，最近 3 小時、1 天 、7 天的日誌檢索，Doris 查詢耗時保持穩定且均低於 4s，最快可在 1s 內響應。而 Elasticsearch 查詢耗時呈現出較大的波動，最長耗時高達 75s，即使最短耗時也需要 6-7s。在更低的資源佔用下，Doris 的查詢效率至少是 Elasticsearch 的 11 倍。

查詢耗時對比.png

02 雲信-數據平台

基於Doris的雲信-數據平台.png

在雲信數據平台中，網易同樣使用 Apache Doris 替代了早期架構中的時序數據庫 InfluxDB，將其作為數據平台核心存儲和計算引擎，由 Apache Doris 統一提供離線和實時查詢服務。

  • 支持高吞吐寫入：線上平均 500M/s、峯值 1GB/s 的寫入流量，InfluxDB 使用 22 台服務器，CPU 資源使用率約 50%，而 Doris 僅使用 11 台機器，CPU 使用率約 50%，整體資源消耗僅僅為之前的 1/2。
  • 存儲資源節省 67%：使用 11 台 Doris 物理機替換了 22 台 InfluxDB ，存儲同樣的數據規模，InfluxDB 需要 150T 存儲空間，而存儲到 Doris 中僅需要 50T 存儲空間，存儲資源節省 67%。
  • 查詢響應快且更穩定：為驗證其查詢響應速度，隨機挑選一個線上 SQL（最近 10min 匹配一個字符串），對該 SQL 連續查詢 99 次。從下圖可知，Doris（藍色）的查詢性能比 InfluxDB（紅色） 更穩定，99 次查詢均比較平穩、沒有明顯波動，而 InfluxD 出現多次異常波動，查詢耗時直線上升，查詢穩定性受到嚴重影響。

InfluxDB vs Doris.png

實踐及調優

在業務落地的過程中，網易也遇到一些問題及挑戰。藉此機會，將這些寶貴的優化經驗整理並分享，希望對大家的使用有所指引及幫助。

01 建表優化

數據庫 Schema 的設計對於性能至關重要，而在處理日誌和時序數據時也不例外。Apache Doris 針對這兩種場景提供了一些專門的優化選項，因此在表的創建過程中啓用這些優化選項非常關鍵。以下是我們在實踐中使用到的具體優化選項：

  1. 當使用 DATETIME 類型的時間字段作為主鍵 Key 時，查詢最新 n 條日誌的速度會得到顯著提升。
  2. 使用基於時間字段的 RANGE 分區，並開啓動態 Partiiton ，以便按天自動管理分區，提升數據查詢和管理的靈活性。
  3. 在分桶策略上，可以使⽤ RANDOM 進行隨機分桶，分桶數量大致設置為集羣磁盤總數的 3 倍。
  4. 對於經常需要查詢的字段，建議構建索引以提高查詢效率；而對於需要進行全文檢索的字段，應指定合適的分詞器參數 parser，確保檢索的準確性和效率。
  5. 針對日誌類、時序類場景，使用專門優化過的時序 Compaction 策略。
  6. 採用 ZSTD 壓縮，可以獲得更好的壓縮效果，節省存儲空間。
CREATE TABLE log
(
    ts DATETIME,
    host VARCHAR(20),
    msg TEXT,
    status INT,
    size INT,
    INDEX idx_size (size) USING INVERTED,
    INDEX idx_status (status) USING INVERTED,
    INDEX idx_host (host) USING INVERTED,
    INDEX idx_msg (msg) USING INVERTED PROPERTIES("parser" = "unicode")
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 250
PROPERTIES (
    "compression"="zstd",
    "compaction_policy" = "time_series",
    "dynamic_partition.enable" = "true",
    "dynamic_partition.create_history_partition" = "true",
    "dynamic_partition.time_unit" = "DAY",
    "dynamic_partition.start" = "-7",
    "dynamic_partition.end" = "3",
    "dynamic_partition.prefix" = "p",
    "dynamic_partition.buckets" = "250"
);

02 集羣配置優化

FE 配置

# 開啓單副本導入提升導入性能
enable_single_replica_load = true

# 更加均衡的tablet分配和balance測量
enable_round_robin_create_tablet = true
tablet_rebalancer_type = partition

# 頻繁導入相關的內存優化
max_running_txn_num_per_db = 10000
streaming_label_keep_max_second = 300
label_clean_interval_second = 300

BE 配置

write_buffer_size=1073741824
max_tablet_version_num = 20000
max_cumu_compaction_threads = 10(cpu的一半)
enable_write_index_searcher_cache = false
disable_storage_page_cache = true
enable_single_replica_load = true
streaming_load_json_max_mb=250

03 Stream Load 導入調優

雲信 - 數據平台在業務高峯期時，面臨着高達 100 萬以上的寫入 TPS 以及 1GB/s 的寫入流量，這無疑對系統性能提出了極高的要求。然而，由於業務側存在眾多小併發的表，且查詢側對數據的實時性要求極高，這使得在短時間內無法將批處理積攢到足夠大的 Batch。聯合業務方進行系列優化後， Stream Load 仍然難以迅速消費 Kafka 中的數據，導致 Kafka 中的數據積壓現象日益嚴重。

經過深入分析，發現在業務高峯期，業務側的數據導入程序已遭受性能瓶頸，主要體現在 CPU 和內存資源的過度佔用。然而，Doris 側的性能狀況尚未出現顯著的瓶頸，但 Stream Load 的響應時間卻有明顯的上升趨勢。

由於業務程序是同步調用 Stream Load 的，這意味着 Stream Load 的響應速度直接影響着整體的數據處理效率。因此，如果能夠有效降低單個 Stream Load 的響應時間，那麼整個系統的吞吐能力將得到顯著提升。

在與 Apache Doris 社區同學交流之後，瞭解到針對日誌和時序場景，Doris 推出了兩個重要的導入性能優化：

  • 單副本導入：先寫入一個副本，其他副本從第一個副本拉取數據。這種方式可避免多個副本重複排序、構建建索引所帶來的開銷。
  • 單 Tablet 導入：相較於普通模式下數據分散到多個 Tablet 的寫入方式，可採用一次僅寫入單個 Tablet 的策略。這種優化減少了寫入時產生的小文件數量和 IO 開銷，進而提升了整體的導入效率。可在導入時設置load_to_single_tablet參數為true來啓用這一功能。

在使用上述方式優化後，導入性能得到顯著的提升：

  • 消費 Kafka 速度提升超 2 倍

Stream Load 導入調優.png

  • Kafka 的延遲時間顯著下降，僅為原先耗時的 1/4

Stream Load 導入調優-2.png

  • Stream Load 的 RT 減少約 70%

Stream Load 導入調優-3.png

網易在正式上線前也開展了大壓力測試和灰度試運行，經過持續不斷的調優工作，最終確保系統能夠在大規模場景下穩定上線運行，為業務提供強有力的支持。

1. Stream Load 超時：

在壓測初期出現數據導入頻繁超時報錯的問題，且在進程及集羣狀態正常的情況下，監控無法正常採集 BE 的 Metrics 數據。

通過 Pstack 獲得 Doris BE 的堆棧，並使用 PT-PMT 對堆棧進行分析。發現主要原因是當客户端發起請求時，沒有設置 HTTP Chunked 編碼 也沒有設置 Content-Length，這導致 Doris 誤認為數據傳輸尚未結束，從而一直處於等待狀態。在客户端添加 Chunked 編碼設置後，數據導入恢復正常。

2. Stream Load 單次導入數據量超過閾值：

通過調大 streaming_load_json_max_mb參數到 250M（默認 100M ）後解決。

3. 副本不足寫入報錯： alive replica num 0 < quorum replica num 1

通過show backends發現有一台 BE 狀態異常顯示為 OFFLINE。查看對應的be_custom配置文件，發現其中存在broken_storage_path。進一步檢查 BE 的日誌，發現報錯信息提示“too many open files”，這意味着 BE 進程打開的文件句柄數量已經超出了系統設定的最大值，從而導致 IO 操作失敗。

當 Doris 系統檢測到這種異常情況時，會將該磁盤標記為不可用狀態。由於該表的配置是單副本策略，當唯一的副本所在磁盤出現問題時，就會因為副本數不足而無法繼續寫入數據。

因此，將進程 FD 最大打開限制調整到了 100 萬，並刪除be_custom.conf配置文件、重啓該 BE 節點，服務最終恢復正常運行。

4. FE 內存抖動

在業務灰度測試期間，出現無法連接到 FE 的問題。通過查看監控數據，發現 JVM 32G 內存已經耗盡，同時 FE 的 meta 目錄下 bdb 文件目錄異常膨脹至 50G。

由於業務一直在進行高併發的 Stream Load 數據導入操作，而導入過程中 FE 會記錄相關的 Load 信息，每次導入產生的內存信息約為 200K。這些內存信息的清理時間由streaming_label_keep_max_second參數控制，默認值為 12 小時，將它調小到 5 分鐘後 FE 內存不會耗盡，但是運行一段時間後，發現內存按照 1 小時為週期進行抖動，高峯內存使用率達到 80%。分析代碼發現清理 label 的線程每隔 label_clean_interval_second 運行一次，默認為 1 小時，把它也調小到 5 分鐘後，FE 內存很平穩。

04 查詢調優

當靈犀 - Eagle 監控平台在進行查詢測試的時候，疑似讀取到了不符合匹配條件的結果，這一現象顯然不符合預期的檢索邏輯。如下圖第一條記錄：

查詢調優.png

起初誤以為是 Doris 的 Bug，於是嘗試搜索類似的 issue 及規避方案。然而，在諮詢社區成員並仔細查閲官方文檔後，發現問題的根源是對match_all使用場景的理解存在誤區。

match_all 的工作原理是隻要存在分詞就能進行匹配，而分詞是依據空格或標點來進行的。在該案例中，match_all中的'29'與第一條記錄後續內容中的'29'進行了匹配，從而輸出了不符合預期的結果。

查詢調優-2.png

針對該 Case，正確的方式是使用 MATCH_PHRASE 進行匹配，MATCH_PHRASE可以滿足文本中的順序要求。

-- 1.4 logmsg中同時包含keyword1和keyword2的行，並且按照keyword1在前，keyword2在後的順序
SELECT * FROM table_name WHERE logmsg MATCH_PHRASE 'keyword1 keyword2';

在使用 MATCH_PHRASE進行匹配時，建索引時需指定 support_phrase，否則系統會進行全表掃描並進行硬匹配，查詢效率較差。

INDEX idx_name4(column_name4) USING INVERTED PROPERTIES("parser" = "english|unicode|chinese", "support_phrase" = "true")

對於已經寫入數據的表，若希望啓用support_phrase，可以執行DROP INDEX來刪除舊的索引，隨後使用ADD INDEX添加新的索引。這一過程是在已有表上增量進行，無需重寫整個表的數據，從而確保了操作的高效性。

相較於 Elasticsearch，Doris 的索引管理方式更為靈活，能夠根據業務需求快速添加或刪除索引，提供了更大的便利性和靈活性。

結束語

Apache Doris 的引入，有效滿足了網易對日誌、時序場景的需求，有效解決了網易靈犀辦公以及網易雲信早期日誌處理及分析平台存儲成本高，查詢效率低等問題。

在實際應用中，Apache Doris 以更低的服務器資源，承載了線上平均 500MB/s 、峯值超 1GB/s 的寫入流量的平穩寫入。同時，查詢響應也得到了顯著的提升，相較於 Elasticsearch ，查詢效率至少提升了 11 倍。此外，Doris 具備更高的壓縮比，存儲資源相較之前可節約 70%。

最後，特別感謝 SelectDB 技術團隊一直以來的支持。未來，網易將繼續推廣 Apache Doris，將其深入應用於網易其他大數據場景中。同時，也期待能與更多對 Doris 感興趣的業務團隊展開深入交流，共同推動 Apache Doris 發展。

開源貢獻

在業務落地及問題排查的過程中，網易的各位同學積極踐行開源精神，為 Apache Doris 社區貢獻了一系列寶貴的 PR 推動了社區的發展和進步：

  1. Stream Load Bug Fix
  2. Stream Load 代碼優化
  3. 冷熱分層尋找合適 Rowset 優化
  4. 冷熱分層減少無效遍歷
  5. 冷熱分層鎖區間優化
  6. 冷熱分層數據過濾優化
  7. 冷熱分層容量判斷優化
  8. 冷熱分層排序優化
  9. FE 報錯規範化
  10. 新增 array_agg 函數
  11. 聚合函數 Bug Fix
  12. 執行計劃 Bug Fix
  13. TaskGroupManager 優化
  14. BE Crash 修復
  15. 文檔修改：
  • https://github.com/apache/doris/pull/26958
  • https://github.com/apache/doris/pull/26410
  • https://github.com/apache/doris/pull/25082
  • https://github.com/apache/doris/pull/25075
  • https://github.com/apache/doris/pull/31882
  • https://github.com/apache/doris/pull/30654
  • https://github.com/apache/doris/pull/30304
  • https://github.com/apache/doris/pull/29268
elasticsearch , 日誌分析 , 大數據 , 時序數據庫 , 數據庫
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.