列式 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 操作，可以将原来数十亿数据的基表转化为数百或数千行的表。查询延迟将大大减少。并发性也将得到显着提高。