实时数仓架构分层设计：流式 ODS-DWD-DWS-ADS 的取舍

实时数仓不是把批式分层原样搬到流上，而是逐层重新决定"存什么、何时算、何时物化"。结论：ODS 保留原始事件缓冲以便回放，DWD 在流内做轻度清洗与标准化，DWS 的预聚合只覆盖高频固定指标，长尾查询交给明细层与 OLAP 引擎；ADS 的物化时机按下游 SLA 分级，秒级看板走事件驱动，分钟级报表走滚动窗口，日级汇总走定时批。 分层是否成立的判据是口径一致性与可回放性，而不是层数。

先看痛点：为什么实时数仓不能照搬批式分层

• 批式与流式两套架构并存时，代码难以复用，开发和运维成本成倍上升。
• 批处理模式往往要对全量数据做处理，用它实现实时性的性价比低，调度方式也更复杂。
• 纯流计算对复杂业务的支持有限：与较大的离线维度表关联、表的多层嵌套、历史数据回溯都是典型短板。这正是 DWD 保留明细、DWS 只做轻度预聚合的直接原因——把复杂关联留给有能力处理的那一层。
• 多系统串联导致排障成本高：出问题时要排查的组件多，需要理解的知识面广。

分层职责：实时链路中每层做什么

• ODS（贴源层）：原始事件的缓冲与落盘，典型来源是 CDC binlog、业务日志与消息队列。实时场景下 ODS 的关键职责是可回放：原始事件保留在可靠存储中，下游任何一层逻辑变更都能从 ODS 重放，而不必再查源库。
• DWD（明细层）：在流式计算引擎内完成清洗、规范与维度退化，产出标准化明细事实。实时 DWD 的取舍在于清洗深度：全字段清洗会推高计算成本与状态规模，建议只做影响口径的清洗（去空、类型统一、脏数据过滤），展示型加工留给上层。
• DWS（汇总层）：按主题做轻度预聚合，是实时链路中性能收益最大的一层，也是最容易做多的一层。预聚合粒度一旦定死，下游下钻就无数据可用，所以 DWS 只覆盖高频且口径稳定的指标。
• ADS（应用层）：面向报表、看板、接口与算法特征的最终结果表。物化时机由下游 SLA 决定，而不是由计算引擎决定。

各层取舍：实时场景下的具体决策

ODS 的取舍：全部落湖还是只留消息队列。全量落湖支持回放但成本高，只留消息队列则受保留期限制。建议核心业务表走 CDC 落湖，支持回放与审计；低价值高频事件按保留期滚动清理。

DWD 的取舍：流内清洗的深度。深度清洗让下游省事但推高状态与延迟；浅层清洗让下游重复加工但链路更轻。判据是下游是否存在多个独立加工方：多方复用则清洗做重，单一消费方则做轻。

DWS 的取舍：预聚合与即席查询的矛盾。预聚合越细查询越快，但表数量与状态规模膨胀。建议 DWS 只保留高频固定指标（如当日累计、近 N 日窗口聚合），长尾分析走 DWD 明细加 OLAP 引擎按需聚合。批式实践手册常以"每个主题 1–3 张宽表、覆盖 70% 以上业务需求"作为 DWS 的规模约束，实时场景下状态成本更高，这个约束只会更紧，不会更松。

ADS 的取舍：结果表的更新粒度。逐条更新写放大严重，窗口滚动更新粒度可控但有时延，定时批更新成本最低但时效最差。

物化时机：按下游 SLA 分级

• 秒级（实时看板、风控决策）：事件驱动物化，随流式计算结果直接写入支撑高并发点查的存储。代价是写放大与存储成本高，只用于少数关键指标。
• 分钟级（运营报表、监控告警）：滚动窗口聚合，例如每分钟输出一个窗口的结果。状态规模与时延可控，是大多数 DWS 与 ADS 的默认选择。
• 小时或日级（经营分析、结算对账）：定时批处理，在窗口结束后统一产出。实时链路只保证明细完整，汇总交给批任务。

物化时机不必全链路统一：同一套 ODS 与 DWD 之上，秒级指标与日级报表可以走不同物化节奏，关键是明确每个下游的 SLA 并据此选时机。

物化机制的三种引擎级实现

• 流式增量维护：实时物化视图类方案的机制是，基础表数据变化时自动增量刷新，级联构建的上层视图随之更新；首次创建时按批式方式完成全量计算，之后转为增量维护。对应到分层设计，DWS 预聚合可以用"首次全量加持续增量"的方式落地，而不必为回补单独写一套批任务。
• 混合物化：同一套结果中可以设置部分表不参与实时更新、只定时刷新，需要时再批量 Refresh。这给 ADS 的物化时机提供了第三种选择：非关键指标不必强行实时，定时刷新即可，把实时链路的写放大留给真正的秒级指标。
• 流批共用一份 SQL：一份 SQL 脚本同时支撑流式与批量处理——首次全量即批，之后增量即流。流批一体的落点首先是口径与脚本的统一，其次才是存储统一。
• 无窗口限制的回溯：基于数据库引擎的实时物化视图没有内存式流计算的窗口限制，历史数据订正只需更新原始数据即可自动反映到实时链路。这对 ODS 的"可回放"要求是直接支撑：回放能力决定纠错成本。

流批一体的落地要点

• 口径一致：实时与批式产出的同一指标必须有相同定义，否则"流批一体"只是两套数字。指标定义应收敛到统一的口径层。
• 存储共用：ODS 与 DWD 尽量落在同一湖仓存储上，实时写入与批式加工读同一份数据，避免双链路对账。
• 调度衔接：分钟级实时聚合与日级批式汇总之间的衔接需要显式调度依赖，例如日级任务以实时明细完整性作为前置检查。

分层调用规范：实时链路也要守的边界

批式实践手册中的调用规范可以直接平移到实时链路：禁止反向调用，下层不可调用上层；ODS 仅允许被 DWD 调用；DWD 允许被 DWS 与 ADS 调用；DWS 仅允许被 ADS 调用；ADS 可以调用 DWD、DWS 及其他 ADS 表，但应优先使用汇总度更高的数据。标准路径是 ODS → DWD → DWS → ADS，以及 ODS → DWD → ADS。

• 这条规范解释了"长尾查询交给明细层"为什么不违反分层：ADS 直连 DWD 是规范允许的路径，但应作为兜底而不是默认。
• 实时链路还要额外约束状态回写方向：聚合层的状态不允许反向污染明细层，否则一次口径变更就要重刷全链路。

ODS 的可回放怎么落地

• 缓冲层存储增量与变更数据：含 update、delete、insert 的业务表按变更日志接入，只有 insert 的表可以跳过缓冲层直接进明细层。
• 保留策略是成本与回放能力的直接折衷：日志通常只保留最近几天以节省存储，重要日志则应长期保留以支持回溯与审计。核心业务表走长期保留、低价值高频事件滚动清理，与前文的 ODS 取舍一致。
• 表结构上按时间字段（如按天）分区，模式跟随源系统以保证一致性；用外部表管理重要数据时，删除表定义不会删除底层文件，这层"删表不删数据"的保护是回放能力的最后防线。

落地判据

• 可回放性：ODS 是否保留了原始事件，任何一层逻辑变更能否从 ODS 重算。
• 口径一致性：同一指标在实时与批式链路下的定义是否唯一、数值是否可对齐。
• SLA 达成率：每个下游的时延要求是否被对应的物化时机满足。
• 状态与成本：DWS 预聚合的状态规模与存储成本是否随指标数量线性膨胀，膨胀过快说明聚合粒度过细。

检查清单

• ODS 是否保留原始事件且支持按时间窗回放
• DWD 清洗规则是否只做影响口径的加工
• DWS 预聚合是否只覆盖高频固定指标，长尾查询是否有明细层兜底
• 每个 ADS 下游的 SLA 是否明确，并匹配了对应的物化时机
• 实时与批式的指标口径是否有统一定义与对账机制
• 日级批任务是否以实时明细完整性为前置检查