都2025年了，Doris 和 ClickHouse 到底怎么选啊！

❝

数据库选型是每个数据工程师都会面临的难题。 

在众多数据库中，Apache Doris和ClickHouse作为两款主流的分析型数据库，经常被拿来比较。它们各有千秋，适合不同的场景，让人难以抉择。 

我曾在某集团负责数据平台架构，当时面临一个选择：是用ClickHouse还是Doris
去替换Hadoop？ 

公司内部争论不休，支持ClickHouse的同学认为它性能卓越；而支持Doris的同学则强调其生态完善、易用性高。 

最终我们花了近两个月时间进行全面测试，才做出选择...

架构：复杂VS简洁

Doris采用典型的FE（Frontend）
和BE（Backend）
分离架构，这种设计使得集群管理变得异常简单。

FE负责元数据管理、查询规划等工作
，多个FE节点之间通过Paxos协议保证元数据一致性；BE负责数据存储和执行引擎
，支持自动均衡和故障恢复。

而ClickHouse则是单机设计，要组建集群需要额外配置分布式表，并依赖ZooKeeper
（或keeper服务）来协调节点。这种设计使得ClickHouse在小规模部署时非常灵活，但大规模集群管理会变得复杂。

假设，你在管理一个100节点的集群：

1️⃣ 使用Doris，你只需通过FE节点添加新的BE节点，系统会自动处理数据分布；

2️⃣ 使用ClickHouse，你需要面对本地表、分布式表、ZooKeeper配置等繁琐操作。

性能：极致VS全面

ClickHouse查询性能确实出色。在单表
查询场景下，特别是需要极致性能的场合，ClickHouse通常能够胜出。

Doris则凭借完善的MPP执行框架和向量化执行引擎，在复杂SQL分析
上表现优秀。

特别是对于多表Join，Doris支持大表间的shuffle join，能够处理ClickHouse难以完成的复杂分析查询。

另外，ClickHouse的更新和删除操作是异步
的，当执行删除命令后，数据并不会立即从查询结果中消失，需要等待后台Merge完成。这种设计优化了写入性能，但牺牲了数据一致性。

Doris则支持同步更新删除
，保证数据实时可见。在主键模型上，Doris的UniqueKey模型通过Merge-on-Write实现了真正的主键去重，性能比ClickHouse提升了10倍。

许多业务场景需要实时更新数据，如用户标签、实时看板等。如果使用ClickHouse，可能会遇到用户已删除但查询结果仍显示的问题，这对业务会产生严重影响。

生态与易用性

Doris在开箱即用方面做得更好。

它支持标准SQL语法，兼容MySQL协议，能与各类BI工具无缝集成
。同时，Doris提供了丰富的连接器，可以无缝对接Hive、Iceberg、Hudi、Paimon等数据源。

ClickHouse使用自己的SQL方言
，虽然功能强大，但学习成本较高。

它不支持某些标准SQL功能，如相关子查询、EXISTS谓词等。

许多公司已有大量的MySQL经验，选择Doris可以降低团队学习成本，并且Doris社区特别活跃
！

一位朋友负责的数据团队在使用Doris后，原本的MySQL DBA也能快速上手，大大提高了团队效率。

应用场景选择

如何选择这两款数据库？

总结了以下几点：

ClickHouse适合的场景：

Doris适合的场景：

另外，也可以结合去年快手的案例参考：快手：从 Clickhouse 到 Apache Doris，实现湖仓分离向湖仓一体架构升级

他们从ClickHouse迁移到Doris，最主要原因是解决湖仓分离架构带来的存储冗余、资源抢占、治理复杂
等问题。

Doris的湖仓一体
能力让他们在提升查询性能的同时，简化了数据治理。

结语

选择数据库没有绝对的对错
，关键在于找到最适合
自己业务场景的工具。

如果你的团队资源有限，追求易用性和全面性，Doris是更好的选择；如果你只追求极致的单表查询性能，且有专业团队维护，ClickHouse可能更适合。

数据库选型好比是在餐厅点菜，没有哪道菜适合所有人。两款数据库都在快速发展，未来的竞争会更加激烈。

下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！