您当前位置:资讯中心 >大数据 >浏览文章

从Clickhouse迁移到Doris,数据仓库性能大提升

来源:互联网 日期:2023/11/17 18:02:19 阅读量:(0)

从一个OLAP数据库迁移到另一个数据库是一项艰巨的工程。即使能找到一些有用的数据工具,您可能仍会犹豫是否对数据架构进行大手术,因为不确定如何运作。

本文分享如何从ClickHouse迁移到Doris的过程,包括为什么需要更改,需要注意什么以及如何比较两个数据库在各自环境中的性能。

1 使用Doris替换Kylin、ClickHouse和Druid

这里有一家电子商务SaaS提供商,其数据系统提供实时和离线报告、客户分割和日志分析服务。最初,他们为这些不同的目的使用了不同的OLAP引擎:

  • Apache Kylin用于离线报告:该系统为超过500万个卖家提供离线报告服务。其中的大型卖家拥有超过1000万注册会员和100,000个SKU,详细信息放在平台上的400多个数据立方体中。
  • ClickHouse用于客户分割和Top-N日志查询:这需要高频更新、高QPS和复杂的SQL。
  • Apache Druid用于实时报告:卖家通过组合不同的维度提取所需的数据,这种实时报告需要快速的数据更新、快速的查询响应和系统的强大稳定性。

图片

这三个组件都有各自的痛点:

  • Apache Kylin在固定表模式下运行良好,但每次添加维度时,需要创建一个新的数据立方体并在其中重新填充历史数据。
  • ClickHouse不适用于多表处理,因此需要额外的解决方案来进行联合查询和多表连接查询。在高并发场景下,它的表现低于预期。
  • Apache Druid实现了幂等写入,因此它本身不支持数据更新或删除。这意味着当上游出现问题时,需要进行完整的数据替换。如果您从头到尾考虑所有数据备份和移动,这样的数据修复是一个多步骤的过程。此外,新摄入的数据在放入Druid中的段之前将无法用于查询。这意味着存在更长的时间窗口,从而导致上下游之间的数据不一致。

由于它们共同工作,这种架构可能太难以导航,因为它需要在开发、监控和维护方面了解所有这些组件。此外,每次用户扩展集群时,他们必须停止当前集群并迁移所有数据库和表,这不仅是一个巨大的任务,而且会对业务造成巨大的干扰。

图片图片

Apache Doris填补了这些空白。

  • 查询性能:Doris擅长高并发查询和连接查询,并且现在配备了倒排索引以加速日志搜索。
  • 数据更新:Doris的唯一键模型支持大容量更新和高频实时写入,而重复键模型和唯一键模型支持部分列更新。它还提供数据写入的恰好一次保证,并确保基表、物化视图和副本之间的一致性。
  • 维护:Doris与MySQL兼容。它支持轻松扩展和轻量级模式更改。它配备了自己的集成工具,如Flink-Doris-Connector和Spark-Doris-Connector。

因此,计划进行迁移。

2 替换手术

ClickHouse是旧数据架构中的主要性能瓶颈,也是最初想要进行更改的原因,因此从ClickHouse开始。

2.1 SQL语句的更改

表创建语句

图片图片

这里构建了自己的SQL重写工具,可以将ClickHouse表创建语句转换为Doris表创建语句。该工具可以自动执行以下更改:

  • 映射字段类型:它将ClickHouse字段类型转换为Doris中对应的字段类型。例如,它将String作为Key转换为Varchar,将String作为分区字段转换为Date V2。
  • 在动态分区表中设置历史分区的数量:某些表具有历史分区,应在Doris表创建时指定分区数,否则将抛出“无分区”错误。
  • 确定桶的数量:它根据历史分区的数据量来决定桶的数量;对于非分区表,它根据历史数据量来确定桶的配置。
  • 确定TTL:它确定动态分区表中分区的生存时间。
  • 设置导入顺序:对于Doris的唯一键模型,它可以根据Sequence列指定数据导入顺序,以确保数据摄入的有序性。

图片图片

查询语句

同样,也有工具可以将ClickHouse查询语句转换为Doris查询语句。这是为了准备ClickHouse和Doris之间的比较测试。转换中的关键考虑因素包括:

  • 表名的转换:这很简单,只需按照表创建语句中的映射规则进行即可。
  • 函数的转换:例如,ClickHouse中的COUNTIF函数等价于SUM(CASE WHEN_THEN 1 ELSE 0)Array Join等价于ExplodeLateral View,而ORDER BYGROUP BY应转换为窗口函数。
  • 语义上的差异:ClickHouse按照自己的协议进行操作,而Doris兼容MySQL,因此需要为子查询设置别名。在这种情况下,子查询在客户分割中很常见,因此他们使用sqlparse

2.2 数据摄入方法的变化

图片图片

Apache Doris提供了广泛的数据写入方法。对于实时链接,采用Stream Load从NSQ和Kafka摄取数据。

对于大型离线数据,测试了不同的方法,以下是结论:

  • Insert Into 使用Multi-Catalog读取外部数据源并使用Insert Into进行摄取可以满足此用例中的大多数需求。
  • Stream Load

Spark-Doris-Connector是一种更通用的方法。它可以处理大量数据并确保写入稳定性。关键是找到正确的写入速度和并行性。

Spark-Doris-Connector还支持Bitmap。它允许您将Bitmap数据的计算工作负载移动到Spark集群中。

Spark-Doris-Connector和Flink-Doris-Connector都依赖于Stream Load。CSV是推荐的格式选择。用户的数十亿行测试表明,CSV比JSON快40%。

  • Spark Load

Spark Load方法利用Spark资源进行数据洗牌和排名。计算结果放在HDFS中,然后Doris直接从HDFS读取文件(通过Broker Load)。这种方法非常适合大规模数据摄入。数据越多,摄入速度越快,资源利用率越高。

3 压力测试

这里比较了两个组件在SQL和连接查询方案上的性能,并计算了Apache Doris的CPU和内存消耗。

3.1 SQL查询性能

Apache Doris在16个SQL查询中的10个中表现优于ClickHouse,最大的性能差距比例接近30。总体而言,Apache Doris比ClickHouse快2~3倍。

图片图片

3.2 连接查询性能

对于连接查询测试,使用了不同大小的主表和维表。

  • 主表:用户活动表(40亿行)、用户属性表(250亿行)和用户属性表(960亿行)
  • 维表:100万行、1000万行、5000万行、1亿行、5亿行、10亿行和25亿行。

测试包括完全连接查询和过滤连接查询。完全连接查询连接主表和维表的所有行,而过滤连接查询使用WHERE过滤器检索特定卖家ID的数据。结果如下:

主表(40亿行):

  • 完全连接查询:Doris在所有维表的完全连接查询中均优于ClickHouse。随着维表变大,性能差距越来越大。最大的差距比例接近5。
  • 过滤连接查询:基于卖家ID,过滤器从主表中筛选出了4100万行。对于小型维表,Doris比ClickHouse快2~3倍;对于大型维表,Doris比ClickHouse快10倍以上;对于大于1亿行的维表,ClickHouse会抛出OOM错误,而Doris则正常运行。

主表(250亿行):

  • 完全连接查询:Doris在所有维表的完全连接查询中均优于ClickHouse。ClickHouse在维表大于5000万行时会产生OOM错误。
  • 过滤连接查询:过滤器从主表中筛选出了5.7亿行。Doris在几秒钟内响应,而ClickHouse在连接大型维表时完成时间为几分钟,并在此过程中崩溃。

主表(960亿行):

Doris在所有查询中都表现出相对较快的性能,而ClickHouse无法执行所有查询。

在CPU和内存消耗方面,Apache Doris在所有大小的连接查询中都保持稳定的集群负载。

关键字:
声明:我公司网站部分信息和资讯来自于网络,若涉及版权相关问题请致电(63937922)或在线提交留言告知,我们会第一时间屏蔽删除。
有价值
0% (0)
无价值
0% (10)

分享转发:

发表评论请先登录后发表评论。愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。