维度建模之事实表三种类型对比事务事实表、周期快照事实表与累积快照事实表在数据仓库Data Warehouse / Kimball 架构体系的建模设计中事实表Fact Table是承载全企业业务度量、交易数字与行为流水的最核心底座。然而很多初级数仓工程师在建表时往往认为“事实表就是把上游业务库的表原封不动搬进数仓”导致所有的事实表全部建成了千篇一律的事务流水表。当业务提出以下两类经典商业分析需求时数仓往往会彻底陷入性能瘫痪需求 A存量状态与余额监控“我想看过去 30 天每天夜间 24:00 全公司所有银行账户的资金结余总额或者每个仓库的库存结存件数”需求 B长周期全链路时效分析“我想统计一笔外卖订单从【用户下单】-【商家接单】-【骑手到店】-【骑手送达】-【用户确认收货】每一个环节之间平均耗时多少分钟”。如果强行用事务明细表去算需求 A必须每次从开天辟地第一天累加到今天算力成本极其昂贵如果用事务表算需求 B必须写 5 层极为复杂的自连接Self-Join。为了在不同的商业时间模式下实现极致的分析效率Kimball 体系将事实表严格划分为三大经典流派——事务事实表Transaction Fact Table、周期快照事实表Periodic Snapshot Fact Table与累积快照事实表Accumulating Snapshot Fact Table。今天我们系统拆解这三大事实表的底层物理机制、生命周期与实战 DDL 建模范式。三大事实表流派全景特征大横评---------------------------------------------------------------------------------------------------- | 评估维度 | 事务事实表 (Transaction) | 周期快照事实表 (Periodic Snapshot) | 累积快照事实表 (Accumulating) | --------------------------------------------------------------------------------------------------------------------- | 1. 数据粒度 | 一行对应一个独立发生的业务事件| 一行对应一段固定时间周期内的状态 | 一行对应一个实体的完整生命周期全流程| | 2. 时间维度 | 离散单点时间戳 | 固定的周期终点 (如每天/每月最后时刻)| 包含多个代表关键里程碑的并排时间戳| | 3. 数据更新机制| 纯增量追加 (Append-Only) | 周期性全量/增量快照 (按天插入新分区)| 随业务状态流转多次更新 (In-Place) | | 4. 典型业务场景| 订单支付流水、点击行为日志 | 每日库存结余、银行账户余额、每日总资产| 订单履约链路、工单审批、货物流转 | ----------------------------------------------------------------------------------------------------模式一事务事实表Transaction Fact Table特征与 DDL 实战记录特定时间点发生的原子事件。一旦发生物理不可更改Append-Only。-- 电商交易下单事务事实表 (dwd_trd_order_create_di) CREATE TABLE dw_prod.dwd_trd_order_create_di ( order_id BIGINT COMMENT 订单ID (退化维度), create_time TIMESTAMP COMMENT 下单精确时间戳, user_key BIGINT, sku_key BIGINT, store_key BIGINT, order_amount DECIMAL(10,2) COMMENT 下单金额 (原子度量) ) PARTITION BY dt;模式二周期快照事实表Periodic Snapshot Fact Table特征与 DDL 实战用于记录不可直接跨时间累加的“存量/状态度量Semi-Additive Measures”。通常在每天夜间定时对全量实体拍一张“数码快照”。-- 每日全量商品库存结存快照事实表 (dws_inv_goods_daily_snapshot_df) CREATE TABLE dw_prod.dws_inv_goods_daily_snapshot_df ( snapshot_date DATE COMMENT 快照日期 (分区键), warehouse_id BIGINT COMMENT 仓库ID, sku_id BIGINT COMMENT 商品SKU_ID, -- 存量度量 (不可跨天直接相加但可在同一天内跨仓库相加) ending_stock_qty INT COMMENT 当日结存物理库存数, ending_stock_amount DECIMAL(12,2) COMMENT 当日结存库存金额, -- 周期内流动度量 daily_inbound_qty INT COMMENT 当日累计入库件数, daily_outbound_qty INT COMMENT 当日累计出库件数 ) PARTITION BY dt;巨大价值要看 9 月 1 日全公司的库存总值直接SELECT SUM(ending_stock_amount) WHERE dt 2026-09-01毫秒级出数零历史回溯计算模式三累积快照事实表Accumulating Snapshot Fact Table特征与 DDL 实战用于追踪具有明确起点、多个里程碑阶段、最终终结的端到端业务全流程End-to-End Pipeline。一行数据在数仓中会随着业务状态推进被多次更新Upsert。-- 订单端到端全链路履约累积快照事实表 (dwd_trd_order_fulfill_acc_di) CREATE TABLE dw_prod.dwd_trd_order_fulfill_acc_di ( order_id BIGINT COMMENT 主订单ID (单实体单行), user_id BIGINT, store_id BIGINT, -- 核心并排记录全流程的 5 个关键里程碑时间戳 create_time TIMESTAMP COMMENT 1. 用户下单时间, pay_time TIMESTAMP COMMENT 2. 支付完成时间, merchant_accept_time TIMESTAMP COMMENT 3. 商家接单时间, delivery_start_time TIMESTAMP COMMENT 4. 骑手取货出发时间, finish_time TIMESTAMP COMMENT 5. 最终送达签收时间, -- 预计算各环节流转耗时度量 (分钟) pay_duration_sec INT COMMENT 支付耗时 (秒: pay_time - create_time), delivery_duration_sec INT COMMENT 配送耗时 (秒: finish_time - delivery_start_time), total_fulfill_duration_min INT COMMENT 全链路总履约耗时 (分: finish_time - create_time), current_status_code INT COMMENT 当前订单最终状态 (1:履约中, 2:已完成, 3:已取消) ) PARTITION BY dt;巨大价值要计算“全国各门店平均骑手送达耗时”直接SELECT AVG(delivery_duration_sec) GROUP BY store_id彻底消灭 5 张表的自连接与窗口函数终极建模选型决策树[ 准备为业务过程设计事实表 ] │ ┌─────────────────────┴─────────────────────┐ ▼ (业务事件的物理时间形态是什么) ▼ 【离散原子事件发生】 【属于连续状态或长流程】 (如: 用户点击/刷卡/加购) │ │ ┌───────────┴───────────┐ [建 事务事实表] ▼ ▼ 【需要看固定周期的存量】 【具有明确起止的多阶段全链路】 (如: 账户余额/仓库库存) (如: 订单履约/工单审批/物流) │ │ [建 周期快照事实表] [建 累积快照事实表]三大事实表就像数仓架构师工具箱里的“短跑运动员事务”、“全景照相机周期快照”与“全程摄像机累积快照”。根据业务分析的物理特征各司其职、协同搭配是构建高吞吐、低延迟现代化数仓的核心基本功。