流批一体架构：实时数仓分层设计

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

流批一体：统一引擎的前世今生

中央厨房出现之前，传统餐厅只有两种备菜方式：一种是“大锅提前炖”,把一天的菜量提前做好放着，客人来了一盛就行，量大但口味不新鲜——这是离线批处理；另一种是“单锅现炒”,客人点了才开火，新鲜但灶台压力巨大——这是实时流处理。传统数仓只能二选一，批处理链路跑离线报表，流处理链路算实时指标，两套系统代码不通，统计口径经常对不上。

Lambda架构干脆用两套系统并行：批处理链路算离线结果，流处理链路算实时结果，最后合并。但维护两套代码意味着同样的业务逻辑要写两遍，就像厨房里备菜区和炒菜区各用各的菜谱，口味容易跑偏。Kappa架构提出，只要流引擎能力足够强，就只保留一条流式链路，离线结果只是流处理结果在一段时间后的重放。

流批一体架构正是Kappa的工程化落地。Flink用一套引擎同时支撑批和流：批处理本质是“有界流”,流处理是“无界流”,两者共享同一个执行引擎、同一套状态管理、同一份代码逻辑。你写一遍ETL逻辑，既能按分钟级延迟跑实时指标，也能按小时级批跑全量回溯，数据口径天然一致。选型时，业务对时效要求高选实时链路，对追溯要求高则重放批链路，这就是“实时与准实时”的灵活切换。

中央厨房里，食材从后门到出餐口要经过收货、清洗、配菜、炒制四站。想客人少等，不能只盯着炒锅，传送带上任何一站的堵塞都会让出餐变慢。流批一体就是“用同一套厨房设备同时做备菜和现炒”,理解了这一点，就能逐层看清每个站房的设计。

ODS层：原样接入的收货区

中央厨房后门是收货区，供应商送货来，收货员过个秤、签个字，整箱整筐推进冷库。不管是土鸡还是洋鸡、这筐菜有没有烂叶，先原样收下再说。ODS层就是数仓的收货后门，任务是“贴源”:把消息队列里的原始数据最快速地承接进来，保存成与源头几乎一致的结构。

ODS(Operational Data Store)是实时数仓第一站，落地存储通常选Kafka topic本身或HDFS上的原始日志。数据带时间戳，按业务主题建立topic分区。实时采集通过Flink CDC或Canal监听业务库binlog,把增删改操作逐条同步过来。这里刻意“保持原样”,是因为清洗规则会随业务变化，保存最原始的形态，将来规则改了还能重新加工——就像食材先冷藏不急着下锅。

ODS层的关键设计决策是：不做过滤、不做聚合、不做格式改造。有人觉得“顺手过滤一下垃圾数据”没什么，但在每秒百万条数据的吞吐下，任何额外的计算都会拖慢摄入速度，还会污染原始数据，让后续无法回溯。数据新鲜度是衡量ODS层健康度的核心指标。

收货区只做“过秤入库”,不挑菜不切菜，看似简单，却是整条流水线的源头。如果收货区开始挑三拣四，必然拖慢收货速度。ODS层守住了“原样摄入”的边界，后续DWD层才能从容地清洗切配。

DWD层：清洗明细的切配间

洗菜阿姨把食材从冷库取出来，抖掉泥土、摘掉烂叶、削皮去核，再按标准切成肉丝、葱段、姜片。DWD层就是这间切配间，做的是“减法”和“整理”,但不改变食材的本质形态——每一条数据依然是一条明细记录。

DWD(Data Warehouse Detail)是明细层，上游ODS的数据带着各种噪声：重复订单、字段缺失、时间格式混乱。DWD层通过Flink SQL或DataStream API完成过滤空值、去重、schema标准化，再使用维表补上品类名称、城市区域等维度属性。加工完成后，数据粒度与源头保持一致，一行就是一个业务事实。

去重是最关键的算子。实时场景下，订单创建、支付、退款可能有多个渠道重复上报，需要用业务主键（如order_id）在Flink状态里做去重。状态中保存已见过的key,新记录主键已存在则直接丢弃。这正是“洗菜时看到烂叶子就摘掉”。同时，明细数据要保留足够长的时间，供维表回溯和问题排查，不可轻易清理。

切配间出来的肉丝、葱段，形态变了，但每一条都看得见摸得着。这就是明细层的原则：不清不行，但绝不丢弃细节。

DWS层：多维汇总的配菜区

配菜师傅根据午市菜单，把肉丝、木耳、胡萝卜丝、调味包组合成“鱼香肉丝半成品包”,一份份装好。客人点单后，灶台师傅把半成品包倒进锅里炒两分钟就能上桌。DWS层就是这间配菜区。

DWS(Data Warehouse Summary)是汇总层，把DWD的明细数据按业务维度——店铺、城市、商品——做实时预聚合。最典型的做法是用Flink的滚动窗口或滑动窗口按分钟、小时粒度计算GMV、订单量、UV等指标，结果写入宽表。宽表预先算好，下游应用来查时直接拿结果，不用现场算，这正是“半成品包”的意义。

设计DWS层要选好两个参数：维度组合和时间粒度。维度组合决定宽表的字段结构，粒度决定每行数据代表的时间窗口。粒度太小（秒级）状态压力大，查询频繁；太粗（天级）失去实时意义。工程上常用“分钟级明细汇总+小时级预聚合”双层结构，既保证时效，又控制存储成本。维度的选择要对着业务方的高频查询来设计，砍掉用不上的维度组合，避免维度爆炸。

半成品包让灶台师傅出餐快，但配菜区要提前研究菜单排期。DWS层的宽表让下游查询快，但设计宽表结构时就要盘算好业务方到底会查哪些维度——这既是架构活，也是业务活。

ADS层：面向出餐的服务台

前台出餐台贴着今日菜单：糖醋排骨、麻婆豆腐、例汤。客人直接报菜名，服务员从保温柜端出成品，两分钟就能上桌。ADS层就是这张菜单和保温柜——面向业务方直接提供已经算好的最终指标。

ADS(Application Data Store)是应用数据层，接收DWS的聚合结果，再按业务需求加工成报表、大屏、推送所需的最终形态，存储到HBase、Redis、Doris或ClickHouse。业务方不再面对原始明细或大宽表，而是像点菜一样直接拿最终指标。报表团队不用再写复杂的聚合SQL,一个简单的读请求就能拿到数据。

ADS层的关键是查询加速。考虑到大屏每秒刷新、报表定时拉取，通常采用“KV存储+缓存”双层架构：高频指标放Redis,历史趋势放HBase。Flink将DWS结果实时写入这些存储，用幂等upsert避免重复计数。查询时先查Redis,命中即返回，未命中再走HBase,把P99延迟控制在百毫秒以内。这里还要考虑数据过期策略——出餐台的菜不能一直放着，分时数据到了就刷新。

保温柜里几十份半成品只是“备好”,出餐台直接端给客人，客人从不会问“这条鱼几点杀的”。ADS层的意义也是如此——业务方只关心结果多快返回，不关心数据清洗了多久。

Flink流式ETL:传送带上的加工

中央厨房最核心的资产不是某个灶台，而是贯穿收货区、洗切间、配菜区的传送带。食材不用人工搬运，沿着传送带依次经过每个工位自动完成加工。Flink就是这条传送带，是流批一体引擎的承重墙。

实时数仓的ETL逻辑全部跑在Flink上，它通过窗口算子按时间切分数据流做聚合，通过状态存储记录中间结果，通过事件时间和水位线处理乱序数据，通过检查点机制保障故障恢复。这套能力让“实时ETL”从理论变成工程实践，而不是一遍遍写shell脚本定时调度。

时间语义上，Flink支持事件时间（业务发生时间）、摄取时间、处理时间，实时数仓优先用事件时间+watermark应对迟到数据。窗口类型上，滚动窗口(Tumble)做固定周期统计，滑动窗口(Hop)做重叠周期统计，会话窗口按活跃间隔切分。状态管理上，Keyed State按key隔离状态，配合RocksDB状态后端支撑超大状态集。检查点周期性做快照，故障时从最近一次检查点恢复，如同传送带断带后从断点重新接上，而不用从头再来。

传送带不会因为某个工位太慢而停下来等。Flink的窗口到了触发时间就算结果，迟到数据走侧输出流兜底，就像洗切间没切完的食材放进下一轮备菜，绝不会堵住后面的工位。

维表关联：实时查菜谱的智慧

配菜师切好肉丝，贴上一张标签：“鱼香肉丝——肉丝200g、木耳50g、胡萝卜100g、豆瓣酱1勺”。这张标签就是菜谱，切菜时翻对应页就是维表关联。实时数仓中，明细数据从Kafka过来，维度属性从MySQL或Redis来，两者按key拼接成更丰富的上下文。

维表关联在实时数仓几乎无处不在：订单流需要店铺名称、商品类目、用户城市。批处理里直接JOIN数据库表即可，但高吞吐流式场景下，每来一条事件去查MySQL会把数据库打爆。解决办法是：把维表缓存到Flink本地状态或Redis,按key取维字段；高延迟维表用异步IO发起并行请求；更新不频繁的小维表做成广播流，每个并行算子本地全量持有。

四种实现各有适用场景：维表缓存(lookup join with cache)适合维表数据量中等、更新不频繁的场景；异步IO适合每个key都要求强制查源、且源能抗住并发压力的场景；广播状态适合几万条以内的小维表，但维表变更需重启任务。双流Join则是把两条流在窗口内按key连接，适合订单流关联支付流这种“两边都是流”的情况。选择哪种，要从维表大小、更新频率、查询并发三个维度权衡。

配菜师翻菜谱不会通读全本，而是直接翻到对应页——这就像维表缓存按key命中。特殊菜品要打电话问总厨，就像异步IO查外部维表，次数不多但必须精准。

状态TTL:给数据贴上保质期

冷库里的每箱食材贴着保质期标签，临期先出库，过期直接扔掉。过期食材留在库里只会占空间、增加翻找成本。Flink的状态管理也一样，每个key的状态不能无限累积，必须设TTL——相当于数据的保质期。

Flink的状态（聚合中间值、去重key）保存在堆内存或RocksDB中，状态无限增长会导致内存溢出或磁盘膨胀。TTL机制给状态附加“存活时间”,状态超过设定时间未更新即过期，后续访问自动删除。这在实时数仓里是控制资源的命门。

TTL不能拍脑袋设定。设太短，窗口还没算完状态就没了，结果出错；设太长，状态堆积浪费资源。经验公式是：TTL ≥ 最大乱序时间 + 窗口长度。比如流量统计用1小时滚动窗口，业务数据最大乱序10分钟，TTL应设为1小时10分以上。工程上还可以用onTimer清理配合延迟删除加速状态回收，定期对过期key做scan-and-rewrite主动清理。

中央厨房每周盘点冷库，把临期食材移到外层优先消耗。实时数仓团队也要周期性审视状态大小、命中率，动态调整TTL——保质期既是底线，也是成本线，定得太宽松就是在给集群喂过期食材。

AI 应用场景

Python 演示

import timeimport randomfrom collections import defaultdict  class RealTimeKitchen:    """实时数仓分层流水线 模拟中央厨房从收货到出餐"""     def __init__(self):        self.ods_list = []                 # ODS层 原样接收        self.dwd_list = []                 # DWD层 清洗后明细        self.dws_map = defaultdict(float)  # DWS聚合结果        self.ads_list = []                 # ADS出餐结果        self.seen_keys = set()             # 去重key集合     def ods_ingest(self, record):        """ODS原样接入 不做加工"""        self.ods_list.append(record)        return record     def dwd_clean(self, record):        """DWD清洗 去空值加去重 输出干净明细"""        if record.get('value') is None:            return None        dedup_key = (record['shop_id'], record['ts'])        if dedup_key in self.seen_keys:            return None        self.seen_keys.add(dedup_key)        row = {            'shop_id': record['shop_id'],            'gmv': round(float(record['value']), 2),            'ts': record['ts'],        }        self.dwd_list.append(row)        return row     def dws_aggregate(self, row):        """DWS按店铺维度实时累加GMV"""        self.dws_map[row['shop_id']] += row['gmv']     def ads_serve(self):        """ADS输出当前GMV TOP3店铺"""        rank = sorted(self.dws_map.items(),                      key=lambda x: x[1], reverse=True)        self.ads_list = [{'shop': k, 'gmv': round(v, 2)}                         for k, v in rank[:3]]        return self.ads_list     def cleanup_expired_state(self, batch_id):        """状态TTL 每50批模拟触发一次状态清理"""        if batch_id % 50 == 0 and self.dws_map:            self.dws_map.clear()            print(f"  TTL触发 第{batch_id}批状态已清理")  def fake_record():    """模拟一笔实时订单事件"""    return {        'shop_id': random.randint(1, 100),        'value': max(random.gauss(100, 20), 0.01),        'ts': int(time.time()),    }  def main():    kitchen = RealTimeKitchen()    for i in range(200):        rec = fake_record()        kitchen.ods_ingest(rec)        row = kitchen.dwd_clean(rec)        if row is not None:            kitchen.dws_aggregate(row)        if i % 20 == 0:            top = kitchen.ads_serve()            kitchen.cleanup_expired_state(i)            print(f"第{i:3d}批 ODS={len(kitchen.ods_list):3d} "                  f"DWD={len(kitchen.dwd_list):3d} "                  f"DWS={len(kitchen.dws_map):3d} TOP={top}")    print("实时数仓分层流水线运行完成 数据闭环 OK")  if __name__ == '__main__':    main()

1. self.dws_map = defaultdict(float)DWS层用字典按店铺ID累加GMV,缺失key自动初始化为0,不需要手动判断
2. dedup_key = (record['shop_id'], record['ts'])用店铺+时间戳作为业务主键，等价于实战中的order_id去重键
3. if dedup_key in self.seen_keys: return None已见过的数据直接丢弃，这就是DWD层明细去重的核心逻辑
4. self.dws_map[row['shop_id']] += row['gmv']一行代码完成实时累加，对应DWS层维度预聚合
5. rank = sorted(self.dws_map.items(), key=lambda x: x[1], reverse=True)ADS按GMV降序排序，取出TOP3店铺
6. if batch_id % 50 == 0 and self.dws_map:模拟TTL清理，周期性清空聚合状态防止无限增长

常见误区

面试题