吴乙己的数仓指南_2维度建模核心思想

最新推荐文章于 2024-08-01 00:00:00 发布

吴乙己

最新推荐文章于 2024-08-01 00:00:00 发布

阅读量548

点赞数

分类专栏：吴乙己的数仓指南文章标签：数据仓库数据挖掘大数据

本文链接：https://blog.youkuaiyun.com/AnchorOscarWoo/article/details/111406628

版权

吴乙己的数仓指南专栏收录该内容

6 篇文章

订阅专栏

0.引言

前两章讲了很多宽泛，大而全，代码之外的东西，想必大家看的昏昏欲睡（不过大家打怪升级多了，会发现代码之外的东西往往才是决定性的东西，相信我）。

本章讲干货，讲数仓工程师设计&开发时关注的干货——维度建模，可谓数仓工程师的内功。

先简单讲一下啥是维度建模，维度建模是Kimball老爷子发明的用来短平快地搭建数仓的方法论，优势在于基于需求快速落地，同时能以维度内聚业务，区分为主题便于管理（当然烟囱式开发会导致数据壁垒和逻辑争执，后面有了数据中台来解决这俩难题）。与之对应的是关系建模，由Inmon老爷子发明，相信计算机专业的朋友在大学的数据库课程中都学习过，关系建模适合对大而全且稳定的业务建模（如银行），严格基于3NF，使用以及维护非常方便，但基于业务变化进行迭代会相对麻烦，我没做过关系建模故此处不展开。

本章不讨论分层等等更贴代码的东西，讨论的是维度建模心法中的核心思想。

数仓工程师的精神导师，维度建模的爸爸Ralph Kimball的著作 《数据仓库工具箱》 想必大家都读过，翻来覆去就说了三样东西：维度建模“四部曲”，总线矩阵，维度建模高级方法。前两者是内功，后者是外功，本章着重讨论内功，外功后期会整理代表类型的技术单独成文。

1.维度建模“四部曲”

本节几乎照搬 《数据仓库工具箱》 ，大家有书可以不看我这里。

1.1选择业务过程

业务过程是由特定功能组织完成的微观活动，如下订单，开发票，保险索赔，医院挂号，等等。
业务有如下公共特征：
1.业务过程通常由行为动词表示。
2.业务过程通常由某个操作性系统（OLTP——OnLine Transaction System）支撑。
3.业务系统建立或获取关键性能度量。有时这些度量是业务过程的结果，也有可能是业务过程中的产出数值。
4.业务过程常由输入激活，产生输出度量。

1.2声明粒度

粒度传递的是与事实表度量相关的细节级别。应使用业务术语来表示粒度。
例如：
登机口每处理登机牌一次，记录一行数据。
医生每开具一张收费单，记录一行数据。
派出所每出警一次，记录一行数据。

1.3确定维度

维度要解决的问题是“业务人员如何描述来自业务过程度量事件的数据？”应使用足够健壮的维度集合来装饰事实表，这些维度承担每个度量环境中所有可能的单值描述符。

1.4确定事实

通过回答“如何度量业务过程？业务过程的度量是什么？”来确定事实。
要以用户需求和数据来源的实际情况确定事实，坚决抵制仅考虑数据来源来建模数据。

关键词
维度：包含与业务过程度量事件有关的文本环境，用于描述“谁/什么/哪里/何时/如何/为什么”有关的事件。
度量：描述业务过程事实的值，如多少，高度，人数，等等。
举例：穿红色衣服的小明在高考中考得666分。其中“高考”是业务过程，“红色衣服”/“小明”是维度，“666分”是度量。