- 背景
- 数据同步方式
- 事实表类型及使用场景
- 事实表设计合并依据
- 总结
背景
在构建数据仓库总线矩阵完成后，可着手事实表和维度表的设计。数仓总线矩阵里每个业务过程都会生成至少一张事实表（识别业务过程的本质就是识别要构建的事实表），因为有可能一个原子事件涉及多张表的情况。同时，因上游业务系统老旧，表设计水平、使用场景等因素，或并不是都是标准3NF范式设计，将多个业务过程事件发生存储在一张表的情况，对于此种情况做事实表设计时，根据使用场景可能会进行表拆分考虑，这里不再展开。这里重点讲述尽量可能将分散在各个业务系统中相同或相似的业务过程进行整合的情况。
对于单事务事实表,一个业务过程建立一个事实表,只反映一个业务过程的事实;对于多事务事实表,在同一个事实表中反映多个业务过程。多个业务过程是否放到同一个事实表中,首先需要分析不同业务过程之间的相似性和业务源系统。还会考虑使用场景、数据共同项、数据产出时效、数据逻辑变动频率、数据量、数据安全性等因素，再决定是否适合放到同一个事务事实表中。
事实表设计是需识别业务过程、探查数据粒度、维度、事实等几个步骤，再根据数据粒度，数据更新方式、数据量大小和使用场景等因素判断是否进行多业务过程或表进行合并，再选择合适的事实表类型进行模型设计。
数据同步方式
在进行表设计之前需要进行数据探查，如数据粒度、字段是否在使用、字段是否为空、记录是否完整、数据更新方式，即粒度更新方式，所谓粒度，就是表中一行记录代表什么，即一个主体何时何地为何发生了什么事件。再根据数据量大小、不同粒度更新方式，可分为以下三种增量、全量和合并数据同步方式：
- 增量：流水表只追加，记录无更新无删除，数据量小可以全量，数据量大一般情况是增量抽取方式（考虑未来数据量的变化）
- 全量：存在数据记录更新
- 合并：存在数据记录删除（合并ETL工具集成可直接使用，不集成抽取后处理也行）
对于无更新无删除记录流水表使用增量、全量都可以，可依据数据量大小来选，因为增量表分区表当成全量表使用，分区条件限定为从历史到当前；对于存在数据记录更新的，可使用全量抽取，否则会导致数据抽取不全或数据存在重复；对于数据记录删除的，需合并之前历史数据，否则会数据丢失，无法反应历史变化的特性。
事实表类型及使用场景
事实表类型蛮多的可根据数据粒度更新方式或使用场景进行合理使用，在模型实际设计过程中，有的无相关使用场景或有的在平常已经在使用了这些事实表类型，但也不清楚是哪类事实表，特别是周期快照和累积快照事实表，这里对常用的事务事实表、周期快照事实表和累积快照事实表进行重点详细说明。
- 事务事实表 事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表,这类健壮的维度确保对事务数据的最大化分片和分块。事务事实表可以是稠密的,也可以是稀疏的,因为仅当存在度量时才会建立行。这些事实表总是包含个与维度表关联的外键,也可能包含精确的时间戳和退化维度键。度量数字事实必须与事务粒度保持一致。事务事实表也即一个事实表同时表达了一个或多个业务过程，用于统计事件发生情况。事务事实表主要分为单事务事实表和多事务事实表。 使用场景：可回答关于非预期的行为的详尽问题的表，如交易流水表
- 周期快照事实表 周期快照事实表中的每行汇总了发生在某一标准周期,如某一天、某周、某月的多个度量事件。粒度是周期性的,而不是个体的事务。周期快照事实表通常包含许多事实,因为任何与事实表粒度一致的度量事件都是被允许存在的。这些事实表其外键的密度是均匀的,因为即使周期内没有活动发生,也会在事实表中为每个事实插入包含0或空值的行。周期快照事实表类型：单维度周期快照事实表（单一个维度）、混合维度周期快照事实表（多个维度）、全量快照事实表(对于状态一直变化的数据，用全量快照表统计最新的状态) 使用场景：可生成业务常规的重要的测量或度量可预测视图的表，如账户余额表、用户积分表
- 累积快照事实表 累积快照事实表的行整合了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程(例如,履行订单或索赔过程)具有定义的开始点,标准中间过程,定义的结束点,它们在此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含日期外键。累积快照事实表中的一行,对应某一具体的订单,当订单产生时会插入一行当管道过程发生时,累积事实表行被访问并修改。这种对累积快照事实表行的一致性修改在三种类型事实表中具有特性,除了日期外键与每个关键过程步骤关联外,累积快照事实表包含其他维度和可选退化维度的外键。如信用贷款用户全流程表milestone就是典型的累积快照事实表，累积快照事实表的粒度是每个用户一行记录，如首次申请、首次登陆、首次授信、首次借款、知道用户注销的关键时间节点或步骤，都有每个步骤时间戳（日期外键），并一个用户的唯一一条记录在更新或修改。 使用场景：可跟踪某主体的具体有限的生命周期的状态的表，并一个主体只存在唯一一条记录在有限的不断更新。如用户全流程表
事实表设计合并依据
在进行事实表设计或进行数仓模型评审是尽量可能将分散在各个业务系统中相同或相似的业务过程进行整合，关于事实表是否应该对多种表进行合并或整合，无论是纵向合并还是横向合并众说纷纭、莫衷一是，这里给出几个是否合并考虑因素，仅供参考：
- 使用场景，如果存在这样使用场景，考虑到减少业务用户使用数据复杂度可进行相关表进行合并，同样也考虑其他因素。
- 数据共同项，特别是纵向合并时（如Union），需考虑到是否相同字段、相同含义、相同数据类型等因素，否则会导致数据稀疏。
- 数据产出时效，多张进行合并时，合并后表的最终产出时间由最晚那张表决定，如其他表都是0凌晨产出，有张表是晚上11点产出，这样不建议合并。
- 数据变动频率耦合性，在进行多张合并时，表的逻辑是否稳定，如果存在一张逻辑经常变化，导致整张表的逻辑都在变化，会导致合并后的表数据不稳定。
- 数据量，特别是纵向合并时（如Union）其中几张数据量不大，可快速查询，如果其中一张巨大无比，合并后导致其他数据也查询巨慢，这种情况也需考虑的。
- 数据粒度，合并之前需要考虑，数据粒度是否一致的，如一张表中即用明细又存在汇总数据，粒度不一致会导致错用。
- 数据安全，在表进行合并时，要考虑到数据安全问题，表查询权限可控制到库级别、表级别、字段级别，但是目前还无法控制记录级别（自研功能另说），特别是纵向合并时，如策略表，把其他的策略和风控策略进行合并。其他业务用户看到风控策略这是不安全的。
总结
本文从数据同步方式分类，根据数据更新方式等因素进行事实表设计时，要选择合适事实表类型，关于事实表是否应该合并给出几点考虑，当然维度表设计也要考虑些原则如维度表平面化，提高易用性，减少用户使用复杂度；常用维度退化到事实表，提高查询性能，注意要维护好数据的一致性；保证一致性维度全局设计等。
