StarRocks 迁移至 Apache Doris 完整指南：三步完成结构、数据与业务平滑切换

原创于 2026-09-20 16:14:23 发布 · 460 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

技术学习

StarRocks 怎么迁移到 Apache Doris？SR 迁移 Doris 是否需要重新建表？几亿、几十亿数据怎么搬？DataX、Flink、Parquet 应该怎么选？全量迁移之后又如何保证增量数据不丢？

实际上，StarRocks 到 Doris 的迁移没有很多异构数据库迁移那么重。

一个重要原因是：Apache Doris 与 StarRocks 技术同源。

从项目演进关系看，StarRocks 从 Apache Doris 项目分支发展而来，两者早期共享技术基础，此后沿着各自的产品路线独立演进。StarRocks 的官方项目资料保留了 Apache Doris 的代码来源声明，历史版本记录也涉及从 Doris 0.13 向早期 StarRocks 版本升级的路径。

从当前产品架构看，两者仍然有不少共同点：都面向 OLAP 分析场景，都采用 MPP 架构，都使用列式存储，也都兼容 MySQL 协议并提供 SQL 接口。StarRocks 官方将其描述为 MPP 分析数据库，并支持 MySQL 协议；Apache Doris 同样采用 MPP 查询架构、列式存储以及 MySQL 协议。

这意味着，与 MySQL 迁移到 ClickHouse、Oracle 迁移到其他分析数据库相比，StarRocks 迁移 Doris 通常可以复用更多已有的表结构、SQL 和数据链路。

普通明细表、聚合表的 DDL 往往具有较高的复用价值；数据迁移也可以使用 DataX、Flink、Stream Load、Parquet 文件中转等成熟方案完成。

但技术同源不等于直接复制。

随着两边独立演进，Primary Key、Unique Key、物化视图、部分列更新、表属性、SQL 函数以及数据导入机制等方面已经产生差异。因此，生产迁移仍然需要进行结构转换、数据校验和业务灰度。

如果企业除了技术迁移，还希望进一步降低数据库运维成本、获得长期版本维护和商业技术支持，则可以把目标端进一步扩展到 SelectDB。飞轮科技（SelectDB）是基于 Apache Doris 的商业化公司，SelectDB 则是围绕 Apache Doris 打造的商业化产品体系。

无论最终目标是 Doris 还是 SelectDB，整体迁移方法都比较接近，可以归纳成三个阶段：

一、结构迁移：批量迁表，不要逐张重建

第一步是将 StarRocks 中的数据库对象迁移到 Doris。

对于表数量较多的集群，没有必要逐张手工重建。可以遍历 StarRocks 的 information_schema 系统表获取数据库和表清单，再通过 SHOW CREATE TABLE 批量提取 DDL，经过规则转换后，在 Doris 中批量执行。

由于两者建表语法整体比较接近，大多数普通表都可以复用原有结构，重点检查以下几类差异即可：

这里最值得关注的是 StarRocks Primary Key 到 Doris Unique Key 的转换。

两者都可以承担按业务主键保留最新数据的场景，但具体的 UPSERT、部分列更新、DELETE 和乱序更新机制需要重新验证。不能只把 PRIMARY KEY 替换成 UNIQUE KEY 就认为迁移完成。

如果现有环境中还有大量 Hive、Iceberg、Hudi 等外部表，可以在迁移过程中顺便评估使用 Doris Catalog + View 重新组织外部数据访问方式，减少大量独立 External Table 的维护成本。

结构迁移需要的工具

这一阶段通常只需要：

StarRocks information_schema
SHOW CREATE TABLE
Python / Shell / Java 脚本
Doris SQL Client

核心目标不是做到百分之百自动转换，而是让简单表自动迁移、复杂表进入人工检查清单。

二、数据搬迁：全量先迁，再追增量

表结构创建完成后，就进入数据迁移阶段。

数据搬迁建议分成两个部分：

历史全量 + 实时增量。

全量迁移解决已有数据怎么过去，增量同步解决迁移期间新产生的数据怎么持续追上。

全量数据怎么迁？

根据现有技术栈，可以选择以下几种方式。

DataX + Doriswriter

如果公司已经有 DataX 平台，这通常是比较容易落地的方案。

整体链路可以理解为：

StarRocks → DataX → Doriswriter → Doris

Doriswriter 最终通过 Stream Load 将数据写入 Doris。

使用时重点注意：loadUrl 配置 FE 的 HTTP 端口，而不是 JDBC 查询端口；单批数据量、批次行数和 Flush 周期不宜设置得过小，否则高频小批次写入会增加目标端压力。

DataX 更适合已经有成熟任务调度平台，希望按表、按分区批量迁移的场景。

Parquet + 对象存储

对于历史数据量较大的场景，可以先将 StarRocks 数据导出成 Parquet，再通过 S3、OSS、HDFS 等中间存储导入 Doris。

链路大致为：

StarRocks
    ↓
Parquet
    ↓
S3 / OSS / HDFS
    ↓
Doris

Doris 可以通过 TVF 配合 INSERT INTO SELECT 读取文件并写入内部表。

这种方案最大的优势是源端和目标端解耦：即使 Doris 导入失败，也不需要重新扫描 StarRocks，历史文件还可以保留作为迁移快照。

对于现在新设计的迁移方案，也更建议优先考虑 TVF / Catalog + INSERT INTO SELECT。Doris 已经将 Broker Load 标记为废弃能力，因此不建议把它作为新的长期迁移方案。

Flink Connector

如果原来的实时数仓已经大量使用 Flink，可以直接复用现有数据链路，通过 Flink Doris Connector 写入 Doris。

这种方式尤其适合：

MySQL / Kafka
        ↓
      Flink
     ↙     ↘
StarRocks  Doris

迁移期间保持两个目标端同时接收数据，待 Doris 完成历史数据补齐后，再逐渐切换业务。

增量数据怎么处理？

真正的在线迁移不能只搬历史数据。

全量迁移完成后，还需要通过 CDC、Kafka 或 Flink 等方式把迁移期间产生的新增、修改和删除持续同步到 Doris。

这里有一个很重要的原则：

尽量从真实上游建立增量链路，而不是把 StarRocks 当成通用 CDC 数据源。

例如原来是：

MySQL → Flink CDC → Kafka → StarRocks

迁移时可以改成：

MySQL → Flink CDC → Kafka → StarRocks
                       └→ Doris

或者在 Flink 层直接双写。

这样比从 StarRocks 再反向抽取增量数据更加容易保证数据完整性。

数据迁移需要的工具

根据环境选择即可：

DataX + Doriswriter
Stream Load
Parquet
S3 / OSS / HDFS
S3 TVF / HDFS TVF
Flink Doris Connector
Flink CDC
Kafka
Doris Streaming Job

没有必要把所有工具全部用上，通常选择一条全量链路和一条增量链路即可。

三、验证与切换：确认数据和查询都正常，再切生产

数据迁移完成不代表项目结束。

正式将业务切换到 Doris 之前，至少要完成数据一致性、查询兼容性和业务双跑三个层面的验证。

数据一致性验证

最基础的方式是比较 StarRocks 和 Doris 两端：

行数；
数值字段 SUM；
MIN / MAX；
分区级记录数；
NULL 数量。

大表可以按照日期分区或主键范围分批比较。

但 COUNT 和 SUM 相同并不能完全证明数据相同。因此对于订单、支付、用户状态等核心表，还应按照业务主键抽样或分批比较具体字段。

尤其需要验证：

INSERT
UPDATE
DELETE
NULL
DECIMAL
DATETIME

这些容易在迁移过程中出现语义差异的数据。

如果有 CDC 增量链路，还应该测试重复消息和乱序消息，避免旧数据覆盖新数据。

查询回放

结构和数据正确之后，还要验证原来的查询是否能够正常运行。

可以从 StarRocks 审计日志中抽取一批真实生产 SQL，包括：

高频查询；
核心 BI 查询；
慢查询；
多表 JOIN；
聚合查询；
窗口函数；
TopN 查询。

在 Doris 中回放后，重点比较两件事：

结果是否一致，性能是否满足业务 SLA。

性能不要只看单条 SQL，也不要直接写“迁移后性能提升几倍”之类没有测试依据的结论。

更可靠的方式是使用真实业务数据和真实 SQL，比较 P95、P99、QPS、CPU、内存和扫描数据量。

双跑和灰度切换

查询验证完成后，不建议一次性切全部流量。

可以先让 StarRocks 和 Doris 同时提供查询，优先迁移低风险报表或非核心业务，再逐步增加 Doris 流量。

灰度期间持续观察：

查询错误率
核心指标结果
P95 / P99
写入延迟
CDC 延迟
CPU / 内存

当数据结果和系统稳定性都达到预期，再完成正式切流。

四、迁移过程中必须保留的几个保障措施

迁移方案不需要设计得特别复杂，但有几个措施不能省。

第一，记录数据水位。

全量快照和增量同步之间必须有明确的衔接点，避免出现历史数据迁完了，但中间几个小时的增量没有同步的问题。

第二，分批迁移。

大表不要一次性全部搬迁。按照分区、日期或主键范围拆批，既方便限流，也方便失败重跑和问题定位。

第三，保留迁移台账。

至少记录：

表名
迁移批次
数据范围
源端行数
目标端行数
迁移状态
校验状态

防止任务执行成功，但实际出现少迁、重复迁移等问题。

第四，保留回滚能力。

正式切换后不要立即下线 StarRocks。

观察期内建议继续保留 StarRocks、Kafka / Binlog、CDC 位点以及历史迁移文件。

如果 Doris 出现问题，可以快速将查询切回 StarRocks。

需要特别注意：如果切流后已经停止向 StarRocks 写入，那么只保留 StarRocks 的只读副本并不能保证无损回滚，还需要确保切流之后的新数据能够从 Kafka、Binlog 或其他上游重新恢复。

五、推荐的迁移路径

对于大多数 StarRocks 到 Doris 的迁移项目，可以采用下面这个组合：

结构：
information_schema
+ SHOW CREATE TABLE
+ 脚本批量转换

全量：
DataX
或
Parquet + 对象存储 + TVF

增量：
Kafka / Flink CDC / Flink Connector

验证：
COUNT / SUM
+ 主键级校验
+ SQL 回放

切换：
双跑
→ 灰度
→ 正式切流
→ 保留回滚

如果企业已经有 DataX，优先复用 DataX。

如果数据量很大且有对象存储，可以优先考虑 Parquet 中转。

如果已经有成熟 Flink 实时链路，则优先从 Flink 或 Kafka 层完成 Doris 增量接入。