从一个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等价于Explode和Lateral View，而ORDER BY和GROUP 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在所有大小的连接查询中都保持稳定的集群负载。
