过去几年，ClickHouse 凭借优秀的列式存储、数据压缩和执行效率，在日志分析、明细查询等场景中快速普及，成为实时分析领域的重要技术选择。
与此同时，企业的数据分析需求也在发生变化。随着数据规模持续增长，分析场景已经从简单聚合和单表查询，逐渐扩展到实时数仓、复杂 SQL、湖仓分析、日志可观测以及 AI 应用。OLAP 数据库承担的职责，也从单纯的查询引擎向企业数据分析基础设施延伸。
在这一背景下，Apache Doris 与 ClickHouse 经常被放在一起比较。
两者都面向大规模分析场景，但长期形成的技术侧重点并不完全相同。ClickHouse 在大规模数据扫描、明细分析等场景中有深厚积累；Doris 则围绕实时数仓、复杂 SQL、高并发分析、湖仓融合等企业级负载持续扩展，同时近两年在日志存储、全文检索和可观测分析上的投入也明显增加。
因此，两者之间的比较，不能只看一组 Benchmark，更需要结合企业的数据类型、查询模式以及未来的架构演进来判断。
一、OLAP 的核心问题正在发生变化
早期企业建设 OLAP 系统时，需求通常比较集中：存储大量明细数据，并快速完成聚合、日志查询和行为分析。
在这类场景中，高效扫描海量数据是数据库最重要的能力之一。ClickHouse 通过列式存储、数据压缩、向量化执行等技术，在大规模明细分析和聚合查询中建立了较强优势。
但企业的数据分析体系发展到一定阶段后，业务很难再围绕单一数据源或一张大表展开。
一个典型的经营分析场景，可能同时涉及用户行为、订单、商品、营销活动和外部业务数据，并在此基础上进行用户画像、指标拆解、多维经营分析和实时决策。
此时，数据库需要解决的问题已经扩展为：
- 多张业务表如何高效关联；
- 实时数据如何及时更新并参与分析；
- 复杂 SQL 如何稳定运行；
- BI 场景下如何支撑大量并发查询；
- 湖上历史数据与实时数据如何统一访问；
- 日志、指标与业务数据能否在同一平台分析；
- 数据如何进一步服务 AI 应用。
企业衡量 OLAP 数据库时，也开始从单次查询速度转向整体分析效率。
二、Doris 与 ClickHouse 的差异，更多体现在系统设计取向
ClickHouse 和 Doris 存在大量重叠场景，但各自长期投入的方向有所区别。
ClickHouse 对分析型负载进行了深入优化，在大规模数据扫描、日志明细查询和聚合计算中具有很强的竞争力。对于查询模型相对清晰、以大表扫描为主的分析任务，它仍然是成熟且高效的选择。
Doris 的技术路线则更偏向综合型企业分析负载。除基础扫描性能之外，其重点能力还包括复杂 Join、查询优化、实时数据更新、高并发分析、多源数据访问以及统一 SQL 分析。
当业务查询中大量出现多表 Join、子查询、多层聚合和复杂过滤条件时，最终性能已经不能简单由扫描速度决定。
例如，一个经营分析任务可能需要关联用户属性、商品信息和订单数据，再按照地区、渠道和时间进行多层聚合。此时，优化器能否选择合理的 Join 顺序、中间数据能否尽早裁剪、执行计划是否稳定，以及计算资源如何调度，都会直接影响查询效率。
Doris 围绕这类场景持续完善 MPP 执行框架、查询优化器、Runtime Filter 和向量化执行等能力。
因此，在选型阶段，与其简单讨论谁"跑得更快"，不如先看清楚业务负载：核心需求究竟是极致的大规模扫描，还是已经进入实时更新、复杂关联和综合分析阶段。
三、日志与可观测，正在成为 Doris 的另一个重要场景
过去谈到日志分析，ClickHouse 和 Elasticsearch 往往是最先被想到的技术方案。
但日志平台本身也在变化。
今天的可观测平台除了日志检索，还需要承载 Trace、Metrics、异常定位、趋势分析、安全审计以及业务数据关联。数据规模大、持续写入时间长，同时大量历史日志的价值密度并不高，因此成本和查询效率需要同时考虑。
Doris 近几年针对这类负载增加了大量专门优化，包括倒排索引、全文检索、JSON 与 VARIANT 数据处理、冷热分层以及面向时序写入的 Compaction 等能力。Apache Doris 已经将 Log、Trace、Metrics 统一分析作为独立的可观测解决方案方向。
这使 Doris 在日志场景中的优势不再只是"可以用 SQL 查日志"，而是同时覆盖几个关键问题。
首先是存储成本。
日志数据量通常远高于核心业务数据，而且需要长期留存。Doris 采用列式存储和 ZSTD 压缩，并支持将冷数据下沉至 S3、HDFS 等低成本存储。Apache Doris 官方文档给出的参考数据中，包含索引后的数据压缩比可以达到 5:1～10:1；与 Elasticsearch 相比，整体存储成本可降低 60%～80%，冷数据进一步下沉后还可以继续降低成本。具体收益会受到日志结构、索引数量、保留周期和部署方式影响。
其次是使用成本。
传统日志平台通常有独立的检索语法、索引体系和运维方式，而 Doris 使用标准 SQL 和 MySQL 协议，可以直接对接 Kafka、Fluent Bit、Logstash、Grafana、Superset 等上下游工具。
对于已经拥有 SQL 数据分析体系的团队来说，日志不必再成为一套完全割裂的技术栈。工程师可以进行关键词检索，数据团队也可以直接完成聚合、Join、子查询甚至日志与业务表的关联分析。
性能同样是日志系统无法回避的问题。
根据 Apache Doris 官方披露的 Benchmark 和生产实践数据，Doris 可以支撑百 TB/天、GB/s 级持续日志写入，并针对倒排索引、全文检索和 TopN 查询进行了专门优化；典型关键词检索和趋势分析能够做到秒级响应。
这也让 Doris 在可观测场景中的定位变得比较清晰：它并不是单纯以牺牲性能换取低成本，而是试图在写入、检索、聚合分析和存储成本之间取得平衡。
对于数据规模达到 PB 级、日志保留周期较长的企业来说，这种综合成本优势尤其重要。
四、湖仓融合正在成为企业分析架构的重要能力
除查询模式变化之外，企业的数据存储方式也在变化。
传统数据仓库通常依赖 ETL，将业务系统中的数据加工后统一导入分析系统。但随着数据来源和规模扩大，企业数据可能同时分布在业务数据库、日志平台、消息系统以及数据湖中。
如果所有数据都必须经过复制和搬迁后才能分析，不仅增加链路复杂度，也会带来额外的存储成本和数据延迟。
因此，越来越多企业希望分析引擎能够直接访问不同位置的数据，在减少数据移动的同时建立统一查询入口。
Doris 目前可以通过 Catalog 等机制访问 Hive、Iceberg、Hudi、Paimon 等湖上数据。其价值不仅在于增加外部数据源支持，更重要的是让实时数据、仓内数据和历史湖数据能够在同一套 SQL 体系下参与计算。
对于企业数据架构而言，真正需要解决的并不是"把所有数据搬到一个数据库"，而是不同存储层的数据能否被统一、高效地分析。
五、企业迁移 OLAP 系统，往往不是因为单一性能问题
从一些公开实践来看，企业更换或整合 OLAP 系统，通常不是某一个性能指标突然无法满足，而是随着数据量、业务数量以及集群数量增加，原有架构的综合成本不断上升。
快手：超大规模环境下的基础设施治理
当 OLAP 系统发展到百 PB 数据、200 多个集群后，企业面对的已经不仅是 SQL 性能。
大量集群、数据表和业务任务会进一步带来运维、版本管理、配置管理和迁移效率等工程问题。
快手基于 Apache Doris 建设自动化迁移平台"星移"，将 DDL 转换、任务复制、存量数据迁移等流程平台化，用于支撑百 PB 级数据、200 多个集群以及数千张表的迁移和管理。
到了这一规模，数据库的工程化能力、集群治理能力和运维效率，与执行引擎本身同样重要。
网易云音乐：从日志检索走向实时分析
网易云音乐的实践则代表另一类变化。
日志平台已经不再只是保存日志和故障检索，还需要支撑系统状态分析、业务运行监控、异常定位以及实时数据洞察。
据公开案例，网易云音乐使用 Apache Doris 替换原有 ClickHouse 方案后，系统稳定运行多个季度，规模达到约 50 台服务器、2PB 数据，每日新增日志超过万亿条，峰值写入吞吐达到 6GB/s。
这一实践也说明，在超大规模日志系统中，企业衡量的不只是峰值查询性能，还包括长期存储成本、持续写入能力、系统稳定性以及后续分析能力。
浩瀚深度：超大规模数据下的综合能力
浩瀚深度的 Doris 集群最大规模达到 117 个节点，单表原始数据超过 13PB，数据行数超过 534 万亿，日均导入数据约 145TB。
到了这一量级，单项 Benchmark 很难完整反映数据库的实际价值。数据导入、容量扩展、查询稳定性、集群管理以及长期运行能力，都需要纳入系统评估。
这些案例所体现的共同趋势是：当 OLAP 成为企业核心数据基础设施后，企业关心的是整套系统长期运行的综合效率，而不只是一个 SQL 能快多少毫秒。
六、AI 正在进一步扩大 OLAP 的能力边界
生成式 AI 和 Agent 的发展，也开始改变分析数据库的使用方式。
过去，数据库主要面向开发人员、数据工程师和 BI 工具提供 SQL 查询能力。未来，越来越多的数据访问可能由 AI Agent 发起。
例如，当业务人员提出"为什么本周某地区销售额下降"时，一个完整的分析过程可能需要完成指标识别、实时数据查询、历史趋势对比、多表关联以及异常原因分析。
数据库在这一过程中不再只是保存数据，而会成为 AI 系统访问企业实时信息的重要基础设施。
这对分析数据库提出了新的要求，包括：
- 低延迟访问实时数据；
- 对结构化数据进行复杂分析；
- 支持全文和向量检索；
- 关联业务数据与可观测数据；
- 为 Agent 提供稳定的数据访问接口。
Doris 近年来也在 AI 数据分析、Agent Facing Analytics、多模态检索以及 AI 可观测等方向持续投入。
从数据库视角看，AI 并没有改变数据基础设施最核心的问题：数据能否被低成本保存，并在需要的时候快速、准确地取出来。变化在于，过去主要是人和 BI 工具查询数据库，未来 Agent 也会成为重要的数据库使用者。
七、如何理解 Doris 与 ClickHouse 的选择
ClickHouse 与 Doris 都已经在大规模分析场景中经过长期实践，两者不存在一个适用于所有业务的固定答案。
如果业务长期以海量明细扫描、日志分析和聚合查询为主，ClickHouse 依然是成熟且有竞争力的技术方案。
如果分析系统需要同时承担实时数仓、复杂 SQL、多表关联、高并发 BI、实时更新、湖仓查询，以及日志与可观测分析等职责，那么评估重点需要进一步扩大到优化器、数据模型、并发能力、数据更新机制、存储成本和整体架构复杂度。
另一个值得关注的因素是商业化生态。
Apache Doris 本身是 Apache 软件基金会旗下的开源项目；SelectDB（飞轮科技）则由 Apache Doris 原创及核心团队成员创立，是基于 Apache Doris 进行产品和商业化服务的公司，并在开源 Doris 之外提供 SelectDB Cloud 等云上产品。
这种关系给企业提供了两条路径：有能力维护基础设施的团队可以直接采用开源 Apache Doris；希望降低部署、运维和升级成本的团队，也可以选择基于 Doris 的商业化产品和服务。
这也是今天讨论数据库选型时容易被忽略的一点------技术内核固然重要，但当系统进入核心生产环境后，部署方式、运维成本、服务体系以及后续升级路径都会进入决策范围。
随着企业数据平台继续演进，OLAP 数据库的竞争维度已经从"单次查询能跑多快"，扩展到实时分析、复杂查询、湖仓、可观测、成本控制以及 AI 数据服务。
从这个角度看，Doris 与 ClickHouse 的比较更适合回到具体业务负载：企业今天需要解决什么问题，以及未来两三年希望把分析平台演进到什么位置。