数据仓库从0到1之数仓建模理论

从ODS层到ADS层，数据是越来越少的，数据分析都是以大量的数据为基础，对数据进行汇总聚合运算，抽丝剥茧，越往后数据的汇总层度越高，最后得到汇总的指标。

数仓分层原因

1. 将复杂问题简化，将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题；
2. 减少重复开发，规范数据分层，通过中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性；
3. 隔离原始数据，不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开；

数仓主体就是DWD(data warehouse detail：数据明细层),DWS(data warehouse service：服务数据层)，DWT(data warehouse topic:数据主题层)。其中DWS,DWT两层都是汇总数据，从DWD来。

各分层简介

ODS

存放原始数据，原始数据保持原状。原始数据一类是日志，一类是业务数据。业务数据从mysql导入进来，本身就是结构化的，以具体分隔符分割，可以直接记载到对应数据库。但是日志数据就不行，是一行一行的字符串，需要将字符串解析成可以导入hive的数据格式。

即ODS层主要是对日志进行解析，要考虑解析成多少张表，按照什么逻辑去解析？定下逻辑后，解析的SQL怎么写？

业务数据主要就是怎么建模？所谓的建模就是明确要建哪些表，明确表中有哪些字段，表与表之间有什么样的关联？建模有一些指导思想，比如维度建模，关系建模，数仓一般采用维度建模。

DWD

明细层是数仓中关键的一层，是数仓的地基。明细数据从ODS层来，明细数据就是最原始最详细的数据，即一行数据指代依次业务行为，比如说order_info，一行数据就是依次下订单行为，该行数据就是明细数据。

该层需要构建维度模型，一般采用雪花模型。

维度建模一般按照以下四个步骤：

选择业务过程→声明粒度→确认维度→确认事实

1. 选择业务过程（有几张事实表）

在业务系统中，挑选我们感兴趣（后面会分析的）的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

如果是中小公司，尽量把所有业务过程都选择。

如果是大公司（1000多张表），选择和需求相关的业务线。

1. 声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

订单事实表中一行数据表示的是一个订单中的一个商品项。

支付事实表中一行数据表示的是一个支付记录。

1. 确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

1. 确定事实

此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。如何判断是否能够关联上呢？在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。

（补充：申明粒度那有了订单详情为什么还要有订单信息？因为考虑性能，假设一个需求订单和订单详情都可完成，但是订单详情需要一定程度聚合才能得到订单，所以直接使用订单可以减少性能开销。）
时间用户地区商品优惠券活动编码度量值
至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。

DWS

数据汇总层：DWS，汇总层有些汇总的比较轻，比如按天汇总用户订单表即可得到一天用户下单数。即一行信息代表一个主题对象（用户）一天的汇总行为。

DWT

有些汇总程度比较大，比如按历史积累数据汇总用户订单表，即可得到用户历史下单记录数。即一行信息代表一个主题对象（用户）历史累计的行为汇总。

DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

宽表层

在维度表中，以事实表为核心，到了宽表层则以维度表为核心。

DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。

1. 问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额
2. 处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。 那怎么设计能避免重复计算呢？ 针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。
3. 总结：

• 需要建哪些宽表：以维度为基准。
• 宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
• DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

ADS

ADS层用于数仓后的应用比如报表、用户画像、机器学习等。通过ODS=>DWD=>DWT=>ADS得到应用需要的数据。

数仓维度建模

维度模型如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。

维度表和事实表

维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。

维表的特征：

• 维表的范围很宽（具有多个属性、列比较多）
• 跟事实表相比，行数相对较小：通常< 10万条
• 内容相对固定：编码表

例子：时间维度表：
日期IDday of weekday of year季度节假日

事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等）**，例如，2020年5月21日，宋宋老师在京东花了250块钱买了一瓶海狗人参丸。维度表：时间、用户、商品、商家。事实表：250块钱、一瓶。

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。

事实表的特征：

• 非常的大
• 内容相对的窄：列数较少（主要是外键id和度量值）
• 经常发生变化，每天会新增加很多。

事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

周期型快照事实表（全量表）

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

比如加购物车、收藏夹表，数据亮大，既有更新又有新增，应该采用新增及变化策略。但是由于这两张表是周期性的快照事实表，所以我们采用全量表。

累积型快照事实表（周期型业务）

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

新增及变化表需要提取新增变化数据与原数据进行整合。
订单id用户id下单时间打包时间发货时间签收时间订单金额

拉链表

当表中的数据每日既有新增，也可能修改，但是修改的频率并不高，属于缓慢变化维度时，可以采用拉链表来存储用户维度数据，以解决数据重复存储。

拉链表简介

一行数据指代用户的一个状态，有一个开始时间和结束日期表示有效状态。

为什么要做拉链表

如何使用拉链表

拉链表形成过程

拉链表需要做一次初始化，将全量数据拉取到拉链表。

保证保证用户状态时间不重复。

拉链表制作过程图：

这里的临时表，是考虑避免在覆盖数据的时候元数据丢失，保证数据的安全性；hive 的insert overwrite会先往临时路径写数据，写完之后再修改临时路径名字，删除原来路径的数据，这也保证了数据的安全性。

原文链接：数据仓库从0到1之数仓建模理论 - 知乎 (zhihu.com)https://link.zhihu.com/?target=https%3A//www.everweekup.com/2021/06/30/%25E6%2595%25B0%25E6%258D%25AE%25E4%25BB%2593%25E5%25BA%2593%25E4%25B9%258B%25E5%25BB%25BA%25E6%25A8%25A1%25E7%2590%2586%25E8%25AE%25BA/侵权删！