Doris vs ClickHouse：深入对比MPP数据库聚合操作的核心区别

布拉德·甘·拉敎

于 2025-04-25 10:12:37 发布

阅读量1k

点赞数 31

文章标签：数据库 clickhouse Doris MPP 大规模并行处理

本文链接：https://blog.csdn.net/weixin_44313745/article/details/147499994

版权

Doris vs ClickHouse：深入对比 MPP 数据库聚合操作的核心区别

在大数据实时分析领域，Doris 和 ClickHouse 作为主流的 MPP 数据库，其聚合模型的设计理念直接影响着开发效率与查询性能。今天，我就来跟大家深入剖析二者的核心差异，让大家在实战中能够有的放矢地选型，避免踩坑。

一、核心差异对比

1.1 数据模型设计差异

Doris Aggregate 模型

核心机制 ：通过 AGGREGATE KEY 定义聚合维度，写入时自动合并相同 Key 的数据。这意味着 Doris 在数据写入的那一刻，就已经帮你把聚合工作做好了，省去了后期查询时的大量计算开销。
聚合方式 ：预置 SUM/MAX/MIN/REPLACE 等函数，存储层直接保存聚合结果。例如，你要统计用户的总消费金额，Doris 会在数据存储时就把同一用户的所有消费金额加总起来，后续查询直接拿结果就好，效率极高。

ClickHouse AggregatingMergeTree

核心机制 ：依赖 MergeTree 引擎的异步合并，需显式定义物化视图或 AggregateFunction 字段。ClickHouse 不会像 Doris 那样在写入时就把数据聚合好，而是先存储原始数据，等后台异步合并的时候才进行聚合操作。
聚合方式 ：使用 - State/-Merge 函数组合实现多级聚合，需手动触发合并或查询时指定 FINAL。这就要求使用者对聚合函数有更深入的理解，并且在查询的时候要记得指定 FINAL 才能拿到最终的聚合结果，否则可能会得到中间状态的数据，增加了使用的复杂度。

1.2 聚合时机与一致性

维度	Doris	ClickHouse
聚合触发时机	写入时立即聚合	异步合并时聚合
数据一致性	强一致（查询即最新）	最终一致（可能存在中间状态）
一致性保证方案	内置事务机制	需 SELECT … FINAL 或手动合并

Doris 的强一致性是它的一大亮点。当你写入数据后，马上查询就能得到最新的、聚合好的结果，这在实时性要求高的场景下，比如实时大屏展示、交易报表统计等，非常关键。而 ClickHouse 由于是异步合并，查询时如果没有指定 FINAL，可能会得到不是最新的聚合数据，数据一致性相对较弱。

1.3 使用复杂度对比

Doris

建表时声明 AGGREGATE KEY，查询语法与标准 SQL 一致。比如 SELECT user_id, SUM(cost) FROM tbl GROUP BY user_id; 这种简洁直观的语法，对于熟悉 SQL 的开发者来说，上手难度低，开发效率高。

ClickHouse

需手动创建物化视图，配合 AggregateFunction 类型字段。查询时还需调用 sumMerge 等函数，如 SELECT user_id, sumMerge(score) FROM mv GROUP BY user_id; 这一系列操作下来，比 Doris 要复杂不少，对开发人员的技术要求也更高。

1.4 分布式处理能力

Doris

原生支持自动分片和负载均衡。FE 节点统一调度查询，BE 节点并行计算。Doris 在分布式处理方面，基本做到了 “开箱即用”，你不需要过多地去关心分片、负载均衡这些底层细节，它自己就能把数据均匀地分片存储，并且在查询时高效地并行计算。

ClickHouse

依赖分片键手动分片，跨节点查询需通过分布式表协调。本地聚合优先，分布式聚合性能依赖网络带宽。在 ClickHouse 中，分片策略需要你根据业务场景自己来定，并且在做分布式查询的时候，性能很大程度上受到网络带宽的影响，网络不稳定或者带宽不足的话，分布式聚合的性能就会大打折扣。

1.5 适用场景总结

场景	Doris Aggregate	ClickHouse AggregatingMergeTree
实时聚合需求	✅ 写入即聚合，适合高频写入 + 实时查询	❌ 依赖合并周期，延迟较高
复杂聚合逻辑	✅ 内置多种聚合函数，SQL 简单	✅ 支持更灵活的自定义聚合，但需复杂配置
运维复杂度	✅ 自动分片、负载均衡，运维简单	❌ 需手动管理分片和副本
数据一致性要求	✅ 强一致	❌ 最终一致，需额外处理

Doris 更适合那些对实时性要求极高，需要快速写入数据并且马上能查询到聚合结果的场景，比如实时监控、实时数据看板等；而 ClickHouse 则在能够接受一定延迟、对聚合逻辑有复杂自定义需求、数据量特别大的离线分析场景中，比如海量日志分析、用户行为的深度挖掘等方面，有其优势。

二、建表示例解析

2.1 Doris 聚合表

CREATE TABLE example_tbl_agg1 (
  `user_id` LARGEINT NOT NULL,
  `date` DATE NOT NULL,
  `city` VARCHAR(20),
  `age` SMALLINT,
  `sex` TINYINT,
  `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00",
  `cost` BIGINT SUM DEFAULT "0",
  `max_dwell_time` INT MAX DEFAULT "0",
  `min_dwell_time` INT MIN DEFAULT "99999"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 10;

特点：

维度列（Key）唯一性约束，指标列（Value）自动聚合。这保证了数据在聚合维度上的唯一性，并且指标列会按照指定的聚合函数自动计算，无需人工干预。
数据写入后立即可查最新结果，完全满足实时性需求。

2.2 ClickHouse 物化视图方案

-- 原始表
CREATE TABLE user_city_record (
  `id` UUID,
  user_id String,
  city_id String,
  score Float64,
  created_time DateTime
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(created_time)
ORDER BY (user_id, city_id);

-- 物化视图（聚合逻辑）
CREATE MATERIALIZED VIEW user_city_count
ENGINE = AggregatingMergeTree()
ORDER BY (user_id, city_id)
POPULATE
AS 
SELECT 
  user_id,
  city_id,
  sumState(score) AS score
FROM user_city_record
GROUP BY user_id, city_id;

-- 查询视图
CREATE VIEW user_city_view AS 
SELECT 
  user_id AS id,
  city_id,
  sumMerge(score) AS score
FROM user_city_count
GROUP BY id, city_id;