導讀：日誌數據已成為企業洞察系統狀態、監控網絡安全及分析業務動態的寶貴資源。網易雲音樂引入 Apache Doris 作為日誌庫新方案，替換了 ClickHouse。解決了 ClickHouse 運維複雜、不支持倒排索引的問題。目前已經穩定運行 3 個季度，規模達到 50 台服務器， 倒排索引將全文檢索性能提升7倍，2PB 數據，每天新增日誌量超過萬億條，峯值寫入吞吐 6GB/s 。
網易雲音樂每天都會產生大量用户行為數據、業務數據及日誌數據，這些數據在異常行為跟蹤、客訴問題定位、運行狀態監控、性能優化等方面扮演守護者的角色。面對每日萬億級別數據的增量，網易雲音樂早期的日誌庫以 ClickHouse 為核心構建，但面臨運維成本高、併發查詢能力不足、寫入性能不穩定、使用費用高昂等問題，在新需求的滿足上稍顯吃力。
為尋找更優質解決方案，結合當前的業務需求，網易雲音樂引入 Apache Doris 作為日誌庫新方案，替換了 ClickHouse。解決了 ClickHouse 運維複雜、不支持倒排索引的問題。目前已經穩定運行 3 個季度，規模達到 50 台服務器， 倒排索引將全文檢索性能提升7倍，2PB 數據，每天新增日誌量超過萬億條，峯值寫入吞吐 6GB/s 。 本文將介紹從 ClickHouse 到 Apache Doris 的遷移思考及調優實踐，並分享網易雲音樂如何在運維效率、併發能力、查詢響應以及存儲性能上實現全方位提升。
早期架構及挑戰
雲音樂數據平台主要包括客户端日誌、服務端日誌、數據平台相關組件運行日誌這幾類：
- 客户端 / 服務端日誌： 客户端 / 服務端產生的日誌是數據體系的核心基礎數據之一，日增數據達萬億級別，存儲佔用數百 TB。幾乎所有業務場景均由該類數據構建。
- 數據平台相關組件運行日誌： 任務及相關組件日誌是數據平台內部的核心數據之一，每天約 1TB 的數據規模。這些日誌能夠及時反映數據平台的運行狀態、性能指標、異常情況等，是實現平台智能化運維的核心資產。
對於上述日誌數據的處理，早期以 ClickHouse 為核心構建了日誌庫、並設計瞭如下兩條數據處理鏈路。這些數據通過日誌採集、清洗、加工後寫入日誌庫中，由日誌庫進行明細和聚合查詢，為異常用户行為、社區熱點監控、任務異常分析、任務預警、大盤監控業務場景提供服務。
上述兩類日誌數據，均要求在實時任務加工處理後寫入到日誌庫，這對日誌庫的穩定性、可用性、性能、容錯等能力都提出了較高要求。而之前日誌庫以 ClickHouse 為核心構建，在使用中暴露出一些痛點問題，在性能及穩定性的滿足上稍顯吃力：
- 運維成本高：早期為兩條處理鏈路，同時也帶來了雙倍維護成本，此外，早期鏈路在面對壞盤、宕機、擴容等場景時，需要手動進行數據均衡和數據恢復，有些場景甚至需要在寫入任務時配合重啓操作。
- 使用門檻高：ClickHouse 除了有基本的本地表和和分佈式表概念外，還提供了 MergeTree/ReplacingMergeTree/SummingMergeTree 等多個引擎，需根據不同情況選擇不同的引擎，比如多副本需要使用 ReplicatedXX 引擎，這對於新人而言使用門檻及成本均比較高。
- 併發查詢能力不足：在併發查詢較多場景下，查詢性能下降明顯，無法支持業務需求。
- 寫入穩定性較差：當單節點宕機或壞盤時，寫入任務會出現 Failover，個別場景還需要人工介入對寫入任務進行重啓。
- 收費較高：由於歷史原因，ClickHouse 使用的相關雲服務，成本高昂。
Apache Doris 日誌場景調研
基於上述問題、技術棧痛點，結合當前的業務需求，網易雲音樂最終選擇 Doris 作為日誌庫的新方案，替換原先架構中的 ClickHouse。 Apache Doris 具備運維便捷、高併發能力優異、大規模數據寫入性能穩定等特點，非常符合選型要求。不僅如此，Apache Doris 所提供的冷熱存儲以及數據湖能力也與後續重點技術發展方向高度契合。
- 簡單易用運維難度低：工程師和數據分析師對於 SQL 非常熟悉，經驗可以複用，不需要學習新的技術棧即可快速上手。同時 Doris 具備完善的分佈式集羣管理，集羣本身易於運維、支持橫向拓展的存儲方案。
- 高吞吐、低延遲日誌寫入：支持每天百 TB 級、GB/s 級日誌數據持續穩定寫入，同時保持延遲 1s 以內， 確保數據的實時性和高效性。
- 高性能日誌全文檢索分析： 支持倒排索引和全文檢索，對於日誌場景中常見的查詢（如關鍵詞檢索明細、趨勢分析等）能夠實現秒級響應，為用户提供極致的查詢體驗。
- 海量日誌數據低成本存儲：支持 PB 級海量數據的存儲，並支持將冷數據存儲到 S3 或 HDFS 等低成本存儲介質，存儲成本進一步降低。
- 開放、易用的上下游生態：上游通過 Stream Load 通用 HTTP API 對接常見的日誌採集系統和數據源 Logstash、Filebeat、Fluentbit、Kafka 等，下游通過標準 MySQL 協議和語法對接各種可視化分析 UI，比如可觀測性 Grafana、BI 分析 Superset、類 Kibana 的日誌檢索 SelectDB WebUI ，為用户打造全方位的日誌存儲與分析生態。
基於 Apache Doris 的日誌平台實踐
01 整體架構
由於 ClickHouse 和 Doris 均採用關係數據庫模型及 SQL，因此架構變化很小、遷移也比較簡單。在新架構中，使用 Apache Doris 替代 ClickHouse 作為日誌存儲和分析引擎，只需調整上游 Flink 寫入程序，將日誌寫入 Doris，並更新下游日誌查詢的 SQL 語句即可。
在實際上線過程中，網易雲音樂進行了 Doris 和 ClickHouse 為期兩週的雙跑測試。在此期間，針對最近兩週的數據進行了記錄數、用户等字段的統計，以及實際明細查詢的抽樣對比，以驗證數據的一致性。經過校驗，Doris 能夠安全地替代原有的 ClickHouse。
02 存儲設計
表結構設計是日誌平台的關鍵因素，其中排序、分區、分桶、壓縮、索引等設計將對性產生顯著影響。
- 分區：基於
dt字段按天分區，使用 Dynamic Partition 功能自動創建和刪除分區。 - 分桶：採用 RANDOM 隨機分桶，既保證了各分桶的數據均衡，也能大幅提升寫入性能。
- 排序：使用
application_id、log_type、container_id、logs_timestamp、log_level、host_name作為排序鍵。這是由於大多數查詢會指定application_id、log_type、container_id，排序後能快速定位到所需數據，跳過不必要的數據。 - 索引：對需要全文檢索的日誌文本字段
message和exception_message創建倒排索引，加速關鍵詞檢索。 - 壓縮：採用 Doris ZSTD 壓縮算法，相比 ClickHouse 默認的 LZ4 壓縮算法，能夠節省 30% 以上的存儲空間。
- Compaction：因為日誌也是一種特殊的時序數據，因此採用
time_series compaction策略，利用時序數據局部性特點減少 Compaction 寫放大，節省 CPU 和 IO 資源。
具體的建表語句參考如下：
CREATE TABLE log_table (
application_id VARCHAR(*) NULL COMMENT '應用id',
log_type VARCHAR(*) NULL COMMENT '日誌類型/jm/tm',
container_id VARCHAR(*) NULL COMMENT 'container_id',
logs_timestamp BIGINT NULL COMMENT '日誌產生時間',
log_level VARCHAR(*) NULL COMMENT '日誌級別',
host_name VARCHAR(*) NULL COMMENT '主機名',
exception_log TEXT NULL COMMENT '異常日誌',
job_id INT NULL COMMENT '任務id',
message TEXT NULL COMMENT '日誌內容',
tag TEXT NULL COMMENT '日誌關鍵指標',
log_file_path TEXT NULL COMMENT '日誌存儲路徑',
exception_class_name TEXT NULL COMMENT '異常類名',
exception_type TEXT NULL COMMENT '異常類型',
exception_message TEXT NULL COMMENT '異常msg',
exception_caused_by TEXT NULL COMMENT '異常caused_by',
dt date NULL COMMENT '天',
hh TEXT NULL COMMENT '小時',
mm TEXT NULL COMMENT '分鐘',
INDEX idx_exception_message (exception_message) USING INVERTED PROPERTIES("parser" = "english"),
INDEX idx_message (message) USING INVERTED PROPERTIES("parser" = "english")
) ENGINE=OLAP
DUPLICATE KEY(application_id, log_type, container_id, logs_timestamp, log_level, host_name)
COMMENT 'OLAP'
PARTITION BY RANGE(dt)()
DISTRIBUTED BY RANDOM BUCKETS 100
PROPERTIES (
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-7",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "100",
"dynamic_partition.create_history_partition" = "true",
"compression" = "ZSTD",
"compaction_policy" = "time_series"
);
03 寫入改造和優化
原來架構中，日誌數據通過 Flink 寫入 ClickHouse。新的架構中，由於 Doris 提供了 Doris Flink Connector，仍然可以沿用 Flink 來寫數據，只需要進行少量調整。
客户端寫入性能調優
目前使用 Apache Flink 1.12 版本，Doris Flink Connector 使用的是 branch-for-flink-before-1.13分支。寫入流程如下圖：
每條上游數據寫入 ArrayList 中，當 ArrayList 中數據的條數 sink.batch.size或大小sink.batch.bytes 達到閾值後，觸發 flush 操作，同時還會啓動 daemon 線程，定時 sink.batch.interval做flush 操作。在 flush 操作中，會將 ArrayList 中的數據按 JSON 或 CSV 的方式序列化為 String 格式，如果開啓壓縮 compress_type（只有 csv 格式支持 gz 壓縮），可將 String 序列化為壓縮後的字節數組，最後將數據通過 StreamLoad 的方式寫入到 BE 節點。
基於該寫入流程，網易雲音樂進行了穩定性及性能壓測，在壓測過程中，發現幾個問題：
- 默認
batch size太小，會導致吞吐量較低，數據延遲問題嚴重；而如果將batch size設置太高（500MB 等），又會導致 Flink TM 端 OOM。 - 寫入 tablet 太多時，元數據產生也較多，不僅影響寫入性能，還可能出現
txn數超限等問題。 - Flink 的 subTask 在初始化後，所寫入的 BE 是確定的，除非產生異常需要重新選擇 BE，否則不會主動變更 BE，這就導致 BE 間負載不均衡。
- BE 在進行滾動變更重啓時，Flink 任務會失敗。
- 監控指標缺失，無法量化客户端各階段耗時。
基於上述問題，網易雲音樂進行了如下優化：
- 在 append 數據操作時，直接寫入壓縮流，無需經過 ArrayList 中轉。這種方式可大幅降低內存的使用，相比之前，TM 內存的佔用從 8G -> 4G。
- 開啓單 tablet 導入功能（要求表必須使用 random bucket 策略），可極大提升寫入性能。
- 每個 batch flush 完成後，隨機選擇一個 BE 節點寫入數據，解決 BE 寫入不均衡問題，相較之前導入性能有 70% 的提升。（_效果見下圖 ，4/30 起為優化後數據_）。
- 調整 failover 策略，同時優化重試邏輯，並增加每次重試的時間間隔，提高系統容錯能力。
- 添加客户端全鏈路監控指標，監測 addBatch/壓縮/flush/發送等各階段耗時，可快速定位主要耗時過程。
HDD 硬盤元數據性能調優
Flink 寫入 Doris 任務偶爾會出現延遲告警，查詢日誌發現 Stream Load 耗時從 5s 突增到 35s 左右。通過 Doris 大盤監控發現 Be Alive 指標抖動嚴重，接着通過 FE 的日誌 grep "finished to handle tablet report from backend" log/fe.log | tail -n 100查看 FE 處理 BE 心跳耗時情況，發現處理 BE 的耗時超 20s。
通過分析 FE 處理 BE 心跳的各步驟，發現大部分處理邏輯都是異步的，只有同步 tablet 元數據的邏輯是同步的。我們通過 grep "tablets in db" log/fe.log | tail -n 100查看相關耗時日誌，發現該階段耗時超 20s，基本可確定是在同步元數據階段出現的嚴重耗時。
進一步的，通過 jstack 打印 FE 的線程棧，可發現 ReportHandler 在處理心跳時，只有 sync meta 一個地方是同步的，正在等待鎖、獲取鎖的邏輯是 flush 元數據。同時，FE 磁盤的 ioutil 達到 50%以上。因此，基本確定問題是由於刷元數據導致性能降低。
在查閲源碼和 bdbje 數據庫的優化措施後，決定對 3 台 Follower FE 調整為異步刷盤：master_sync_policy=WRITE_NO_SYNC 和 replica_sync_policy=WRITE_NO_SYNC，最終實現 4 倍性能的提升。
04 查詢改造和優化
由於 ClickHouse 和 Doris 都支持 SQL，查詢的變化不大，主要區別在於，Doris 支持倒排索引和全文檢索的函數，可用全文檢索代替 LIKE 字符串匹配。
- 普通的查詢
select logs_timestamp,message from log_table
where dt>= '2024-07-29'
and application_id='sloth-f52a7cda-50f8-4092-b6e7-6c9d8ce82c7b'
and log_type='jobmanager'
and container_id='sloth-f52a7cda-50f8-4092-b6e7-6c9d8ce82c7b-6457b684bf-vcrjb'
and logs_timestamp>=1722241811000 and logs_timestamp < 1722241819000
order by logs_timestamp desc limit 500 offset 0;
- 全文檢索的查詢，
message MATCH_ANY 'Exception Failed'匹配 Exception 或者 Failed 關鍵詞。
-- match 全文檢索查詢：
SELECT logs_timestamp,message FROM log_table
WHERE dt>= '2024-07-29'
and application_id='sloth-f52a7cda-50f8-4092-b6e7-6c9d8ce82c7b'
and log_type='jobmanager'
and container_id='sloth-f52a7cda-50f8-4092-b6e7-6c9d8ce82c7b-6457b684bf-vcrjb'
and message MATCH_ANY 'Exception Failed'
and logs_timestamp>=1722241811000
and logs_timestamp < 1722241819000
order by logs_timestamp desc limit 500 offset 0
-- like 模糊匹配查詢:
message LIKE '%Exception%' OR message LIKE '%Failed%'
05 其他調優實踐
使用 partition balance 策略讓 BE 之間數據更加均衡
隨着導入任務的不斷增多，系統在高峯期開始出現了延遲。通過監控發現，個別 BE 的出入流量遠高於其他 BE，進一步分析腳本得知，是由於當天分區的 tablet 在 BE 之間分佈不均衡導致。
為解決這一問題，網易雲音樂決定改用 Partition 策略 tablet_rebalancer_type=partition。該策略可將每天的分區 tablet 均勻分佈到各 BE 上，避免局部負載過高的問題。這也要求寫入任務必須保證數據在單分區內的 bucket 是均勻分佈的，而當前的日誌場景正好滿足這一要求。下圖為優化後數據（_6 月 11 日在進行滾動變更，抖動較為嚴重，6 月 13 日後為穩定數據_）：
調整參數讓磁盤之間更加均衡
-
重度不均衡
從下圖可以看出，個別 BE 的 Compaction Score 非常高，同時這些 BE 的某些磁盤 I/O 利用率持續保持在 100%。與社區同學交流後得知，這主要是由於 BE 磁盤選擇策略與 trash 清理機制之間的相互影響所致。
具體來説，儘管 BE 選擇磁盤的策略是 round-robin，但當磁盤空間使用率超過 80% 時，系統會強制觸發 trash 清理機制，這會導致某些磁盤的使用率急劇下降，從而使新的 tablet 更多地被分配到這些“低負載”磁盤上，導致這些磁盤負載持續升高。
進一步的，通過 BE 提供的查詢 tablet 分佈 OpenAPI，發現該 BE 上大流量表當天分區的 tablet 分佈情況如下圖所示，存在磁盤之間不均衡問題。
通過調整以下參數，來解決該問題：
trash_file_expire_time_sec = 0：關閉 trash，日誌場景中每天數據量級非常大，且 trash 恢復比較困難，沒有必要使用 trash。high_disk_avail_level_diff_usages = 0.8：BE 選擇磁盤時，先根據磁盤的空間使用率劃分級別，每個級別使用 round-robin 的方式分配，提升分級別的參數，可以將使用率高和低的盤強制放在一個級別中（風險提示：如果不確定是 trash 導致，可能存在個別盤打滿的風險）
-
輕度不均衡
壓測過程中，還發現存在輕度磁盤不均衡問題。這是由於 FE 的 balancer 機制，會選擇 BE 磁盤使用率最小的 disk 進行遷移，從而導致存在部分不均衡問題。可暫時通過設置參數
disable_balance=false關閉 balancer 解決此問題。
監控運維
在落地過程中，運維方面主要進行以下三方向的建設：
- 可觀測性：基於社區提供的的 Grafana 監控模版，對相關指標進行完善，構建了全面的可觀測體系，實現對集羣運行狀況、關鍵指標的實時監控與分析。
- 自動化運維：依託內部的運維平台，構建了自動化告警、自動拉起、問題處理等邏輯。當系統出現異常時，系統可自動檢測並採取相關措施，極大減輕了運維人員的工作負擔。
- 自動化均衡：採取了自動化探測 tablet 磁盤是否分配均衡的策略，並針對不均衡的情況進行自動化遷移。這一能力確保了集羣在擴容或停機維護時，能夠自動達到最佳的負載均衡狀態。
通過這三個方向的建設，進一步強化了 Doris 在運維層面的自動化和智能化能力，極大提升了整體的運維效率和可靠性。這不僅大幅減輕了運維人員的工作負擔，也為系統穩定運行提供了有力保障。
升級收益
網易雲音樂使用 Apache Doris 替換 ClickHouse 構建了新的日誌平台，已經穩定運行三個季度，規模達到 50 台服務器、2PB 數據量。這次架構升級帶來查詢響應、併發能力、穩定性和運維效率等多方面可觀的收益。
- 查詢響應提升：整體 P99 查詢延遲降低了 30%。特別是通過倒排索引加速，Doris 的全文檢索 MATCH 查詢性能比 LIKE 查詢提升了 3-7 倍（在查詢約 6TB 數據時，LIKE 查詢耗時 7-9 秒，而 MATCH 查詢僅需 1-3 秒）。此外，倒排索引的全文檢索具備自動的大小寫和單複數歸一化能力，能夠高效檢索出更多相關日誌。
- 查詢併發提升：ClickHouse 併發查詢數超過 200 時就會經常出現
Too many simultaneous queries錯誤，而 Apache Doris 能夠支撐 500+ 併發查詢。Doris 還可以對單次查詢的數據量和併發數進行調整，以靈活應對不同場景下的併發要求。 - 寫入穩定性提升：FE / BE 發生單點故障時，都能自動感知和重試恢復，保證服務高可用。
- 運維成本降低：在壞盤和宕機場景下，Doris 的自恢復能力結合進程自動拉起腳本，降低人工干預的運維成本。擴容或停機維護場景下，Doris 的自動均衡能力很強，擴容後隨着 tablet 的自動均衡和老數據的清理，集羣會自動達到均衡狀態。
此外，網易雲音樂在技術能力上也有良好的積累，積極與 Doris 社區同學深入溝通、解決關鍵性問題，同時也積極向社區提交相關 Issue 和 PR，共同推動 Doris 社區的建設與發展。
未來規劃
當前，網易雲音樂內部所應用 Doris 集羣已達 100 餘台（包括日誌存儲和其他數據分析場景），後續還將在更多場景中推廣落地。未來還將着重從以下幾方面發力：
- 利用 Doris 冷熱分層存儲等能力，在提高查詢性能的同時進一步降低成本。
- 使用 Doris Workload Group能力，進行相關資源隔離，提升集羣穩定，按優先級保障業務使用。
- 增加在線查詢等更多應用場景，Doris 出色的併發查詢能力將為這些場景提供強有力的支持。
- Doris 的數據湖擴展能力也是網易雲音樂非常看重的能力，這為規劃中的 One-SQL 數據架構奠定了堅實基礎。
更多關於 日誌場景應用實踐及優化經驗已經沉澱到的《日誌存儲與分析解決方案白皮書》 中，感興趣的同學可以下載參考。
