三、架构分析

• 右侧是ClickHouse的部署架构图，ClickHouse本身只有一个模块，就是ClickHouse Server，周边有两个模块，如ClickHouseProxy主要是转发请求、配额限制和容灾等，ZooKeeper这块负责分布式DDL和副本间数据同步，ClickHouseCopier负责集群和数据迁移，ClickHouse一般需要Server、ZooKeeper和CHProxy三个组件。

2）多租户管理

ClickHouse的权限和Quota的粒度更细，可以很方便的支持多租户使用共享集群。比如可以设置查询内存、查询线程数量、查询超时等，以便来限制查询的大小；同时结合查询并发和一定时间窗口内的查询数量，以便来控制查询数量。多租户的方案，对发展中的业务非常友好，因为使用共享集群资源，可以快速动态调整配额，如果是独占集群资源利用率不高、扩容相对麻烦。

3）集群迁移

Doris通过内置的backup/restore命令将数据和元数据备份到三方对象存储或者HDFS上，backup可以通过快照的方式完整导出一致性的数据和元数据，并且可以按照分区来实现增量备份，降低备份的成本。在Doris中，有一种变通的迁移集群的方法，把新机器分批加入到已有的集群，然后再把旧机器逐步下线，集群能够自动均衡，这个过程视集群数据量可能会持续数天。

ClickHouse有几个方法实现数据迁移，数据量大通过自带的Clickhouse-copier工具进行集群间的数据拷贝，实现数据的跨集群迁移，需要手工配置很多信息，我们做了一些完善和改进；数据量小通过SQL命令remote关键字实现跨集群的数据迁移。而官方对实现其他存储介质的备份和恢复的推荐是采用文件系统的snapshot实现，或者可以通过三方工具（https://github.com/AlexAkulov/clickhouse-backup）来实现。

4）扩容/缩容

Doris支持集群的在线动态扩缩容，通过内置的SQL命令 alter system add/decomission backends 即可进行节点的扩缩容，数据均衡的粒度是tablet，每个tablet大概是数百兆，扩容后表的tablet会自动拷贝到新的BE节点，如果在线扩容，应该小批量去增加BE，避免过于剧烈导致集群不稳定。

ClickHouse的扩容缩容复杂且繁琐，目前做不到自动在线操作，需要自研工具支持。扩容时需要部署新的节点，添加新分片和副本到配置文件中，并在新节点上创建元数据，如果是扩副本数据会自动均衡，如果是扩分片，需要手工去做均衡，或自研相关工具，让均衡自动进行。

1）分布式协议和高可用

Doris在FrontEnd中包含元数据的管理能力，内置了BerkeleyDB JE HA组件，包含选举策略和副本数据同步，提供了FE的高可用方案。FE中管理的元数据也非常丰富，包含节点、集群、库、表和用户信息，以及分区、Tablet等数据信息，也包含事务、后台任务、DDL操作和导数相关任务等信息。

Doris的 FrontEnd可以部署3个Follwer + n个Oberserver（n>=0）的方式来实现元数据和访问连接的高可用，Follower参与选主，在有Follwer宕机时，会自动的选举出新节点保证读写高可用，Observer是只读的扩展节点，可以水平扩展实现读的扩展。BE通过多副本来实现高可用，一般来说也采取默认的三副本，写入的时候采用Quroum协议保证数据一致性。

Doris的元数据和数据多副本存储的，能自动复制具有自动灾备的能力，服务挂了可以自动重启，坏一块盘数据自动均衡，小范围的节点宕机不会影响集群对外的服务，但宕机后数据均衡过程会消耗集群资源，引发短时间的负载过高。架构如下图：

ClickHouse目前版本是基于ZooKeeper来存储元数据，包含分布式的DDL、表和数据Part信息，从元数据丰富程度来说稍弱，因为存储了大量细粒度的文件信息，导致ZooKeeper经常出现性能瓶颈，社区也有基于Raft协议的改进计划。ClickHouse依赖Zookeeper来实现数据的高可用，Zookeeper带来额外的运维复杂性的同时也有性能问题。

ClickHouse没有集中的元数据管理，每个节点分别管理，高可用一般依赖业务方来实现。ClickHouse中某个副本节点宕机，对查询和分布式表的导入没有影响，本地表导入要在导数程序中做灾备方案比如选择健康的副本，对DDL操作是有影响的，需要及时处理。

在分布式能力这块，Doris在内核侧已经实现，使用的代价更低；而ClickHouse需要依赖于外部配套的措施去保障，使用成本较高。

2）事务支持

ACID指事务的原子性、一致性、隔离性和持久化，OLAP的事务体现在几个方面，一是导数，需要保证导数的原子性，同时也要保证明细数据和物化视图的数据一致性；二是元数据的变更，需要保证所有节点的元数据统一变更的强一致性；三是在节点间做数据均衡时，需要保证数据的一致性。

Doris提供了导入的事务支持，可以保证导数的幂等性，比如数据导入的原子性，如果有其他错误会自动回滚，同时相同标签的数据不会重复导入。基于导入事务的功能，Doris还实现了Flink-connector这样的外部组件可以实现数据导入不丢不重。两者均不支持通用TP场景中的BEGIN/END/COMMIT语义的事务，很明显有事务支持的Doris比无事务支持的ClickHouse要节省很多开发成本，因为在ClickHouse中，这一切都需要外部导数程序来保证。

ClickHouse不支持事务，需要在外部去做各种校验和检查，在导数这块能保证100万以内的原子性，但是不保证一致性，比如要更新某些字段或者更新物化视图，这个操作是后台异步的，需要显示指定关键字FINAL来查询最终数据，而且其他操作没有事务支持。

DDL操作两者都是异步的，但是Doris能保证各个节点元数据的一致性，但ClickHouse中保证不了，会出现局部节点元数据和其他节点不一致的情况。

Doris中有RoutineLoad、BrokerLoad和StreamLoad等丰富内置的导数方式，这些功能非常好用，虽然无法处理复杂的ETL逻辑，但是支持简单过滤和转换函数，也能容忍少量的数据异常，同时支持ACID和导数幂等性。

ALTER TABLE [db.]table DELETE WHERE filter_expr;ALTER TABLE [db.]table UPDATE column1 = expr1 [, ...] WHERE filter_expr;

--Doris/DorisDB SQL 1select i_item_id, avg(cs_quantity) agg1, avg(cs_list_price) agg2, avg(cs_coupon_amt) agg3, avg(cs_sales_price) agg4from catalog_sales, customer_demographics, date_dim, item, promotionwhere cs_sold_date_sk = d_date_sk and     cs_item_sk = i_item_sk and    cs_bill_cdemo_sk = cd_demo_sk and    cs_promo_sk = p_promo_sk and    cd_gender = 'M' and     cd_marital_status = 'D' and    cd_education_status = 'Advanced Degree' and    (p_channel_email = 'N' or p_channel_event = 'N') and d_year = 1998 group by i_item_id order by i_item_id limit 10;

--ClickHouse SQL 1select i_item_id, avg(cs_quantity) agg1, avg(cs_list_price) agg2, avg(cs_coupon_amt) agg3, avg(cs_sales_price) agg4 from catalog_sales_distglobal inner join (select cd_demo_sk from customer_demographics_dist where cd_gender = 'M' and cd_marital_status = 'D' and cd_education_status = 'Advanced Degree' ) on cs_bill_cdemo_sk = cd_demo_skglobal inner join (select d_date_sk from date_dim_dist where d_year = 1998 ) on  cs_sold_date_sk = d_date_skglobal inner join ( select i_item_sk, i_item_id from item_dist ) on cs_item_sk = i_item_skglobal inner join ( select p_promo_sk from promotion_dist where p_channel_email = 'N' or p_channel_event = 'N') on cs_promo_sk = p_promo_skgroup by i_item_id order by i_item_id limit 10;