The Data Warehouse Toolkit 阅读笔记
前言
本文主要参考了《The Data Warehouse Toolkit》一书中相关章节的内容，并将其核心观点进行了归纳总结；此书可被广泛认为是数据仓库建模领域的经典著作
什么是星型模型
以单一业务事实作为核心记录。例如一笔订单可视为一个核心业务记录。该记录包含商品编码信息、销售区域信息以及交易时间字段等基础维度
雪花
一个产品类别不仅包含分类与包装等细节信息，并且单独制作成表格形式依附于事实表旁边
为什么要用星型模型
- OLTP专门针对线上事务中的高频操作场景。
- 数据仓库（Data Warehouse, DW）模型主要应用于数据分析领域，在处理大规模查询时需要优化设计以减少数据间的关联性并提高数据整合效率。
- 降低业务理解难度和复杂性方面：某些业务事实往往涉及多个表层信息甚至跨越多个数据库系统。
- 例如：一个订单的生命周期通常会牵扯到订单团队、仓储团队以及物流团队等多个协作环节。
- 如果不进行建模，则需要所有依赖这些数据的人员都清楚对应的业务细节及各表的数据结构。
三种模型类型
总结来看，事实表分为三种类型。
- 事务事实存储方案：例如一个典型的例子是单笔商品交易记录。
- 时间维度上的快照存储方案：为业务实体在各个时间节点上生成完整的快照信息。例如在促销活动期间的商品销量数据会得到集中存储。
- 累积变化过程中的关键节点信息存储方案：用于反映企业核心运营流程中关键事项发生变动的情况。
数仓的数据模型：其设计往往需要兼顾这三种类型的数据模型以满足不同场景的需求。他们之间的区别主要体现在：
- 事务事实表与周期快照表的区别在于前者注重对单一事件的具体描述而后者则侧重于时间段内的整体状态；
- 周期快照表与累计快照表的区别主要在于前者采用一次性完整保存的方式而后者则是分阶段、分步式的增量式更新模式；
- 事务事实表与累计快照表的区别则体现在它们对数据表现形式的不同关注点上。
累计事实模型
某些业务实体将经历一系列业务流程的变化，在事实表中采用一条记录来存储该业务实体所有关键流程的信息，并伴随各项业务事件的发生而被相应更新。即一条记录会累积各种变化以形成所谓的累积快照表。例如一个商品从供应商进入仓库的整体流程包括收货操作验货操作装箱操作以及运输操作等。其模型设计示例如下：
一行数据的变更示例如下：
为了确保累计快照事实表的有效性，在设计时必须限定流程节点的数量。对于动态且数量可变的多个流程而言，在实际应用中不宜直接构建累计快照的事实表……这是因为这种频繁的变化可能导致维护困难。
一个模型怎么定义
- 确定核心业务事实
它能够清晰地回答“谁”“何时”“何地”“做了什么事”这四个基本问题，并且通过分析其原因和实施过程来深入理解业务运作机制。 - 设定数据颗粒度标准
设定合理的数据颗粒度标准后，在实际应用中可以通过细化粒度来满足不同层次的需求。 - 创建维度表
- 构建事实表
如何响应维度表的变化
维度表具有较强的稳定性然而并非完全没有变化例如用户的信息维度表就可以相应地进行调整以适应用户的年龄和地址等信息的变化面对这些情况主要包括以下几点
- 保持原有数值
- 修改维度表的属性数值
- 链式数据结构
- 新增字段用于存储旧数据信息
- 小型化维度结构（Mini-Dimension）
- 综合处理
保留原值
不依赖于关联维度表来存储实际数值的事实表格会更加高效准确。在相关属性发生变化时，在不影响现有数据的情况下及时更新能够有效避免数据滞后问题。通过这种方式新的事实记录将对应地包含新属性数据从而保证数据的一致性与完整性。例如 商品当时的售价就可以直接存入到事实表格中无需通过中间层或其他渠道进行间接操作这不仅提高了效率还减少了潜在的人为错误风险
修改维度表属性值
操作将对应的变化字段的值进行修改可能导致事实表中旧数据获取新数值并影响相关联维度的数据进而使报表结果发生变化同时已预存于OLAP Cube的数据结构也需要重新计算从而可能出现错误或不准确的结果因此在采用此方法时应当谨慎地举个例子说明如下
拉链表
增添数据有效时间字段后,通过这一操作使维度表成为拉链表结构;从而使得该表格不仅能够展示当前的数据值还能够记录历史信息的变化情况.示例如下:
每个记录都有一个id，事实表关联当时的维度id。
添加新字段记录老数据
在某些报表场景中，可能会需要根据新的维度信息将老的事实表记录关联起来，并且这种变化通常不会过于频繁。可以通过在维度表中增加字段的方式，在新增字段中存储老数据的信息，并同时保留新数据的存在性以满足这种需求。例如，在处理时可以在维度表新增一个字段用于存储历史数据，并保证新旧数据都能被正确引用和检索。
迷你维度表(Mini-Dimension)
某些维度表的数据字段数量较多，并且其中部分字段的数据变更频率较高。若采用链表结构进行设计，则会导致数据规模迅速扩大。因此这种设计并不理想。例如，在用户信息中籍贯和民族等属性的变化频率较低；然而用户的收入等级以及活动范围却会发生频繁变动。因此我们可以将这些变化项提取出来形成一个迷你维度表以提高数据管理效率同时减少数据条目数量为此我们可以将这些变化项提取出来形成一个迷你维度表以提高数据管理效率同时减少数据条目数量为此我们可以将这些变化项提取出来形成一个迷你维度表以提高数据管理效率同时减少数据条目数量为此我们可以将这些变化项提取出来形成一个迷你维度表以提高数据管理效率同时减少数据条目数量
最终的模型设计如下：
该微视图记录了那些变化频率较高的属性值的各种可能组合
层级维度如何处理
例如一个组织包含上级机构以及下属机构。这种层次结构如何将其反映到维度表中？通常分为有限层次和无限层次两种情况。
层级是少量有限
该系统设计中的层级数量有限制，在实际应用中通常仅涵盖省级及以下地区层次。例如省、市、区、县这些较低级别的行政区域，在设计时应控制至村一级范围以内，并且不可无限制地延伸。对于这种层级结构，在一行中是可以容纳多个字段的。
| Province | city | zone | county |
|---|
不固定的层级
例如部门这类实体其结构无明确层次这时如果在表中增加一个字段以解决这一问题就不现实为此必须引入一个更为抽象的父子关系模型例如在此表中添加一个 parent_key 列即可实现这一目标
一些建模规范
打平所有的层级
某些维度信息具有复杂的层级结构，在这种情况下它们往往表现为一对多的关系模式。如果我们按照事务型数据库的设计模式构建多张表而不是将它们整合到同一张主表中那么这样做可能会导致查询效率低下甚至影响系统的性能表现。为了优化数据库设计我们可以将这些字段展平成单一层级从而实现对数据的一体化管理这不仅能够简化查询逻辑还能显著提升系统的运行效率由于这些维度表格的数据量通常较小并不需要担心数据冗余的问题
将编码中隐含的信息抽出
某些业务包含业务编码。每个业务代码包含多种信息。例如前两位代表大区后两位代表省份等。这些数据除了需要存储业务代码之外还需要将代码中的隐含信息分别以字段形式记录下来以便于后续的数据处理和分析工作这些操作都是以细粒度和直观的方式存储各种数据从而方便报表的计算以及提升计算性能
避免字段为null
如果一个字段尤其是会用于关联操作的字段建议尽量避免设置为Null值因为这可能导致表之间的关联异常统计数据以及展示界面出现显示问题因此当实际数据确实存在缺失值时可以通过设置特定数值或标识符来替代这些缺失值例如在维基百科条目分类系统中通常会使用-1或其他特定数值或标识符来表示未找到对应条目。特别地对于维基百科中的条目分类系统当某个维基页面不存在时可以在其分类信息中插入一条用于记录该情况的数据条目这样既保证了数据完整性又不会影响后续的数据关联操作。
退化维度(Degenerate Dimensions)
在实际应用中可以使用(productId)资源作为示例，在关系型数据库环境中通常会涉及一个唯一标识符（ID）或者发票编号等信息来区分不同的业务事件记录。这些信息对于后续报表分析仍然具有重要价值。
需要注意的是，在这种情况下，
我们依然会将这些字段包含在事实表中作为一个独立的维度字段进行处理，
但与标准产品ID不同，
这类特殊字段不对应于任何特定的标准数据模型，
因此我们将这种情况称为退化维度。
没有发生的事实表(Factless Fact Tables)
通常情况下，在进行数据分析时，默认会基于已发生的业务事件构建模型，并将具有真实购买记录的商品在促销期间的数据作为训练样本集进行分析研究。
该数据模型无法单独回答关于某促销商品在特定日期未被购买记录的问题。由于缺乏相关的零售记录信息，在现有数据库中根本不存在相关信息。为了更好地完善这一模型设计思路，在原有基础之上建议补充构建一个专门的事实信息表，并配合相应的促销维度表共同完成对促销活动效果的分析与预测工作。
以解答前文所述的问题为目标，在促销事实表中查找对应日期下的所有参与消息商品。通过关联实际销售记录表中的数据获取当天的实际销售商品信息。将这两部分数据进行关联操作即可得到所需结果。
维度表主键(Surrogate Keys)
维度表不应在操作性数据库中使用对应的ID,亦即不应采用OLTP对应表中的唯一约束键值,而是应自行生成整数类型的自增主键以提高查询效率.其原因在于,避免与分析型数据仓库中的主键产生冲突,同时便于后续的数据维护与管理.
- OLTP主要用于处理线上业务事务，在其设计中通常会采用分库分存的方式存放大量新增及更新频繁的数据。
- 维度表的数据来源可能来自多个原始OLTP视图（视图），由于本身并没有固定主键的设计。
- 优化性能的角度来看，在这种情况下使用整数字段就完全足够了。事实上，在实际应用中维度表的ID字段往往会通过外键关系连接到其他事实型数据仓库中的实体。
- 为了满足一些特定业务需求的需求，在设计时还可以预留一些特殊的元数据来支持这些特殊场景的应用。
事实表主键
尽管事实表中一条记录可通过其存储的所有维度外键的结合体来唯一确定, 为了与维度表主键相一致, 特别设立一个事实表主键, 其主要优势包括提高数据一致性、减少数据冗余以及优化查询效率
某些处理恢复时, 可以追踪断点处的主键ｉd来判断恢复量, 由于主键通常是有序的
可以快速定位到该条事实表记录
当存在多个事实表间存在父子关系时, 可以将它们作为连接键使用
多角色维度表
一个事实表可能会包含多个字段，并基于同一个维度表构建关系。然而，在基于该事实表格生成报表计算时会遇到问题，因为无法将同一张维度表用于两次join操作。解决方案是创建多个新的维度表，并使事实表格与这些新维度表格建立关联关系。其中一些新维度表格可以直接作为实体存储（实体型），而另一些则可以作为数据视图（视图型）存储。例如，在这种情况下，模型构建的具体方法如下：
数据表中设有多个扩展属性用于处理可提前计算的指标。这些属性的功能在于预处理这些指标以提高数据处理效率，并确保计算的一致性与规范性。
事实表泛型粒度
例如，在一个订单中包含有对应的订单明细这一业务。
所以最好将订单主表事实与明细表事实进行关联设置，并将其移入到订单明细中。为了性能优化考虑，在某些情况下可以选择性地将不参与计算的订单属性移入到订单明细中；如果仅使用订单明细事实表时，则无需关联过多表格以避免性能瓶颈。举个反例说明：如果在订单主表中字段客户信息没有移入到明细表中，则可能导致数据关联异常的问题
实时计算与数仓
一般情况下，在大多数情况下，企业所使用的数据仓库都会采用T+1的机制来管理数据。然而，在某些特定业务环境中,确实存在对实时数据的需求.具体来说,这类实时数据通常分为两类:
- 瞬时（Instantaneous），常规的数据直接接入变化的数据源。从而降低了整体系统的延迟问题。
- 当天内（Intra-Day），与普通T+1的处理方式相同，在一天之内定期从源系统获取最新的信息，并完成全部的ETL流程步骤。
在第二种情况下，同样需要进行建模；然而，在这种情况下关联的维度表必须能够动态适应当天的数据信息
宏观流程
启动会议，确立相关人员职责
包括涉及的领域中有一项是确定‘懂业务的权利负责人’这一职位。其中最为关键的是这一职位的确立对整个系统的成功运行至关重要。因为数仓系统的根本目标就是为具体的业务需求提供支持保障这不仅要求相关责任方具备深入分析并系统整理各项业务的基础能力还需要他们具备高度职责权限的负责人员才能有效执行相应的策略措施以确保系统的高效运作和数据安全
宏观模型梳理
使用矩阵图，对公司的整体业务建模，找出公共维表，统一各种业务术语。
如果术语存在不一致性 数仓系统最终生成的报表可能会因各团队名称的不同而导致信息混乱 从而彼此之间无法准确理解 这种情况会提升使用者的易用性难度
如果不统一维度比如时间维度存在不一致的情况
计算选型和建模
培训使用，后期维护升级
统一各类专业术语 并开展针对各类业务人员的专业知识培训 以降低信息不对等现象 并持续关注并及时解决他们在工作中的困难和问题 推动系统的不断优化和完善
数据质量把控
进行数据清洗工作的同时进行数据分析质量评估环节，并将其纳入数据库设计初审阶段以尽早发现问题。在进行字段分析时需关注非空字段是否存在缺失值以及字段类型是否符合规范？在构建数据库模型时需考虑各表之间的关联性关系是否合理？在实施系统时需验证特定业务场景下的约束条件是否满足？对于发现的问题实例应详细记录其触发条件以便后续排查
对于错误数据的记录
一些踩坑最佳实践
- 打好基础是关键的前提条件之一，在数据分析架构中通常将星型模型放置于Data Warehouse Dashboard（DWD）层面。为了确保整体架构的成功构建, 首先必须先将DWD这一核心组件打造得完善无缺, 只有根基打得扎实, 才能让 subsequent 的工作如虎添翼, 构建时需要特别注意设计与评审流程的衔接, 以保证整体系统的稳定性和可靠性。
- 在搭建数据质量管理平台之前, 需要对各层级的数据质量实施实时监控, 并及时发出警报, 这种机制应该融入到各个层级的数据处理流程中, 以确保系统的安全性与稳定性。
- 元数据管理平台作为整个架构中的地图存在, 它的作用就是帮助我们清晰了解各个节点之间的关联关系以及整体架构的布局走向。
- 在报表开发过程中, 应避免直接引用ODS层面的数据表, 因为这种做法会形成所谓的" 数据烟囱", 导致信息孤岛现象出现并影响整体系统的可扩展性。
如果没有质量管理系统
- 由用户反馈发现报表质量存在问题后进行排查，在整个系统流程中逐一检查会耗费较长时间
- 一旦发现问题后进行处理，则需要重新执行数据验证流程，并花费较长时间
如果没有元数据管理系统
- 数仓建设若不及时实施将导致失控状态
- 数仓技术的传承依赖于口口相传的方式，在员工离职后可能无法快速恢复
- 面对领导的质疑'做了多少' '做了什么' '有哪些资产'这些问题都难以回答