ClickHouse vs StarRocks 选型对比

ClickHouse vs StarRocks 选型对比

面向列存的 DBMS 新的选择

Hadoop 从诞生已经十三年了，Hadoop 的供应商争先恐后的为 Hadoop 贡献各种开源插件，发明各种的解决方案技术栈，一方面确实帮助很多用户解决了问题，但另一方面因为繁杂的技术栈与高昂的维护成本，Hadoop 也渐渐地失去了原本属于他的市场。对于用户来说，一套高性能，简单化，可扩展的数据库产品能够帮助他们解决业务痛点问题。越来越多的人将目光锁定在列存的分布式数据库上。

ClickHouse 简介

ClickHouse 是由俄罗斯的第一大搜索引擎 Yandex 公司开源的列存数据库。令人惊喜的是，ClickHouse 相较于很多商业 MPP 数据库，比如 Vertica，InfiniDB 有着极大的性能提升。除了 Yandex 以外，越来越多的公司开始尝试使用 ClickHouse 等列存数据库。对于一般的分析业务，结构性较强且数据变更不频繁，可以考虑将需要进行关联的表打平成宽表，放入 ClickHouse 中。
相比传统的大数据解决方案，ClickHouse 有以下的优点：

• 配置丰富，只依赖与 Zookeeper
• 线性可扩展性，可以通过添加服务器扩展集群
• 容错性高，不同分片间采用异步多主复制
• 单表性能极佳，采用向量计算，支持采样和近似计算等优化手段
• 功能强大支持多种表引擎

StarRocks 简介

StarRocks 是一款极速全场景 MPP 企业级数据库产品，具备水平在线扩缩容，金融级高可用，兼容 MySQL 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。
相比于传统的大数据解决方案，StarRocks 有以下优点：

• 不依赖于大数据生态，同时外表的联邦查询可以兼容大数据生态
• 提供多种不同的模型，支持不同维度的数据建模
• 支持在线弹性扩缩容，可以自动负载均衡
• 支持高并发分析查询
• 实时性好，支持数据秒级写入
• 兼容 MySQL 5.7 协议和 MySQL 生态

StarRocks 与 ClickHouse 的功能对比

StarRocks 与 ClickHouse 有很多相似之处，比如说两者都可以提供极致的性能，也都不依赖于 Hadoop 生态，底层存储分片都提供了主主的复制高可用机制。但功能、性能与使用场景上也有差异。ClickHouse 在更适用与大宽表的场景，TP 的数据通过 CDC 工具的，可以考虑在 Flink 中将需要关联的表打平，以大宽表的形式写入 ClickHouse。StarRocks 对于 join 的能力更强，可以建立星型或者雪花模型应对维度数据的变更。

大宽表 vs 星型模型

ClickHouse：通过拼宽表避免 join 操作

不同于以点查为主的 TP 业务，在 AP 业务中，事实表和维度表的关联操作不可避免。ClickHouse 与 StarRocks 最大的区别就在于对于 join 的处理上。ClickHouse 虽然提供了 join 的语义，但使用上对大表关联的能力支撑较弱，复杂的关联查询经常会引起 OOM。一般我们可以考虑在 ETL 的过程中就将事实表与维度表打平成宽表，避免在 ClickHouse 中进行复杂的查询。
目前有很多业务使用宽表来解决多远分析的问题，说明了宽表确有其独到之处：

• 在 ETL 的过程中处理好宽表的字段，分析师无需关心底层的逻辑就可以实现数据的分析
• 宽表能够包含更多的业务数据，看起来更直观一些
• 宽表相当于单表查询，避免了多表之间的数据关联，性能更好
  但同时，宽表在灵活性上也带来了一些困扰：
• 宽表中的数据可能会因为 join 的过程中存在一对多的情况造成错误数据冗余
• 宽表的结构维护麻烦，遇到维度数据变更的情况需要重跑宽表
• 宽表需要根据业务预先定义，宽表可能无法满足临时新增的查询业务

StarRocks：通过星型模型适应维度变更

可以说，拼宽表的形式是以牺牲灵活性为代价，将 join 的操作前置，来加速业务的查询。但在一些灵活度要求较高的场景，比如订单的状态需要频繁改变，或者说业务人员的自助 BI 分析，宽表往往无法满足我们的需求。此时我们还需要使用更为灵活的星型或者雪花模型进行建模。对于星型/雪花模型的兼容度上，StarRocks 的支撑要比 ClickHouse 好很多。

在 StarRocks 中提供了三种不同类型的 join：

• 当小表与大表关联时，可以使用 boardcast join，小表会以广播的形式加载到不同节点的内存中
• 当大表与大表关联式，可以使用 shuffle join，两张表值相同的数据会 shuffle 到相同的机器上
• 为了避免 shuffle 带来的网络与 I/O 的开销，也可以在创建表示就将需要关联的数据存储在同一个 colocation group 中，使用 colocation join

CREATE TABLE tbl (k1 int, v1 int sum)
DISTRIBUTED BY HASH(k1)
BUCKETS 8
PROPERTIES(
    "colocate_with" = "group1"
);

目前大部分的 MPP 架构计算引擎，都采用基于规则的优化器（RBO）。为了更好的选择 join 的类型，StarRocks 提供了基于代价的优化器（CBO）。用户在开发业务 SQL 的时候，不需要考虑驱动表与被驱动表的顺序，也不需要考虑应该使用哪一种 join 的类型，CBO 会基于采集到的表的 metric，自动的进行查询重写，优化 join 的顺序与类型。

高并发支撑

ClickHouse 对高并发的支撑

为了更深维度的挖掘数据的价值，就需要引入更多的分析师从不同的维度进行数据勘察。更多的使用者同时也带来了更高的 QPS 要求。对于互联网，金融等行业，几万员工，几十万员工很常见，高峰时期并发量在几千也并不少见。随着互联网化和场景化的趋势，业务逐渐向以用户为中心转型，分析的重点也从原有的宏观分析变成了用户维度的细粒度分析。传统的 MPP 数据库由于所有的节点都要参与运算，所以一个集群的并发能力与一个节点的并发能力相差无几。如果一定要提高并发量，可以考虑增加副本数的方式，但同时也增加了 RPC 的交互，对性能和物理成本的影响巨大。
在 ClickHouse 中，我们一般不建议做高并发的业务查询，对于三副本的集群，通常会将 QPS 控制在 100 以下。ClickHouse 对高并发的业务并不友好，即使一个查询，也会用服务器一半的 CPU 去查询。一般来说，没有什么有效的手段可以直接提高 ClickHouse 的并发量，只能考虑通过将结果集写入 MySQL 中增加查询的并发度。

StarRocks 对高并发的支撑

相较于 ClickHouse，StarRocks 可以支撑数千用户同时进行分析查询，在部分场景下，高并发能力能够达到万级。StarRocks 在数据存储层，采用先分区再分桶的策略，增加了数据的指向性，利用前缀索引可以快读对数据进行过滤和查找，减少磁盘的 I/O 操作，提升查询性能。

在建表的时候，分区分桶应该尽可能的覆盖到所带的查询语句，这样可以有效的利用分区分桶剪裁的功能，尽可能的减少数据的扫描量。此外，StarRocks 也提供了 MOLAP 库的预聚合能力。对于一些复杂的分析类查询，可以通过创建物化视图进行预先聚合，原有几十亿的基表，可以通过预聚合 RollUp 操作变成几百或者几千行的表，查询时延迟会有显著下降，并发也会有显著提升。

数据的高频变更

ClickHouse 中的数据更新

在 OLAP 数据库中，可变数据（Mutable data）通常是不受欢迎的。ClickHouse 也是如此。早期的版本中并不支持 UPDATE 和 DELETE 操作。在 1.15 版本后，Clickhouse 提供了 MUTATION 操作（通过 ALTER TABLE 语句）来实现数据的更新、删除，但这是一种“较重”的操作，它与标准 SQL 语法中的 UPDATE、DELETE 不同，是异步执行的，对于批量数据不频繁的更新或删除比较有用。除了 MUTATION 操作，Clickhouse 还可以通过 CollapsingMergeTree、VersionedCollapsingMergeTree、ReplacingMergeTree 结合具体业务数据结构来实现数据的更新、删除，这三种方式都通过 INSERT 语句插入最新的数据，新数据会“抵消”或“替换”掉老数据，但是“抵消”或“替换”都是发生在数据文件后台 Merge 时，也就是说，在 Merge 之前，新数据和老数据会同时存在。
针对与不同的业务场景，ClickHouse 提供了不同的业务引擎来进行数据变更。
对于离线业务，可以考虑增量和全量两种方案：
增量同步方案中，使用 ReplacingMergeTree 引擎，先用 Spark 将上游数据同步到 Hive，再由 Spark 消费 Hive 中的增量数据写入到 ClickHouse 中。由于只同步增量数据，对下游的压力较小。需要确保维度数据基本不变。
全量同步方案中，使用 MergeTree 引擎，通过 Spark 将上游数据定时同步到 Hive 中，truncate ClickHouse 中的表，随后使用 Spark 消费 Hive 近几天的数据一起写入到 ClickHouse 中。由于是全量数据导入，对下游压力较大，但无需考虑维度变化的问题。
对于实时业务，可以采用 VersionedCollapsingMergeTree 和 ReplacingMergeTree 两种引擎：
使用 VersionedCollapsingMergeTree 引擎，先通过 Spark 将上游数据一次性同步到 ClickHouse 中，在通过 Kafka 消费增量数据，实时同步到 ClickHouse 中。但因为引入了 MQ，需要保证 exectly once 语义，实时和离线数据连接点存在无法折叠现象。
使用 ReplacingMergeTree 引擎替换 VersionedCollapsingMergeTree 引擎，先通过 Spark 将上游存量数据一次性同步到 ClickHouse 中，在通过 MQ 将实时数据同步到 ReplacingMergeTree 引擎中，相比 VersionedCollapsingMergeTree 要更简单，且离线和实时数据连接点不存在异常。但此种方案无法保重没有重复数据。