Doris与ClickHouse的对比

前言

• 工作中olap引擎主要用的是 Doris和ClickHouse，一直想要做一个对比，这里梳理一下自己的理解。

对比	Doris	ClickHouse
架构	FE和BE分离的 MPP 架构	单机设计，依赖 ZooKeeper分布式协调
数据一致性	好	差
SQL 兼容性	好	差
数据模型	丰富	单一
并发能力	支持高并发	不支持高并发
查询场景	多表join	单表查询

详细解释

• Doris

  • 架构：采用典型的FE（Frontend）和BE（Backend）分离的 MPP 架构，这种设计简化了集群管理，例如新增节点只需通过 FE 自动完成数据均衡，无需人工干预。
    • FE负责元数据管理、查询规划等工作。
    • BE负责数据存储和执行引擎，支持自动均衡和故障恢复。
  • 数据一致性：好
    • 支持同步更新和删除操作，保证数据实时可见。通过主键模型（UniqueKey）实现行级实时一致性。例如用户标签更新后查询结果立即可见。
  • SQL 兼容性：高度兼容 MySQL 协议和标准 SQL，支持 EXISTS 谓词、相关子查询等复杂语法，降低学习成本。
  • 数据模型：支持多种数据模型，包括 Unique Key、Duplicate Key 和 Aggregate Key 模型。Unique Key 模型适用于需要保证数据唯一性的场景，如用户表中的用户 ID 字段；Duplicate Key 模型适合日志类数据存储，允许数据重复；Aggregate Key 模型则在聚合查询场景下表现出色，能快速对数据进行预聚合处理。
  • 并发：支持高并发，无并发瓶颈限制，100台集群可达10w QPS。
  • 查询性能：适合复杂join查询，拥有强大的查询优化器（CBO、RBO），支持向量化执行引擎。

• ClickHouse

  • 架构： 单机设计，依赖 ZooKeeper 协调分布式表和数据分片，组建集群需手动配置本地表、分布式表和副本策略，大规模集群运维复杂度高。
  • 数据一致性：差
    • 更新/删除为异步操作，当执行删除命令后，数据并不会立即从查询结果中消失，依赖后台 Merge 任务，可能导致短暂数据不一致，如删除用户后查询仍显示旧数据。
    • 这种设计优化了写入性能，但牺牲了数据一致性。
  • SQL 兼容性：使用自有 SQL 方言，部分功能（如窗口函数）需特定语法实现，对 MySQL 用户存在适配门槛。
  • 数据模型：相对单一，主要以 MergeTree 系列引擎为核心，数据模型相对单一。虽然 MergeTree 引擎在许多场景下表现良好，但在处理一些特殊业务需求时，灵活性不如 Doris。
  • 并发：不支持高并发，单条查询语句默认使用机器核数一半的CPU，因此不支持高并发的应用场景，官方建议QPS100。单条过大的查询或者过高的并发都会导致集群资源使用率过高，影响集群稳定性。
  • 查询性能：适合单表查询，列存储 + 向量化引擎使其在单表聚合、过滤场景性能卓越，尤其适合 PB 级日志分析。

• 参考了很多文章（1、2）