首先阐述了跨集群数据迁移能力的必要性，接着剖析了跨集群数据迁移技术架构，然后从FE任务状态管理角度，着重介绍数据快照、物理复制和数据可见性等三个方面的技术原理，最后总结下这种数据迁移技术的限制。
1 引言
经过StarRocks 2024 Roadmap社区讨论，一个重大的转变已经来了——内核功能开发优化会优先在存算分离版本中发布，这代表着社区的开发重心由存算一体转变为存算分离。随着存算分离功能不断丰富，性能不断优化，加上成本优势，存算分离版的用户也必将增多。一个现实性的用户问题不得不考虑:现有存算一体架构下库表数据如何迁移到存算分离架构下？
一种容易想到的方法是将存算分离集群库表作为存算一体集群库表的外表，然后通过INSERT INTO写入数据至StarRocks外表，可以将源集群的数据写入至目标集群。这种数据复制能力需要源集群和目的集群投入大量计算资源，可能会阻塞用户查询需求。是否有更好的跨集群数据迁移方法呢？答案是有。
物理复制技术能更加高效的完成跨集群数据迁移。本文详细介绍该技术架构和实现原理，旨在帮助用户和开发人员理解该技术原理，进而准确、高效完成存算一体架构下的数据迁移到存算分离集群。
2 跨集群数据迁移架构
StarRocks跨集群数据迁移是3.2.3版本内核提供的一个能力。它可以将全量数据、增量数据从存算一体集群搬迁到存算分离集群或者存算一体集群。
以数据流向角度来看，跨集群数据迁移主要参与角色为目的集群Frontend(统一称为FE)和目的集群Backend(统一称为BE)和源集群BE。
目的集群FE主要负责管理数据迁移任务，维护任务状态。任务状态根据数据迁移原理具体划分为四个，初始化、数据快照、物理复制和数据可见。任务被提交到FE就进入初始化状态。数据快照状态完成对哪些数据、如何快速生成快照的工作。物理复制状态完成快照文件的迁移。目的集群FE调度下发任务完成相应状态工作。
目的集群BE主要接收FE调度，完成快照管理、数据复制管理和数据版本发布。快照管理维护快照的版本信息和快照事务日志信息。数据复制管理负责快照文件下载和复制事务日志。版本发布负责将快照数据对用户可见。
源集群BE根据两个集群数据版本差异执行数据快照，提供快照文件下载服务。
跨集群数据迁移原理架构见图1。
图 1 跨集群数据迁移原理架构
从数据导入事务角度看，数据迁移分为两个阶段，即write和commit阶段。任务初始化、数据快照和物理复制属于write阶段，数据可见属于commit阶段。在write阶段，FE从事务ID管理处获取一个全局唯一的事务ID，封装事务并入队。当物理复制完成后，FE修改事务状态为commit。后台线程将状态为commit的事务序列执行，完成数据可见工作。
图2 数据迁移Job事务状态管理
3 快照技术原理
StarRocks中的快照信息包含两类信息，一是底层物理存储文件，二是快照元数据。物理存储文件是Segment数据的具象文件，以.dat为后缀。快照元数据主要是桶的元数据信息，其中主要包含了包含快照的Rowset信息。
数据快照原理示意如图3所示。目的集群BE接收快照请求时，首先会根据TabletId和TxnId信息确认是否做过快照。如果是快照事务日志文件存在，快照事务日志状态为TXN_SNAPSHOTED且快照事务日志版本为快照请求中携带的源集群可见版本，那么认定此次快照请求已经完成。
图3 数据快照原理
一个关键性的问题，对哪些数据进行快照？StarRocks中使用版本信息来描述。举个简单例子，目的集群某个Tablet的可见版本是3，源集群中Tablet的可见版本是5，那么此次需要做快照的版本为[4-4]和[5-5]。所以在快照管理中，维护一个Missed Version信息。
在发送执行快照请求到源集群BE前，需要决定快照类型。快照类型分为全量快照和增量快照。如果目的集群中桶的可见版本小于等于1，此次快照请求是全量数据快照，否则就是增量快照。只有增量快照请求中会携带Missed Version信息。
源集群BE根据请求是否携带Missed Version信息，决定执行全量快照还是增量快照。无论是增量快照还是全量快照，执行逻辑都是分为两步。第一个逻辑是根据Version找到Rowset，第二个逻辑是根据Rowset找到存储文件，硬连接到快照目录下的一个新文件，同时在快照目录下持久化元数据。
目的集群BE的快照请求完成后，会收到快照目录信息。接着开始生成快照事务日志。快照事务日志中主要包含数据迁移状态(TXN_SNAPSHOTED)和快照版本信息，用来避免同一版本重复快照，也是整个任务状态迁移重要一步。最后就是远程过程调用告知目的集群FE快照路径。
上述过程是理想情况下的执行逻辑。实际情况是增量快照过程可能出现异常，举个简单例子说明失败原因。假如在两个集群之间同步某个桶的版本信息是[4-4],恰好源集群中发生Compaction，将该小版本合并成一个大版本[0-5]。此时增量快照异常，但是BE不会上抛异常，而是进行全量快照。
4 物理复制技术原理
物理复制技术是基于快照文件的一种数据写入方式。与SQL方式导入数据相比较，物理复制技术在几乎不消耗计算资源的情况下，也能获得极高的数据写入速度，类似于离线批加载数据能力，非常适合海量数据跨集群数据迁移。
数据物理复制原理图见图4。物理复制技术原理过程主要分为两个步骤。第一个步骤是下载快照文件，包括快照元数据和数据文件。第二个步骤是根据快照元数据构建物理复制事务日志。
图4 数据物理复制原理
目的集群BE根据物理复制请求中快照路径，使用第三方C库libcurl与源集群BE文件传输服务交互，实现快照文件的下载功能。通过解析快照元数据，目的集群BE可以知道需要下载哪些物理文件。在文件传输过程中，物理存储文件被重命名到目的集群BE桶数据目录下，命名规则为事务ID加上UUID。
构建物理复制事务日志的主要依据是快照元数据。快照元数据中数据行数、大小、删除条件，还有物理存储文件的新名称等构成了物理复制事务日志的主要内容。另外还有状态变更为TXN_REPLICATED。
在构建完事务日志后，目的集群FE接收完成消息，并将事务状态修改为可提交状态。
5 数据可见性
此时，虽然存储文件被复制到目的集群数据目录下，但是对用户而言不可见。BE中数据可见性由FE根据Commit time序列触发。数据可见性原理见图5。FE中有一个后台线程，周期性check出可提交的事务。根据数据位置向BE发送publish请求。
请求信息中包括主要包括三个信息。第一个信息为TxnId，用于定位物理复制事务日志，里面保存有待发布的数据文件信息。第二个是Version信息，该信息是由FE维护，界定了用户可见的数据。第三个是BaseVersion信息，用于定位待修改的BE元数据。
在开始发布前，会校验快照版本和NewVersion。校验通过后，开是发布流程，在老旧版本的BE元数据中，增加待发布的数据文件元数据并修改可见版本，保证桶数据版本和FE一致。
完成发布版本后，目的集群BE会清除掉快照事务日志和复制事务日志，发送删除快照目录的请求到源集群BE中。
图5 数据可见性原理
6 总结
跨集群数据物理复制技术有以下几点限制值得关注。
第一个限制是数据迁移流向只能是存算一体集群到存算一体或存算分离集群，因为数据快照利用Linux文件硬连接能力来完成快照构建，存算分离架构集群内核没有数据快照能力，所以数据源只能是存算一体集群。
第二个限制是在数据跨集群迁移过程中，用户不能导入数据到目的集群中。数据快照首先要找到两个集群下每个桶的差异化版本信息，根据这些信息计算出需要快照的元数据。在目的集群中导入数据会导致桶可见版本变化，会导致两个集群数据不一致，更为严重的是可能导致数据迁移中断。。
第三个限制是如果目的集群是存算分离架构，那么必须关闭Compaction。存算分离架构下Compaction触发机制、版本控制与存算一体架构不一样。存算分离架构下的Compaction也会导致桶可见版本变化，这会导致数据快照不准确，可能会产生数据同步丢失，也可能会产生快照失败。
虽然数据物理复制技术存在一些使用限制，但仍然不失为一种用户数据上云、跨集群全增量数据迁移的高效方法。
