數據價值的不斷升級，是過去三十年來數據庫演進的核心驅動力。而 AI 的崛起，將這一需求推向新的高度：數據不僅要能被“看”到，更要能被“理解”和“創造”——這一點已在基於大語言模型（LLM）為核心的代碼生成、智能對話等應用中得以驗證。

這一背景下，由自主 AI 智能體（Agent）驅動的分析已成為典型範式。 智能體能夠獨立推理、實時分析數據，甚至主動觸發行動。這意味着分析模式正從被動報告轉向主動決策，處理模式也從以查詢為中心轉向以語義和響應為中心。

這一轉變對數據基礎設施提出巨大挑戰：工作負載已從“少量用户、繁重查詢、慢容忍度”轉變為“海量用户（智能體）、輕量級/迭代查詢、零延遲容忍度”。如果數據庫系統無法滿足高併發低延遲的查詢需求，那麼其上構建的 AI 智能體就會變得緩慢、笨拙，尤其是在一些信息檢索的領域產生幻覺，給人誤導性的結果。

因此，面向智能體的高併發和低延遲處理能力，已不再是可選項，而是決定數據倉庫能否支撐 AI 時代的生存基石。

1. 查詢吞吐（QPS）全面領先

進入 AI 時代，Apache Doris 繼續保持技術領先。4.0 版本實現了與 AI 能力的深度融合，增強 AI 原生支持，並基於混合搜索技術統一處理結構化過濾、文本搜索、向量語義搜索，突破數倉功能界限，升級為企業核心的“AI 分析中樞”，為智能決策和創新實踐提供穩定、高效的底層數據支持。

不可忽視的是，Apache Doris 一直以實時極速著稱，在性能和吞吐量方面均處於領先水平。因此，在 AI 時代，這一能力依舊強悍，能夠高效支持面向 Agent 分析的高併發分析。

為了更直觀的展示這些能力，我們對最當下流行幾款數據系統進行評估，結果顯示，結果顯示，Apache Doris 在每種設置下的表現均優於其他系統。

1.1 基礎配置

我們對 SelectDB（基於 Apache Doris 內核構建的現代實時數據倉庫）、Snowflake 和 Clickhouse Cloud 進行了性能及吞吐量的比較。評測基於 SSB-FLAT、SSB、TPC-H 這三個測試集，並藉助 Apache JMeter（一款開源軟件應用程序，旨在對功能行為進行負載測試並測量性能）進行負載測試。具體測試方法為：啓動 10/30/50 個線程並按順序提交查詢，每個查詢運行 3 分鐘，然後獲取每個查詢的 QPS。

為確保測試的準確性和公平性，我們儘可能保證配置規模和定價的一致性。由於各平台對計算資源的命名不盡相同，以下是相關配置的簡要説明：

• SelectDB 和 Clickhouse Cloud：用户可以根據 CPU 核心數選擇預期的集羣規模。本次評估 SelectDB 和 Clickhouse Cloud 均選擇了 128 核集羣。
• Snowflake：集羣按大小（超小、小、中、大、超大）衡量。本次評估選擇超大（X-Large）尺寸集羣，約等於 128 核集羣。

1.2 測試及結果

結論先行，在三個基準測試集中，SelectDB 在不同並行度（10/30/50）下的性能及吞吐量均優於 SnowFlake 和 Clickhouse。

其中 SSB-FLAT 是一個純寬表基準測試，而 SSB 和 TPC-H 則是包含了表連接的複雜查詢測試。

通常情況下，Clickhouse 在掃描單個寬表時通常表現更快，Snowflake 以其更好的彈性擴縮容能力而著稱，SelectDB 則兼具二者，並且在複雜查詢和單表查詢的場景都進行了針對性的優化。SelectDB 憑藉強大的優化器能夠重寫複雜查詢，憑藉高效的執行引擎來執行查詢，從而能夠在各個並行度的基準測試中表現出了遠優於其他系統的併發處理能力。

SSB-FLAT

SSB-FLAT 旨在衡量系統查詢單張寬表的能力。在該基準測試中，SSB 中所有表被轉換為一個非規範化的扁平表，且不涉及連接操作。

在 10、30、50 三種並行度下，SelectDB 均展現出比 Snowflake 和 ClickHouse 更高的 QPS ：

• 相比 Snowflake，SelectDB 的 QPS 分別達到其 6.38 倍、7.28 倍、7.39 倍；
• 相比 ClickHouse，SelectDB 的 QPS 分別達到其 6.92 倍、5.66 倍、4.76 倍。

下圖直觀展示了這一性能對比結果。

SSB

專為評估數據庫對星型模型的查詢優化能力而設計。該基準結構簡明，包含四個查詢集、四個維度表和一個簡單的彙總層次。在該測試集下：

1. 在 10、30、50 三種併發條件下，SelectDB 的 QPS 分別是 Snowflake 的 6.37 倍、5.98 倍、5.17 倍，性能表現顯著領先。
2. 由於 ClickHouse 在當前測試中無法完整支持 SSB 所需的連接操作，未能產生有效可比結果，因此在圖中將其結果設為 0。

TPC-H

TPC-H 是業界廣泛採用的決策支持系統基準測試。它包含一系列面向業務的即席查詢與併發數據更新任務，其查詢語句與測試數據均經過嚴謹設計，具備廣泛的行業代表性。該基準旨在評估系統處理大規模數據、執行復雜查詢並輔助關鍵業務決策的能力。

1. 在 10、30、50 三種併發度下，SelectDB 的 QPS 分別達到 Snowflake 的 3.10 倍、2.16 倍與 1.71 倍，持續保持性能領先。
2. 由於 ClickHouse 在部分 TPC-H 查詢（尤其是 Q20、Q21、Q22）中無法完全支持所需的連接操作，未能獲得有效的可比結果，因此在圖表中將其設為 0 。

完整測試結果可從 SelectDB 官網獲取：https://www.selectdb.com/blog/1580

2. Apache Doris 為何能夠領先？

承接前文基準測試中展現出的卓越吞吐性能，接下來介紹為何 Apache Doris 在高併發查詢上能全面領先其他同類型產品，其背後有哪些能力或技術支持？

其能力並非源於單一優化手段，而是通過多層協同——比如高效的數據裁剪、Pipeline 執行模式、向量化執行引擎等共同構築了支撐海量請求併發的技術基石。下面我們將對其中的幾項關鍵技術進行原理解析。

2.1 數據裁剪

如何高效處理數據是實時數據倉庫中的核心主題之一。在 Apache Doris 中，過濾掉不必要的數據，只讀取最小的數據子集，這被稱為“數據裁剪”，是查詢加速的主要手段之一。

2.1.1 謂詞過濾

在 Apache Doris 中，就生成過濾器的時間而言，可將其分為兩類：靜態過濾器和動態過濾器。

• 我們將查詢執行前生成的過濾器稱為靜態過濾器。例如，假設用户要查詢所有價格大於 10 的飲料，> 10 這一謂詞過濾器就可在 SQL 解析階段推導出來。
• 對於包含內等值連接的查詢，只有探測側與構建側匹配的行才應該被讀取。因此，這些過濾器只能在構建哈希表之後生成，稱為動態過濾器。

現在我們探討 Apache Doris 中的靜態過濾器——謂詞過濾。對於一張普通的表，其列可分為分區列、鍵列和值列三種類型。針對不同類型的列，過濾方式也各不相同：

1. 對於分區列的謂詞： FE 可直接根據元數據判斷需要訪問哪些分區，從而直接在分區級別進行數據裁剪，這是最高效的數據裁剪方式。
2. 關於鍵（Key）列的謂詞：由於數據在段內是按鍵列順序組織的，只需根據謂詞條件生成鍵列的上下邊界，再通過二分查找即可定位需要讀取的數據行範圍。
3. 關於普通列的謂詞：每個列數據文件都會維護包含最大值/最小值的元數據，因此可以通過比較謂詞條件和元數據來過濾列文件。然後讀取剩餘列文件並執行謂詞計算，過濾掉所有不匹配謂詞的行。

完成謂詞過濾後，系統獲得所有匹配查詢條件的行索引。隨後，只需按行索引加載對應的數據行即可。

2.1.2 LIMIT 裁剪

另一種數據裁剪的方法是 LIMIT 裁剪。在查詢時限定返回行數是常見使用方式，具體來説：由於限制條件會被下推至查詢執行過程中，一旦滿足該行數限制，查詢即可提前終止。

2.1.3 TopK 裁剪

TopK 查詢在 BI 查詢中廣泛使用。簡單來説，TopK 查詢是指根據某些列的順序檢索前 K 個結果，與 LIMIT 裁剪類似。但如果使用最基本的方法對數據進行全排序，然後取前 K 個結果，掃描數據所帶來的開銷非常大。因此，在 Apache Doris 中，TopK 通常通過堆排序方法實現。

A. 標準堆排序方法

處理 TopK 查詢的直觀方法是標準堆排序方法。核心是維護一個最小堆以實現降序排序。當新數據入堆時，會即時更新堆內容。此過程中，不在堆排序範圍中的數據將被丟棄，這意味着無需維護不必要的數據。掃描完成後，堆中現有數據便是我們所需的全部結果。

B. 理論最優解

堆排序的理論最優解指通過掃描數據獲取正確結果所需的最小數據量。在 Doris 中，數據在段內按鍵列順序存儲。因此，當 TopK 查詢的結果按鍵列排序時，我們只需讀取每個段的前 K 行，然後進行歸併排序即可得到最終結果。如果排序結果基於普通列，理論最優的方法應是讀取每個段的排序數據進行排序，並根據排序結果檢索相應的數據行，而無需讀取所有數據進行排序。

那麼在堆排序過程中，如果能夠應用一些特殊的優化方法，只掃描滿足查詢條件的數據，查詢執行的效率將得到極大提升。因此，Doris 針對 TopK 查詢，主要進行了以下優化：

首先，在數據掃描線程中，先對數據局部截斷，然後通過全局協調器對數據進行最終排序，並根據排序結果進行全局截斷。因此，Doris 的 TopK 查詢執行過程實際上分為兩個階段：

• 第一階段，按照上述方案讀取排序列，執行局部排序和全局排序，得到符合條件的數據的行號。
• 第二階段，根據第一階段得到的行號，讀取除排序列之外的所需列，從而得到最終輸出結果。

2.1.4 JOIN 裁剪

JOIN 是數據庫系統中最耗時的操作，數據量越少，JOIN 的開銷就越低。若暴力執行 JOIN，即計算笛卡爾積，時間複雜度為 O（M*N），其中 M 和 N 分別為兩個表的大小。因此，我們通常選擇 Hash Join 作為更高效的連接方法。

在 Hash Join 中，我們選擇較小的數據表作為構建端，基於其數據構建哈希表，然後用另一側的表作為探測端來查找哈希表。理想情況下，若忽略內存訪問的影響，構建和探測單行的複雜度為 O（1），整個哈希連接的複雜度為 O（M + N）。由於探測端的數據通常較大，減少探測端數據的讀取和計算顯得尤為重要。

Apache Doris 支持 JOIN 裁剪，能夠對探測側數據進行有效裁剪。由於哈希表中構建側數據的值是確定的，可以根據數據量的大小選擇合適的 JOIN 裁剪方式。

2.2 Pipeline 執行引擎

Apache Doris Pipeline 執行引擎的設計目標是能夠在查詢執行遇到阻塞算子（例如，Join 和 Shuffle 算子中的磁盤 IO、網絡 IO）時在用户態主動出讓 CPU。這些阻塞算子被稱為 Pipeline Breaker。因此，每個執行線程可以專注於計算密集型任務，儘量減少上下文切換的開銷。同時， Pipeline Breaker 的存在使得數據能夠均勻重新分佈，每條 Pipeline 可以獨立設置並行度。例如，在單線程情況下，從兩個分片加載數據的掃描算子可以將數據分發到所有具有 N 並行度的下游算子。

通過 Pipeline 執行引擎，用户可以更高效地處理數據，具體收益包括：

1. 引入本地交換優化，充分利用 CPU 資源，實現數據均勻分佈，最大限度減少數據傾斜，同時並行性不再受分片數量的限制。
2. 多個併發任務共享狀態，減少額外的初始化開銷，如表達式和常量變量。
3. 所有流水線任務的阻塞條件通過 Dependency 進行封裝，任務執行邏輯由外部事件（如 RPC 完成）觸發，消除阻塞輪詢線程的開銷。
4. 用户可獲得更直觀的查詢 Profile。

2.3 向量化執行引擎

向量化查詢執行是指通過批量處理數據而非逐行處理來提升查詢性能的方法。該方法充分利用現代 CPU 架構的優勢，藉助單指令多數據流（SIMD）操作和循環展開等技術，顯著提高了 CPU 的數據處理效率。在 Apache Doris 中，向量化執行引擎為實際應用場景帶來了顯著的查詢性能提升。數據壓縮、循環計算等操作也因此得到大幅加速。

結論

在本文中，我們探討了 AI 時代數據倉庫的現狀與前景，我們認識到數據在訓練和推理中發揮着關鍵作用。針對這一挑戰，面向 AI 時代設計的 Apache Doris 4.0 版本應運而生，該版本原生支持 MCP Server、向量檢索、檢索增強生成（RAG）及 AI 函數等功能。並在查詢延遲、吞吐量和成本效益方面均顯著優於同類產品，成為 AI 時代理想的數據倉庫解決方案。

完整測試結果可從 SelectDB 官網獲取：https://www.selectdb.com/blog/1580