数仓规范三要素：分层、模型选型与生命周期管理

去年年底我接手了一个做了一半的数仓项目，第一眼看到线上表的时候我就知道问题不小：三张核心表分别叫“fact_table_v2”“订单最终版”“dr1_副本”，同一份订单数据在不同表里的粒度对不上，下游报表取数全凭记忆。需求方要近一年的订单趋势，我连“一天应该看哪张表”都答不出来。这种混乱我见过太多次，根子往往不在技术，而在三个最基本的规范层面没有想清楚：数仓怎么分层、模型类型怎么选、数据生命周期怎么管。这篇内容就围绕这三件事展开，把我这些年做数仓从踩坑到形成规范的经验完整梳理一遍，适合准备建仓或者已经被乱表折磨到想重构的团队参考。

1. 数仓分层的底层逻辑：层次不是纸面架构，而是排障地图

很多团队对分层的理解停留在“别人都分了，我不分不好意思”。真正上线跑三个月，遇到需求反复变更和数据对不上的时候，才会明白层次的价值到底是什么。

1.1 分层之前先想清楚：这个数仓要支撑什么

我见过最直接的失败模式，是把数仓当成数据库来建。业务说“我要一个报表”，开发就把源表Sync过来，写一条聚合扔给前端，完事。第一个月很爽，到第三个月另一个部门也要报表，口径稍微不一样，开发就在同一张表上改字段、加字段、覆盖历史数据，最后谁也不敢动这张表。

所以分层的第一步不是画图，而是回答一个问题：数仓的产出物是什么？

如果主要支撑固定报表，最小的分层可以是ODS加ADS，中间只做轻量清洗；如果要支撑自助分析和数据产品，就必须有明细层和汇总层；如果要实时和离线两套体系，DWD层往往是最关键的公共资产。我自己的经验是，一定要先盘点下游需求类型、查询频率、允许的延迟，再决定层次数量。层次不是越多越好，多一层就多一份存储和一天的加工延迟，但该有的公共层绝对不能省。

1.2 主流分层模型与职责边界

目前国内用得最普遍的一套分层，基本可以归纳为五层：ODS、DIM、DWD、DWS、ADS。每一层的职责和约束必须清晰，否则边界模糊，分层的意义就没了。

这张表里最容易出错的是DWD和DWS的边界。DWD坚持明细，DWS做汇总宽表。如果开发把聚合结果直接放回DWD，整个血缘就乱了，下游不知道这张表到底是明细还是汇总。我处理过一起事故，就是因为有人把DWS的指标结果写入DWD表，导致下游取数发现同一天订单数翻了三倍。

DIM层在一些老团队里会被忽略，维表直接散落在DWD里。短期看没什么问题，长期做跨域分析时，用户维度和订单明细反复Join，字段口径各写各的，最终必然对不上账。层面不是一劳永逸，后面各层还有各自规范。DIM更是如此，需要一致的代理键。

1.3 分层带来的价值与隐性成本

分层的显性价值有三个容易感知：

第一，错误隔离。源库字段变更，ODS先扛住，DWD按既定规则解析字段，下游不用跟着乱。第二，计算复用。DWD统一清洗后，DWS可以同时为BI报表、算法特征、实时链路供数，避免每条线都重新清洗一遍。第三，血缘可追。出了问题可以从ADS一路追到ODS，定位到具体某一天某个字段的变化。典型的一次“订单金额对不上”排查，如果没有分层，就得翻十几条ads临时SQL，有分层半小时就能锁定DWD里某张表某天的空值替换逻辑。

隐性成本同样真实：存储冗余。ODS每天全量导一次，每层又存一份，磁盘消耗是指数级涨的。延迟。一条数据要经过多层加工，T+1报表基本是标配，想做小时级还得另走实时链路。维护复杂。表的数量可能是源系统的三到五倍，没有元数据管理就是灾难。

我的经验是：不要为了分层面子工程盲目上五层，小团队三件套“ODS+DWD+ADS”也够跑；但只要有多个业务线共享数据，DIM和DWS就必须补上。

2. 模型类型选型：事实表、维度表与两种典型建模法的取舍

分完层，接下来要解决的是“每一层里面放什么类型的数据模型”。这里最容易犯的错误是照搬ER模型的写法，把数仓建成了操作型数据库的翻版。

2.1 事实表设计的三个关键属性

事实表是分析的主体，通常包含维度外键、度量值、退化维度字段。设计事实表时我会优先确认三个东西：粒度、可加性、更新策略。

粒度是事实表的灵魂。同一张订单表，一行代表一个订单明细，还是一行代表一个订单整体，统计结果完全不同。曾经有个团队做支付金额报表，明细事实表明细到支付流水，汇总事实表却按订单数统计，两边差出了退款单，争论一周才发现是粒度不一致。

可加性分三种。可加事实（订单金额、销售数量）可以跨任意维度直接求和。半可加事实（库存余额、账户余额）只能跨维度之外求和时间。不可加事实（折扣率、转化率）根本不能求和，只能重新计算。建模时连“库存表能不能按月累加”都没想清楚，报表数据出来错得离谱也不奇怪。

更新策略则决定了事实表是日增、全量覆盖，还是用拉链表记录变化。订单类事务事实表一般是增量；库存类快照事实表一般是全量；订单履历这种累积型事实表则要不断更新同一行。三种场景对应事务事实表、周期快照事实表、累积快照事实表。方便记忆的判断标准：一条事实发生一次，看流水；一个状态周期性地截图，看快照；一个业务流程从头走到尾，看累积变化。

2.2 维度表：代理键、粒度与SCD策略的选择

维度表是分析的角度，常见的有用户、商品、渠道、时间。维度表设计有三个要点，任何一个做错，后面都要返工。

第一，代理键优先于自然键。用数据库自增或字典映射生成的代理键，可以把源系统的主键变化完全隔离。自然键受上游系统影响很大，用户ID一旦被源系统重建，没有代理键做缓冲，事实表外键全部作废。第二，只要能用业务主键唯一定义一行，就确定维度粒度。比如用户维度，一行必须是一个业务用户，不能一行是一个注册设备加用户名的组合。第三，是最容易决策错误的SCD。

缓慢变化维在实际项目中主要用两种策略：

SCD1直接覆盖，只保留最新值，实现最简单，但历史被抹掉。适用于地址、昵称这类不太需要追溯分析的字段。SCD2按版本保留，每变更一次开新行，保留历史版本，用有效开始和结束时间标记。适用于手机号绑定、渠道归属这类需要回看历史的字段。SCD3会在维度表里同时保留当前值和上一值，适合只需要“上一步”分析而不需要全量历史的场景——现实中用得少，因为多数场景一旦要历史，就会要全量历史。

有个来自会员运营的项目很典型：用户手机号变更后，业务方要统计“老手机号带来的复购率”，如果用SCD1，历史手机号直接丢失，分析完全做不了。这类字段在设计DIM层时就该定成SCD2。我建议在建表文档里把每个变更字段的SCD策略写清楚，别等需求来了一层层改。

2.3 星型模型与雪花模型的业务取舍

很多人纠结星型还是雪花，其实在大数据环境下，这个选择并不纠结。星型模型把维度冗余在事实表周边，结构简单、查询Join少、性能好；雪花模型对维度做了规范化拆分，避免了重复存储，但查询链路变长，钩子复杂。

分布式数仓环境下，磁盘比Join便宜，这是选型的第一原则。事实表几亿行，多放几个冗余维度字段不过多几列，但少两个Join，查询响应能差出数量级。我主导过的项目，绝大多数事实表最终都用了星型结构，只有极小众的场景，比如维度表本身特别大又有很强的层级关系，才会考虑雪花。

还有一个现在很常见的趋势：为了极致查询性能，直接在DWS层把多个维度的字段拼成宽表，一张表里事实加维度的扁平字段几十上百列。这种宽表模型本质上就是星型的极端形态，它牺牲灵活性换取速度，是能在实践里落地的，但要注意谁来保证宽表字段口径的权威性。如果同一个指标在DWD和DWS各有一版口径，那比雪花模型带来的问题更严重。

3. 生命周期管理：覆盖数据从产生到销毁的每个决策点

层次和类型决定了数仓长什么样，生命周期管理决定它能活多久。见过太多数仓跑了一年，磁盘爆了，临时表几千张，想删不敢删，想归档不知道从哪开始。简化一下：生命周期管理就是围绕每条数据回答“什么时候在什么存储上，保留多长时间，最终如何处理”。

3.1 生命周期各阶段的定义

一条数据进入数仓后，会经历采集、加工、使用、归档、销毁五个阶段。生命周期规范要做的，就是给每个阶段设定明确的准入条件和退出条件。

采集阶段定义数据从哪里来、以什么格式落地ODS。加工阶段定义它何时进入DWD/DWS、关联哪些维表、刷新频率是多少。使用阶段要确认哪些应用在消费它、允许哪些粒度。归档阶段是冷数据迁移到低成本存储，或者压缩成列式格式。销毁阶段是确认数据不再被引用后，安全删除并且留下审计记录。

很多人把生命周期狭隘理解为“删数据”。实际上，归档和销毁的边界一旦模糊，问题更大。举个例子，外部客户画像数据如果因为“看着没用”就被删，三个月后合规要求提供数据来源证明，你就只能抓瞎。做一个“数据保留策略表”很重要，把每个主题域的数据按业务风险分开标注，比如交易数据因为财务审计需要保留五年，日志类数据只保留一百八十天。

3.2 冷热数据分层与保留期限的实践方案

不同热度意味着不同访问概率，我把数仓数据分成三档：

热数据：最近7到30天，报表查询和分析高频访问，放在高性能存储，保持DWS和ADS的在线服务能力。温数据：30到180天，查询频率下降，但依然会被钻取分析，可以保持在线，但允许更长延迟，放到性能要求低的存储节点。冷数据：180天以上甚至更久，只保留法律或合规要求，基本不查询，压缩后移动到归档存储。

保留期限的确定，不应该是开发拍脑袋，而是业务和价值讨论出来的。比如我们处理订单数据时，业务侧的复盘分析经常要看半年度数据，180天是从业务访谈里来的，不是凭空定的。这里提供一个可参考的档案：ODS层一般短备份，30天左右，因为它的价值主要在近期回溯；DWD层是公共资产，保留期最长，如果数据量大可以超过一年；DWS汇总宽表因为已经高度汇总，增值在于口径一致，可以保留两到三年；ADS层往往跟着应用走，应用一停，表就可以立刻准备归档。

定期执行“冷热清单”检查，每季度把没有查询记录的ADS表全部标记为待清理。从我这边的经验看，连续两个季度零查询的表至少占三成，清理掉对集群健康十分关键。

3.3 归档、清理与销毁的实操规则

归档不是简单地把文件挪走。要注意三点：第一，归档后必须确保元数据里保留指针，查询历史能明确“这数据是归档状态”；第二，归档格式尽量列式压缩，比如用Parquet或ORC，查询时可以按分区裁剪恢复；第三，归档后不要立刻删除源表，要留一个安全观察窗口。

清理的主要对象是临时表和任务产生的中间数据。开发跑实验经常建tmp表，跑完不删。每个任务的生命周期里都把“清理临时表”当作收尾步骤，设置调度时间自动删除，否则一年下来，临时表占用比正式表还多。我处理过的一个集群，临时表占存储的46%，全部删掉以后集群压力直接降了一个量级。

销毁是最后一个环节，也是最需要纪律的。销毁前必须查血缘，确认没有下游引用；必须确认备份里也已经处理，不能主表删了备份还留着，恢复后数据又“复活”；必须留下删除记录，包括表名、删除时间、删除人、审批单号，这在合规审计时是保命的东西。

我用过一张简单的销毁审批表，字段就六个：数据域、表名、最后使用时间、下游引用数、审批人、预期删除日期。道理很简单，只有“谁负责、为什么删、删了怎么追溯”说清楚了，销毁才敢做。

4. 规范落地的方法论：命名、元数据与变更管控

有了层次、模型类型、生命周期策略，接下来就是怎么让规范真正被团队执行。规范写在文档里没有用，必须落到建表流程、调度任务和发布流程里。

4.1 命名规范的最小可行方案

命名规范是投入产出比最高的规范，我见过最惨烈的旧系统里有“订单表2”“订单_最终”“订单_final_v3”并存，谁都不敢删背后就是没人知道哪张是权威表。一个最小可行方案只需要四件套：

库名前缀：ods/dim/dwd/dws/ads。表名格式：数据域_主题_粒度_更新方式_存储周期。例如dwd_tradeorder_df，表示交易域订单明细、全量。字段命名：统一业务词根，例如订单金额order_amount，支付金额pay_amount，避免同一个指标叫两种名字。分区规范：统一用dt='yyyy-mm-dd'分区，实时表用window_start等明确时间区间。

表名一旦上生产，尽量不改，后面加新字段可以，改名不行。很多团队命名规范写得很细，到了执行就废，原因是流程上没卡死。最有效的执行方式是把命名检查放到建表审批里，自动化脚本扫表，不符合规范直接拒绝创建。规范要简单到不需要解释，能靠脚本强制执行，不要靠开发自觉。

4.2 元数据与血缘追踪的落地方式

命名规范解决“叫什么”，元数据解决“是什么”，血缘解决“从哪来、到哪去”。很多团队用离线任务调度平台，天然就能看到血缘——哪个任务产出哪张表，哪个任务又消费了它。不要另外搞一套昂贵系统，先把平台自带的能力用起来。

落地元数据时最忌讳追求大而全。先保证三类信息完整：表级信息（负责人、业务口径、刷新周期、保留期限、是否归档）、字段级信息（字段含义、取值枚举、空值规则）、任务级信息（调度依赖、数据质量规则）。我把这个清单做成建表模板，新表申请直接按模板填，填不齐不给上线。

血缘的实际价值，在一次口径变更时体现得最明显。业务说要改“GMV”的口径，从“支付成功减去退款”改成“支付成功”。如果血缘清晰，用下游依赖列表把所有涉及的表一次性筛出来，逐张评估影响；如果没有血缘，只能靠人肉回忆，几乎必然会漏表。安全删除前查血缘，也需要依赖这个能力。

4.3 变更管控与上线检查

数仓里最怕的不是需求变更，而是无记录的变更。生产表被开发直接改字段、加注释、改口径，第二天报表数据少了一截，所有人都说“不是我改的”。

变更管控设了三道点：

第一道，任何结构变更必须走审批，审批信息包括变更原因、影响范围、回滚方案。第二道，数据回刷必须核对历史峰值，防止回刷任务把某一天的数据写重复。第三道，发布上线前的检查必须包含数据校验，不能只跑通任务就完事。我踩过这样一个坑：某张DWS宽表加了筛选条件，任务日志全绿，但结果数据量少了20%，报表那天直接出错。后来把“产出数据行数对比”和“关键指标同环比”写进上线检查，才把这类问题挡在发布前。

这里建议沉淀一个“回滚预案”模板，至少包含：如果新口径出问题，如何切回上一版本；如果数据写坏了，从上游重新跑需要多长时间；以及，当天数据异常时，谁能快速定位到具体环节。

5. 实战踩坑记录与一套可复用的检查清单

写了这么多原则，最后分享几个真实的坑，再给一套可以直接拿去用的检查清单。这些坑大多数时候不是单点技术问题，而是规范缺失。

5.1 三个典型问题复盘

第一个坑：ODS全量历史无脑备份。某业务线的ODS层每天都全量拉取一次，而且持续了三年，磁盘占用飞速增长。后来总结，源表很少变化的数据，全量只要保留当前快照加少量历史，不需要每天全套；源表变化频率高的，也要设定期限，超期归档。全量无期限，是最容易踩但完全可以通过“生命周期策略”绕开的坑。

第二个坑：维表类型选型反复。会员表一开始用了SCD1覆盖，几个月后运营要把“换绑前手机号”和“换绑后手机号”分别统计，只能重新开发一套SCD2的历史维表。如果当时建表前功能确认时就把SCD策略写清楚，补历史成本其实很低的。建议在维度表申请模板里直接加“变更字段与SCD策略”一栏，逼着建表的人提前想。

第三个坑：临时表失控。有一位同事每次调优都建tmp_mid_xxx，调完不删，次数多了，数据团队每个人都在猜哪些临时表还有用。后来我们在调度里强制临时表TTL，超过7天自动清理，再也没人为这事开会。不能让生命周期管理只针对正式表，临时表也要纳入。

5.2 可直接复用的数仓设计检查清单

设计阶段：

• 是否明确数仓目标场景：报表、分析、特征、实时？
• 是否按ODS/DIM/DWD/DWS/ADS完成分层并写明各层边界？
• 是否每张事实表声明粒度、可加性、更新策略？
• 是否每张维度表确定粒度和SCD策略？
• 是否检查过星型/雪花/宽表模型的选择依据？

开发阶段：

• 是否按统一命名规范建表并被脚本校验？
• 是否填写元数据信息：负责人、口径、刷新周期、保留期限？
• 是否配置每条任务的数据质量校验（行数、空值、同环比）？
• 是否在下游引用前完成血缘登记？
• 临时表是否设置TTL？

上线与运行阶段：

• 是否完成变更审批并记录影响范围？
• 是否执行了发布前数据核对和回滚预案确认？
• 是否按冷热分层配置存储策略？
• 是否定期扫描无引用表并走归档/销毁流程？

这张清单不是一次性的，而是每个项目交付前都要过一遍。我通常会在kickoff时就把检查清单发出去，让设计者在第一天就对照着做，而不是最后补作业。等你把这三件事真正落实下来，你也会发现，数仓设计的核心规范其实不是多么高深的理论，而是把“分层、类型、生命周期”这三个词，变成团队每一天都看得见、愿意执行的工作习惯。