浩瀚深度（[SHA: 688292]）旗下企業級大數據平臺選擇 Apache Doris 作為核心數據庫解決方案，目前已在全國范圍內十余個生產環境中穩步運行，其中最大規模集群部署于 117 個高性能服務器節點，單表原始數據量超 13PB，行數突破 534 萬億，日均導入數據約 145TB，節假日峰值達 158TB，是目前已知國內最大單表。憑借 Apache Doris 的高可靠、高性能與高可擴展能力，該集群已持續穩定運行半年以上，充分驗證了其在超大規模數據場景下的卓越表現。

浩瀚深度作為國內互聯網流量解析與數據智能化領域的領軍企業，深耕行業三十余載，持續為國內互聯網提供高性能、高精度、高可靠的整體解決方案。公司業務覆蓋網絡可視化、AI 智能、數據治理、數據價值挖掘及安全防護，是一家集軟硬件產品研發、生產、銷售和服務于一體的大型高科技企業。

順水云大數據平臺（StreamCloud）作為浩瀚深度自主研發的企業級的大數據平臺產品，涵蓋了從數據采集、數據存儲、數據處理、數據挖掘、數據治理到數據共享的完整數據開發流程。幫助企業客戶快速構建 PB 級數據中臺，目前已經在通信、金融、交通等領域落地部署 100+ 項目，管理超過 130PB 數據，集群節點規模近萬個。

為滿足客戶每日寫入及查詢萬億級增量數據的嚴苛需求，順水云對 MPP 數據庫產品進行了多輪選型測試，并在實際生產環境中嘗試過 Greenplum、ClickHouse 等多個方案。經過綜合比對，最終選定 Apache Doris 作為核心數據庫解決方案。目前，該方案已在全國十余個生產環境上線運行，其中規模最大的集群部署于 117 個高性能服務器節點之上，單表原始數據量超 13PB，行數突破 534 萬億，日均導入數據量約 145TB ，節假日峰值數據量約 158TB，且已持續穩定運行半年以上。

早期架構以及痛點

早期架構如圖所示，數據主要來源為用戶上網日志，數據經過采集設備解析還原后發送到接口機上，再由接口機上程序接入 HDFS 集群，基于 Apache Spark 將不同類型話單經過加工、回填、合成等流程處理后生成結果數據，最終寫入至 ClickHouse 中，用于日志存儲與快速查詢、流量質量分析、面向政企市場的用戶畫像 & 精準營銷等場景。

隨著業務數據體量逐漸龐大，對于高吞吐的數據寫入、億級數據的秒級響應、海量數據關聯查詢的需求也愈加迫切，以 ClickHouse 為核心的 OLAP 查詢分析引擎體系在使用過程中對業務人員開發、運維人員維護存在如下痛點：

1. 寫入穩定性差且存儲成本較高：為降低存儲成本，我們嘗試使用 ZSTD 壓縮格式，但因其高壓縮比帶來的性能開銷，頻繁出現 “too many parts” 及當日數據入庫積壓問題。為保障業務穩定運行，只能增加存儲成本使用默認的 LZ4 壓縮；
2. 運維成本高：使用自研的數據入庫工具，由于不同接口機上數據量和導入性能差異，導致 ClickHouse 集群上各節點數據量不均衡，由于 ClickHouse 架構特性，壞盤時數據無法自動遷移，需要人工持續干預；
3. 并發查詢能力不足：在并發查詢較多場景下，查詢性能下降明顯，無法支持業務需求；
4. JOIN 能力不足：由于 ClickHouse 自身組件設計無法支持多表或大表 Join 查詢場景，難以滿足大表關聯查詢需求。

為了進一步對比驗證 Doris 的寫入和查詢性能，我們使用了三臺物理機模擬生產環境數據和業務對 Apache Doris 和 ClickHouse 做了一系列對比測試。主要分為以下 3 部分：

• 前綴索引測試對比

查看前綴索引文檔詳情

• 二級索引測試對比

查看 BloomFilter Index 文檔詳情 查看 Inverted Index 文檔詳情

• 全表掃描測試對比
• 測試參數：
• 建表：
• Doris 自 2.0.0 版本支持倒排索引能力，因此我們在表的數據量和字段一致的背景下，針對不同的排序鍵與索引類型進行查詢速度測試：

前綴索引可以加速等值查詢和范圍查詢。在 Doris 中，建表時自動取表的 Key 的前 36 個字節作為前綴索引。前綴索引測試分為 3 次冷查詢，測試結果如下：

測試二：二級索引

• BloomFilter Index 是基于 BloomFilter 的一種跳數索引，其原理是利用 BloomFilter 跳過等值查詢指定條件不滿足的數據塊，達到減少 I/O 查詢加速的目的。
• Inverted Index 可以用來進行文本類型的全文檢索、普通數值日期類型的等值范圍查詢，快速從海量數據中過濾出滿足條件的行。

二級索引分別對比測試了 Doris 的 BloomFilter Index 和 Inverted Index ，測試分為 3 次冷查詢，測試結果如下：

測試三：全表掃描

全表掃描測試主要是測試了常用業務查詢場景：like 模糊查詢和 IP 函數，根據測試結果， IS_IP_ADDRESS_IN_RANGE 函數查詢方面 ClickHouse 略勝。

結果分析

在合理配置索引的前提下，Doris 在關鍵查詢場景下展現出顯著性能優勢：

• 前綴索引：Doris 查詢速度是 ClickHouse 的 2 倍以上。
• 二級索引：使用 BloomFilter 索引時，Doris 查詢速度領先 ClickHouse 達 2 倍。相同場景下 Doris 的倒排索引功能，使得查詢性能更是大幅躍升，速度遠超 ClickHouse，是其性能的 5 倍以上。
• 全表掃描：兩者性能接近，ClickHouse 在特定函數調用上略占優勢。

綜合來看，兩者各有所長，但測試表明：在常用業務查詢場景中，Doris 的前綴索引、BloomFilter 和倒排索引性能全面優于 ClickHouse。據此評估，遷移至 Doris 后，查詢響應速度預計提升超 2 倍。

Doris 替換實踐

由于 ClickHouse 和 Doris 均為 MPP 架構數據庫，且 Doris 支持 MySQL 語法，因此架構變化小、遷移便捷。僅需將日志存儲與分析引擎由 ClickHouse 替換為 Doris，具體步驟如下：

• 調整上游 Importer 寫入組件的配置，使其將日志數據直接寫入 Doris 表；
• 更新下游查詢服務的 SQL 語句以適配 Doris 語法即可完成無縫遷移。

雖然我們對 Doris 做了幾 TB 的數據測試做使用參考，但考慮生產環境日增數百 TB 的數據量級，再加上引入新組件的不確定性，實施初期我們采用了 ClickHouse 和 Doris 并行運行的方式。

同時在壓測期間也遇到一些問題，目前均已解決，我們將這些問題的解決思路整理并分享至社區，以供參考。

實踐一：解決大批量寫入報錯問題

在進行導入壓力測試階段，小數據量下，集群運行狀況和導入性能均表現良好。但是在逐漸上升至 30 臺接口機同時并發導入時，系統逐漸出現一些異常情況。具體如下：

org.apache.doris.common.UserException: errCode = 2, detailMessage = get tableList write lock timeout, tableList=(Table [id=885211, name=td_home_dist, type=OLAP])[INTERNAL_ERROR]cancelled: tablet error: tablet writer write failed, tablet_id=24484509, txn_id=3078341, err=[E-216]try migration lock failed, host: ***

在出現異常情況后，我們及時和社區同學聯系溝通，參考官方文檔中的《日志存儲和分析》模塊的參數進行調優后，導入任務恢復正常。

實踐二：Compaction 壓力過載優化

進一步壓測，我們發現在導入持續一段時間后，BE 節點在監控中出現異常。結合監控以及 top -H 的輸出，發現 Compaction 占用 CPU 資源比較多，導致 BE 出現假死。經過 Compaction 問題排查，發現與 Bucket 數量有關。

由于當時按照 ClickHouse 自動合并后單個分區下文件數量的最大值來設置， Bucket 數量我們設為了 480，導致 Tablet 過多而引發問題。

后來結合實際業務場景，以及業務高峰期數據量等因素進行了計算后，將 Bucket 縮減為 280 ，調整后 Compaction 資源占用恢復正常 ，BE 節點恢復平穩運行。

實踐三：導入異常問題排查

在壓測期間導入出現一個事物卡住的情況，異常如下：

errCode = 2, detailMessage = current running txns on db 10194 is 10000, larger than limit 10000

根據報錯內容引導處理，我們調整了單個 DB 下的事務數量，發現不是根本原因。隨后，我們將問題反饋給社區同學，在他們的協助下，很快定位到了問題根源。具體定位步驟如下：

1. 找到一個具體的事務 ID

1. 登錄 FE 的主節點，搜索事務對應的具體 BE

grep "16788479" /opt/install/doris-2.15/fe/log/fe.log

1. 登錄到具體 BE，在日志中搜索該事務 ID

grep "16788479" /opt/install/doris-2.15/be/be.INFO

排查發現，事故起因是某臺機器磁盤寫滿，導致集群開始將該節點的寫入和副本調度至其他節點，而當前寫入壓力較大，進而引發了事務積壓。此外，由于磁盤上仍殘留部分 ClickHouse 數據，進一步加劇了磁盤空間分布不均的問題。

實踐四：使用 Broker Load 解放接口機

由于 Doris 中的導入功能非常豐富，幾乎在每個場景都有對應的導入，剛開始我們使用的是 Stream Load 導入本地數據文件，在進一步學習了解使用 Doris 后，發現 Broker Load 的導入方式更契合業務場景，因為系統加工合成的數據本身就存儲在 HDFS 上，Broker Load 可以直接從 HDFS 上拉取數據，相比較之前從 HDFS 下載數據到本地再進行導入方式，這樣不僅能減少一次數據傳輸，還解放了數據導入使用的接口機，進一步提高了效率。我們需要做的就是申請 Doris 集群和 HDFS 集群的網絡打通和 Broker 的部署，并編寫一套檢測數據并提交 Broker Load 的腳本。

經測試，目前已經上線上百臺的 Broker 節點去進行并行拉取 HDFS 的數據并進行導入，寫入性能優異。但使用 Broker Load 時要注意按照業務場景進行調整，如果默認子任務失敗則會導致整個目錄的文件導入全部失敗。HDFS 中數據以 15 分鐘粒度為目錄存儲的，需要做好相應的失敗檢測與重試機制。

在機器成本方面，相較于使用 ClickHouse 導入一天數據需要 32 臺接口機，改用 Doris 后，省去了從 HDFS 拉取數據的機器，僅需 23 臺即可完成同等數據量的導入，機器資源節省超過 28%，顯著降低了成本并提效。

架構升級成果

目前，浩瀚深度已在某運營商客戶環境使用 Doris 替換 ClickHouse 構建了新的查詢分析平臺，服務器規模超百臺，并實現日增數據量峰值近 158TB 的數據導入。采用雙副本 + 倒排索引 + ZSTD 壓縮后，存儲量約 6.5PB，和原始數據相比，Doris 中單個副本的壓縮率在 4 倍左右，且目前已穩定運行半年多，這次升級帶來查詢響應、并發能力、穩定性和運維效率等多方面的收益，成果顯著。

• 顯著降低硬件資源成本：利用 Doris Broker Load 高效導入機制，釋放原 ClickHouse 所需的 32 臺專用接口機，這些資源可靈活用于計算或存儲，整體硬件成本節超 28%。采用 ZSTD 高壓縮比格式，在未出現寫入瓶頸的前提下，存儲資源消耗相較 ClickHouse（LZ4 壓縮）降低了 6%。
• 大幅提升查詢效率：Doris 卓越的索引優化（前綴索引、Bloom Filter、倒排索引）及多表 JOIN 性能全面超越 ClickHouse。單 SQL 查詢響應速度提升近 2 倍。批量查詢任務執行效率提升近 30%。
• 有效降低運維復雜度與成本：服務器宕機或壞盤時，Doris 自動完成副本切換與寫入重定向，保障服務連續性。集群擴縮容時，Doris 自動實現 Tablet 均衡分布，快速恢復集群負載均衡。通過 Doris 原生 Web UI 與 Grafana 監控，異常節點與磁盤故障可被快速定位。

未來，浩瀚深度將從以下方面重點發展：

• 持續深化 Doris 的湖倉一體化應用：通過 Doris 的 Hive Catalog 功能整合數據倉庫資源，統一數據訪問接口，實現對全量數據的統一查詢與分析；
• 復雜查詢加速：在多維度分析、聚合計算等復雜查詢場景下，依托 Doris 強大的整合能力提升查詢效率，加速報表生成；
• 成本優化：利用 Doris 的冷熱數據分層存儲等特性，在持續優化查詢性能的同時，進一步降低總體存儲成本。

最后，衷心感謝飛輪科技技術團隊與 Doris 社區對浩瀚深度的持續、專業的技術支持，有力推動了我們的國產化架構轉型進程。 我們熱忱期待更多同仁加入 Apache Doris 的應用實踐與社區貢獻行列，共同豐富其功能生態、擴展函數支持，助力 Apache Doris 在全球 MPP 數據庫領域綻放璀璨光芒！