1. 从一次数据口径打架说起为什么分层不是画着玩的刚入行那会儿我参与过一个零售行业的分析项目。业务方早上开会说昨天华东区的销售额是 320 万到了下午财务那边拉出来的数字却是 287 万。两边都觉得自己没错吵到数据团队这里我们一查发现业务方看的是订单创建时间财务用的是支付完成时间而且业务方那张表里还混着测试环境的脏数据。这件事让我第一次真切意识到如果数据从源头到消费端没有清晰的分层和职责边界后面所有的分析、报表、决策都是建在流沙上的。数据仓库的分层结构说白了就是给数据从原始状态到可放心使用状态设计一条有明确站点的流水线。它要解决的核心问题有三个第一让不同来源、不同格式的数据有一个统一的归集和清洗路径第二让每一层的数据职责单一避免一张表打天下导致的逻辑混乱第三让下游用数的人能快速找到自己该看哪一层而不是每次都去翻原始日志。这套东西适合谁看如果你是刚接触数仓的数据开发、分析师或者是从业务转数据岗、需要理解为什么不能直接查原始表的同学这篇内容会帮你把分层的来龙去脉、每层到底干什么、实际落地时怎么设计讲清楚。我不会只给你一个 ODS-DWD-DWS-ADS 的缩写列表而是把每一层背后的取舍逻辑、踩过的坑、以及不同规模团队该怎么裁剪方案都摊开说。先给一个最朴素的认知分层不是为了显得架构高级而是为了控制复杂度和降低重复计算。一个没有分层的数仓就像把所有食材、半成品、成品全堆在一个灶台上看着热闹真做起饭来手忙脚乱。分层就是给你配了备菜区、烹饪区、出餐区各司其职。2. 四层主干结构每一层到底在解决什么问题2.1 ODS 层贴着源系统走别急着做业务判断ODSOperational Data Store操作数据存储层是整个数仓的地基。它的核心原则只有一条尽可能原样保留源系统的数据只做最轻量的技术处理。什么叫最轻量比如字段类型统一、时间格式规整、加上数据抽取的时间戳和来源标识这些可以做。但像把订单状态 1 翻译成已支付这种带业务含义的转换坚决不放在这一层。为什么这么强调原样因为一旦你在 ODS 层做了业务逻辑后面如果业务规则变了你连回溯原始数据的机会都没有。我见过一个团队在 ODS 层就把退款订单直接过滤掉了结果半年后业务要看退款率趋势发现原始数据里根本没有退款记录只能重新从源库抽白白浪费了大量存储和计算资源。ODS 层通常按天分区采用增量抽取或全量抽取。增量抽取适合有明确更新时间戳的表全量抽取适合数据量小但变更频繁的维表。这里有个实操细节增量抽取一定要处理迟到数据。比如源系统里一条订单的更新时间是昨天但因为同步延迟今天才到如果你的抽取条件是更新时间等于今天这条数据就永远丢了。稳妥的做法是每次抽取最近 N 天的数据做覆盖写入N 一般取 3 到 7 天。提示ODS 层建议保留至少 6 个月到 1 年的历史数据具体看存储成本和合规要求。别为了省空间把原始数据删了后面想补都补不回来。2.2 DWD 层清洗、规范化、拉链把数据变成可信原料DWDData Warehouse Detail明细数据层是数仓里最考验功力的地方。它要做的事情是把 ODS 层那些毛坯数据加工成干净、规范、可复用的明细数据。具体包括去重、空值处理、字段标准化比如把男/女/M/F统一成male/female、维度退化把常用的维度字段直接冗余进事实表减少关联、以及缓慢变化维的处理。缓慢变化维是 DWD 层的重头戏。举个典型场景一个客户的所属区域从华东变成了华南你希望历史订单仍然关联到当时的华东还是统一显示成现在的华南前者需要拉链表后者直接覆盖就行。拉链表的设计思路是给每条记录加上start_date和end_date当前有效记录的end_date设为一个极大值比如 9999-12-31。这样查询某个时间点的状态时用where dt between start_date and end_date就能精准还原。DWD 层还有一个容易被忽视的职责统一命名规范和度量单位。比如有的源表金额单位是分有的是元到了 DWD 层必须统一成元。有的源表用order_id有的用order_noDWD 层要统一成同一个字段名。这些看似琐碎的工作恰恰是下游能高效使用的关键。2.3 DWS 层按主题聚合让常用指标一次算好处处能用DWSData Warehouse Summary汇总数据层的核心思想是预聚合。你想想如果每个报表都去 DWD 层扫全量明细那计算资源会被重复消耗无数次。DWS 层就是把这些高频的聚合逻辑提前算好按主题域比如交易、用户、商品、流量组织成宽表。举个例子交易主题下可以有一张用户日粒度交易汇总表包含每个用户每天的订单数、支付金额、退款金额、首单时间等。这张表按user_id dt聚合下游做用户画像、复购分析时直接查这张表就行不用再去关联订单明细和支付明细。DWS 层的设计有个关键取舍聚合粒度越细灵活性越高但存储和计算成本也越大。粒度太粗比如只按天汇总遇到按小时看趋势的需求就抓瞎粒度太细比如按秒又失去了预聚合的意义。我的经验是大部分场景按天 业务主键的粒度就够了个别实时性要求高的场景再单独走实时链路。2.4 ADS 层面向应用怎么好用怎么来ADSApplication Data Store应用数据层是直接对接报表、大屏、接口的层。这一层不再追求通用性而是怎么方便应用怎么来。比如某个报表需要华东区 Top 10 门店的周销售额环比那 ADS 层就可以直接建一张专门服务这个报表的表字段名甚至可以用中文拼音缩写只要应用方看得懂就行。ADS 层的数据通常会有较强的时效性要求很多团队会在这里引入 ClickHouse、Doris 这类 OLAP 引擎来加速查询。但要注意ADS 层不是垃圾桶不能什么临时需求都往这里塞。我的做法是只有被两个以上应用复用的指标才值得在 ADS 层单独建表一次性的分析需求直接在 DWS 层查就行。3. 分层之外的那些层ODS 之前和 ADS 之后还有什么3.1 数据源层与贴源缓冲别让抽取任务压垮业务库严格来说数据源层比如业务系统的 MySQL、日志文件、第三方接口不算数仓的一部分但它和 ODS 层之间的衔接方式直接影响数仓的稳定性。我踩过最大的坑就是抽取任务直接连业务库做全表扫描结果把业务库的 CPU 打满了线上订单都卡了。后来我们加了一个贴源缓冲的环节先用 Canal 或者 Flink CDC 把业务库的变更日志实时同步到一个中间库ODS 层再从中间库抽取。这样业务库的压力就小多了。如果团队没有实时同步的条件至少也要做到抽取任务在业务低峰期执行、加限流、避免select *。3.2 维表层别把维度散落在各个事实表里维度表Dim 表严格来说可以放在 DWD 层但因为它太重要了很多团队会单独拎出来管理。维度表的核心是一致性同一个门店在交易事实表里叫store_id在流量事实表里叫shop_id那下游关联时就会疯掉。所以维表要统一主键、统一命名、统一口径。维度表还分稳定维和变化维。稳定维比如省份城市这种基本不变的直接全量覆盖就行变化维比如客户等级这种会变的就要用拉链表或者快照表来处理。我一般建议变化频率低于每月一次的用拉链高于每月一次的用每日快照因为拉链表的关联查询在数据量大时性能会明显下降。3.3 数据集市层给不同业务线开小灶数据集市Data Mart可以理解为 ADS 层的一个变体它是面向特定业务线比如市场部、供应链部的独立数据集。和 ADS 的区别在于数据集市通常有更强的业务属性甚至会有自己的主题划分和指标体系。什么时候需要数据集市当公司业务线多、各业务线指标口径差异大、且数据团队人力充足时可以考虑建。但小团队千万别一上来就搞数据集市先把 ODS-DWD-DWS-ADS 这条主干跑通再说。我见过一个十来人的数据团队硬要模仿大厂搞数据集市结果每个集市都半死不活维护成本高得吓人。4. 不同规模团队的分层裁剪方案4.1 小团队1-3 人三层足够别硬凑四层小团队最大的问题是人力有限如果硬套四层结构光是维护 ODS 和 DWD 的同步任务就能把人累垮。我的建议是三层ODS DWD ADS。把 DWS 的聚合逻辑直接放在 DWD 层用视图或者临时表实现虽然性能差一点但维护成本低很多。具体做法ODS 层保留原始数据DWD 层做清洗和规范化ADS 层直接面向报表做聚合。DWS 层的功能通过 DWD 层的宽表 ADS 层的聚合来分担。等团队扩充到 5 人以上再把 DWS 层独立出来。4.2 中型团队5-15 人四层标准结构重点抓规范这个规模是大多数公司的常态。四层结构ODS-DWD-DWS-ADS能跑起来但关键是建立规范并严格执行。我建议至少定下这几条规矩每一层的表必须有明确的命名前缀比如ods_、dwd_、dws_、ads_。跨层引用必须逐层向上禁止 DWD 直接查 ODS 以外的层禁止 ADS 直接查 DWD 以外的层。每一层的数据必须有质量监控比如空值率、主键唯一性、数据量波动。这些规矩听起来简单但执行起来需要工具支撑。我们当时用的是一个自研的元数据管理系统每次建表都要填表所属层级、责任人、更新频率不填就不让上线。一开始大家嫌麻烦后来发现查问题时能快速定位到责任人效率反而高了。4.3 大型团队15 人以上分层 主题域 数据治理大团队的分层会更细可能会在 DWD 和 DWS 之间再加一层 DWMData Warehouse Middle中间层用来做轻度汇总。同时会按主题域划分团队比如交易域、用户域、流量域各自负责自己的 DWD 到 DWS 链路。这个阶段最重要的是数据治理。分层结构本身不复杂复杂的是如何保证几十上百人按照同一套规范协作。我们当时的做法是每个主题域有一个数据管家负责审核本域的建表申请和口径定义跨域的指标由数据平台团队统一管理。这样既保证了灵活性又避免了口径打架。5. 落地时最容易踩的五个坑5.1 坑一ODS 层做业务清洗导致无法回溯前面提过但值得再强调一次。ODS 层的唯一使命是忠实记录任何带业务判断的操作都不应该在这里做。我见过最离谱的案例是有人在 ODS 层就把测试用户过滤掉了结果后来做用户增长分析时发现新用户数对不上查了半天才发现是测试用户里混着真实用户。5.2 坑二DWD 层拉链表没处理好历史状态错乱拉链表最常见的错误是end_date更新不及时。比如一个客户今天从 A 等级降到 B 等级拉链表应该把旧记录的end_date改成今天然后插入一条新记录。但如果更新逻辑写错了旧记录的end_date还是 9999-12-31那查询时就会同时命中两条记录数据直接翻倍。排查这种问题的技巧定期跑一致性校验比如select count(*) from dim_customer where end_date 9999-12-31的结果应该等于当前有效客户数。如果对不上说明拉链断了。5.3 坑三DWS 层聚合粒度选错下游用不了有个项目我们按天 省份聚合了交易数据结果业务方要按城市看我们只能重新跑一遍明细。后来学乖了DWS 层的聚合粒度至少要比最细的分析需求再细一级。比如业务最细要看城市那 DWS 就按城市聚合如果业务可能要看门店那就按门店聚合。5.4 坑四ADS 层表太多维护不过来ADS 层最容易失控因为每个报表都想要一张自己的表。我们的对策是ADS 层的表必须有明确的退役机制。每张表上线时登记预期使用周期到期前一周自动提醒责任人确认是否续用。不续用的表自动下线释放存储和计算资源。5.5 坑五分层规范有了但没人执行这是最根本的坑。规范写在文档里但开发图省事直接跨层查时间一长分层就名存实亡。解决办法只有一个把规范嵌入工具链。比如在 SQL 审核环节加规则发现跨层引用直接打回在调度系统里配置依赖DWD 的任务只能依赖 ODS不能依赖 DWS。让违规操作做不了比让人自觉不做靠谱得多。6. 一套可直接抄作业的建表规范模板6.1 命名规范层级前缀示例说明ODSods_ods_order_info源系统表名直接拼接DWDdwd_dwd_trade_order_detail主题_业务过程_明细DWSdws_dws_trade_user_1d主题_粒度_周期ADSads_ads_report_region_sales应用_报表名6.2 字段规范所有表必须包含dt分区字段格式yyyy-MM-dd。金额字段统一用decimal(18,2)单位统一为元。时间字段统一用timestamp或string格式yyyy-MM-dd HH:mm:ss。主键字段统一以_id结尾比如order_id、user_id。枚举字段必须附带注释说明每个值的含义。6.3 更新策略ODS每日增量抽取保留最近 7 天可重跑。DWD每日全量覆盖或增量合并拉链表按需更新。DWS每日全量覆盖按分区写入。ADS按报表需求可全量可增量。注意全量覆盖虽然简单但数据量大时性能很差。建议超过 1000 万行的表都用增量合并配合分区裁剪来提升查询效率。7. 分层之后怎么验证它真的在起作用建完分层不是终点你得有办法验证这套结构是否真的在提升效率。我一般看三个指标第一跨层查询的比例。如果 DWD 的任务大量直接查 ODS说明 DWD 的覆盖度不够大家不信任它。理想情况下跨层查询应该趋近于零。第二重复计算的比例。同样的聚合逻辑如果在多个任务里重复出现说明 DWS 层没建好。我们当时用 SQL 解析工具扫描所有任务找出重复的子查询模式然后针对性地下沉到 DWS 层。第三需求响应时间。分层建得好新需求应该能快速找到对应的数据层而不是每次都要从原始数据开始加工。我们统计过分层规范执行半年后简单报表的开发时间从平均 3 天降到了 1 天以内。最后分享一个我个人坚持的习惯每季度做一次分层健康度巡检。把所有的表按层级列出来看看有没有孤儿表没人用也没人维护、有没有越权表层级和实际用途不符、有没有僵尸任务调度还在跑但下游已经没人依赖。这件事花不了多少时间但能避免数仓随着时间推移变得越来越臃肿。分层结构不是一劳永逸的它需要持续维护就像家里的收纳系统隔段时间不整理就会乱。