周期快照事实表怎么设计？
面试怎么回答
周期快照事实表按固定周期记录业务对象在某个时点的状态，设计时先明确周期、时点口径和粒度，例如“每天日终、每个仓库每个商品一行”。分区通常用快照日期，度量要区分可加和半可加。生产中还要明确零值是否保留、业务时区，以及迟到流水触发的历史分区重算策略。它适合趋势和时点分析，但不能替代用于过程追溯的事务事实表。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务希望查看“每天结束时，每个仓库还有多少库存”，并能比较月初、月末和任意一天的状态。
只保存最新值无法回看历史；只保存库存变动流水，每次查询又要从头累计。
这类需求通常适合：周期快照事实表。
周期快照事实表不是记录一次业务事件，而是在固定时间间隔，对一组业务状态做一次完整或约定范围内的快照。
先定周期，再定粒度
设计前先把一句话说完整：
每天结束时，每个仓库、每个商品保存一行库存状态。
这句话同时定义了：
- 周期：每天
- 时间口径：日终
- 粒度：日期 × 仓库 × 商品
- 度量：库存量、可售量、冻结量、库存金额等
如果业务按小时运营，周期可能是小时；如果只做财务月报，也可能按月。周期越细，数据量越大，但分析时效和回溯能力更强。
它和事务事实表有什么区别？
事务事实表记录“发生了什么”：入库一笔、出库一笔、支付一次。
周期快照事实表记录“这个时点是什么状态”：当天库存 120、账户余额 5000、在贷客户数 300。
事务表适合追溯过程，快照表适合趋势、时点和同比环比分析。很多场景两者会同时保留：流水负责追根，快照负责高效查询。
表结构怎么设计？
以库存日快照为例：
inventory_snapshot_di (
snapshot_date,
warehouse_id,
sku_id,
on_hand_qty,
available_qty,
frozen_qty,
inventory_amount,
etl_time
)主键语义是 snapshot_date + warehouse_id + sku_id。实际存储中通常按 snapshot_date 分区，再根据查询模式设计分桶、排序或聚簇字段。
度量还要区分：
- 可加：不同仓库的同一天库存量通常可以相加
- 半可加：同一商品跨日期的库存量通常不能直接求和
- 不可加：库存周转率等比率应基于分子分母重新计算
三个容易踩的坑
零值快照是否保留？
不保留零库存行能节省空间，但会把“库存为零”和“数据漏了”混在一起。要根据分析口径明确稠密快照还是稀疏快照。
日终到底按哪个时区？
跨时区业务必须明确业务时区和关账时间，否则同一天的快照不可比。
迟到流水如何回刷？
迟到的入库或订单可能改变历史状态。要定义重算窗口、分区覆盖策略、版本或校验机制，不能只修当天最新快照。