列式 DBMS 的新选择

Hadoop 是 13 年前开发的，提供大量的开源插件以及技术解决方案，再解决了使用者的问题，同时带来了高昂的维护成本，Hadoop逐渐失去了市场份额。当前对使用者来说要求低成本、简单且可扩展的数据库，因此列DBMS越来越多的关注。

ClickHouse简介

ClickHouse 是俄罗斯最大的搜索引擎 Yandex 所有者的开源数据库。与许多商业 MPP 数据库（例如 Vertica 或 InfiniDB）相比，它具有增强的性能。

ClickHouse 相对于传统大数据解决方案的竞争优势：

• 配置丰富，只依赖 Zookeeper。
• 它的集群可以通过添加服务器来线性扩展。
• 高容错性，不同分片之间的异步多主复制。
• 出色的单机性能，采用向量化计算，支持采样、近似计算等优化方法。
• 为许多不同的数据模型提供了强大的支持。

StarRocks 简介

StarRocks 是一个全场景MPP企业级数据库，在速度上具有极强的性能。StarRocks 具有水平在线可扩展性和金融级别的高可用性，兼容 MySQL 协议，提供了全面的向量化化引擎和多数据源的联合查询等重要特性。StarRock为用户提供全场景OLAP业务的综合解决方案，适用于对性能、时效性、并发性、灵活性要求较高的各种应用场景。

StarRocks 相对于传统大数据解决方案的竞争优势：

• 无依赖，可以通过查询联合来兼容大数据生态。
• 提供多种模型，支持不同维度的数据建模。
• 支持在线弹性伸缩，可自动负载均衡。
• 支持高并发分析查询。
• 支持实时数据分析。支持秒级数据导入。
• 兼容 MySQL 5.7 协议和 MySQL 生态。

StarRocks 和 ClickHouse：功能比较

StarRocks 和 ClickHouse 有很多共同点：都可以提供卓越的性能，都独立于 Hadoop 生态系统，都提供了高可用的主-主复制机制。

在功能、性能和应用场景上也存在差异。ClickHouse 更适合宽表的场景。如果 TP 的数据通过 CDC 工具，可以在 Flink 中将表格展平，并以宽表的形式写入 ClickHouse。StarRocks 在连接方面的能力更强，可以构建星型或雪花模式来处理维度数据的变化。

宽表还是星型模式？

ClickHouse：通过宽表来避免连接操作

与TP业务侧重点查询不同，在AP业务中，事实表和维度表的关联操作是不可避免的。ClickHouse 和 StarRocks 最大的区别在于对连接的处理。

虽然 ClickHouse 提供了 join 的语义，但它关联宽表的能力相对较弱。复杂的关联查询通常会导致内存不足。一般我们可以考虑在ETL过程中将事实表和维度表扁平化为一个宽表，避免复杂的查询。

目前很多商家都使用宽表来解决多因素分析的问题，由此可见宽表确实有自己独特的好处，比如：

• 在ETL过程中，宽表的字段处理得很好，分析人员可以在不关心底层逻辑的情况下进行工作。
• 宽表可以包含更多的业务数据并且更容易理解。
• 宽表便于单表查询，避免数据混杂，提供更好的服务。

同时，宽表也降低了它的灵活性：

• 宽表中的数据由于join过程中的一对多机制，可能会导致错误数据的冗余。
• 宽表结构维护难度大，结构变化时需要重新生成宽表。
• 宽表需要预先定义，可能无法适应临时更改。

StarRocks：通过 Star Schema 适应维度变化

公平地说，宽表是以牺牲灵活性为代价的，在灵活性要求较高的场景下，比如订单状态频繁变化，或者业务人员自助BI分析等，宽表往往无法满足需求。因此，我们还需要使用更灵活的模式，如星形或雪花。在支持星/雪花模式方面，StarRocks 比 ClickHouse 工作得更好。

StarRocks 中提供了三种不同类型的连接：

• 广播join用于将小表与大表关联起来，小表会通过广播加载到不同节点的内存中
• 当一个宽表关联另一个时，可以使用shuffle join，两个表中相同值的数据会被shuffle到同一台机器上
• 为了避免shuffle带来的网络和I/O开销，可以将需要关联的数据存储在同一个colocation group up创建中，使用colocation join

目前，MPP架构的大部分计算引擎都使用基于规则的优化器（RBO）。为更好地选择连接类型，StarRocks 提供了基于成本的优化器 (CBO)。用户在开发业务SQL时，不需要考虑驱动表和驱动表的先后顺序，也不需要考虑使用哪种类型。CBO 会根据收集到的指标自动查询更新，优化连接的顺序和类型。

高并发

ClickHouse 对高并发的支持

对于互联网、金融等行业来说，万人规模的员工很常见，高峰时段的并发量几千也不是什么新鲜事。随着互联网和场景化的趋势，业务变得以用户为中心，分析的重点也从原来的宏观分析转变为对用户维度的细粒度分析。在传统的 MPP 数据库中，所有节点都必须参与计算，因此集群的并发能力与节点的并发能力几乎相同。如果一定要增加并发量，可以考虑增加节点数，但同时，在 ClickHouse 中，我们在大多数情况下不推荐高并发业务查询。对于三副本集群，QPS通常控制在100以下。ClickHouse对高并发业务不友好。即使是一个查询也会占用一半的 CPU。只能考虑通过将结果集写入 MySQL 来提高查询的并发性。

StarRocks 对高并发的支持

与 ClickHouse 相比，StarRocks 可以支持数千用户同时进行分析和查询。在某些场景下，并发能力可以达到10000。在数据存储层，StarRocks 采用先分区后分桶的策略，让数据更加可见。前缀索引可以用来快速过滤和搜索数据，减少磁盘I/O操作，提高查询性能。

在建表时，partition和bucketing要尽量覆盖查询语句，这样才能充分发挥partition和bucketing的作用，尽可能减少扫描数据量。此外，StarRocks 还提供了 MOLAP 库的预聚合能力。对于一些复杂的分析查询，用户可以通过创建物化视图进行预聚合。通过预聚合的 RollUp 操作，可以将原来数十亿数据的基表转化为数百或数千行的表。查询延迟将大大减少。并发性也将得到显着提高。

数据更新

ClickHouse 中的数据更新

在 OLAP 数据库中，对数据更新通常不友好，ClickHouse 也是如此。早期版本不支持 UPDATE 和 DELETE。在 1.15 版本之后，Clickhouse 提供了 MUTATION 操作（通过 ALTER TABLE 语句）来更新和删除数据ClickHouse 提供了不同的业务引擎来进行数据变更。

对于线下业务，可以考虑增量和全量两种选择：

在增量同步方案中，应用了MergeTree引擎，上游数据先用Spark同步到Hive，Hive的增量数据会被Spark消费，写入ClickHouse。由于增量数据是同步的，对下游流的影响很小，用户需要保证维度数据基本不变。

全量同步方案中，使用MergeTree引擎通过Spark将上游数据同步到Hive，ClickHouse中的表被截断，Spark消费的最近几天Hive中的数据同步写入ClickHouse。因为是全数据导入，对下游会有不利影响，但因素变化的问题不需要考虑。

对于实时服务，可以使用两个引擎，
VersionedCollapsingMergeTree 和 ReplacingMergeTree：

使用
VersionCollapsingMergeTree 引擎，首先通过 Spark 将在线数据同步到 ClickHouse，然后使用 Kafka 消费增量数据并实时同步到 ClickHouse。但是因为引入了MQ，所以需要保证实时的数据连接，实时和离线数据连接点的存在并不能减少重叠。

使用ReplacingMergeTree引擎替换
VersionedCollapsingMergeTree引擎，库存数据通过Spark同步到ClickHouse，实时数据通过MQ同步到ReplaceMergeTree引擎，比
VersionedCollapsingMergeTree简单，离线和真实都没有异常- 时间数据连接点。但是使用这个方案并不能保证保存不重复的数据。

StarRocks 中的数据更新

与 ClickHouse 相比，StarRocks 对数据更新的操作更简单。

StarRocks 提供多种模型来适应更新操作、召回、聚合等业务需求。更新模型可以根据主键执行 UPDATE/DELETE 操作。通过存储和索引优化，可以在并发更新的同时进行高效查询。在一些电商场景下，订单状态需要频繁更新，每天更新的订单数量可能达到数亿。通过更新模型，可以很好地适应实时更新要求。

在 StarRocks 1.19 版本之前，您可以使用 更新模型通过主键进行更新。更新模型采用 Merge-on-Read 策略，即当数据存储到数据库时，每批导入的数据都会被分配一个编号和相同的主键。数据可能有多个版本号。查询时，StarRocks 会先合并并返回最新版本号的数据。

从 StarRocks 1.19 版本开始，发布了主键模型，可以通过主键进行更新和删除，支持实时/频繁更新需求。与 Unique 模型中的 Merge-on-Read 模式相比，在主键模型中使用 Delete-and-Insert 更新，性能将提升 3 倍左右。对于前端TP库通过CDC实时同步到StarRocks的场景，推荐使用主键模型。

集群维护

与单实例数据库相比，任何分布式数据库的维护成本都会成倍增加。一方面，随着节点数量的增加，失败的概率变得更高。对于这种情况，需要一个良好的自动故障转移机制。另一方面，随着数据量的增长，实现在线弹性伸缩是必须的，以保证集群的稳定性和可用性。

ClickHouse 中的节点扩展和重新分配

不同于一般的分布式数据库或Hadoop，HDFS可以根据集群节点的增减自动调整数据平衡。但是ClickHouse集群不能自动感知集群拓扑的变化，所以不能自动平衡数据。当集群数据较大时，增加集群节点可能会给数据负载均衡带来巨大的运维成本。

一般来说，增加集群节点提供了三种方案：

• 如果业务允许，用户可以为集群中的表设置TTL，保留时间长的数据会被逐步清理，新的数据会自动为新节点选择，最后负载均衡取得成就。
• 在集群中创建临时表，将原表中的数据复制到临时表中，然后删除原表。当数据量大，或表数过多时，维护成本高，无法应对实时数据变化。
• 通过配置权重将新写入的数据引导到新节点。重量维护成本相对较高。

对于上述所有的解决方案，从时间成本、硬件资源、实时性能等方面来看，ClickHouse 都不太适合在线节点扩展和数据部署。由于 ClickHouse 无法自动检测节点拓扑变化，我们可能需要在 CMDB 中编写一套数据重新分配逻辑。因此，我们需要尽早估计数据量和节点数。

StarRocks 中的在线弹性缩放

与 HDFS 一样，StarRocks 集群在感知到集群拓扑发生变化时，可以进行在线弹性伸缩，避免增加节点对业务的入侵。

StarRocks 中的数据通过分区和分桶存储。数据分桶后，根据bucket key进行hash计算，将结果相同的数据划分为同一个数据切片，我们称之为tablet。Tablet 是 StarRocks 中数据冗余的最小单位。通常，我们默认将数据存储为三份，节点通过仲裁协议进行复制。当一个节点宕机时，丢失的 tablet 将自动填充到其他可用节点上，以实现不易察觉的故障转移。

当新增节点时，FE 也会自动调度，将现有节点中的 tablet 调度到扩展节点，实现数据切片自动均衡。为了避免在tablet迁移过程中对业务性能的影响，您可以选择在非高峰期尽量扩容或缩容节点，或者调整调度参数来控制tablet的速度，尽量减少对业务的影响。

ClickHouse 和 StarRocks 的性能比较

导入性能测试

无论是 ClickHouse 还是 StarRocks，我们都使用 DataX 导入全量数据，增量部分可以通过 CDC 工具写入 MQ，然后由下游数据库消费。

数据集

对于测试，选择了ClickHouse 原生格式。一个xz格式的压缩文件大约85GB，解压后的原始文件为1.4T，31条数据。格式为 CSV。

导入方式

ClickHouse 中使用的 HDFS 的外观。ClickHouse 中的分布式表只能选择一个整数列作为 Sharding Key。观察数据，发现基数很低，所以使用了rand()分布形式。

HDFS的外部表定义如下

在 StarRocks 中，导入采用 Broker Load 模式，

结果

可以看到，使用 GitHub 数据集进行导入时，StarRocks 和 ClickHouse 导入的性能基本一致：

结论

ClickHouse 和 StarRocks 都是出色的 OLAP 数据库。两者有很多相似之处，都为分析查询提供了极致的性能，并且不依赖于 Hadoop 生态系统。从对比可以看出，在某些场景下，StarRocks 的性能要优于 ClickHouse。ClickHouse适用于尺寸变化较少的宽表场景。StarRocks 不仅在单表测试中有更好的表现，在多表关联方面也有更大的优势。