主页 > 科技 >

ClickHouse vs StarRocks选型对比

2021-12-05 10:28 来源:中国资讯报道网
  面向列存的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:通过拼宽表避免聚合操作
  不同于以点查为主的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
  目前大部分的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要更简单,且离线和实时数据连接点不存在异常。但此种方案无法保重没有重复数据。
  StarRocks中的数据更新
  相较于ClickHouse,StarRocks对于数据更新的操作更加简单。
  StarRocks中提供了多种模型适配了更新操作,明细召回操作,聚合操作等业务需求。更新模型可以按照主键进行UPDATE/DELETE操作,通过存储和索引的优化可以在并发更新的同时高效的查询。在某些电商场景中,订单的状态需要频繁的更新,每天更新的订单量可能上亿。通过更新模型,可以很好的适配实时更新的需求。
  StarRocks 1.19版本之前,可以使用Unique模型进行按主键的更新操作,Unique模型使用的是Merge-on-Read策略,即在数据入库的时候会给每一个批次导入数据分配一个版本号,同一主键的数据可能有多个版本号,在查询的时候StarRocks会先做merge操作,返回一个版本号最新的数据。
  自StarRocks 1.19版本之后发布了主键模型,能够通过主键进行更新和删除的操作,更友好的支持实时/频繁更新的需求。相较于Unique模型中Merge-on-Read的模式,主键模型中使用的是Delete-and-Insert的更新策略,性能会有三倍左右的提升。对于前端的TP库通过CDC实时同步到StarRocks的场景,建议使用主键模型。
  集群的维护
  相比于单实例的数据库,任何一款分布式数据库维护的成本都要成倍的增长。一方面是节点增多,发生故障的几率变高。对于这种情况,我们需要一套良好的自动failover机制。另一方便随着数据量的增长,要能做到在线弹性扩缩容,保证集群的稳定性与可用性。
  ClickHouse中的节点扩容与重分布
  与一般的分布式数据库或者Hadoop生态不同,HDFS可以根据集群节点的增减自动的通过balance来调节数据均衡。但是ClickHouse集群不能自动感知集群拓扑的变化,所以就不能自动balance数据。当集群数据较大时,新增集群节点可能会给数据负载均衡带来极大的运维成本。
  一般来说,新增集群节点我们通常有三种方案:
  ·如果业务允许,可以给集群中的表设置TTL,长时间保留的数据会逐渐被清理到,新增的数据会自动选择新节点,最后会达到负载均衡。
  ·在集群中建立临时表,将原表中的数据复制到临时表,再删除原表。当数据量较大时,或者表的数量过多时,维护成本较高。同时无法应对实时数据变更。
  ·通过配置权重的方式,将新写入的数据引导到新的节点。权重维护成本较高。
  无论上述的哪一种方案,从时间成本,硬件资源,实时性等方面考虑,ClickHouse都不是非常适合在线做节点扩缩容及数据充分布。同时,由于ClickHouse中无法做到自动探测节点拓扑变化,我们可能需要再CMDB中写入一套数据重分布的逻辑。所以我们需要尽可能的提前预估好数据量及节点的数量。
  StarRocks中的在线弹性扩缩容
  与HDFS一样,当StarRocks集群感知到集群拓扑发生变化的时候,可以做到在线的弹性扩缩容。避免了增加节点对业务的侵入。
  StarRocks中的数据采用先分区再分桶的机制进行存储。数据分桶后,会根据分桶键做hash运算,结果一致的数据被划分到同一数据分片中,我们称之为tablet。Tablet是StarRocks中数据冗余的最小单位,通常我们会默认数据以三副本的形式存储,节点中通过Quorum协议进行复制。当某个节点发生宕机时,在其他可用的节点上会自动补齐丢失的tablet,做到无感知的failover。
  在新增节点时,也会有FE自动的进行调度,将已有节点中的tablet自动的调度到扩容的节点上,做到自动的数据片均衡。为了避免tablet迁移时对业务的性能影响,可以尽量选择在业务低峰期进行节点的扩缩容,或者可以动态调整调度参数,通过参数控制tablet调度的速度,尽可能的减少对业务的影响。
  ClickHouse与StarRocks的性能对比
  单表SSB性能测试
  由于ClickHouse join能力有限,无法完成TPCH的测试,这里使用SSB 100G的单表进行测试。
  测试环境
  测试数据
  测试结果
  从测试结果中可以看出来,14个测试中,有9个SQL,StarRocks在性能上要超过ClickHouse。
  多表TPCH性能测试
  ClickHouse不擅长多表关联的场景,对于TPCH测试机,很多查询无法跑出,或者OOM,目前只进行了StarRocks的TPCH测试。
  测试环境
  测试数据
  选用TPCH 100G测试集。
  测试结果
  导入性能测试
  无论是ClickHouse还是StarRocks,我们都可以使用DataX进行全量数据的导入,增量部分通过CDC工具写入到MQ中在经过下游数据库消费即可。
  数据集
  导入测试选取了ClickHouse Native Format数据集。1个xz格式压缩文件大概85GB左右,解压后原始文件1.4T,31亿条数据,文件格式为CSV
  导入方式
  ClickHouse中采用的HDFS外表的形式。ClickHouse中分布式表只能选择一个integer列作为Sharding Key,观察数据发现技术都很低,因此使用rand()分布形式。
  HDFS外表定义如下:
  导入结果
  可以看出,在使用github数据集进行导入的时候,基本上StarRocks和ClickHouse导入的性能相差不多。

  结论
  ClickHouse与StarRocks都是很优秀的关系新OLAP数据库。两者有着很多的相似之处,对于分析类查询都提供了极致的性能,都不依赖于Hadoop生态圈。从本次的选型对比中,可以看出在一些场景下,StarRocks相较于ClickHouse有更好的表现。一般来说,ClickHouse适合于维度变化较少的拼宽表的场景,StarRocks不仅在单表的测试中有着更出色的表现,在多表关联的场景具有更大的优势。
责任编辑:资讯报道
网站首页 我要评论 分享文章 回到顶部