4、数据摄入成本：实时采集与批量导入的差异
数据摄入，说白了就是数据怎么进到你的数仓或数据湖里。这一步看似简单，但成本差异能大到让你怀疑人生。我见过不少团队，前期调研时只盯着计算引擎优化，结果上线后发现钱全烧在数据摄入上了。
今天咱们就掰开揉碎，聊聊实时采集（CDC、Logstash）和批量导入（Sqoop、DataX）到底差在哪。嗯，这里要注意，我说的成本不只是服务器账单，还包括运维心力、数据延迟带来的业务损失。
4.1 两种摄入模式的核心差异
先看一张图，帮你快速建立整体认知。
从图上能直观看到，实时采集的成本几乎是批量导入的 3-5 倍。但别急着下结论——有些场景你不得不用实时，有些场景用批量就是浪费钱。
4.2 实时采集：CDC 与 Logstash 的成本拆解
4.2.1 计算资源：7×24 的隐形账单
实时采集最坑的地方，就是它必须一直跑着。你想想看，一个 CDC 任务，不管是 Debezium 还是 Canal，都得常驻一个进程监听 Binlog。哪怕凌晨三点没数据，机器也得开着。
我在项目中遇到过最夸张的情况：某团队部署了 12 路 CDC 任务，每路 4C8G 规格，一个月光计算资源就烧掉 6 万多。后来一查，其中 3 路源表每天只有几百条变更，完全可以用批量替代。
关键成本因子：
- 常驻进程：每路至少 4C8G，云上约 2000-4000 元/月
- 连接数开销：CDC 需要保持长连接，数据库侧也要预留资源
- 日志解析：Binlog 解析本身消耗 CPU，表结构越复杂开销越大
4.2.2 存储开销：Binlog 的长期滞留
Logstash 和 CDC 都会产生中间状态数据。比如 Debezium 的 offset 文件、Logstash 的持久化队列。这些文件看似不大，但日积月累也很可观。
更隐蔽的成本是源库的 Binlog 保留时间。为了支持断点续传，很多团队把 Binlog 保留 7 天甚至更长。我一个朋友的公司，就因为 Binlog 保留太久，把 MySQL 实例的磁盘撑爆了，最后花了半天恢复数据。
避坑指南：我曾经吃过这个亏——CDC 任务挂了 3 天没发现，恢复时 Binlog 已经过期，只能全量重导。后来我强制要求：Binlog 保留时间 = 任务最大容忍延迟 × 2，且必须配置监控告警。
4.2.3 网络带宽：小流量但持续
实时采集的带宽消耗不大，但胜在持续。每条变更记录可能只有几百字节，但一天下来累积的流量也不小。更麻烦的是，业务高峰期（比如双十一）流量会突然暴涨，带宽规划很难做。
我个人习惯的做法是：给 CDC 任务单独划一个带宽池，并设置限流。别让它跟业务流量抢带宽，否则两边都受影响。
4.3 批量导入：Sqoop 与 DataX 的成本优势
4.3.1 计算资源：用完即走
批量导入最大的好处，就是资源可以按需分配。Sqoop 跑在 YARN 上，DataX 跑在独立容器里，任务结束资源就释放。你想想看，如果每天只跑一次全量同步，那机器只需要开机 1-2 小时，剩下 22 小时都是省下来的钱。
我建议的做法是：把批量任务调度到低峰期，比如凌晨 2-4 点。这时候云上资源价格最低，还能避开业务高峰。
成本优化技巧：DataX 支持限速和分片，你可以把一个大表拆成 10 个分片并行跑。这样既能控制资源峰值，又能缩短同步时间。我一般把单机并发数控制在 4-8 之间，再高反而会因为 IO 争抢导致性能下降。
4.3.2 存储开销：临时文件可清理
批量导入的中间文件通常是临时的。Sqoop 会生成 MapReduce 中间结果，DataX 会有 channel buffer。这些文件在任务结束后就可以清理，不会长期占用存储。
但要注意一点：如果批量导入失败，临时文件可能残留。我习惯在任务脚本里加一个清理步骤，不管成功失败都执行。
4.3.3 网络带宽：短时高吞吐
批量导入的带宽消耗是脉冲式的。比如你每天同步 100GB 数据，如果限定 1 小时内完成，那带宽峰值就是 100GB/h ≈ 230Mbps。这个峰值对网络设备是个考验。
我建议的做法是：把大表拆成多个小批次，拉长同步窗口。比如 100GB 数据分 4 小时同步，带宽峰值降到 60Mbps 左右，对网络的压力小很多。
4.4 核心成本对比表
| 成本维度 | 实时采集（CDC/Logstash） | 批量导入（Sqoop/DataX） |
|---|---|---|
| 计算资源 | 常驻 4C8G，约 3000 元/月 | 按需调度，约 800 元/月 |
| 存储开销 | Binlog 保留 + offset 文件，约 500 元/月 | 临时文件可清理，约 100 元/月 |
| 网络带宽 | 持续小流量，约 200 元/月 | 短时高吞吐，约 300 元/月 |
| 运维成本 | 高：断流恢复、位点管理、数据校验 | 低：失败重跑、断点续传 |
| 数据延迟 | 秒级到分钟级 | T+1 或小时级 |
| 适用场景 | 实时风控、在线推荐、监控告警 | 离线报表、数据仓库、历史归档 |
4.5 选型建议：什么时候该用什么？
说了这么多，到底怎么选？我总结了几条经验：
- 数据延迟要求 < 5 分钟：必须上实时采集，没得选。比如实时风控、在线推荐。
- 数据延迟可以接受 T+1：优先用批量导入。省钱又省心。
- 数据量 < 10GB/天：批量导入足够，别折腾 CDC。
- 数据量 > 100GB/天：建议实时 + 批量混合。实时采集增量，批量做全量校验。
- 源库是 MySQL 且表结构频繁变更：慎用 CDC。DDL 变更可能导致解析失败，我踩过这个坑。
我的个人建议：别一上来就全量上实时。先评估业务对延迟的真实容忍度，很多时候「分钟级」就够了，没必要追求「秒级」。省下来的钱，够你买好几台机器做其他事了。
4.6 混合架构：鱼与熊掌兼得
其实，很多大厂的做法是混合架构。比如：
- 用 CDC 采集核心业务表的增量变更，延迟控制在 1 分钟以内
- 用 DataX 每天凌晨批量同步全量数据，做数据对账和补全
- 两套数据在目标端做合并，保证最终一致性
这样做的好处是：既满足了实时需求，又控制了成本。我参与过的一个金融项目，就是用这种方案把月摄入成本从 12 万降到了 4 万，而且数据延迟只增加了 30 秒。
落地技巧：混合架构的关键是数据对账。我习惯每天跑一次全量校验，对比实时链路和批量链路的数据差异。如果发现不一致，以批量链路为准进行修复。
好了，数据摄入的成本差异就聊到这。记住一句话：实时采集是奢侈品，批量导入是日用品。按需选择，别盲目追求技术上的「高级感」。