过去评估 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 的能力边界，实际上也是企业数据架构的边界。