批处理与流处理：两种数据处理范式的原理与分野
在湖仓一体架构中，“批流融合”并非一种模糊的技术口号，而是建立在对批处理（Batch Processing）与流处理（Stream Processing）两种范式深刻理解之上的工程实践。要真正掌握融合设计，首先必须厘清二者在时间模型、数据触发方式、计算语义以及结果一致性上的本质差异。本节将从原理出发，剖析两种范式的核心机制，并通过对比与案例帮助您建立清晰的判断框架。
核心原理：从“有限数据集”到“无限数据流”
批处理与流处理的分野，首先源于它们对“数据”这一对象的哲学假设不同。
- 批处理（Batch）：面向有界数据集（Bounded Data）。数据在计算开始前已完整存在，处理过程是一次性的、确定性的扫描。其核心模型是“分而治之”——将大任务切分为小任务并行执行，最终合并结果。典型代表如 MapReduce、Spark Core（RDD 模式）、Hive 离线任务。
- 流处理（Stream）：面向无界数据流（Unbounded Data）。数据持续产生，永无止境。其核心模型是“持续查询（Continuous Query）”——数据到达即被处理，结果不断更新。典型代表如 Flink、Kafka Streams、Spark Structured Streaming（微批模式）。
下图直观展示了两种范式在数据到达、处理窗口与结果产出上的核心差异：
关键区别：时间、触发与一致性
两种范式的差异并非仅体现在“快与慢”上，而是涉及数据处理模型的多个维度。下表从工程决策最关心的角度进行了对比：
| 对比维度 | 批处理 | 流处理 |
|---|---|---|
| 数据视图 | 有界、静态、完整 | 无界、动态、持续 |
| 触发机制 | 手动调度 / 定时触发（如每日凌晨） | 数据到达即触发（事件驱动） |
| 时间模型 | 处理时间（Process Time），与事件时间无关 | 支持事件时间（Event Time）与水位线（Watermark） |
| 计算语义 | Exactly-Once（天然幂等，可重放） | At-Least-Once / Exactly-Once（需借助检查点机制） |
| 延迟 | 分钟 ~ 小时级 | 毫秒 ~ 秒级 |
| 吞吐量 | 极高（适合海量历史数据全量扫描） | 较高（受窗口与状态大小影响） |
| 结果精度 | 精确、完整、可重复 | 近似（受窗口边界与迟到数据影响） |
核心洞察：批处理追求的是“最终精确”，流处理追求的是“持续近似”。在湖仓一体架构中，我们往往需要利用批处理的结果来校准流处理的近似值，这正是“批流融合”的底层逻辑之一。
方法流程：如何为业务选择范式
在实际架构设计中，并不存在“非此即彼”的二元选择。一个成熟的湖仓系统通常需要根据业务对延迟和精度的要求，将数据路径划分为不同的处理管道。以下是一个典型的方法流程：
- 识别业务需求的时间敏感度：判断该指标是用于实时监控（如秒级风控），还是用于事后分析（如月度经营报表）。
- 评估数据量级与事件模式：数据是突发性批量到达，还是持续平稳产生？是否存在明显的峰值？
- 确定容错与一致性要求：金融交易要求 Exactly-Once，而用户行为分析可容忍少量重复。
- 设计双轨或融合管道：对于需要同时满足实时与精确的场景，可采用“流处理先行 + 批处理校准”的 Lambda 架构，或采用“流批一体”的 Kappa 架构（如 Flink 统一处理）。
案例与场景：从实际业务看范式选择
以某电商平台的“实时大屏”与“财务对账”两个场景为例，可以清晰地看到两种范式的适用边界：
- 场景一：实时大屏（流处理）——需要展示当前秒级的 GMV、订单量、活跃用户数。数据以 Kafka 事件流形式持续进入，Flink 使用 5 秒滚动窗口聚合，结果直接推送到前端。即使因网络抖动丢失 1~2 条数据，对趋势展示无实质影响。
- 场景二：财务对账（批处理）——每日凌晨，系统从 Hive 中读取前一日全量订单流水与支付流水，进行精确的关联比对，生成对账差异报表。该过程必须保证数据完整、结果可复现，任何一条记录都不能遗漏。
在湖仓一体架构中，这两个场景可以共享同一份存储在数据湖中的原始数据（如 Iceberg 表），但通过不同的计算引擎（Flink 与 Spark）分别处理，最终结果再写回湖中不同的结果表。这种设计既保证了实时性，又确保了财务数据的准确性。
误区与复盘：避免“流批割裂”的常见陷阱
误区一：认为流处理可以完全替代批处理。流处理的状态管理成本高，且对于需要全量历史数据参与的复杂计算（如跨年同比分析），流处理并不擅长。正确的做法是让流处理聚焦于近期窗口，而批处理负责全量扫描。
误区二：忽视事件时间与处理时间的差异。在流处理中，如果直接使用处理时间进行窗口划分，当数据延迟到达时会产生错误结果。必须引入事件时间与水印机制，并设计好迟到数据的处理策略（如侧输出流）。
复盘建议：在设计批流融合管道时，建议先为每个数据流定义清晰的 SLA（服务等级协议）——包括最大延迟、数据完整性百分比、故障恢复时间。这能帮助团队在架构评审时快速判断某个计算任务应该放在流处理侧还是批处理侧，避免凭直觉做技术选型。