对 "Streaming vs. Batch" 二分法的质疑：我认为这会产生误导

“Streaming vs. Batch” Is a Wrong Dichotomy, and I Think It's Confusing

Source | HN Comments

文章质疑了将数据处理方式简单划分为 "Streaming vs. Batch" 的二分法。作者认为，许多 streaming 系统也会采用 batching 技术以提升性能。真正的关键在于 "Pull vs. Push" 语义，即系统是主动获取数据还是被动接收数据。作者强调 streaming 提供了数据的实时视图，尽管复杂性更高，但其优势明显。最后，作者指出这两种方法并非对立，而是互补的，并鼓励读者尝试 streaming，体验其带来的价值。

Gunnar Morling

关于软件工程的随想

对 "Streaming vs. Batch" 二分法的质疑：我认为这会产生误导

发表于 2025 年 5 月 14 日

通常，人们讨论 "Stream vs. Batch" 时，好像只能选择其中一个，但对我来说，这实际上没有太多意义。

许多 streaming 系统也会应用 batching，即一次处理或传输多个记录（一个 "batch"），从而抵消连接开销，分摊将工作分发到多个线程的成本，并为高效的 SIMD 处理打开大门，所有这些都是为了确保高性能。数据 streaming 和处理架构中 storage/compute 分离的普遍趋势（例如，考虑像 WarpStream 这样的平台，以及 Diskless Kafka）进一步加速了这一发展。

通常，这对用户来说是透明的，以一种机会主义的方式完成：处理自上次 batch 以来到达缓冲区中的所有这些记录（直到某个限制）。这构成了一个非常好的自调节系统。记录的高到达率：更大的 batch，提高吞吐量。低到达率：更小的 batch，甚至可能只有一个记录，确保低延迟。像 Apache Arrow 这样的 Columnar in-memory 数据格式对于实现这样的设计非常有帮助。

相反，在我看来，"Stream vs. Batch" 讨论实际上应该关注的是 "Pull vs. Push" 语义：系统是否会以固定的间隔查询其来源以获取新记录，还是新记录会尽快推送到系统？现在，无论你 pull 的频率有多高，你都无法将基于 pull 的解决方案转换为 streaming 的解决方案。除非来源本身代表可消费的变更流（你明白我的意思），否则 pull 系统可能会错过在获取尝试之间发生的更新以及删除。

这就是 streaming 如此有趣和强大的原因：它为你提供数据的完整实时视图。 streaming 系统使你可以将数据放入需要的_位置_，以需要的_格式_和需要的_形状_（考虑反规范化），并在数据生成或更新后立即执行。这样做的代价是潜在的更高复杂性，例如在推理 streaming joins（及其状态）或处理乱序数据时。但是 streaming 社区正在不断努力改进这方面，例如通过分离的状态后端、事务性流处理等等。我对目前在这个领域发生的所有创新感到非常兴奋。

现在，你可能想知道：“我真的需要 streaming (push) 吗？我对 batch (pull) 感到满意。”

这是一个常见且合理的问题。以我的经验，最好通过自己尝试来回答。我一次又一次地看到，最初持怀疑态度的人们，一旦他们看到 real-time streaming 的实际效果，就很快想要为越来越多的用例（如果不是全部）获得它。如果你已经体验过数据仓库中一两秒钟的数据新鲜度，你就不想再错过这种魔力了。

综上所述，实际上不仅仅是 pull 或 push 那么简单——这些方法是互补的。例如，回填通常通过 batching（即查询）在原本基于 streaming 的系统中完成。此外，如果你想要 streaming 的完整性，但不需要超低延迟，你可以决定在数据量较低时暂停 streaming pipelines（从而节省成本），并在有新数据要处理时恢复，然后再次停止。

Batch streaming，如果你愿意这么称呼它的话。