大家好，又见面了，我是你们的朋友全栈君。
DWD（Data WareHouse Detail）数据明细层，主要是将从业务数据库中同步过来的ODS层数据进行清洗和整合成相应的事实表。事实表作为数据仓库维度建模的核心，需要紧紧围绕着业务过程来设计。在拿到业务系统的表结构后，进行大概的梳理，再与业务方沟通整个业务过程的流转过程，对业务的整个生命周期进行分析，明确关键的业务步骤，在能满足业务需求的前提下，尽可能设计出更通用的模型。
业务方有时只仅仅只是考虑了当下的情况。例如业务想要一个审核通过人员的明细数据，我们设计了一个全量的审核明细表，过了几天，业务方又想要分析审核流程中每个环节的转化情况，我们又要设计一张增量的明细表。一张表就可以满足需要的事被弄成了两张，而如果放弃前一张表一方面否定了自己之前的工作，另一方面所有依赖的下游都需要变更取数逻辑，增加了工作量；不放弃表的数量增加，数据就有了两个逻辑出口，统一口径和数据管理也成为一个问题。而这一切都可以在模型设计前期与业务沟通的过程中避免。因此我们在与业务沟通时，一方面了解整个业务周期过程，另一方面要考虑的是从业务方的角度来，分析当下业务需求和未来潜在的需求，尽量做到一次设计，全面覆盖。
DWD层中主要的事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。
（一）事务事实表
事务事实表，主要分两种单事务事实表和多事务事实表。
1.单事务事实表
针对单个业务过程而设计一个事实表。这样的设计可以对每个业务过程进行单独分析，并且对于业务方而言，符合其逻辑认知，使用起来没有障碍。
2.多事务事实表
单事务事实表比较容易实现，但也有一定的缺点。1.在多个业务过程在维度和粒度一致的前提下，且业务过程维度较多而事实相对少的情况下，我们每个业务过程都需要去join关联维度，一方面存储量增加，另一方面多次重复的join维度带来的存储计算量也会增加。2.多个业务过程多张表，随着业务发展，表的数量明细资产太多不方便管理。所以就有了多事务事实表。
我们使用多事务事实表来替代单事务事实表需要明白3个问题 1.如何同时记录多个业务过程的信息（多事务的实现）？2.如何进行单个业务过程的统计分析（成为单事务事实表的替代品）？3.什么时候可以使用多事务事实表（多事务的局限性）？
针对第一个问题，一般而言针主要做法是对每个业务过程的度量都使用一个字段进行保存 ，即不同的事实使用不同的字段进行存放;如果不是当前业务过程的度量，则采取零值处理方式。这样我们取每个实例最新的一条记录就可以看到该实例截止到统计日期的业务进度。
针对第二个问题，单事务事实表一般用来分析无非从两方面入手，一个是明细数据，二是统计数据，统计某个时间区间内的事务发生频率，例如最近一周的下单数量。明细数据在多事务事实表中也会保存，而统计数据，我们需要对每个业务过程都设置一个是否当天完成的字段来解决。我们可以统计周期区间内有多少个当天完成作为统计结果。
针对第三个问题，1.多事务事实表中的多个业务过程其粒度和维度必须是一致的。如果粒度不一致则没办法整合在一起。2. 多事务事实表当实例没有在一天完结，则会存在多条数据，如果需要统计每个实例的业务过程时长或者要看每个实例的最新状态，需要筛选所有数据最新的数据，再对每条数据进行计算，比较消耗性能。
这里在给出多事务表在具体设计时的操作，传统的多事务表可能会一个业务过程一条数据，只有当前发生的业务过程有相应数据，其他数据均置零。假如一天一个实体有多个业务过程发生，我们应该有几条数据。这里有两种做法，一个是每个业务过程都有一条数据，非当前业务过程的度量都置零。这样的好处是我们统计度量时可以直接sum或者其他操作。另一种方式是保留最新业务过程之前的业务过程的所有度量，这样总条数会减少（同一天可能多个业务过程都完成），但是统计时必须要加上是否当天的标记来过滤再统计（保证一个业务过程只有一条记录有效）。
事务事实表区别:
| 单事务事实表 | 多事务事实表 | |
| 业务过程 | 一个 | 多个 |
| 粒度 | 相互之间不相关 | 相同粒度 |
| 维度 | 相互之间不相关 | 一致 |
| 事实 | 只取当前业务过程中的事实，且需要为可累加事实 | 保留多个业务过程巾的事实， 非当前业务过程中的事实需要置零处理，且需要为可累加事实 |
| 冗余维度 | 多个业务过程 ， 则需要冗余多次 | 不同的业务过程只需要冗余一次（记录次数<=业务过程数） |
| 理解程度 | 易于理解，不会混淆 | 难以理解 ， 需要通过标签来限定 |
| 计算存储成本 | 较多 ， 每个业务过程都需要计算 | 较少 ， 不同业务过程融合到一起 ， 降低了储存计算量， 但是会存在大量零值。 |
（二）累计快照事实表
为了解决多事务事实表第三个问题的第二点，能不能有一张表保存实例所有的最新状态，这样我们就不需要每次统计全量数据都要取全量去重取最新数据进行计算统计。这其实就是累计快照事实表的产生。将所有实例都只保存最新的状态。其实现方式可以以拉链表的方式来实现，以事务表中历史最新数据作为初始数据，每天更新其中的数据。这样既可以保存一份全量数据，并且可以在表的基础上计算相关的业务时长。
但这也导致一个问题，数据量太大。如果每天都存储全量最新，我们必须要将表的生命周期设置相比较而言小一点。
（三）周期快照事实表
事务事实表主要储存的都是可累加行的度量。当需要一些状态度量时，比如账户余额、买卖家星级 、 商品库存、卖家累积交易额等，事务事实表就不太适合。就需要周期快照事实表。我们按照一定的周期进行汇总。周期快照事实表产出方式1.对于可以通过对事务表聚集的数据，从事务事实表中汇总得到，但是这样可能逻辑比较复杂。2.无法聚集的数据，从操作系统中以快照的方式同步下到ods层，再在进行加工。
表之间的关系图：
总结
数据明细层是下游计算各种信息的基础，数据资产的底层建设，我们在设计时，尽量设计通用的模型。针对不同的业务需求，采用不同的表设计，本篇仅介绍了相关表的概念和逻辑，具体设计过程，要针对具体业务再展开。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/153221.html原文链接：https://javaforall.net
