3、数据交换模式：批量交换、微批量交换、实时流交换的场景与选择
数据交换怎么做？说白了就三种路子：批量、微批量、实时流。
我见过不少团队，一上来就奔着实时去，觉得实时才高级。结果搞了三个月，延迟没降下来，数据还老对不齐。反过来，也有团队死守批量，业务方天天抱怨报表太滞后。
选哪种模式，不是拍脑袋的事。你得看业务容忍多久的延迟，数据量有多大，下游能不能扛住压力。今天我就把这三类模式的适用场景、技术选型和避坑点，掰开了讲清楚。
3.1 批量交换：稳，但慢
批量交换，就是按固定时间窗口（比如每小时、每天）把数据打包搬过去。这是最古老也最成熟的方式。
核心特征：定时触发、全量或增量抽取、数据落地后再处理。
什么时候选批量？
- 下游是BI报表、财务对账这类T+1场景
- 数据量极大（TB级），实时处理成本扛不住
- 源系统不支持流式读取（比如老旧的Oracle、SQL Server）
- 需要做复杂的数据清洗、聚合、回溯
我在项目中遇到过一家金融客户，每天凌晨跑批处理交易数据。一开始用Sqoop直抽，跑一次要4小时。后来换成Spark批量读取Parquet文件，压缩后走对象存储，时间压到了40分钟。嗯，这里要注意：批量不是慢的代名词，选对工具和格式，效率能差一个数量级。
我的习惯：批量交换尽量用列式存储（Parquet/ORC），配合分区裁剪和谓词下推。别用CSV或JSON，IO开销太大。
批量交换的典型架构：
源系统（MySQL/Oracle）
↓ 定时抽取（Sqoop/DataX/Spark）
暂存区（对象存储 / HDFS）
↓ ETL（Spark SQL / Hive）
数据湖（Delta Lake / Iceberg）
↓ 定时加载
目标系统（ClickHouse / Redshift）3.2 微批量交换：折中的艺术
微批量，说白了就是把批量的窗口缩小。比如每5分钟、每1分钟跑一次增量。它不是真正的实时，但延迟已经可以控制在分钟级。
为什么会有微批量？因为很多场景不需要毫秒级响应，但又受不了T+1的滞后。比如实时大屏、运营看板、推荐系统的特征更新。
核心特征：短周期调度、增量处理、状态管理、Exactly-Once语义。
什么时候选微批量？
- 延迟要求1-10分钟
- 数据量中等（GB~TB级/天）
- 需要处理乱序数据或迟到的数据
- 团队对流处理框架不熟悉，想降低运维复杂度
我个人习惯用 Spark Structured Streaming 做微批量。它本质上是把流当成小批量来算，但提供了Trigger机制，可以精确控制触发间隔。
// 微批量示例：每5分钟处理一次增量
spark
.readStream
.format("kafka")
.option("subscribe", "orders")
.load()
.writeStream
.format("delta")
.trigger(Trigger.ProcessingTime("5 minutes"))
.option("checkpointLocation", "/checkpoint/orders")
.start()我曾经踩过的坑：微批量的checkpoint目录千万别放在临时盘。有一次集群重启，checkpoint丢了，结果重复消费了整整两小时的数据。从那以后，我坚持把checkpoint放在S3或HDFS上。
微批量 vs 批量对比：
| 维度 | 批量 | 微批量 |
|---|---|---|
| 延迟 | 小时~天级 | 秒~分钟级 |
| 吞吐量 | 极高 | 高 |
| 状态管理 | 无状态 | 有状态（Watermark + State） |
| 乱序处理 | 弱 | 强（Watermark机制） |
| 运维复杂度 | 低 | 中 |
3.3 实时流交换：快，但贵
实时流交换，数据从产生到消费，延迟在毫秒到秒级。典型代表是Kafka + Flink，或者Kafka + Spark Streaming（连续处理模式）。
你想想看，什么场景需要实时？风控、交易监控、IoT设备告警、在线推荐。这些场景下，晚一秒可能就是损失。
核心特征：持续消费、低延迟、状态一致、容错机制。
什么时候选实时流？
- 延迟要求 < 1秒
- 数据是连续产生的流式数据（点击流、传感器、交易）
- 下游系统支持流式写入（如Kafka、Redis、Druid）
- 团队有流处理运维能力
我建议，除非业务明确要求秒级响应，否则别轻易上实时流。为什么？因为实时流的成本是批量的3-5倍。计算资源、网络带宽、运维人力，样样都得加码。
我的经验：实时流一定要做背压（Backpressure）处理。Flink的Checkpoint机制虽然成熟，但背压没配好，整个拓扑都会崩。我曾经见过一个Flink任务，背压打到100%，结果Kafka消费Lag从100涨到10万，花了半天才恢复。
实时流典型架构：
数据源（App / IoT / DB CDC）
↓ 实时采集（Kafka Connect / Debezium）
消息队列（Kafka / Pulsar）
↓ 流处理（Flink / Spark Streaming）
实时数仓（Druid / ClickHouse / HBase）
↓ 实时查询
应用层（风控 / 推荐 / 监控）3.4 三种模式的选择矩阵
说了这么多，到底怎么选？我整理了一个选择矩阵，你直接对着看就行。
| 业务场景 | 推荐模式 | 理由 |
|---|---|---|
| 财务对账、月报 | 批量 | T+1可接受，数据量大，需要全量校验 |
| 实时大屏、运营看板 | 微批量 | 分钟级延迟够用，成本可控 |
| 风控、交易反欺诈 | 实时流 | 毫秒级响应，错过一笔可能就出问题 |
| 推荐系统特征更新 | 微批量 | 特征时效性要求5-10分钟，微批量性价比最高 |
| IoT设备告警 | 实时流 | 设备状态变化快，延迟必须低 |
| 数据湖入湖（CDC） | 微批量 | CDC数据流用微批量写入Delta/Iceberg，兼顾时效和一致性 |
3.5 三种模式的核心逻辑图
下面这张图，把三种模式的数据流向和关键差异画出来了。你一看就明白。
3.6 混合模式：现实中的常态
说实话，真实项目里很少只用一种模式。大多数Lakehouse架构都是混合的。
比如我做过的一个电商数据平台：
- 订单交易走实时流，进风控系统
- 用户行为日志走微批量，每5分钟入湖，供推荐系统用
- 财务对账走批量，每天凌晨跑全量校验
三种模式共存，互不干扰。关键在于：数据分层要清晰，交换链路要解耦。实时层、近线层、离线层各司其职，别混在一起。
避坑指南：我曾经见过一个团队，把实时流和批量写进同一个Delta表。结果实时流频繁小文件写入，批量读取时性能暴跌。后来我建议他们分层：实时流写到一个独立的实时表，批量再合并到宽表。问题就解决了。
好了，三种模式的核心逻辑和选择方法，就讲到这里。你根据业务延迟、数据量、团队能力，对号入座就行。记住：没有最好的模式，只有最合适的模式。