过去评估 OLAP 数据库，最容易被量化的指标是查询性能。

一张几十亿甚至上百亿行的表，聚合查询需要多久？同样的机器规模下，谁能扫描更多数据？在日志分析、用户行为分析和大规模明细查询兴起的阶段，这些指标直接决定了一套分析系统是否可用。

ClickHouse 正是在这样的负载中建立了很强的市场认知。列式存储、高压缩比和高效执行引擎，使其成为大规模日志、事件数据和实时分析的重要选择。

但企业把 OLAP 用得越来越深之后，问题开始变复杂。

订单状态需要实时更新，经营分析需要关联多张业务表，历史数据沉淀在 Iceberg、Hive 等湖存储中，日志平台既要做全文检索又要做 SQL 聚合，AI Agent 还可能在一次任务中连续发起多次数据查询。

此时再用“一条 SQL 跑多快”衡量数据库，已经很难反映真实的系统成本。

Doris 与 ClickHouse 今天的比较，也更适合放在这样的背景下讨论：当 OLAP 从查询引擎逐渐进入企业核心数据基础设施，两套系统各自把能力边界扩展到了哪里。

## 一、复杂分析的关键，已经不只是扫描速度

很多 OLAP 系统最初承载的是相对简单的事件数据分析：按照时间、用户、设备或者业务维度过滤，再进行聚合计算。

这类负载中，数据往往集中在一张事实表里，数据库能够快速扫描和聚合，基本就解决了大部分问题。

企业经营分析则不同。

一个销售指标可能同时关联订单、用户、商品、地区和营销活动；用户画像需要组合交易、行为和标签数据；风控分析还可能涉及实时事件和历史特征。SQL 中开始大量出现 Join、子查询、多层聚合以及复杂过滤条件。

这时，执行性能很大程度上取决于优化器能不能找到合理的执行计划，而不是单纯取决于底层每秒可以扫描多少数据。

Doris 的 Nereids 优化器同时使用基于规则和基于成本的优化方式，并结合统计信息进行 Join Enumeration；Runtime Filter 则可以根据 Join 一侧的数据动态生成过滤条件，并下推到扫描阶段，尽早减少参与后续计算的数据量。Pipeline 执行引擎负责进一步提高并行执行效率。

这些能力针对的是一个很实际的问题：当 SQL 从单表聚合变成十几张表之间的复杂关联后，查询性能越来越依赖整个执行计划，而不是某一个算子的局部性能。

这并不意味着 ClickHouse 不能处理 Join 或复杂 SQL。ClickHouse 本身也在持续加强查询优化和数据仓库能力。真正需要区分的是业务负载：如果主要处理 append\-only 的事件数据和大规模扫描，ClickHouse 依然很有竞争力；如果大量查询建立在业务模型、多表关联和复杂指标计算之上，优化器的成熟度和执行计划稳定性就会成为更重要的选型因素。

## 二、实时数仓的难点，在于“写、改、查”同时发生

另一类容易被低估的差异来自数据更新。

日志和行为事件通常具有明显的 append\-only 特征：数据产生以后持续追加，很少修改历史记录。这种数据模型非常适合分析型列存数据库。

但业务数据不是这样。

订单会从“待支付”变成“已支付”，物流状态持续变化，用户标签会被更新，账户余额和库存也可能不断变动。数据库既需要承接持续的数据写入，又需要处理主键去重、更新和删除，同时保证最新数据能够快速进入查询。

Doris 的 Unique Key 模型就是围绕这类负载设计的。Merge\-on\-Write 会在写入阶段完成同一 Key 数据的合并，使查询直接读取最新版本；同时支持部分列更新，因此可以承接订单状态、用户画像、实时维表以及 CDC 同步等数据。

在数据接入侧，Routine Load 可以持续消费 Kafka，并提供 Exactly\-Once 语义；针对高频小批量写入，Group Commit 可以将多个小事务合并提交，减少事务和 Compaction 压力。

这些机制组合起来，解决的是实时数仓中一个比“写得快”更复杂的问题：数据进入数据库以后，还要能够持续变化，并且变化之后立即参与分析。

因此，实时数仓的评估指标通常应该同时包含写入吞吐、数据可见延迟、更新能力以及查询性能，而不是单独测试其中一项。

## 三、湖仓一体解决的不是“多支持几个数据源”，而是减少数据搬迁

企业数据规模扩大之后，另一个现实问题是：数据不可能全部放在一个数据库里。

大量历史明细可能沉淀在 S3、HDFS 或 OSS，对应 Hive、Iceberg、Hudi、Paimon 等表格式；实时业务数据可能位于数据库或数仓内部；维度信息还可能来自 MySQL、PostgreSQL 等系统。

传统做法是先通过 ETL 把需要的数据复制到分析系统，再进行计算。

数据源越多，这种方式的问题越明显：同一份数据在多个系统重复存储，ETL 链路越来越长，数据新鲜度下降，故障和运维节点也随之增加。

Doris 的 Multi Catalog 更接近一个联邦分析层。外部的 Hive、Iceberg、Hudi、Paimon 以及关系型数据库可以注册为 Catalog，不同 Catalog 之间的数据可以直接通过 SQL 关联，查询仍然由 Doris 的 MPP 引擎执行。

在 Iceberg 场景中，Doris 已经不仅能够读取数据，也支持 INSERT、UPDATE、DELETE 和 MERGE INTO 等写操作。

因此，湖仓能力真正影响的是数据架构。

企业不一定需要为了每一次分析先复制一份数据。实时数据可以留在高性能存储中，长期历史数据继续保留在低成本对象存储，需要联合分析时再通过统一 SQL 访问。

当数据规模进入几十 PB 甚至更高之后，减少一次数据复制，带来的往往不只是存储费用下降，还包括数据链路、计算任务和运维工作的同步减少。

## 四、日志与可观测：Doris 开始进入 ClickHouse 的传统强势场景

日志一直是 ClickHouse 最具代表性的应用场景之一，这一点今天依然成立。

而且 ClickHouse 自身也在继续向完整的可观测平台演进。当前 ClickStack 已经围绕 OpenTelemetry 将 Logs、Metrics、Traces 和 Session Replay 纳入统一技术栈；ClickHouse 26\.2 还将新的全文 Text Index 推向 Production。

因此，如果今天再把两者描述成“ClickHouse 做日志，Doris 做数仓”，已经不准确。

变化更值得关注的是 Doris 这几年也在主动进入日志和可观测负载，而且它切入这个市场的方式并不是重新做一个独立日志引擎，而是直接在 OLAP 内核上补齐全文检索和半结构化数据处理能力。

Doris 目前可以作为 OpenTelemetry 的存储后端，统一接收 Logs、Traces 和 Metrics；针对日志查询，则提供倒排索引、全文检索、SEARCH DSL，以及面向动态 JSON 的 VARIANT 类型。日志进入 Doris 后，可以同时进行关键词检索、SQL 聚合、多维分析，并进一步与业务表进行 Join。

成本是这个场景尤其值得关注的一点。

日志的数据量通常很大，但单位数据价值随着时间快速下降。如果一个平台每天新增数十甚至上百 TB 日志，让所有数据长期停留在昂贵的热存储中，最终往往不是性能先遇到瓶颈，而是成本。

Apache Doris 官方针对日志负载给出的参考数据显示，采用列存与 ZSTD 后，包含索引的数据压缩比通常可以达到 5:1～10:1；历史冷数据还可以自动下沉至 S3/HDFS 等低成本存储。其官方与 Elasticsearch 的对比测试中，整体存储成本可降低 60%～80%，不过实际结果仍然取决于副本数、索引数量、日志结构和保留周期。

Doris 在日志场景中的价值因此不只是查询速度。

当同一套引擎既能承担日志全文检索，又能处理 SQL 聚合、复杂关联和业务数据分析时，企业有机会减少 Elasticsearch、日志数仓以及额外分析引擎之间的数据复制。对于 PB 级日志平台，存储成本和系统数量的下降，通常比某一条查询快几十毫秒更直接地影响长期 TCO。

## 五、AI 带来的变化，是数据库开始直接面对 Agent

AI 对分析数据库的影响，很容易被简单理解成“数据库增加一个向量索引”。

实际变化要更深一些。

过去 BI 用户提出一个问题，通常对应一条或者几条 SQL；Agent 执行一个业务任务时，则可能经历规划、数据查询、结果判断、再次查询、调用工具等多个步骤。一个自然语言问题背后，可能连续触发大量数据库请求。

例如用户提出：

> “为什么昨天华东地区的订单金额下降？”
> 
> 

Agent 可能需要先找到对应指标，再拆解地区和渠道，查询历史同期数据，关联营销活动，最后才能形成解释。

这种交互方式对数据库提出了两个方向的要求。

第一个方向，是 **Agent 使用数据库**。

Apache Doris 4\.0 已经原生加入向量索引，并将结构化 SQL、全文检索和向量检索放在同一个引擎中，同时提供 AI Functions，使 SQL 可以调用外部大模型完成分类、信息抽取、摘要等任务。Doris 的 AI 能力中还包括 MCP Server，用于让 Agent 直接访问数据库能力。

这种架构的价值在于减少数据系统之间的切换。例如 RAG 场景不一定需要先把业务数据同步到独立向量数据库，再维护两套数据的一致性；结构化过滤、关键词检索和向量相似度可以在同一份数据上组合执行。

第二个方向，则是 **分析 Agent 自己产生的数据**。

Agent 在执行过程中会持续产生 Prompt、Response、Tool Call、Trace、Token、模型延迟、RAG 检索结果以及评测数据。这些数据天然具有日志量大、JSON 结构动态、文本字段长、需要全文检索和聚合分析等特点。

Doris 已经把这类负载纳入 AI Observability 场景，通过实时写入、VARIANT、全文索引以及向量检索，对 Agent Trace 进行存储和分析。

商业化产品也开始沿着这个方向出现。

SelectDB 是 Apache Doris 原创团队创立的商业化公司，在开源 Doris 之外提供云服务和面向企业的产品体系。2026 年，SelectDB 发布了基于 Doris 构建的 Agent 可观测平台 Litefuse，将 Agent Trace 的采集、存储、检索、评估和数据集管理整合到同一平台，并提供对 Langfuse SDK、OpenAI、Anthropic、LangChain、Dify 等生态的兼容。

这里 Doris 与 SelectDB 的关系也比较清楚：Apache Doris 提供开源数据库内核和社区生态，SelectDB 则进一步围绕云服务、Agent 工具链和企业级交付构建商业产品。

这种分工对于企业用户的意义在于，既可以直接部署开源 Doris，也可以在不自行维护全部基础设施的情况下使用商业化产品。

## 六、企业级数据库最终比的是长期使用成本

当数据库真正进入生产核心链路，Benchmark 的权重反而会下降。

因为企业最终承担的成本远不只有 CPU 和磁盘。

数据模型是否容易维护、扩容是否需要重新规划集群、版本升级是否影响业务、实时和离线是否需要两套系统、日志是否还要额外维护 Elasticsearch、湖数据是否必须搬进数仓、出现故障后是否有成熟的诊断能力，这些都会进入数据库的长期账单。

ClickHouse 和 Doris 今天都已经远远超出了早期“高性能 OLAP 数据库”的能力范围。

ClickHouse 继续强化实时分析，并通过 ClickStack、全文检索以及 Agentic Data Stack 向可观测和 AI 扩展；Doris 则从实时数仓和复杂业务分析出发，逐渐把湖仓、全文检索、可观测、向量检索和 Agent 数据访问纳入同一个分析引擎。

因此，两者之间已经很难用一句“谁更快”概括。

如果业务主要是海量 append\-only 事件、日志和大规模明细扫描，ClickHouse 依然值得重点评估；如果系统同时存在复杂 Join、实时更新、高并发 BI、湖仓联合查询、日志分析以及 AI Agent 数据访问，那么数据库的综合能力和系统整合成本会变得更加重要。

企业真正需要回答的问题，也不再是：哪个数据库在某一个 Benchmark 上最快？

而是：未来三到五年，我们希望维护多少套数据系统，同一份数据需要复制多少次，以及这些系统能否支撑不断增加的新负载？

到了这个阶段，OLAP 的能力边界，实际上也是企业数据架构的边界。





一张几十亿甚至上百亿行的表，聚合查询需要多久？同样的机器规模下，谁能扫描更多数据？在日志分析、用户行为分析和大规模明细查询兴起的阶段，这些指标直接决定了一套分析系统是否可用。

Doris vs ClickHouse：企业级分析场景下，OLAP 的能力边界正在如何变化？

数据库

大数据

云计算

OLAP评估正从单纯查询性能转向系统综合能力，核心包括复杂关联查询优化、实时数据更新、湖仓一体存储、日志检索与AI集成。ClickHouse擅长海量事件数据和扫描负载，Doris则在多表关联、实时更新、统一存储及Agent场景下扩展能力边界，选型需基于长期数据架构与TCO综合考量。

关系型数据库

向量数据库

结构化数据

对象存储

数据分析

数据仓库

日志分析

PostgreSQL

Kafka

MySQL

JSON

OLAP

2026上云采购 | AI焕新·智启新局

bigdata-class

tchoused

tchousec

腾讯云BI特惠9.9元起！


tchousep

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Doris vs ClickHouse：企业级分析场景下，OLAP 的能力边界正在如何变化？-腾讯云开发者社区-腾讯云

Doris vs ClickHouse：企业级分析场景下，OLAP 的能力边界正在如何变化？

Doris vs ClickHouse：企业级分析场景下，OLAP 的能力边界正在如何变化？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐