数仓分层到底是为了架构好看还是真有用？3 个人的团队该不该硬上四层

背景

过去 3 年我先后在两个大数据团队待过，一个 12 人、一个 4 人，都搞数仓。12 人那套是标准 Kimball 四层（ODS → DWD → DWS → ADS），每层独立 schema、独立调度、独立质量校验，看起来非常"正规"。4 人那套我接手时也是四层，但实际跑起来发现：ODS 层 200 多张表基本没人查，DWD 和 DWS 的口径经常对不上，ADS 层一半的表是"先建着备用"——结果就是调度链路平均 7 层依赖，一个上游 ODS 延迟 10 分钟，下游 4 个 ADS 报表全部延迟，值班的人每天被业务催。

后来我帮那个 4 人团队做了一轮"降层"：砍掉 ODS（直接抽到 DWD），DWS 合并进 DWD（因为下游只有 3 个消费方，复用率根本没到需要独立一层的程度），ADS 只保留真正被 BI 看板引用的 6 张表。砍完之后调度依赖从 7 层降到 3 层，日常故障处理时间从平均 40 分钟降到 12 分钟，但并没有丢任何一张业务表。

这件事让我开始认真想一个问题：数仓分层的核心收益到底是什么？是"架构好看"还是"真能省人力"？ 我越来越倾向于认为，分层是一个规模驱动的工程决策，而不是一个数据工程的信仰。

常见分歧 / 几种做法

1. 分层派（Kimball 正统）：分层 = 解耦。ODS 存原始数据（不可变），DWD 做清洗和维度退化，DWS 做轻度聚合，ADS 面向应用。好处是：上游 schema 变更只影响 ODS→DWD 这一跳，下游无感；DWS 的聚合结果可以被多个 ADS 复用，避免重复计算；每一层可以独立做数据质量校验（row count、null rate、主键唯一性），问题定位有"断点"。反对声音：小团队根本用不到这么细的解耦，层数越多调度依赖越长，一次上游抖动全链路雪崩；而且"复用"在小团队里经常是伪需求——建了 DWS 结果只有 1~2 个下游在用，维护成本反而高于直接写。

2. 扁平派（宽表 / 按需建模）：不预设层数，从消费方倒推。BI 看板要什么字段就建什么宽表，上游 schema 变更直接改宽表 SQL，不经过中间层。好处是链路短、故障面小、开发速度快（一张宽表 1 个 SQL 搞定）；反对声音：上游一变，所有下游宽表全要改（N 个消费方 = N 次改动），而且"原始数据"没有独立留存，一旦清洗逻辑写错，回刷时没有干净的 ODS 可以重跑。

3. 折中派（两层：ODS + 消费层）：只保留 ODS（原始数据不可变，用于回刷和审计）和消费层（直接面向 BI / API），砍掉 DWD 和 DWS。好处是保留了"原始数据可回刷"这个最核心的分层收益，同时链路只有 2 层，调度依赖短；反对声音：如果消费方 > 5 个且口径有差异，"消费层"会膨胀成一个大杂烩，每张表里都混着清洗 + 聚合 + 业务逻辑，改一处要回归所有表。

4. 数据湖 / Lakehouse 派：不建模，原始数据全进对象存储（Parquet），查询时用 Trino / Spark SQL 按需聚合，"建模"推迟到查询时。好处是零维护（不用管 schema 演进、不用管调度链路）；反对性能确定性和查询成本（每次全表扫 + 全量聚合，P99 不可控，而且存储便宜 ≠ 计算便宜）。

我的倾向与理由

我的判断标准只有一条：下游消费方数量 × 口径差异度。

• 消费方 ≤ 3 个、口径基本一致 → 两层（ODS + 消费层） 足够，别搞四层。
• 消费方 4~8 个、口径有 2~3 种差异（比如"活跃用户"的定义在不同看板不一样）→ 三层（ODS + DWD + ADS），DWD 承担口径收敛的角色。
• 消费方 > 8 个、有跨域复用（同一个 DWS 聚合被 3 个以上 ADS 引用）→ 四层，但前提是 DWS 层有真实的复用率（> 2 个下游），否则就是多养了一层。

核心逻辑：分层的收益是"一次清洗、多次复用"和"变更隔离"，这两个收益都需要"下游数量"来兑现。3 个人的团队、5 个看板，硬上四层就是多养了 3 个"没人用但坏了会报警"的中间层，纯成本。

但有一个前提我特别强调：不管几层，ODS（原始数据不可变层）不能砍。这是我见过最多翻车的点——为了"简化"把原始数据直接覆盖成清洗后的，结果上游有一次脏数据回刷，所有下游全部污染，而且没有干净的源可以重跑。ODS 层的真正价值不是"架构好看"，而是回刷时的安全网。

想听大家

• 你们团队几个人、几张表、几层？砍层或加层的触发条件是什么（消费方数量？故障频率？还是"领导要求"）？
• 有没有"为了分层而分层"导致调度链路太长、一次上游抖动全链路雪崩的真实案例？最后怎么收的？
• ODS 层你们保留多久？有没有"ODS 存了 3 年没人查、存储成本比计算还高"的情况？你们的清理策略是什么？
• 数据湖 / Lakehouse 方案你们实际用过吗？"零建模"的查询成本（每次全表扫 + 聚合）在生产环境撑得住吗？P99 大概多少？

欢迎带具体数字来聊：几个人、几张表、几层、多少下游、调度依赖几层、砍层后故障处理时间从多少降到多少。越具体越有参考价值。