"我们公司的订单数据到底要不要上实时同步？"
这是过去一年我被问得最多的问题。问的人有刚搭数仓的CTO，有被业务催得不行的数据工程师，也有被"实时"这个词吓到的项目经理。
答案不是哪个技术好，是你到底需要多快。
先把两种模式说清楚
批量ETL（T+1 或 分钟级轮询）
怎么跑的：定时任务触发——比如每天凌晨2点、或者每5分钟一次。源库跑一条SELECT，把数据拉到目标端。
适合的场景：
● 日/周报表（领导早上9点看昨天数据，凌晨2点跑完就行）
● 数据量稳定、不需要秒级响应的表（部门表、产品类目表、地区表）
● 离线数据分析（做月度复盘、季度对比、年度总结）
不适合的场景：
● 库存预警（等T+1报表出来，货早卖完了）
● 实时大屏（双十一盯着GMV看，延迟5分钟能被业务骂死）
● 风控规则（异常交易得秒级抓出来，第二天才看到等于没抓）
开源工具代表：Sqoop、DataX、Kettle定时调度模式、SeaTunnel批量模式
CDC实时同步（秒级，基于binlog日志解析）
怎么跑的：不是去源库SELECT查询，而是直接监听MySQL的binlog日志（或Oracle的LogMiner/redo log）。源库有一条INSERT/UPDATE/DELETE，CDC引擎立刻就感知到，实时推送到目标端。
适合的场景：
● 实时大屏（销售数据秒级刷新）
● 库存同步（ERP减库存，大屏立刻反映）
● 风控监控（异常交易触发即时告警）
● 主备容灾（数据库热备，故障秒级切换）
● 多系统数据联动（CRM新增客户 → 实时同步到ERP → 财务系统立刻建账号）
不适合的场景：
● 维表、字典表（三个月不改一次，CDC纯浪费资源）
● 数据分析跑批（本来就是T+1离线跑模型，根本不需要实时数据）
● 日均增量几百条的小表（实时没啥意义，批量全量跑也就几秒）
开源工具代表：Flink CDC、Canal+Kafka+Flink、Debezium+Kafka、SeaTunnel CDC模式
怎么选？看这三个指标
指标一：延迟容忍度
| 业务场景 | 能容忍的延迟 | 该选哪种 |
|---|---|---|
| 管理层日报、周报 | 24小时+ | 批量ETL |
| 每日运营监控 | 30分钟 | 批量ETL（高频调度） |
| 部门协作、数据打通 | 5-10分钟 | 批量ETL或准实时CDC |
| 实时大屏、双十一看板 | 1-5秒 | CDC实时 |
| 风控、告警、库存预警 | 毫秒-秒级 | CDC实时 |
判断一句话：如果"数据慢了"会直接造成业务损失（货卖超了、告警没触发、大屏断数了），上CDC。其他情况，批量完全够。
指标二：数据量级
| 单表数据量 | 日增量 | 推荐方案 |
|---|---|---|
| 百万级 | 几千条 | 批量，5分钟一次完全够 |
| 千万级 | 几万条 | 批量（高频）或CDC均可 |
| 亿级 | 几十万条+ | CDC实时，批量根本跑不动 |
| 十亿级 | 百万条+ | CDC，且必须考虑分布式 |
判断一句话：增量不大就别折腾实时。日增量几千条上Flink CDC + Kafka，属于"在厨房里开坦克"——不是不行，是没必要。
指标三：是否需要捕获DELETE
这是很多人忽略的关键点。Sqoop和DataX的批量模式，本质上是SELECT查询——源库删了一条记录，它根本感知不到。结果就是Hive里的数据永远比源库多。
| 需要同步DELETE？ | 推荐方案 |
|---|---|
| 不需要（数据只增不改） | 批量ETL足够 |
| UPDATE需要同步，DELETE不重要 | 批量（用时间戳增量更新）或者CDC |
| DELETE必须同步 | 只能选CDC |
判断一句话：如果Hive需要和源库"一模一样"（数据镜像），CDC是必选项，没有替代方案。
大部分公司其实是混合场景
真实情况不是"选CDC还是选批量"，而是"哪些表走CDC、哪些表走批量"。
一个典型的制造企业同步需求：
核心业务表（订单、库存、工单）：CDC实时同步 —— 延迟敏感、量级大、必须捕获DELETE
维表（产品类目、部门、地区）：T+1批量 —— 几乎不变，CDC纯浪费
日志表（操作日志、接口日志）：增量批量，每小时跑一次 —— 量极大但不需要实时
问题是，如果用开源组件拼，你的架构长这样：
实时链路：MySQL → Flink CDC → Flink → Hive（Flink集群运维中）
批量链路：MySQL → DataX → Hive（crontab+shell脚本中）
日志链路：MySQL → Sqoop → Hive（MR任务排队中）
三条链路，三个技术栈，三套监控，三种故障排查方式。
FineDataLink的双模式实测：同一个平台，两种引擎
FineDataLink把批量ETL和CDC实时做到了同一个平台里，但用的不是同一套引擎——批量走数据开发引擎，CDC走数据管道引擎，各自独立，互不干扰。
批量模式：配一个订单表T+1同步
1. 新建定时任务，拖入「数据同步」节点
2. 来源选MySQL，写SQL：SELECT * FROM orders WHERE update_time > '${last_run_time}'
3. 目标选Hive，字段自动映射，勾选"按日期分区写入"
4. 调度配置：每天凌晨3点执行，失败自动重跑3次
整个过程3分钟，没写一行代码。${last_run_time}是FineDataLink内置参数，自动记录上次执行时间，增量位点不用手动改。
性能数据（Oracle环境，同等配置下实测）：
| 数据量 | FineDataLink批量 | DataX |
|---|---|---|
| 100万 | 约5秒 | 约15秒 |
| 1000万 | 约25秒 | 约80秒 |
| 5000万 | 约90秒 | 约300+秒 |
快的主要原因：分布式执行引擎 vs DataX单机架构；写入Hive自动合并小文件。
CDC模式：配一个库存表实时同步
1. 新建数据管道任务
2. 来源选MySQL，选择"基于binlog日志解析"
3. 目标选Hive（需开启ACID事务表）
4. 设置脏数据阈值、失败重跑次数
5. 启动——第一次全量快照，之后自动切换增量binlog
关键特性：
● 不依赖外部Kafka：FineDataLink自研CDC引擎直接解析binlog，不需要中间消息队列
● DDL自动同步：源库加字段、删字段，Hive端自动跟随，不需要手动改表
● 断点续传：任务挂掉重启后从binlog断点继续，不丢不重
● 脏数据隔离：同步失败的记录单独存，校准后批量回写
混合部署：同一个运维面板
批量任务和CDC任务在同一个面板上管理——同一个告警通知渠道（钉钉/企微/飞书/邮件），同一套权限体系，同一个血缘分析页面。
不用像开源方案那样：批量任务在crontab里找、CDC任务在Flink Dashboard里盯、Kafka积压再开一个监控页面。
一个真实的混合场景案例
安特威（工业阀门制造商）用FineDataLink做的方案：
● MES、ERP、SQS、APS、PLM等系统，通过CDC实时同步到数据仓库，目标库数据10秒内跟随变化
● 维表和配置表走批量定时同步
● 目标库数据10秒内即可跟随变化
以前用开源工具拼的时候，各系统之间的同步任务散落在不同服务器上，运维人员要逐个登录排查。统一到FineDataLink后，全在一个面板上管理。
选型决策表：直接照着选
| 你的情况 | 推荐方案 |
|---|---|
| 只做日报/周报，延迟一天完全OK | 批量ETL，凌晨定时跑 |
| 每天早会要看昨天的运营数据，10分钟延迟可接受 | 批量ETL，高频调度（每5-10分钟一次） |
| 核心业务表需要实时，维表可以T+1 | CDC + 批量混合 |
| 必须同步DELETE，数仓要和源库一模一样 | CDC，没得选 |
| 日均增量几千条，表总量百万级 | 批量ETL，不要折腾CDC |
| 日均增量百万级以上，且需要秒级响应 | CDC实时，批量方案跑不完 |
| 老系统跑着Sqoop/DataX，不想动但需要实时能力 | 保留批量任务不动，核心表单独加CDC管道 |
| 公司已经在用FineReport/FineBI | FineDataLink混合部署，源端到报表全链路打通 |
几个容易踩的坑
1. Hive普通外部表只支持追加，CDC的UPDATE/DELETE必须用ACID事务表（ORC格式）。 很多人配置对了CDC链路，但Hive表建成了普通外部表，UPDATE全部变成重复行。
2. 实时写入Hive会产生大量小文件。 不管用Flink CDC还是FineDataLink CDC，都要配置小文件合并策略。FineDataLink内置了自动合并，Flink需要在Hive Sink里手动配。
3. CDC一定要用MySQL从库。 解析binlog对主库有额外IO开销，高并发下会影响业务。
4. 批量同步用时间戳做增量，注意处理时区。 源库UTC、目标库北京时间，时间戳差了8小时——这种数据不一致排查起来极其痛苦。FineDataLink会自动校准时区。
