数仓分层架构

命名示例：ods_order_di（di=daily increment，日增量）

DWD层 — 明细清洗

这层是数仓的核心苦力层，干的活最多也最重要。具体来说包括三件事：

字段清洗：NULL处理、类型统一、异常值过滤。比如源系统传过来的年龄字段可能是-1或者999，这些明显不合理的值就需要在DWD层统一处理。我一般的做法是把异常值统一设为NULL，而不是直接删除这条记录——因为其他字段可能是正常的。

维度关联：把user_id关联出用户名、城市等维度信息。这一步做了之后，下游使用时就不需要每次都JOIN维度表了，大大减少了重复JOIN带来的性能开销和出错概率。

数据标准化：时区统一、编码映射、枚举值转换。这是很多人容易忽略的部分，但在实际工作中却是最让人头疼的。不同的源系统可能用不同的编码来表示同一个概念，DWD层就是统一这些差异的地方。

Wood的实战经验 我在短剧出海公司，DWD层最头疼的就是跨时区处理。海外用户遍布多个时区，原始数据是UTC，DWD层要统一转成当地时间。为什么这么重要？因为如果不做时区转换，留存率、日活这些指标全是错的。 比如一个美国用户在当地晚上11点操作，UTC时间已经是第二天了。不转换的话这个用户就会被算到第二天的日活里，留存率也会因此失真。 我们的做法是在DWD层统一加一个local_date字段，根据用户的注册地区转换时区。这样下游所有涉及日期的分析都用local_date，口径就统一了。这个小改动避免了无数次口径争议。

命名示例：dwd_order_detail_di

DWS层 — 主题汇总

DWS层的工作是按业务主题做预聚合，减少下游重复计算。比如你有一张订单明细表，每天有几千万条记录。如果每个报表都要从DWD层开始算，既浪费计算资源，也容易出现口径不一致的问题。

DWS层就是提前把常用的聚合计算做好。典型粒度包括：用户粒度（每个用户每天的行为汇总）、商品粒度（每个商品每天的销售汇总）、天/周粒度（按时间汇总的指标）。

命名示例：dws_user_behavior_1d（1d=天级汇总）

ADS层 — 应用输出

ADS层是数仓的「最后一公里」，直接对接报表、大屏、API接口。通常是宽表或高度聚合的结果表，业务方拿到就能直接用，不需要理解底层表结构和关联关系。

这一层的设计要以终为始——先搞清楚报表需要什么字段、什么粒度，再往回推ADS表该怎么设计。而不是先建一堆ADS表，再看能不能满足报表需求。

命名示例：ads_daily_revenue_report

面试加分提示 不要只背概念，面试官一定会追问「你们公司是怎么分的」。加分回答模板： 「我们ODS层接入了十几个数据源（App埋点、广告平台、第三方支付等），DWD层约30张明细表，每天处理约5000万条数据。DWS层按用户、内容、广告三大主题建设，ADS层直接供报表平台查询。我主要负责广告域的DWD和DWS建设。」 能说出具体数字和你负责的部分，比背书强10倍。