1. 事实表在数仓里的角色，比想象中更重要
我入行第五年换到一家新的数据团队时，第一次被拉到评审会上看他们正在用的"核心模型"，一张表里装了订单明细、用户画像标签、商品类目路径、甚至还有促销活动的配置信息，宽得吓人。负责的同学很自豪地说：我们所有需求都从这一张大宽表出，查起来特别方便。
我问了一句：那这张表的粒度是什么？一行代表什么？
全场安静。过了几秒才有人说：应该是一个订单吧？但是那张表里明明还有退款记录、支付流水、加购物车的行为日志。等到需求方想统计"一天内支付成功但未发货的订单数"时，这张表怎么也查不对，因为退款记录和订单记录混在一起，粒度早就乱了。
这就是我从那次之后一直强调的：数仓建模的核心，其实不是维度表多齐全，而是事实表设计得够不够干净。事实表承载的是业务过程发生的"度量事实"——每一行代表某一粒度下的一次业务事件或一个业务快照。它决定了后面所有统计分析的边界。维度表可以慢慢补，但事实表一旦粒度定错、度量口径含糊，后面所有下游报表都会跟着错，而且越叠越难修。
所以这篇分享不是给你讲书上的三范式，而是我在多个项目里反复被问到、也反复栽过跟头之后整理出来的事实表设计思路。内容面向的主要是刚入大数据开发、准备做数仓建模的工程师，也适合那些已经用明细宽表用得很顺手、但想系统理解事实表设计的同学。你不需要精通建模理论，只要跟着这个思路走，基本能把一张事务型事实表设计得像个样子。
2. 设计事实表的第一件事：把粒度钉死
2.1 粒度到底在说什么
简单说，粒度就是"事实表中一行代表什么级别的业务含义"。同样是交易数据，粒度可以是"订单行"（一个订单里的一件商品）、"订单"（一次下单）、"支付流水"（一次支付动作）或者"每天每个商品汇总"。粒度不只是一个概念，它直接决定了这张表能回答哪些问题、不能回答哪些问题。
我在带新人的时候喜欢打一个比方：粒度就是这张表的分辨率。分辨率越高，能回答的细节问题越多，但同时数据量也越大，查询越慢。分辨率太低，比如把所有交易都汇总成"每天总额"，那你想看某个商品卖了多少钱就查不了。关键是先想清楚需求方常用的分析粒度，而不是一味求细，也不是为了省事直接汇总。
2.2 定粒度的标准动作
我实际设计时，会按下面四步走，这四步几乎是固定操作：
- 列出这个业务过程里所有可能的分析维度。比如订单业务：用户、商品、店铺、类目、促销活动、订单日期、发货城市、支付方式。
- 找出需求方最低要看到哪一层。如果业务方要分析到"订单行的商品维度"，粒度就不能合并成订单。
- 确认度量字段在目标粒度下是否有唯一取值。比如"支付金额"在订单行粒度下是唯一的，但一个订单可能有多次支付流水，如果你要分析支付明细，粒度就必须到支付流水。
- 把粒度写进表名或注释里，写清楚。我见过太多人只在代码注释里写了"订单表"，结果三个月后自己都忘了一行是订单还是订单行。
这四步做完，你要能对任何人说清楚：这张表的一行，最小业务单位是什么，覆盖哪些维度，度量字段分别是谁。说不清楚，就不要写建表语句。
2.3 我见过最典型的粒度错误
有一种很常见的错误，是把不同业务过程塞进同一张"事实表"。比如一边有订单下单事实，一边有订单退款事实。业务方说，我就是要看一个订单什么时候下的、什么时候退的，放在一起多方便。但这样带来的问题是：一个订单未退款时，退款金额字段填0还是空？如果一个订单退部分商品呢？如果退两次呢？事实表要求每一行的维度组合和度量是同一业务事件产生的结果，混入多个过程后，sum(re退款金额)会翻倍，count(订单数)也会重复计数。
正确做法是拆成两张表：订单事实表记录下单事件，退款事实表记录退款事件。然后通过订单维度外键关联，在数据集市层再按需合并。底层建模宁可多一张表，也不要把事件混在一起。
重要经验：写事实表前的第一行伪代码应该是
insert into fact_order_line select ...，而不是create table。先把你想"怎么查"写清楚，再考虑"怎么存"。
3. 三种事实表形态：事务、快照、累积快照的选择逻辑
3.1 三张表分别解决什么问题
接触过几个数仓项目后你会发现，事实表的形态并不是只有一种。我一般按业务过程的状态变化方式来选，常见的就三种：
| 形态 | 每一行代表什么 | 更新方式 | 典型场景 |
|---|---|---|---|
| 事务事实表 | 一次业务事件（下单、支付、点击） | 增量插入，不修改历史 | 订单明细、访问日志、支付流水 |
| 周期快照事实表 | 某个周期末的固定状态（每日库存、每月余额） | 定期覆盖或插入新快照 | 库存快照、账户余额快照 |
| 累积快照事实表 | 一个业务流从开始到结束的完整过程 | 随流程推进反复更新同一行 | 订单从下单到发货到签收的全链路 |
事务事实表最常用，记录发生即追加，维护简单，查询灵活，但要算一段时间的状态变化（比如本月至今仍有效的订单）会很麻烦。周期快照表本来就是为了解决"某个时点有多少量"而设计的，按天、按月存一下状态，查询一个时间点很快，但丢失了周期内发生过的中间细节。累积快照表则是针对"有明确起止状态的短流程"，比如订单、工单、物流，它把整个生命周期的关键时间点和状态字段都放在一行里，方便看流程进行了多少步。
3.2 同是订单，三种表怎么选
拿订单业务举例，如果我要做用户购买行为分析，需要看每一次下单的时间和金额，那就用事务事实表。但如果我要统计每天仓库里的库存量、每天账户上的余额，事务表就无能为力了，因为这不是"事件"而是"状态"，必须用周期快照表。
还有一种场景，运营想要看"本周下单并在3天内发货的比率"，如果只有下单事务表，没有发货事件表，就得把订单表、发货表join起来，再算时间差。如果这个需求天天看，不如直接设计一张订单累积快照表，每一行是一个订单，里面有下单时间、支付时间、发货时间、签收时间，以及当前状态。每来一个新状态就update这行，重算的过程也很简单。
所以正确的思路不是只建一种表，而是围绕同一个业务过程按分析需求建多种形态的事实表，各司其职。我在项目里经常同时存在：订单事务表（明细分析）、订单每日快照表（存量与状态分布分析）、订单累积快照表（时效分析）。
3.3 选择时的两个判断问题
判断用哪种表，我一般问自己两个问题：
- 这个业务过程是"一次发生"还是"持续变化"？一次发生优先事务型，持续变化就要考虑快照。
- 用户最关心的指标是"发生量"还是"时点存量"？发生量用事务，时点存量用周期快照。
一个经验法则是：数仓里90%的新手设计失败，不是因为不会建维度表，而是因为拿一张事务事实表去硬答"截止到目前有多少未完成"。回答这种问题，要么用累积快照，要么配合一个当前状态维度，绝对不要对着历史流水做distinct去重。
4. 订单业务为例：从业务过程到事实表DDL的完整过程
4.1 明确业务过程和度量字段
我在实际项目中接到过一个模拟电商订单需求，最开始收到的需求只有一句"想看每天每个商品的销售情况"。听起来很简单，但"销售情况"到底是下单、支付、还是发货？口径完全不一样。我拉上业务方开了一次碰头会，把指标拆成了三个：下单金额、支付金额、发货金额，并且明确：只有支付成功的才计为销售额，下单但未支付的只计订单量。
度量字段的选定要记住一个原则：尽量选连续可加的数值，不要存比比率。比如毛利率、折扣率这类字段，如果直接存在事实表里，后面做sum就会得到完全没意义的结果。要存也是存分子（毛利额）和分母（销售额）这两个原始值，比率在应用层算。
订单交易事实表的度量我通常会包含这些：下单数量、下单金额（含税）、支付金额、优惠分摊金额、商品成本额、退款金额。每个字段都必须是该粒度下一个业务动作产生的真实数值，不能是算出来的比率。
4.2 维度外键该加哪些
维度外键就是事实表里关联维度表的字段。订单业务我一般至少会给：用户维表键、商品维表键、店铺维表键、下单日期维表键、支付日期维表键、促销活动维表键、发货区域维表键。
这里有个容易忽略的点：同一个业务过程可能有多个日期维度。比如订单既要看下单日期，也要看支付日期和发货日期。有些人习惯只放一个订单日期，后面想分析"下单当周但支付跨周"时就抓瞎了。我的习惯是给每个有意义的业务时点都建一个日期外键，至少保留下单、支付、发货、签收四个时间点。
还要注意代理键和外键的区别。维度表的主键不要直接用业务编号，比如商品ID可能是 1001，但商品维表自己的主键我一般建一个自增代理键。事实表存代理键，这样维度表即使修改历史数据（缓慢变化维）也不会影响已经加载的事实记录。当然，如果数据源稳定、维度简单，直接用业务键做外键也能跑，但一旦做SCD就会很难受。
4.3 一套能用的DDL示例
我拿一个简化但可落地的订单事务事实表来当例子，这是一个订单行粒度的表，一个订单包含两件商品就会产生两行。
CREATE TABLE fact_order_line ( order_line_sk BIGINT COMMENT '订单行代理键', order_id STRING COMMENT '业务订单号，退化维度', order_line_no INT COMMENT '订单行号', user_dim_sk BIGINT COMMENT '用户维度代理键', product_dim_sk BIGINT COMMENT '商品维度代理键', shop_dim_sk BIGINT COMMENT '店铺维度代理键', order_date_dim_sk BIGINT COMMENT '下单日期维度代理键', pay_date_dim_sk BIGINT COMMENT '支付日期维度代理键', promo_dim_sk BIGINT COMMENT '促销活动维度代理键', order_qty DECIMAL(18,4) COMMENT '下单数量', product_amount DECIMAL(18,2) COMMENT '商品原始金额', discount_amount DECIMAL(18,2) COMMENT '优惠分摊金额', pay_amount DECIMAL(18,2) COMMENT '实际支付金额，含税', order_status STRING COMMENT '订单状态码，用于轻量分析', etl_load_time TIMESTAMP COMMENT 'ETL加载时间' ) PARTITION BY (order_date_dim_sk) DISTRIBUTE BY HASH(order_id) SORT BY (order_line_sk);这段DDL里有几个设计点值得解释：order_id直接冗余在事实表里，叫退化维度，省得每次为了拿一个订单号还要去join订单头表；order_status我也冗余进来了，因为很多"统计进行中订单数"的需求其实不需要精确流程追溯，用一个状态码字段就够了，但如果要精确分析状态变化，还是得走累积快照表。
分区字段选择order_date_dim_sk而不是直接用日期字符串，是因为事实表通常按时间维度做生命周期管理，这样分区的粒度天生对应日期维表，后面清理历史数据也方便。
4.4 写入与更新策略
事务事实表通常是不可变的（immutable），数据进来就是历史，不允许update。ETL过程一般是：读取业务库binlog或ODS层变更数据，按照主键（业务唯一键）去重，过滤掉无效数据，再按分区插入目标表。
如果因为数据晚到需要重刷某一天的数据，我的习惯是把当天的分区先drop再覆盖写，绝不在原表上delete或update，因为大范围update会导致小文件膨胀和查询效率下降。在数仓里，用"分区幂等"来保证数据可重跑，比依赖事务机制更靠谱。
5. 度量字段设计：可加性、单位、口径这类细节才是重点
5.1 可加性：字段能不能直接sum
事实表里每个度量字段，第一件事就要判断它是否可加。我面试时经常问这个问题，很多人答不上来。
- 完全可加：销售额、订单量、成本，任意维度组合下都能相加。
- 半可加：库存量、余额，按时间维度相加是无意义的，但按商品、店铺维度可以相加。
- 不可加：比率、单价，如折扣率、转化率，直接相加没有任何业务含义。
实际设计时，我会给每个度量字段都打上标签：可加/半可加/不可加。半可加的字段要么单独存快照表（库存），要么在事实表里存"时点值"并明确查询规则。不可加的字段选择不存，或者同时存分子分母。这样做的好处是，后面写报表SQL的人不用再猜：看到checkout_rate直接sum，错了；看到pay_cnt和visit_cnt自然知道算比率。
5.2 单位：金额到底是元还是分
金额单位这个坑，我至少踩过两次。有一次核对报表，ETL里明明写的是amount/100，结果报表还是差了好几个数量级。最后查出来，业务库部分表金额单位是分，部分是元，同一个字段名在不同来源里口径竟然不同。
我的处理方式是在事实表里统一金额单位为"元"，保留两位小数，并且在字段注释里写死"单位：元，含税"。如果来源是分，ETL阶段就必须除以100；如果是不同币种的订单，我会再加一个币种维度外键，并且单独存一个currency_exchange_rate字段，方便换算成统一币种做汇总。
还有一个细节：金额字段一般用DECIMAL(18,2)，不要用float或double，否则加加减减之后出现0.30000000000000004是常态。
5.3 口径：同名不同义是最隐蔽的雷
有一次业务方拿着报表质问：上个月支付金额明明是1200万，为什么你这个表里只有800万？两边查了一遍，发现报表里那个"支付金额"统计的是支付成功且当天未退款的部分，而事实表里pay_amount记录了每一笔支付成功的流水，不管当天是否退款。
这就是典型的口径不一致。数仓里同一个指标词在不同部门可能指完全不同的东西。我在每张事实表的设计文档里都会列一张"度量字典"：字段名、业务定义、统计口径、包含/排除条件、取数逻辑、负责人。比如：
| 字段 | 定义 | 口径说明 |
|---|---|---|
| pay_amount | 用户实际支付金额 | 包含所有支付成功流水，包含满减，不含退款 |
| net_pay_amount | 净支付金额 | pay_amount - 当笔退款，用于GMV口径 |
这张字典别嫌麻烦，等表上线三个月后再有人来问"这个字段怎么算"，你直接甩给他一个链接，省掉无数次无休止的沟通。
6. 上线之后才容易踩的坑：外键、口径、缓慢变化维的关联问题
6.1 事实表引用了维度表里不存在的键
这个坑非常隐蔽。你在事实表里存了user_dim_sk = 10086，但用户维度表里根本没有这个键。SQL join出来全是null，导致所有和用户相关的指标都缺一部分。出现这种问题的原因通常是：ETL加载事实表时，业务库里就存在脏数据，比如用户id已经被物理删除，或者维度表还没加载出来。
我在实践中会给每个外键都做"引用完整性检查"。方式可以是在ETL最后跑一个check SQL，统计count(*)里关联不上的行数。一旦超过阈值（比如0.01%），就发报警，同时把脏数据单独写到一张异常表里人工处理。加这个步骤不复杂，但能把很多"莫名其妙少数据"的排查时间省下来。
6.2 缓慢变化维带来的关联陷阱
事实表和维度表关联时，最容易忽略的就是维度表历史变化。假如用户维表把会员等级从普通改到了VIP，那张事实表里user_dim_sk如果指向同一个代理键，那么历史订单算出来的用户等级全部变成了VIP，历史统计就失真了。
解决方式有两种。第一种最简单：在事实表里直接冗余"当时"的维度标签字段，比如把当时的用户会员等级、商品类目路径直接拷进事实表，这样查询不用join也能拿到历史快照。第二种是维度表采用SCD2，同一业务主键会对应多条记录，事实表需要按日期区间匹配当时有效的代理键。SCD2更规范，但实现复杂度高，如果只是几个常用标签字段，我一般优先选择冗余方案。
6.3 把非事实字段塞进事实表，越塞越乱
我见过有同事往事实表里加"用户性别"、"商品品牌"、"店铺城市"这种字段，理由是查询方便。这些字段本质都是维度属性，放到事实表里会让事实表不断膨胀，而且一旦维度属性变化（比如品牌改个名，城市重新划分），就要update大表，代价极高。
正确的做法是，让事实表只保留外键和度量，维度属性交给维度表或视图层去承载。如果你确实因为性能需要冗余部分维度字段，我的建议是严格控制数量，只保留那些不常变化、又高频查询的标签（比如会员等级、主品类ID），其他一律通过外键关联维表。
7. 再谈性能和存储：一张事实表要同时扛住写入和查询
7.1 分区、分桶和排序键怎么设置
事实表动辄几十亿行，没有任何优化，一个group by能跑死集群。我的配置经验是：如果没有特殊需求，事实表至少按日期分区，保证查询裁剪掉不需要的分区。如果维度基数很大（比如按用户、订单查），可以加一个哈希分桶键，让相同业务实体的数据尽量落在同一个存储单元，这样join和聚合都能本地化。
在支持排序键的引擎里（比如Doris、ClickHouse、Hive的bucket sort），排序键的选择要和你最常用的查询匹配。比如订单事实表经常按订单日期和商品维度聚合，那把order_date, product_id作为排序键就很合适。但要留意，排序键不是越多越好，字段多了反而影响写入性能，选最核心的两个就够了。
7.2 列式存储和压缩编码
事实表分析型场景优先选列存，只有取用到的列才会被读取。列存再配合对应的压缩算法，效果能到一个量级。比如数值字段选压缩率高的算法，枚举型低基数字段用字典编码，字符串大字段直接普通压缩。不同引擎写法不一样，但思路一致：不要让每个查询都全表扫描整行。
我见过有人把事实表里所有字段都设计成STRING，说是为了灵活。结果一张100GB的表，实际按某一天分区过滤后扫描还是慢，因为连数值字段都要转类型、参与比较。事实表字段类型尽量保持原始业务类型，枚举用编码字段，不要全用字符串。
7.3 物化视图能用，但别用成习惯
对于高频固定的汇总指标，我会顺手建几张物化视图或者汇总表，比如每天每个商品的销售汇总、每天每个店铺的支付汇总。这能大幅度降低即时查询的压力。但我不建议把所有指标都物化，因为物化太多意味着口径复制太多，一旦底层事实表口径调整，所有物化视图都得跟着改，很容易漏。
所以我的判断标准是：同一个指标如果被5个以上的报表引用，才值得物化；如果只有一两个临时分析，直接跑明细就好。物化视图建立后，最好在视图命名中保留"粒度+口径版本"，比如dm_shop_daily_pay_v2，避免后面团队搞混。
7.4 数据生命周期：不是所有历史都有必要在线
这件事我在后期才开窍。事实表越堆越大，查询性能下降，其实是很多历史冷数据根本没有查询价值。比如三年前的订单明细，业务侧只看月度汇总，那我就会做分层管理：最近两年的明细保留在在线表，更早的明细归档到低成本存储或直接压缩成月度汇总表。在做设计时就要把生命周期考虑进去，别等磁盘报警才想起来。
经验补充：事实表设计不追求一步到位。先用事务事实表把明细接进来，再有针对性地补充快照表和汇总表，逐步演进。只要底层明细粒度清晰，重建上层模型并不难；难的是底层粒度本来就乱。
8. 一个快速实用的自查清单
最后分享一张我每次做完事实表都会过一遍的自查清单。它不是理论，是我在实际项目里反复吃亏总结出来的：
- [ ] 是否能用一句话说清"这一行代表什么"？如果说不清，说明粒度没定好。
- [ ] 度量字段是否有明确的业务口径，包括单位、包含/排除条件？
- [ ] 是否把比率值直接存成了度量字段？
- [ ] 每个外键能否关联到维度表有效记录？有没有做引用完整性检查？
- [ ] 日期的处理是否严谨：时区、精确到日/小时/分钟、多个业务时间点是否都覆盖？
- [ ] 是否冗余了过多维度属性，导致事实表异常膨胀？
- [ ] 是否区分了事务、周期快照、累积快照三种形态，而不是一张表打天下？
- [ ] 是否设计了生命周期策略，比如保留周期、归档路径？
- [ ] 有没有配套的度量字典或数据字典，让别人能看得懂？
我自己的习惯是，事实表写完DDL之后先不急着建表，而是拿过去三个月最常用的业务SQL去"试跑"一遍，看能不能顺畅地查出来。如果发现哪个查询要绕过很多圈子才能出结果，说明设计里还藏着粒度或口径问题，这时候改还来得及，等数据上线再改就真的伤筋动骨了。
数仓技术这些年轮番换，从Hive到Spark再到各种新式数仓产品，但事实表和维度表这两类建模的底子基本没变。它解决的不是某个引擎的问题，而是业务口径和数据组织方式的问题。把事实表设计这件事想清楚，后面无论是在哪套平台做开发，你都能少走很多弯路。
