StarRocks跨集群迁移最佳实践｜得物技术

一、引言

2024年之前，DBA维护的StarRocks集群存在在用低版本多、稳定性受组件bug影响大的问题，给日常运维带来一定压力，版本升级迫在眉睫。于是，我们在今年年初安排了针对2.5以下版本升级2.5.13的专项。这里和大家分享下，针对因版本兼容问题而不能原地升级的场景下，进行跨集群升级时迁移数据方面的实践。

二、方案流程

方案可行性评估口径

针对跨集群迁移方案的评估，主要从迁移成本角度考虑，主要分为资源成本和稳定性成本：

资源成本

完成迁移所需要的人力工时投入、软硬件投入（如使用哪些三方平台、需要多少机器资源、带宽资源等）。

稳定性成本

数据迁移过程中，线上业务一般仍会继续提供服务，则迁移操作对系统产生的压力可能影响正常的生产服务，随之会带来额外的稳定性成本。这里从迁移服务产生系统压力的可监控预警能力评估稳定性成本。

方案设计

方案一：StarRocks外表

1. 技术原理

1.19 版本开始，StarRocks支持将数据通过外表方式写入另一个StarRocks集群的表中。这可以解决用户的读写分离需求，提供更好的资源隔离。用户需要首先在目标集群上创建一张目标表，然后在源StarRocks集群上创建一个Schema信息一致的外表，并在属性中指定目标集群和表的信息。

通过INSERT INTO写入数据至StarRocks外表，可以将源集群的数据写入至目标集群。借助这一能力，可以实现如下目标：

• 集群间的数据同步；

• 读写分离。向源集群中写入数据，并且源集群的数据变更同步至目标集群，目标集群提供查询服务。

2. 方案评估

3. 适用场景

• 数据量较小（200G以内）；

• 无三方平台可用；

• 数据迁移无需考虑稳定性成本；

• 测试场景快速验证；

• 存在hll、bitmap类型字段，但是又没有底表数据进行数据重建（hll/bitmap类型字段借助三方组件进行迁移的方案可参考官方文档flink导入至-bitmap-列、flink导入导入至-hll-列等）；

• Array/Map/Row等复杂类型的迁移。

方案二：Flink Connector

1. 技术原理

Flink是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。随着不断迭代，Flink已提供了接口统一的批流处理模型定义，同时提供了灵活强大的DataStream API和抽象度更高的Table API，供开发人员尽情发挥，更提供了SQL支持。

Flink提供了丰富的Connector，用以打通各类数据源，形成强大的数据联通能力。StarRocks官方也推出了导入和导出Connector，满足基于Flink对StarRocks的读写能力。

2. 方案评估

3. 适用场景

• 数据量较大；

• 有三方平台可用；

• 稳定性要求高，期望控制稳定性成本；

• 有24h持续同步需求。

方案规划

在同步操作前，需要明确待同步的数据范围，统计较精确的待迁移数据量，评估数据迁移所需耗时，决策数据迁移完成时间等。

方式一

结合预期的同步完成DDL，集群每天可用于同步的时间段，推导出同步时需要达到的速率。

计算公式：

预期同步最大速率(MB/s)=待同步数据总量(MB)/同步总耗时(天)/每天可同步时间(个小时/天)

方式二

根据集群负载可支持的最大速率、集群每天可用于同步的时间段，计算完成同步所需的时间。

同步总耗时(天)=待