数据价值的不断升级，是过去三十年来数据库演进的核心驱动力。而 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

1. 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