共计 5192 个字符，预计需要花费 13 分钟才能阅读完成。
每个数据仓库都蕴含一个或者多个事实数据表。其中可能蕴含业务销售数据，如现金注销事务所产生的数据，通常蕴含大量的行。事实数据表的次要特点是蕴含数字数据（事实），并且这些数字信息能够汇总，以提供无关单位作为历史的数据，每个事实数据表蕴含一个由多个局部组成的索引，该索引蕴含作为外键的相关性维度表的主键，而维度表蕴含事实记录的个性。
事实表根底
1、事实表特色
事实表作为数仓维度建模的外围，紧紧围绕着业务过程来设计，通过获取形容业务过程的度量来表白业务过程，蕴含了援用的维度和业务过程无关的度量。事实表中一条记录所表白的业务细节水平被称为粒度(业务中的细节水平)。通常粒度能够通过两种形式来表白：一种是维度属性组合所示意的细节水平，另一种是所示意的具体业务含意。
作为度量业务过程的事实（事实表属性），个别为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型：
可加性事实 是指能够依照与事实表关联的任意维度进行汇总。
半可加性事实 只能依照特定维度汇总，不能对所有维度汇总。
不可加事实 不具备可加性，比方比率型事实。对于不可加性事实可分解为可加的组件来实现汇集。
2、有事实的事实表
有事实表分为三种类型：事务事实表、周期快照事实表和累积快照事实表。
3、无事实的事实表
无事实的事实表能够用来跟踪事件的产生。例如，在给定的某一天中产生的学生加入课程的事件，可能没有可记录的数字化事实，但该事履行带有一个蕴含日期、学生、老师、地点、课程等定义良好的外键。利用无事实的事实表能够按各种维度计数上报这个事件。
事实表设计规定
尽可能蕴含所有与业务过程相干的事实；
只抉择与业务过程相干的事实；
合成不可加性事实为可加的组件；比方订单的优惠率，应该合成为订单原价金额与订单优惠金额
在抉择维度和事实之前必须先申明粒度；
在同一个事实表中不能有多种不同粒度的事实；粒度的申明是事实表设计中不可漠视的重要一步，粒度用于确定事实表中一行所示意业务的细节档次，决定了维度模型的扩展性，在抉择维度和事实之前必须先申明粒度，且每个维度和事实必须与所定义的粒度保持一致
在同一个事实表中不能有多种不同粒度的事实；
事实的单位要保持一致；
对事实的 null 值要解决；在数据库中 null 值对罕用的大于或小于等 SQL 不失效，倡议应用零值填充
应用进化维度进步事实表的易用性；目标次要是为了缩小上游用户应用时关联多个表的操作。间接通过进化维度实现对事实表的过滤查问、管制聚合档次、排序数据以及定义主从关系等。
事实表设计办法
Kimball 的四步维度建模办法：抉择业务过程、申明粒度、确定维度、确定事实。
Step 1: 抉择业务过程及确定事实表类型。
在明确了业务需要当前，接下来须要进行具体的需要剖析，对业务的整个生命周期进行剖析，明确要害的业务步骤，从而抉择与需要无关的业务过程。(业务过程通常应用行为动词示意业务执行的流动)
Step 2: 申明粒度。
粒度的申明是事实表建模十分重要的一步，意味着准确定义事实表的每一行所示意的业务含意，粒度传递的是与事实表度量无关的细节档次。明确的粒度能确保对事实表中行的意思的了解不会产生混同，保障所有的事实依照同样的细节档次记录。
Step 3 : 确定维度。
实现粒度申明当前，也就意味着确定了主键，对应的维度组合以及相干的维度字段就能够确定了，应该抉择可能形容分明业务过程所处的环境的维度信息。
Step 4 : 确定事实。
事实能够通过答复“过程的度量是什么”来确定。应该抉择与业务过程无关的所有事实，且事实的粒度要与所申明的事实表的粒度统一。事实有可加性、半可加性、非可加性三种类型，须要将不可加性事实合成为可加的组件。
Step 5: 冗余维度。
冗余维度是在 kimball 维度建模办法根底上新增的步骤。次要是因为在大数据的事实表模型设计中，须要思考更多的是进步上游用户的应用效率，升高数据获取的复杂性，缩小关联的表数量。所以通常事实表中会冗余不便上游用户应用的罕用维度，以实现对事实表的过滤查问、管制聚合档次、排序数据以及定义主从关系等操作。
有事实的事实表
有事实表分为三种类型：事务事实表、周期快照事实表和累积快照事实表。
1、事务事实表单事务事实表，
针对于每个业务过程设计一个事实表，不便每个业务过程进行独立剖析钻研。
长处：更不便跟踪业务流程细节数据，针对非凡的业务剖析场景比拟不便和灵便，数据处理上也更加灵便;
弊病：数仓中须要治理太多的事实表，同时跟踪业务流转不够直观多事务事实表，将不同的事实放到同一个事实表中，即同一个事实表蕴含不同的业务过程。
多事务事实表在设计时有两种办法进行事实的解决：
一是不同业务过程的事实应用不同的事实字段进行寄存：
二是不同业务过程的事实应用同一个事实字段进行寄存，但减少一个业务过程标签。
长处：可能更直观的跟踪业务流转和以后状态，流程事实集中，不便大部分的通用剖析利用场景，因为和业务侧的数据模型设计思路统一，也是目前最罕用的事实表设计;
弊病：细节数据跟踪不到位，非凡场景的剖析不够灵便;
两种表的设计区别在于对业务流程的拆分思路不同，具体抉择事实表的构建思路，须要依据理论的业务确定，个别倡议两者联合。
父子事实的解决形式，通过摊派父订单的金额将所有业务过程的度量全副带进购物网站交易事务事实表中，包含下单数量、商品价格、子订单折扣、下单摊派比例、父订单领取金额、父订单领取邮费、父订单折扣、子订单下单金额、子订单下单无效金额、领取摊派比例、子订单领取金额等，将父子事实同时冗余到事务表中。
设计准则
1. 事实完整性
事实表蕴含与其形容的过程无关的所有事实，即尽可能多地获取所有的度量。
2. 事实一致性
在确定事务事实表的事实时，明确存储每一个事实以确保度量的一致性。
3. 事实可加性
事实表确定事实时，往往会遇到非可加性度量，比方摊派比例、利润率等，尽管它们也是上游剖析的关键点，但往往在事务事实表中关注更多的是可加性事实，上游用户在聚合统计时更加不便。
2、周期快照事实表
快照事实表在确定的距离内对实体的度量进行抽样，这样能够很容易地钻研实体的度量值，而不须要汇集长期 的事务历史。特色用快照采样状态
快照事实表以预约的距离采样状态度量。这种距离联结一个或多个维度，将被用来定义快照事实表的粒度，每行都将蕴含记录所波及状态的事实。
快照粒度
事务事实表的粒度能够通过业务过程中所波及的细节水平来形容，但快照事实表的粒度通常总是被多维申明，能够简略地了解为快照须要采样的周期以及什么将被采样。
密度与稠密性
快照事实表和事务事实表的一个要害区别在密度上。事务事实表是稠密的，只有当天产生的业务过程，事实表才会记录该业务过程的事实，如下单、领取等；而快照事实表是浓密的，无论当天是否有业务过程产生，都会记录一行，比方针对卖家的历史至今的下单和领取金额，无论当天卖家是否有下单领取事实，都会给该卖家记录一行。
半可加性
在快照事实表中收集到的状态度量都是半可加的。与事务事实表的可加性事实不同，半可加性事实不能依据工夫维度取得有意义的汇总后果。设计实例单维度的每天快照事实表确定粒度、确定维度混合维度的每天快照事实表确定粒度、确定维度、确定状态度量全量快照事实表
相比单维度的快照事实表，多了一些冗余维度。例如，商品评估表，多了子订单维度、商品维度、评论者维度。
3、累计快照事实表
对于相似于钻研事件之间工夫距离的需要，采纳累计快照事实表能够很好地解决。如在统计买家下单到领取的时长、买家领取到卖家发货的时长等，事务事实表很难满足，须要用到累计快照事实表。
**
特色数据不断更新 **
针对于实体中的某一实例定期更新。
多业务过程日期
累积快照事实表实用于具备较明确起止工夫的短生命周期的实体，比方交易订单、物流订单等，对于实体的每一个实例，都会经验从诞生到沦亡等一系列步骤。对于商品、用户等具备长生命周期的实体，个别采纳周期快照事实表更适合。累积快照事实表的典型特色是多业务过程日期，用于计算业务过程之间的工夫距离。但联合阿里巴巴数据仓库模型建设的教训，对于累积快照事实表，还有一个重要作用是保留全量数据。非凡解决非线性过程购物网站个别流程是：下单、领取、发货、确认收货。但并不是所有的交易都会走此流程，比方买家下单之后不领取或敞开订单。针对这种非线性过程，解决状况次要有以下几种：
(1）业务过程的对立咱们以流程完结标记为根据，敞开订单也是完结标记，对立起来。
(2）针对业务要害里程碑构建全面的流程对于没有领取或没有发货的交易订单也将其纳入流程来，相干的业务字段置孔。
(3）循环流程的解决次要解决问题是一个业务过程有多个日期。应用业务过程的第一次产生日期还是最近产生日期，依据用户决定。多源过程
针对多源业务建模，次要思考事实表的粒度问题。
业务过程取舍
当领有大量的业务过程时，模型的实现复杂度会减少，特地是对于多源业务过程，模型的精合度过高，此时须要依据商业用户需要，选取要害的里程碑。
物理实现逻辑模型和物理模型密不可分，针对累积快照事实表模型设计，其有不同的实现形式。
第一种：增量存储 以业务实体的完结工夫分区。即每周期仅解决增量局部的数据，针对状态无变动的数据比拟适宜；
第二种：全量快照 状态有变动，每天的分区存储昨天的全量数据和当天的增量数据合并的后果，对于数据量在可控范畴内的状况能够采纳如下 保留策略: 如果存储空间和老本可承受，残缺存储，确保可能追溯到历史每天数据状态 存储空间无限，思考挪动历史快照数据到冷盘，须要应用的时候可复原 数据历史状态数据无太大价值，能够思考局部删除，比方近保留每月最初一天的快照数据；
第三种：拉链 针对于全量表的变动模式，数据量大、但迟缓变动、须要跟踪历史状态，和迟缓突变维相似。设计准则同事务事实表设计一样。
无事实的事实表
在维度模型中，事实表用事实来度量业务过程，不蕴含事实或度量的事实表称为无事实的事实表。尽管没有明确的事实，但能够用来反对业务过程的度量。常见的无事实的事实表次要有如下两种：
第一种是事件类的，记录事件的产生。如阿里巴巴数据仓库中，最常见的是日志类事实表。
第二种是条件、范畴或资格类的，记录维度与维度多对多之 间的关系。如客户和销售人员的分配情况、产品的促销范畴等。
汇集型事实表
数据仓库的性能是数据仓库建设是否胜利的重要规范之一。汇集次要是通过汇总明细粒度数据来取得改良查问性能的成果。通过拜访汇集数据，能够缩小数据库在响应查问时必须执行的工作量，可能疾速响应用户的查问，同时有利于缩小不同用户拜访明细数据带来的后果不统一问题。如阿里巴巴将应用频繁的专用数据，通过汇集进行积淀，比方卖家最近 l 天的交易汇总表、卖家最近 N 天的交易汇总表、卖家天然年交易汇总表等。这类汇集汇总数据，被叫作公共汇总层。
绝对于明细事实表，聚合事实表通常是在明细事实表的根底上，依照肯定的粒度粗细进行的汇总、聚合操作，它的粒度较明细数据粒度粗，同时随同着细节信息的失落; 在数仓层次结构中，通常位于 dws 层，个别作为通用汇总数据存在，也能够是更高粒度的指标数据。
1、根本准则
一致性 汇集表必须提供与查问明细粒度数据统一的查问后果。
防止繁多表设计 不要在同一个表中存储不同档次的汇集数据；否则将会导致双重计算或呈现更蹩脚的事件。
汇集粒度可不同 汇集并不需要放弃与原始明细粒度数据一样的粒度，汇集只关怀所须要查问的维度。
2、根本步骤
Step 1：确定汇集维度。
Step 2：确定一致性上钻。
Step 3：确定汇集事实。
3、常见汇集型事实表
数据仓库中，依照日期范畴的不同，通常包含以下类别的汇集事实表公共维度层 - 通用汇总
应答大部分可预期的、惯例的数据需要，通常针对模式绝对稳固的剖析、BI 指标计算、特征提取等场景，封装局部业务解决、计算逻辑，尽量避免用户间接应用底层明细数据，该层用到的数据范畴比拟宽泛。
日粒度
次要应答模式稳固的剖析、BI 日报、特征提取场景，同时日粒度也为后续累积计算提供粗粒度的底层，数据范畴个别为上一日的数据。
周期性累积
次要应答明确的周期性剖析、BI 周期性报表，数据范畴个别在某周期内的。
历史累积
顾名思义，历史以来某一特定数据的累积，通常在用户画像、经营剖析、特征提取方面场景较多，设计数据范畴比拟宽泛，通常是计算耗时较长的一部分，比方某门店累积营业额、某用户累积利润奉献、用户首次下单工夫(非可度量、描述性)。
4、汇集补充阐明
汇集是不逾越事实的
汇集是针对原始星形模型进行的汇总，为了获取和查问与原始模型统一的后果，汇集的维度和度量必须与原始模型保持一致，因而汇集是不逾越事实的。
汇集带来的问题
汇集会带来查问性能的晋升，但汇集也会减少 ETL 保护的难度。当子类目对应的一级类目产生变更时，先前存在的、曾经被汇总到汇集表中的数据须要被从新调整。这一额定工作随着业务复杂性的减少，会导致少数 ETL 人员抉择简略强力的办法，删除并重新聚集数据。
