流批一体架构核心思想

可视化演示

流批一体概述

一茶二室的楼下备料间里，店员等着打烊后把所有小票一次性算清：今天珍珠用了多少、茶底煮了几锅，数据是“收齐了才算”；楼上现制台则是来一单做一杯，永远不知道下一个顾客点什么，数据是“源源不断”的。店长小林发现，两种活法本质都是“把订单变成奶茶”，只是数据的“边界”不同。

大数据里的批处理，就是楼下备料间的逻辑：把一段时间内收齐的数据一次性算完，有头有尾；流处理则是楼上现制台的逻辑：数据像河水一样不断涌来，来一条处理一条，没有尽头。过去很多公司为了兼顾两者，架了两套系统——离线用 Spark，实时用 Flink，同一指标要写两遍代码，像两本菜谱分别管两个厨房，口径还经常对不上。

流批一体的核心思想，正是小林的那本“统一菜谱”：一套 API、一套引擎，通过切换执行模式同时支持批和流。在它看来，批不过是“有界的流”——水流到了终点，把终点前的所有事件一起算完而已。

小林把那两个厨房合并后，店员们终于不用再记两套流程；同样，企业把两套引擎收编成一套后，维护成本直线下降，指标口径也第一次真正统一了。不过，光有理念还不够，要让一个厨房兼容两种火候，靠的是那本写满基础操作的“统一菜谱”——DataStream API。

DataStream统一API

林记的菜谱上写满了基础操作：“加珍珠”“去冰”“换大杯”“按口味分组”。不管是楼下大批量备料，还是楼上现做单杯，店员都是照着同一套操作来组合，只是执行节奏不同。DataStream 之于 Flink，就是这本菜谱。

DataStream 统一 API 的意思是：无论是实时流还是离线批，你都用同一组算子来编写代码——map 做转换、filter 做过滤、keyBy 做分组、window 开窗口、aggregate 做聚合、sink 写出结果。批处理不再需要另一套“Spark 方言”，因为批数据在 API 眼里只是“有界的流”：给同一个任务切到 BATCH 执行模式，引擎就按有界输入做整体调度；切回 STREAMING 模式，就恢复逐条消费、增量计算。

这套设计让“算子一致性”成为天然属性：同一个窗口聚合函数，在流模式下按水位线增量触发，在批模式下按输入边界整体切分，代码一字不改。

有了这本统一菜谱，店长终于不用再教两批店员。但小林很快发现一个新问题：统计“3 点钟卖了多少杯”时，楼下按小票时间算，楼上按接单时间算，两边数字又打架了——问题的根源，藏在“时间”这个看似简单的词里。

时间语义

顾客小票上印着“14:32“，这是她实际点单的时刻；厨房忙碌时，店员可能 14:38 才看到这张小票开始制作。小林把这两个时间分别记了下来：前者叫”事件时间“，后者叫”处理时间”。统计 14:30 那一档的销量，到底该信哪个？

在流处理中，“事件时间”是业务实际发生那一刻的时间，它永远不会变，就像小票上的印字；“处理时间”是数据进入引擎、被算子处理的时刻，像店员拿到小票开始做奶茶的时刻，受机器负载、网络延迟影响，充满不确定性；还有第三种“注入时间”，是数据进入系统时被统一打上的时间戳，介于两者之间。

如果按处理时间统计，一台机器卡顿 5 分钟，“3 点档”的数据就可能被记到“3 点 05 分档”；只有事件时间才能还原业务真相。所以流批一体里，事件时间才是默认的“裁判”，而它必须给出一个数学承诺：

选定事件时间后，小林面临下一个难题：网络会让订单乱序到达——3 号桌的小票可能 4 号桌之后才送到柜台。他需要一把“等多久才算齐”的尺子，这就是水位线。

水位线机制

店长小林定了一条规矩：统计 3:00 的订单时，只等到 3:05，误差 5 分钟内的迟到小票都算数，超过 5 分钟就不再等了。这 5 分钟就是“耐心阈值”δ；"3:05"这个时刻，就是店长心中的水位线——它宣告：所有事件时间不晚于 3:00 的订单，此刻应该基本到齐了。

水位线（Watermark）正是这样一把“数据到齐”的尺子：它由已到达事件的最大事件时间减去容忍阈值 δ 得到。水位线越往前推，引擎就越有底气触发窗口：当水位线推进到某个窗口的结束时刻时，这个窗口就“封盘开奖”——像店长宣布“3:00 的账可以算了”。

如果数据提前到达或乱序到达，水位线负责兜底：窗口触发前到达的旧数据正常计入；触发后、水位线允许范围内仍会再等一等（allowedLateness）；迟得太离谱的数据则走旁路输出（side output）进“待复核筐”，绝不让它污染已发出的结果。

水位线让“何时算齐”有了数学依据，但窗口结果要如何高效地更新？小林发现，光有静态账本不够——他需要一块会自己跳数字的“看板”。

动态表机制

林记前台挂着一块“实时爆款排行看板”，每卖出一杯，看板上对应口味的计数就 +1。小林从不让人每分钟重算整块板，而是“来一条改一次”；打烊后，他又用全天小票重算一遍整块板做对账。同样一块看板，白天增量更新，晚上全量重算——这就是动态表的流与批两面。

动态表（Dynamic Table）是把无限数据流映射成一张“一直在变”的表：每条流入数据都触发一次行级更新，就像每杯奶茶让看板 +1。在这张表上执行的 SQL 叫“连续查询”：它不是跑一次就结束，而是随着新数据的到来持续输出新结果——白天那套增量更新逻辑。

引擎能做到“来一条改一次”，靠的是查询重写：把用户写的 SQL 自动改写成增量算子，只计算“新来的数据影响了哪些旧结果”，再维护一份状态把它们累积起来。最后，查询结果表每变一次就吐出一条变更流，重新变成下游可消费的数据流。

看板之所以能自己跳数字，是因为它背后有人把每一次“新增一杯”“改大杯”“退单”都记成了变更日志——这，就是 Changelog 机制。

Changelog机制

一位顾客点了中杯奶茶，两分钟后改口要大杯。小林不会让店员“再做一杯新的”然后不管旧杯，而是记一条变更：撤掉中杯、加上大杯；若顾客退单，就记一条删除。厨房里永远只有一杯正在制作的奶茶，但账本上清清楚楚躺着变更记录。

Changelog（变更日志）机制正是这套账本：它把动态表的每一次变化记录成三类操作——插入（+I）、更新（-U 删旧行、+U 加新行）、删除（-D）。下游不需要重新读整张表，只要顺着变更日志一条条“重放”，就能重建出任何时刻的结果表。

这带来一个强大的能力：增量物化。最终结果不再是“每来一条数据就全量重算”，而是“初始快照 + 不断追加的增量变更”。配合 Flink 的检查点机制，变更日志还能保证一致性——系统崩溃后从头重放日志，账本分毫不差，就像录像带可以倒带重播。

账本清楚了，小林终于可以回答最本质的问题：既然批和流都能用同一套工具搞定，那过去为什么要养两个厨房？答案写在一段狼狈的演进史里。

实时数仓演进

最早，林记是标准的“双厨房”：楼下备料间按天出“全天报表”，楼上现制台按秒出“实时数字”，两本账经常对不上，店长每天要花大量时间“对账”；后来改成“全流水线现制”，所有数据都走流式管道，但重算历史时效率太低；直到统一菜谱出现，才真正做到一个厨房两种火候。

这套演进对应着实时数仓的三代架构。第一代叫 Lambda 架构：离线批链路算全量数据，实时流链路算增量数据，最后合并出结果——但两条链路两套代码，结果冲突时要靠“对账”解决，代价高昂。第二代叫 Kappa 架构：干脆让所有数据都以流的方式处理，需要历史就从头回放消息队列——代码只有一套了，但回放重算既慢又费资源。

流批一体是第三代：在一套引擎里，流模式负责实时增量，批模式负责历史上卷，两种执行模式共享同一套 API 与算子。批不再是“另一个系统”，而是“流引擎的一种特殊执行模式”。这正是它相对 Lambda 和 Kappa 的最优解：一套代码、两种模式、一个口径。

小林终于关掉了那间备料间。如今，一茶二室用一本菜谱管住了两种节奏：批量备料是“把流暂停后整体算”，现制单杯是“边来边算”。而大数据世界里的流批一体，也在实时数仓的舞台上扮演着同样的角色。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""流批一体最小演示：一套窗口求和逻辑，流式与批式两种执行模式复用"""  def window_sum(events, start, end):    """同一套窗口计算逻辑：流模式增量跑、批模式整体跑都调用它"""    return sum(v for t, v in events if start <= t < end)  class UnifiedPipeline:    """同一份代码，两种执行模式"""     def __init__(self, events, mode="streaming", max_delay=1.0):        self.events = events          # 按到达顺序排列的事件        self.mode = mode              # streaming / batch        self.max_delay = max_delay    # 水位线容忍的最大迟到量        self._count = 0               # 触发窗口次数     def run(self, win_size=5):        if self.mode == "batch":            ordered = sorted(self.events, key=lambda e: e[0])            max_t = max(t for t, _ in ordered)            boundary = win_size            while boundary <= max_t + win_size:                self._emit(ordered, boundary - win_size, boundary, "batch")                boundary += win_size        else:            self._stream_run(win_size)        return self._count     def _emit(self, seq, start, end, label):        total = window_sum(seq, start, end)        print("%s: 窗口[%d, %d) total=%d" % (label, start, end, total))        self._count += 1     def _stream_run(self, win_size):        watermark = 0.0        boundary = win_size        arrived = []        for t, v in self.events:            arrived.append((t, v))            watermark = max(watermark, t - self.max_delay)            if watermark >= boundary:                self._emit(arrived, boundary - win_size, boundary, "stream")                boundary += win_size  if __name__ == "__main__":    # 事件(3,7)最后才到，属于迟到的乱序数据    orders = [(1, 8), (2, 5), (5, 3), (4, 9), (6, 6), (8, 2), (7, 4), (3, 7)]    print("== 流模式：水位线推进、窗口增量触发 ==")    UnifiedPipeline(orders, "streaming").run(5)    print("== 批模式：同样一套窗口求和逻辑整体切窗 ==")    UnifiedPipeline(orders, "batch").run(5)

1. def window_sum(events, start, end):这就是“统一菜谱”里的那道基础菜：窗口求和，流批两种模式都调用它。
2. return sum(v for t, v in events if start <= t < end)只统计落在 [start, end) 窗口内的事件，边界规则清晰。
3. ordered = sorted(self.events, key=lambda e: e[0])批模式的“打烊整理”：先按事件时间排好序，再整体切窗。
4. watermark = max(watermark, t - self.max_delay)流模式每来一条数据就前推一次水位线，容忍 max_delay 的迟到。
5. if watermark >= boundary:水位线越过窗口边界才触发计算，像店长确认“账可以算了”才动手。
6. self._emit(arrived, boundary - win_size, boundary, "stream")增量触发时复用的是同一份 window_sum，体现“API 统一”。
7. UnifiedPipeline(orders, "streaming").run(5)同一个类只改一个参数就能切换执行模式，正是流批一体的精髓。

常见误区

面试题