数据仓库事实表：事务型 快照型 累积型

可视化演示

动态演示数据仓库事实表的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

事实表概览

阿茶每天最关心的是一件事：生意到底做了多少。不管是卖出奶茶、补货还是接受大订单，最终都能变成一句话——今天发生了一件事，产生了多少钱或者多少数量的结果。阿茶把这些话整理进账本，就成了“事实表”。在数据仓库里，事实表是记录业务过程度量值的核心表，是整个数仓模型的中心骨架。旁边那些描述“谁、何时、何地、什么”的表叫维度表，它们和事实表像齿轮一样咬合在一起。

事实表的结构并不神秘：一行就是一个业务行为的“脚印”，由两部分组成——维度外键和度量值。维度外键用来指出这行发生在哪个时间、哪个门店、哪个商品上；度量值则是真正要分析的数字，比如销售金额、销售杯数。当我们说“建立星型模型”时，说的就是用事实表做中心，把很多维度表挂在周围。

事实表的价值在于它能回答“有多少、多少钱、多频繁”这类定量问题，而且一旦设计好，可以稳定支撑数年的分析需求。设计事实表最关键的动作，就是认清业务过程、定义每行的含义、挂上正确的维度外键、放入合适的度量值。

阿茶发现，只要把“发生什么 + 数字多少”这对组合记清楚，生意账就立住了。接下来要决定的是：同一个业务过程，到底该怎么用不同的账本记录？这就要走进三种事实表类型。

事务事实表

阿茶的第一本账是收银台上的流水账。每卖出一杯奶茶，她就在本子上添一行：几点几分、哪个顾客、哪款奶茶、多少钱。即使同一个顾客一口气买了五杯，她也会写五行，因为每一行代表一次独立的事件。这种“来一笔、记一笔”的记账方式，就是事务事实表。

事务事实表的每一行对应一个业务事件，是各种事实表中最细、最原始的一种。它的最大特点是“追加不更新”：新增的销售记录只会插到表尾，历史行永远不会被修改。因为它完整保留了每一次发生的细节，所以能回答“昨天卖了多少杯”“哪个时段是高峰”“哪种奶茶最畅销”这类明细分析问题。

在数仓实践中，订单流水表、支付流水表、点击日志表都是典型的事务事实表。ETL 作业通常在每日结束后，把当天新增的事务追加进事实表，并记录一个时间戳。它的粒度天然是“一次事件”，所以维度外键组合通常就是事件本身的编号，加上发生时间和地点。

阿茶盯着流水账，心里踏实了：每一分钱都有来龙去脉。但她很快发现，流水账只能告诉她“发生了什么”，却回答不了“打烊时还剩多少珍珠”。

周期快照事实表

晚上九点，阿茶关店后开始数库存：珍珠还剩两袋，茶包还剩一箱，杯子还剩半箱。她把数字写进另一本账——盘点账。这本账不记今天卖了多少，而是记“今天结束时还剩多少”。每天晚上拍一张“库存照片”，日子久了就是一张库存趋势图。这种固定周期、拍状态照的记账方式，就是周期快照事实表。

周期快照事实表按固定的时间周期，给每个业务维度拍一次状态快照。每一行代表“某个周期末，某个维度组合下的状态值”，比如“2024年1月1日，A门店，珍珠库存80袋”。它非常适合余额、库存量、累计值等状态型指标，因为这些数字只在某个时点才有意义，把每一笔变动都摊开反而无法直接回答“现在还剩多少”。

周期快照事实表的度量通常是“期末值”或“期间汇总值”，如账户日终余额、月累计销售额。它的半可加性特点非常明显：按门店、商品维度相加有意义，但沿时间维度相加没有意义——你不能把周一库存和周二库存加起来说成“总库存”。

阿茶的盘点账让她一眼看清库存水位，及时补货。可她还缺一本账：那些下了大订单却迟迟没来取的顾客，到底卡在哪一步？这就要用到第三本账。

累积快照事实表

某天，一位企业客户订了 100 杯定制奶茶。阿茶从下单那一刻起，就在追踪这个订单的每一步：下单、付款、开始制作、取货离开。这本追踪账最特别的地方是一个订单只占一行，随着流程推进不断更新这一行，直到订单完成才“定稿”。这种记录流程完整生命周期的记账方式，就是累积快照事实表。

累积快照事实表适用于有明确开始和结束的业务流程，如订单履约、物流派送、售后处理。它的每一行代表一个流程实例，并且会为每个关键里程碑保存一个时间戳字段。订单刚创建时，这一行只有“下单时间”；支付了，就填上“支付时间”；出库了，再填上“发货时间”。分析师可以通过各时间戳之间的差值，精确计算每个环节耗时。

相比事务事实表和周期快照表，累积快照事实表的行会被反复更新，粒度永远固定为“一个流程实例”。这让它特别擅长回答“平均配送时长”“哪一步耗时最长”“本月履约超时订单有多少”这类跨阶段分析问题。

阿茶的三本账都齐了。可是把账本铺开时，她又犯难了：同一件事，流水账能写一行，盘点账为什么也能写一行？一行到底代表什么，得先有个说法——这就是粒度。

粒度设计原则

阿茶发现，流水账可以一行记一笔销售，但如果顾客一次买五杯，她也可以选择把五杯合成一行，记成“5杯、50元”。两种写法都不错，但分析能力完全不同。这个“一行字到底写多细”的规则，就是事实表的粒度。粒度是事实表设计最先要回答的问题：一行到底代表什么？

事实表的粒度由维度外键组合决定。组合越细，粒度越细，行数越多；组合越粗，粒度越粗，行数越少。数仓建模有一条铁律：先声明粒度，再选维度，最后定度量。因为粒度没定，你不知道要不要包含某个维度，也不知道度量应按什么层级汇总。

举个例子，订单事实表可以按“订单行”为粒度，那么一个包含三种商品的订单会产生三行；也可以按“整单”为粒度，那这个订单只占一行，商品明细信息就要忍痛舍弃。粒度还影响存储量和性能：粒度太细，数据量巨大；粒度太粗，分析时无法下钻。因此，设计者必须先问业务方：你们最常要看哪一层细节？

阿茶终于明白了：先写清楚一行是什么，再往里面填外键和数字。账本的行格式定了，接下来还要搞清楚一件事——账本里的数字，到底能不能随便相加？

维度度量关联

阿茶看着账本上的数字，心里冒出几个问题：销售额可以今天加明天，但库存量能周一加周二吗？单价能两个加起来说均价吗？显然都不行。事实表中的数字按“可加性”分成三类：可加、半可加、非可加。可加度量如销售金额，可以沿任意维度相加；半可加度量如库存量，沿除时间外的维度可加；非可加度量如单价、利润率，怎么加都会失真。

维度外键则相当于账本上的“标签”，每个外键都连接一张维度表。比如“门店键”指向门店维度表，告诉你这个数字来自 A 店还是 B 店；“时间键”指向日期维度表，告诉你这个数字发生在哪一天。事实表通过外键与维度表关联，才有了钻取、切片、过滤的能力。

设计事实表时，要将高频筛选和分析字段提取为外键，把真正要聚合的数字放成度量列。度量列的选取直接影响后续报表的灵活度——可加字段尽量做成数值型度量，非可加字段则保留原始值，交给应用层去计算比率，避免在事实表中直接存放易误导的派生结果。

阿茶把数字的“性格”摸清了：有的能加，有的不能加；所有数字都要靠维度标签才能说清来路。最后一步，她要根据不同问题来选账本。

选型设计策略

阿茶总结出一套“对号入座”口诀：要问卖了多少钱、卖了多少杯，翻开流水账——事务事实表；要问打烊时还剩多少库存，翻开盘点账——周期快照事实表；要问一个订单从下达到取货花了多久，翻开追踪账——累积快照事实表。三种账本各回答一类问题，而且可以同时存在。

实际操作中，一个业务过程往往需要多张事实表互相配合。比如电商平台：订单明细用事务事实表，每日库存用周期快照事实表，订单履约进度用累积快照事实表。它们可以共享同一组维度表，但各自的粒度和更新策略不同。设计时，要依据业务的分析频率和查询模式来决定：高频事件用事务表保明细，周期状态用快照表提供时点视图，长链路用累积表追踪阶段耗时。

选型没有绝对的对错，但有明确的依据：先看业务要分析“事件、状态还是流程”，再定粒度，再定事实表类型。一个优秀的数仓模型，往往就是把三本账组合起来，用不同视角共同拼出业务全貌。

阿茶的三本账终于各归其位：流水账负责“发生了什么”，盘点账负责“剩下多少”，追踪账负责“走到哪一步”。真实的数仓工程师，每天都在替企业做同样的事情——用三本账把业务真相记录下来。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""三本账最小演示事务表:事件一行;快照表:时点一行;累积表:流程一行"""from datetime import date, timedelta  def transaction_fact(events):    """事务事实表:每个事件追加一行,不更新历史"""    rows = []    for e in events:        rows.append({            "time": e["time"], "shop": e["shop"],            "drink": e["drink"], "cups": e["cups"],            "amount": e["amount"]        })    return rows  def snapshot_fact(days_stock):    """周期快照事实表:每个周期末,每个维度组合一行状态"""    rows = []    for day, stock in days_stock.items():        for item, qty in stock.items():            rows.append({"day": day, "item": item, "qty": qty})    return rows  def accum_fact(orders):    """累积快照事实表:一个订单一行,取开始与完成时间算时长"""    rows = []    for order in orders:        total_hours = (order["done"] - order["start"]).total_seconds() / 3600        rows.append({            "order_id": order["id"],            "start": order["start"],            "done": order["done"],            "hours": total_hours        })    return rows  if __name__ == "__main__":    day1 = date(2024, 1, 1)    sales = [        {"time": day1, "shop": "A店", "drink": "珍珠奶茶", "cups": 2, "amount": 30},        {"time": day1, "shop": "B店", "drink": "柠檬茶",   "cups": 1, "amount": 12}    ]    print("事务事实表(每笔销售一行):")    for r in transaction_fact(sales):        print(" ", r)     stock = {        day1: {"珍珠": 80, "茶包": 60},        day1 + timedelta(days=1): {"珍珠": 55, "茶包": 60}    }    print("周期快照事实表(每天库存一行):")    for r in snapshot_fact(stock):        print(" ", r)     orders = [        {"id": "M001",         "start": day1 + timedelta(hours=10),         "done": day1 + timedelta(hours=18)}    ]    print("累积快照事实表(一单一行):")    for r in accum_fact(orders):        print(" ", r)

1. for e in events:逐笔读取销售事件，体现事务表一次一行。
2. rows.append({"time": e["time"], ...})每行由时间、门店等维度键和金额等度量组成。
3. for day, stock in days_stock.items():按天遍历库存，体现周期快照的“按时点拍状态”。
4. rows.append({"day": day, "item": item, "qty": qty})快照行 = 日期 + 物品维度 + 期末库存量。
5. total_hours = (order["done"] - order["start"]).total_seconds() / 3600累积快照用开始、结束时间戳计算流程时长。

常见误区

面试题