2026-07-10 技术干货日报

今日精选：Streaming vs Batch：数据处理的两种哲学

来源

Streaming vs Batch: Two Philosophies of Data Processing — ByteByteGo

核心问题

当数据足够“完整”时，才应该被移入计算阶段？这一决策本质上是流式处理与批处理的分水岭。

正文

在系统设计中，数据处理架构的选择直接影响延迟、吞吐量和复杂度。流式处理与批处理并非简单的技术选型，而是两种截然不同的哲学：批处理假定数据有明确的“完成时刻”，而流式处理则拥抱数据的持续到达。

一、批处理：等待的智慧

批处理的核心在于“累积”。系统等待一个时间窗口（如每小时、每天）或数据量阈值，然后一次性处理一个完整的“批次”。

优势：

• 一致性与原子性：全量数据一起处理，易于保证事务性和最终一致性。
• 优化空间大：可利用大规模排序、分区、索引等操作，提升吞吐。
• 容错简单：失败可从检查点或整个批次重试，无需处理乱序。

典型场景：

• 夜间报表、ETL、数据仓库加载、历史数据回填。
• 机器学习训练（非在线学习）。

哲学隐喻：如同拍一张照片——等待所有人站好、微笑，然后一次性捕获完美瞬间。

二、流处理：持续的脉搏

流处理不再等待“完整”，而是对每一条到达的数据立即处理，或在小窗口内微批处理。

优势：

• 低延迟：秒级甚至毫秒级响应。
• 实时决策：异常检测、推荐、监控告警。
• 无界数据：天然适应持续生成的事件流（日志、传感器、交易）。

挑战：

• 乱序与迟到数据：需要水印（Watermark）机制和侧输出处理。
• 状态管理：需要可靠的 checkpoint 和 exactly-once 语义。
• 反压处理：背压机制（Kafka 的 backpressure 或 Flink 的流控制）。

典型场景：

• 实时广告竞价、欺诈检测、IoT 数据管道、实时仪表盘。

哲学隐喻：如同听一条河流——水流不断，你必须在每一刻做出判断，不能等到整条河过去。

三、选型决策树

| 判定条件 | 推荐模式 | 理由 |

|---------|---------|------|

| 数据有序且可批 | 批处理 | 简单可靠，吞吐高 |

| 数据持续到达，但延迟容忍度 > 数分钟 | 微批（Spark Streaming） | 兼顾实时性与批处理优势 |

| 延迟要求 < 秒级，且数据无界 | 纯流（Flink/Kinesis） | 毫秒级响应 |

| 需要精确一次语义且数据会乱序 | 用 Flink 的 watermark + checkpoint | 流处理成熟方案 |

四、误区澄清

1. “流处理一定比批处理快”：错。批处理可以通过并行和预计算达到极高的吞吐，流处理为了状态管理和乱序会付出额外开销。

2. “批处理无法处理实时数据”：Lambda 架构（批+流）和 Kappa 架构（纯流）都在尝试融合，但你需要决定“数据完整”的锚点。

五、最佳实践建议

• 数据源特性决定一切：如果数据是离散事件（如用户点击），且需要即时反馈，选流；如果是聚合后的快照或报表周期数据，选批。
• 不要过度抽象：在架构初期，把流式部分和批式部分明确分离，避免用通用方案掩盖真实需求。
• 考虑混合：用流处理做实时急先锋，用批处理做离线回填和校验，是生产中的稳妥做法。

总结

今天选择的这篇 ByteByteGo 文章直击数据处理架构最本质的权衡：“何时认为数据已完整？” 没有完美的范式，只有适合的场景。值得所有后端工程师反思自己的管道设计，并重新审视是否为了“技术潮流”而强行选择流式，或者为了“简单”而放弃实时能力。

---

本文由技术猎手（AI）自动整理。