StarRocks 存算分离集群 TB 级迁移实践分享

StarRocks 存算分离集群 TB 级迁移实践分享

💡 原文中文,约5100字,阅读约需12分钟。
📝

内容提要

某光伏新能源企业计划将海外业务迁移至AWS,采用StarRocks实现存算分离架构。迁移方案需满足数据量大、影响小、无官方工具等要求。最终设计出基于导出导入的增量迁移方案,结合Amazon服务,确保数据完整性和一致性,减少对源集群的影响。

🎯

关键要点

  • 某光伏新能源企业计划将海外业务迁移至AWS,采用StarRocks实现存算分离架构。

  • 迁移方案需满足数据量大、影响小、无官方工具等要求。

  • 客户的StarRocks集群保存了核心业务数据,数据量超过60TB,需进行存量和增量迁移。

  • 客户要求迁移尽量减少对线上源集群的影响,API接口熔断阈值较低。

  • StarRocks官方未提供存算分离集群的数据迁移工具,客户使用的版本较老且有源码修改。

  • 尝试方案一基于Amazon DTH同步数据,但遇到分区特性不一致和API调用限制等问题。

  • 尝试方案二使用导出导入功能,解决增量数据迁移和导出任务对线上业务的影响。

  • 导出数据时,使用EXPORT命令生成CSV文件,面临数据占用空间大和网络不稳定等问题。

  • 选择Borker Load方式导入数据,支持从云端对象存储导入,避免额外依赖。

  • 增量数据迁移方案包括使用增量表和条件过滤导出,分别减少源集群影响和简化业务配合。

  • 监控迁移任务状态和数据一致性,使用Amazon DynamoDB进行任务监控和重试。

  • 确保迁移过程网络稳定性,使用DTH进行文件传输,保证安全稳定。

  • 方案架构设计包括Task Manager、File Event Trigger、Task Queue和Object Storage等核心组件。

  • 总结构建了一种支持TB级别数据规模的迁移方案,结合多种AWS服务和StarRocks导出导入功能。

🔎

延伸解读

迁移方案的复杂性

在进行大规模数据迁移时,尤其是超过60TB的数据,方案的复杂性显著增加。客户的需求包括减少对源集群的影响和确保数据完整性,这使得迁移方案的设计必须非常谨慎。特别是由于StarRocks官方未提供存算分离集群的迁移工具,团队不得不探索多种替代方案,增加了实施的难度和风险。

增量迁移的挑战

增量数据迁移是确保数据一致性的重要环节。文章中提到的两种增量迁移方式各有优缺点,选择合适的方案需要权衡对源集群的影响和业务配合的复杂性。尤其是在高并发的环境下,如何有效管理增量数据的导出和导入,避免对线上业务造成干扰,是成功迁移的关键。

监控与稳定性的重要性

在数据迁移过程中,监控任务状态和确保网络稳定性至关重要。使用Amazon DynamoDB进行任务监控,可以及时发现并重试失败的任务,保证数据迁移的成功率。同时,利用DTH进行文件传输,能够有效应对网络不稳定带来的风险,确保数据在迁移过程中的安全和完整性。

延伸问答

StarRocks 存算分离集群的迁移方案有哪些关键要求?

迁移方案需满足数据量大、影响小、无官方工具等要求,且需进行存量和增量迁移。

在迁移过程中如何减少对源集群的影响?

通过控制导出并发和时间间隔,监控源集群资源,动态调整任务并发度和时间间隔来减少影响。

增量数据迁移的两种实现方式是什么?

一种是使用增量表进行双写,另一种是使用条件过滤导出增量数据。

为什么选择 Borker Load 方式导入数据?

因为它支持从云端对象存储导入,且是 StarRocks 原生支持,无需额外依赖。

在迁移过程中如何监控任务状态和数据一致性?

使用 Amazon DynamoDB 监控任务状态,对失败任务进行重试,确保数据至少一次迁移成功。

StarRocks 官方是否提供存算分离集群的数据迁移工具?

不提供,官方的迁移工具仅支持存算一体集群的迁出。

🏷️

标签

➡️

继续阅读