摘要： 本文结合 NineData 产品，介绍如何将 MySQL 中的订单、用户和日志数据同步到 Doris，覆盖 Doris 表模型选择、目标表创建、全量迁移、Binlog 增量同步、数据校验、异常处理和上线验证。NineData 通过可视化复制任务统一管理数据源、同步对象、结构复制、全量复制、增量复制、任务监控和数据对比，适合建设 MySQL 到 Doris 的实时数据入仓链路。
|----------------------------------------------------------------------------------------|
| 本文所说的"实时同步"，是指基于 MySQL Binlog 的 CDC 增量复制。实际延迟取决于源端写入量、网络、目标端资源、表模型和任务配置，不代表所有场景下绝对零延迟。 |
一、 MySQL 数据同步到 Doris的场景
MySQL 主要承载在线事务业务，Doris 更适合大规模数据分析、报表查询和多维聚合。将 MySQL 中的业务数据同步到 Doris，可以减少直接查询 MySQL 对线上业务的影响。
常见场景包括：
- 订单实时分析；
- 用户行为分析；
- 商品和库存统计；
- 运营报表；
- 实时数据大屏；
- 用户画像；
- 风控指标；
- 日志检索和趋势分析；
- 业务库数据进入数据仓库或数据集市。
典型链路如下：
如果只做一次性导入，Doris 只能获得某个时间点的数据快照，源端后续产生的新增、更新和删除无法自动进入目标端。因此，生产环境通常采用：
二、NineData 能解决什么问题
NineData 可以通过复制任务组织 MySQL 到 Doris 的迁移和实时同步，主要包括：
- 数据源可视化配置；
- 结构复制；
- 全量数据复制；
- Binlog 增量同步；
- 同步对象选择；
- 表和字段映射；
- 数据过滤；
- 任务预检查；
- 复制延迟监控；
- 任务日志查看；
- 数据一致性对比；
- 异常告警；
- 差异处理和重新同步。
NineData 的一个重要特点，是将数据源、复制类型、同步对象、任务状态、错误日志和数据校验集中在可视化复制任务中管理。
相比需要分别维护导出脚本、Binlog 消费程序、Doris 写入任务和校验脚本的方式，NineData 可以降低复制链路的配置和运维复杂度，尤其适合需要持续迁移、实时同步和过程监控的项目。
三、NineData 可视化操作的优势
MySQL 到 Doris 的同步，不只是把数据写入目标库，还需要持续管理：
- 哪些库表需要同步；
- 目标表使用什么模型；
- 全量复制是否完成；
- 增量延迟是否升高；
- 哪些表发生失败；
- 字段如何映射；
- 数据类型是否兼容；
- 差异数据如何定位；
- 任务异常后如何恢复。
在 NineData 控制台中，实施人员可以完成：
- 创建 MySQL 和 Doris 数据源；
- 选择结构、全量和增量复制；
- 选择数据库、表和字段；
- 配置表名、字段和过滤规则；
- 执行任务预检查；
- 启动、暂停和管理复制任务；
- 查看全量进度和增量延迟；
- 查看失败对象和任务日志；
- 发起数据对比；
- 重新同步异常表。
对于迁移项目而言，可视化任务管理可以让实施人员直接查看任务进度、失败对象、延迟和日志，也便于多人协作、项目交接和上线审计。
需要说明的是，可视化复制操作降低的是数据链路实施成本，不能替代 Doris 表模型设计、分区分桶规划、数据分层和查询优化。
四、迁移前需要准备什么
1. 配置 MySQL Binlog
MySQL 作为增量同步源端时，需要满足 NineData 当前链路的 Binlog 配置要求。官方 MySQL 复制文档通常要求：
|--------------------------------------------------------|
| Plain Text binlog_format = ROW binlog_row_image = FULL |
如果源端 MySQL 本身是复制从库，还需要根据链路要求确认：
|-----------------------------------|
| Plain Text log_slave_updates = ON |
具体参数、权限和版本要求，应以 NineData 当前版本文档和任务预检查结果为准。
还需要确认：
- Binlog 已开启；
- NineData 可以读取 Binlog；
- Binlog 保留时间覆盖全量迁移和异常恢复窗口；
- 源端账号权限满足要求；
- 源端网络可达；
- 日志空间充足。
2. 表主键、唯一键与目标模型
订单、用户等需要持续更新的业务表，应优先具备主键或唯一约束。主键或唯一键有助于定位更新记录、处理删除记录、避免重复数据，并支持后续数据校验和差异处理。
MySQL 到 Doris 链路中，NineData 会根据源表的主键或唯一键情况选择目标表模型：有主键或唯一键的表使用 Unique 模型，没有主键和唯一键的表使用 Duplicate 模型。
但无主键表无法通过主键稳定表达更新和删除语义。对于日志、事件等只追加数据，可以结合 Duplicate 模型进行评估；对于订单、用户等需要更新的业务表，应优先补充主键或唯一键并使用 Unique 模型。不能将无主键表直接当作支持稳定更新同步的业务实体表。
3. 确认 Doris 目标端环境
在创建任务前，需要明确：
- Doris 集群地址；
- Doris 版本；
- 目标数据库；
- 目标端账号权限；
- BE 节点资源；
- 磁盘空间；
- 分区和分桶规划；
- 目标表模型；
- 是否由 NineData 自动创建表；
- 是否已经存在目标表。
MySQL 是在线事务数据库，Doris 是分析型数据库。迁移到 Doris 时，不能简单地把源端表结构原样视为最终数仓模型。
五、Doris 表模型如何选择
Doris 常见的表模型包括 Duplicate、Unique 和 Aggregate。三种模型适合的场景不同。
点击图片可查看完整电子表格
NineData 自动选择模型的行为
NineData MySQL 到 Doris 复制链路，在结构复制自动创建目标表时：
- 源端有主键的表，目标端使用 Unique 模型；
- 源端有唯一键的表，目标端使用 Unique 模型；
- 源端既没有主键也没有唯一键的表，目标端使用 Duplicate 模型。
因此，有主键的订单表通常会自动创建为 Unique 模型；有唯一键的用户表通常会自动创建为 Unique 模型；没有主键或唯一键的日志表通常会自动创建为 Duplicate 模型。
实施人员应在任务配置和目标端建表后确认实际模型是否符合分析场景。自动选择可以减少建表工作，但不能代替数仓建模，也不能解决无主键表的更新和删除定位问题
六、使用 NineData 创建复制任务
第一步：创建数据源
在 NineData 控制台中创建：
- MySQL 源数据源；
- Doris 目标数据源。
完成连接测试后，确认网络、账号权限和数据库连接正常。
第二步：选择复制类型
完整入仓通常选择：
- 结构复制；
- 全量复制；
- 增量复制。
如果 Doris 目标表已经按照数仓模型人工创建，可以根据实际情况不启用结构复制，但必须确认目标表的字段、类型、分区、分桶和写入模型符合任务要求。
第三步：选择同步对象
建议按业务域选择：
- 订单库；
- 用户库；
- 日志库；
- 商品库；
- 支付库。
需要明确：
- 是否排除临时表；
- 是否排除备份表；
- 是否排除历史归档表；
- 是否只同步部分字段；
- 是否过滤测试数据；
- 是否进行库表映射；
- 是否进行字段脱敏；
- 是否存在无主键表；
- 目标端是否存在同名表。
NineData 提供了黑名单配置项，在全部实例或全库复制模式下，可以通过黑名单直接排除不需要同步的库或表，操作路径在"选择复制对象"页签中。
第四步：配置字段映射和过滤
检查：
- 字段名称；
- 字段类型；
- 数值精度；
- 时间类型；
- 字符串长度；
- NULL 值；
- 默认值；
- 大字段；
- 敏感字段；
- 不需要入仓的字段。
第五步：确认 Doris 表模型
如果由 NineData 自动创建目标表，应检查：
- 有主键或唯一键的表是否创建为 Unique；
- 无主键、无唯一键的表是否创建为 Duplicate；
- 订单和用户表是否适合更新；
- 日志表是否适合追加；
- 分区和分桶是否满足查询需求；
- 自动创建结果是否需要人工调整。
第六步：执行预检查
重点处理：
- MySQL Binlog 配置不满足要求；
- 账号权限不足；
- 无主键或无唯一约束表；
- Doris 连接失败；
- 字段类型不兼容；
- 目标端表已存在；
- Doris 空间或资源不足；
- 网络不稳定；
- 映射或过滤规则错误。
预检查通过后，再启动正式任务。任务启动后，可通过任务详情页的运维入口进行同步位点管理、线程查看、限流设置和日志排查。
此外，NineData 支持为复制任务配置告警策略，可监控任务状态和复制延迟，异常时通过短信、电话、邮件或钉钉/飞书/企业微信推送告警。
七、执行全量迁移
全量迁移会增加 MySQL 的读取压力和 Doris 的写入压力。
MySQL 侧关注
- CPU；
- 磁盘 IO；
- 活跃连接；
- 慢查询；
- 锁等待；
- Binlog 增长；
- 线上接口响应时间。
Doris 侧关注
- BE 节点 CPU；
- 内存和磁盘；
- 写入吞吐；
- 分区和分桶热点；
- 导入失败；
- 查询响应时间；
- 目标表数据量。
NineData 侧关注
- 全量复制进度；
- 复制速率；
- 增量延迟；
- 失败表；
- 执行线程；
- 当前 SQL；
- 提交响应时间；
- 任务日志。
建议先使用低并发进行小规模验证，再逐步提高迁移速度。
八、MySQL Binlog 增量同步到 Doris
典型增量流程如下：
订单场景
重点验证：
- 新订单是否进入 Doris；
- 同一订单号是否保持唯一；
- 订单状态更新是否正确；
- 支付和退款是否同步；
- 取消订单是否反映到目标端；
- DELETE 行为是否符合目标表模型。
用户场景
重点验证：
- 用户注册是否同步；
- 用户状态更新是否同步；
- 标签和等级变化是否同步；
- 敏感字段是否按要求处理。
日志场景
重点验证：
- 高频写入是否造成延迟；
- 大字段是否影响同步速度；
- 日志分区是否正常；
- 错误日志是否集中积压；
- 日志保留策略是否生效。
"实时"应通过实际监控数据定义。上线前建议明确：
- 正常延迟目标；
- 告警阈值；
- 最大可接受延迟；
- 延迟升高后的处置人；
- 是否允许短时间积压。
九、DDL 变更如何处理
NineData 支持 DML 和 DDL 增量数据复制能力，但 MySQL 到 Doris 属于异构链路，DDL 能否在目标端按预期执行，可进一步验证。
需要重点验证：
- 新增字段；
- 删除字段；
- 修改字段类型；
- 修改字段长度；
- 新增或删除索引；
- 表重命名；
- 分区变更；
- 目标端模型变化；
- 库表映射变化。
生产环境建议：
- 冻结非必要 DDL；
- 必须变更时先在测试环境验证；
- 确认 Doris 目标表模型是否支持；
- 检查 NineData 任务日志；
- 重新执行数据对比；
- 验证下游报表和查询。
十、数据一致性校验
NineData 数据对比能力可用于迁移后的数据检查：
建议分三层校验。
1. 数量和范围校验
检查：
- 表行数；
- 订单数量；
- 用户数量；
- 日志数量；
- 时间范围；
- 最大时间和最小时间；
- 金额汇总；
- 状态分布。
2. 数据对比
根据表规模选择：快速对比、全量对比、抽样检查、分片对比。NineData 在 MySQL 到 Doris 链路上支持全量数据对比，增量对比暂不支持该链路。
订单表重点检查订单号、状态、金额和时间；用户表重点检查用户 ID、状态和注册时间；日志表重点检查事件时间、请求 ID、错误码和日志数量。
3. 业务口径校验
数据对比不能替代业务验证，还需要确认：
- 订单金额报表是否一致；
- 支付和退款统计是否一致；
- 用户日活和月活是否一致；
- 日志错误率是否一致；
- 下游 BI 报表是否正常；
- Doris 查询结果是否符合业务要求。
十一、NineData 核心优势
1. 全量和增量统一管理
结构复制、历史数据迁移和 Binlog 增量同步可以在同一复制任务中配置和跟踪，减少多套工具拼装。
2. 可视化配置，降低实施门槛
数据源、复制类型、同步对象、字段映射、任务状态、失败日志和数据对比结果，都可以在控制台中查看和操作。
3. 自动选择基础表模型
根据 NineData MySQL 到 Doris 链路文档：
- 有主键的源表默认创建为 Doris Unique 模型；
- 有唯一键的源表默认创建为 Doris Unique 模型；
- 没有主键和唯一键的源表默认创建为 Doris Duplicate 模型。
这可以减少目标表初始化工作，但实施人员仍需要确认模型是否满足订单、用户和日志的实际更新语义。
4. 便于迁移项目管理
NineData 将预检查、任务启动、暂停、日志查看、延迟监控、数据对比和重新同步集中在复制任务中，便于多人协作、过程审计和故障处理。
5. 支持持续数据校验
迁移完成后，可以使用快速对比、全量对比发现差异，再结合业务统计完成验收。
NineData 的可视化能力降低了复制链路的实施复杂度，但 Doris 的模型设计、分区分桶、数据生命周期和查询优化，仍需要数仓团队负责。
十二、实施交付清单
建议准备：
- MySQL 源端环境清单；
- Doris 目标端环境清单；
- Binlog 和账号权限检查表；
- 订单、用户、日志迁移对象清单；
- 字段映射表；
- 敏感字段处理清单；
- Doris 表模型设计；
- 分区和分桶设计；
- NineData 任务配置记录；
- 预检查问题处理记录；
- 全量复制报告；
- 增量延迟监控记录；
- 数据一致性报告；
- 业务口径校验报告；
- 异常处理记录；
- 上线和回退方案。
总结
MySQL 到 Doris 的实时同步，不是简单地把 MySQL 表复制到 Doris，需要同时解决：
NineData 通过可视化复制任务，将数据源管理、结构复制、全量迁移、增量同步、任务监控、数据对比和差异处理集中在一个平台中，适合实施 MySQL 到 Doris 的实时数据入仓项目。
在实际项目中，订单和用户等更新型业务表应优先评估 Doris Unique 模型，日志和事件等追加型数据可以评估 Duplicate 模型，固定模式的统计结果再考虑 Aggregate 模型。
常见问题
MySQL 可以实时同步到 Doris 吗？
可以。NineData 支持 MySQL 到 Doris 的全量复制和增量复制，增量同步通常基于 MySQL Binlog。实际延迟取决于源端写入量、网络和 Doris 目标端处理能力。
MySQL 到 Doris 是否需要先做全量迁移？
生产场景通常需要。全量迁移用于初始化历史数据，增量同步用于持续复制全量期间和后续产生的数据变化。
订单表应该选择 Doris 哪种模型？
订单表通常会发生状态、支付和退款信息更新，优先评估 Unique 模型。若由 NineData 自动创建，并且源表具有主键或唯一键，目标表通常会选择 Unique 模型，但上线前仍需检查实际建表结果和更新语义。
日志数据应该选择哪种模型？
日志通常是追加型数据，可以优先评估 Duplicate 模型。但如果日志存在更新、删除或去重需求，也需要重新评估目标模型。
NineData 是否需要编写大量脚本？
NineData 通过可视化复制任务管理数据源、同步对象、映射、结构复制、全量复制、增量复制、监控和数据对比，可以减少脚本拼装。但 Doris 表模型和数据仓库设计仍需要人工完成。
增量延迟为0秒是否代表数据完全一致？
不一定。延迟为0秒表示当前复制链路没有显示积压，不等于所有业务口径和分析结果已经验证通过。正式上线前仍需要进行数据对比和业务校验。