一个统计当天销售额的程序，得先回答一个问题：今天的订单到底来齐了没有？如果数据老老实实躺在文件里，这事儿很简单——文件有结尾。可要是数据像水管一样不停往外流，永远没有“收工”的节点，事情就变得微妙。怎么处理这个没齐的“齐”，正是批处理和流处理分道扬镳的地方。

批处理：先攒够，再动手
它把“完整性”当硬指标。等到一个天然边界（打烊时间、文件关闭、窗口截止），才一次性扔进计算引擎。就像月底结账，少一张小票都不行。这条路上的策略包括：全量加载，每次搬空所有数据重算；增量加载，只搬变化的部分；大窗口聚合，把数小时甚至数天的数据揉成一团算总账。微批处理则夹在中间，既想保完整又想赶时间，把流切成小碎块，模仿批的姿态。

打开网易新闻 查看精彩图片

流处理：边收边算，错了再改
它用“速度”去冲击完整性。数据还在一笔笔涌进来，答案就得持续往外蹦。所以它必须估算“应该已经到齐了”的时刻，并且随时准备翻案——当估错时，把迟到的数据补进回溯。这条路上满是应对不确定性的发明：滚动窗口，按固定间隔切分，一刀刀毫无重叠；滑动窗口，每次移动一小步，窗口之间大面积重合，像一场不停擦掉重写的计算；会话窗口，靠活动间隙来判断一段对话是否结束，更贴近用户行为。

迟到的数据怎么收拾？
核心凶器是水位线和延迟数据处理。系统设定一个阈值，声称“这个时间点之前的数据理论上都到了”，迟到的一律标记、侧路处理或直接更新旧结果。Lambda架构则干脆维护两套引擎：批处理层定期产出精确视图，流处理层用近似结果填补新鲜度，用冗余换正确性。Kappa架构更激进，把所有数据都当流，用同一个流引擎复刻历史重算，靠去重和幂等来达成那个总被误读的目标——精确一次处理。

最终，选边站其实就是回答一个老问题：你更怕算错，还是更怕算慢？这组偏好在具体的数据管道里，变成对窗口策略、架构、容错机制的成本投票。