[大数据]数据仓库之DWD层

DWD（Data WareHouse Detail）数据明细层，主要是将从业务数据库中同步过来的ODS层数据进行清洗和整合成相应的事实表。事实表作为数据仓库维度建模的核心，需要紧紧围绕着业务过程来设计。在拿到业务系统的表结构后，进行大概的梳理，再与业务方沟通整个业务过程的流转过程，对业务的整个生命周期进行分析，明确关键的业务步骤，在能满足业务需求的前提下，尽可能设计出更通用的模型。

业务方有时只仅仅只是考虑了当下的情况。例如业务想要一个审核通过人员的明细数据，我们设计了一个全量的审核明细表，过了几天，业务方又想要分析审核流程中每个环节的转化情况，我们又要设计一张增量的明细表。一张表就可以满足需要的事被弄成了两张，而如果放弃前一张表一方面否定了自己之前的工作，另一方面所有依赖的下游都需要变更取数逻辑，增加了工作量；不放弃表的数量增加，数据就有了两个逻辑出口，统一口径和数据管理也成为一个问题。而这一切都可以在模型设计前期与业务沟通的过程中避免。因此我们在与业务沟通时，一方面了解整个业务周期过程，另一方面要考虑的是从业务方的角度来，分析当下业务需求和未来潜在的需求，尽量做到一次设计，全面覆盖。

DWD层中主要的事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。

（一）事务事实表

事务事实表，主要分两种单事务事实表和多事务事实表。

1.单事务事实表

针对单个业务过程而设计一个事实表。这样的设计可以对每个业务过程进行单独分析，并且对于业务方而言，符合其逻辑认知，使用起来没有障碍。

2.多事务事实表

单事务事实表比较容易实现，但当我们想要了解整个业务流程的情况时，如果是单事务事实表就需要多个单事务事实表进行join，再进行统计。这样处理起来就比较麻烦了。所以就有了多事务事实表。

我们使用多事务事实表来替代单事务事实表需要明白3个问题 1.如何同时记录多个业务过程的信息（多事务的优势）？2.如何进行单个业务过程的统计分析（成为单事务事实表的替代）？3.什么时候可以使用多事务事实表（多事务的局限性）？

针对第一个问题，一般而言针主要做法是对每个业务过程的度量都使用一个字段进行保存 ，即不同的事实使用不同的字段进行存放;如果不是当前业务过程的度量，则采取零值处理方式。这样我们取每个实例最新的一条记录就可以看到该实例截止到统计日期的业务进度。

针对第二个问题，单事务事实表一般用来分析无非从两方面入手，一个是明细数据，二是统计数据，统计某个时间区间内的事务发生频率，例如最近一周的下单数量。明细数据在多事务事实表中也会保存，而统计数据，我们需要对每个业务过程都设置一个是否当天完成的字段来解决。我们可以统计周期区间内有多少个当天完成作为统计结果。

针对第三个问题，1.多事务事实表中的多个业务过程其粒度和维度必须是一致的。如果粒度不一致则没办法整合在一起。2. 多事务事实表当实例没有在一天完结，则会存在多条数据，如果需要统计每个实例的业务过程时长或者要看每个实例的最新状态，需要筛选所有数据最新的数据，再对每条数据进行计算，比较消耗性能。

事务事实表区别:

（二）累计快照事实表

为了解决多事务事实表第三个问题的第二点，能不能有一张表保存实例所有的最新状态，这样我们就不需要每次统计全量数据都要取全量去重取最新数据进行计算统计。这其实就是累计快照事实表的产生。将所有实例都只保存最新的状态。其实现方式可以以拉链表的方式来实现，以事务表中历史最新数据作为初始数据，每天更新其中的数据。这样既可以保存一份全量数据，并且可以在表的基础上计算相关的业务时长。

但这也导致一个问题，数据量太大。如果每天都存储全量最新，我们必须要将表的生命周期设置相比较而言小一点。

（三）周期快照事实表

事务事实表主要储存的都是可累加行的度量。当需要一些状态度量时，比如账户余额、买卖家星级 、 商品库存、卖家累积交易额等，事务事实表就不太适合。就需要周期快照事实表。我们按照一定的周期进行汇总。周期快照事实表产出方式1.对于可以通过对事务表聚集的数据，从事务事实表中汇总得到，但是这样可能逻辑比较复杂。2.无法聚集的数据，从操作系统中以快照的方式同步下到ods层，再在进行加工。

表之间的关系图：

总结

数据明细层是下游计算各种信息的基础，数据资产的底层建设，我们在设计时，尽量设计通用的模型。针对不同的业务需求，采用不同的表设计，本篇仅介绍了相关表的概念和逻辑，具体设计过程，要针对具体业务再展开。

?