数仓避坑：搞懂维度模型.docVIP

数仓避坑：搞懂维度模型 / 前言 这个系列将从小白视角讲述构建数据仓库过程所需的知识和问题，主要受众是数据中台产品、数据开发、数据分析人员。 引入 在大学就听说过数据仓库，但是当时被书的厚度劝退。后来工作中要做数据仓库，这次不得不咬牙重新翻开那些经典大头书。 一开始，我想赶紧落地，快速过了一遍概念性的东西，业务过程、粒度、维度、事实、度量等等。做到中途发现，各种基础抽象概念没搞清，竞品的某些功能我都看不懂。 正所谓欲速则不达，这些底层的知识，是数据类不变的产品的内核，搞懂了这些，才能跑得快、跑得稳、跑得远。 一、什么是模型，什么是建模 什么是模型？作为数据行业从业者，如果你从来没有思考过这个问题，你一定要看下去。 先看一个例子：2021年 3 月 6 日，小明到楼下【行家】便利店买吃的，来来回回逛了几圈，虽然很饿，但又想减肥，最终拿了 1 个【柯德吉】人造肉汉堡。 准备付账的时候，收银员跟他说，最近搞活动，加 4 块可以选一瓶原价 8 块的【卡石】酸奶。小明觉得很划算，于是去拿了酸奶，一共付了 12 块。 上面的这段文字，就是模型。 作为计算机专业的学生，第一次看到别人给我解释这个模型的时候，我第一反应是What？这不就是一段文字嘛？都没数据库，都不是表单，这能算模型？ 别急，先看看百度百科给出的模型定义。 模型，是指通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟）。 简单来说，模型是映射 “事实” 的东西，构建这个东西的动作就叫做建模。 其实，如果我们学了数据库，且没认真读教科书，很容易狭隘地只从数据库、数据结构的层面去理解模型。 上述的例子，是一种“文字模型”。而且，这个模型还可以补充更多细节，比如，采用什么方式付款、支付了多少钱。 为了表达更加简洁，我们可以省略更多的信息，只记录关键信息：“ 2021年 3 月 6 日，小明买了，一个 柯德吉牌人造肉汉堡，一瓶卡石牌酸奶（共计 ￥12）”。 如果用 Excel，我们可以更加简洁（节省空间你懂的）： 二、范式模型，为了更好地记录和更新 计算机的出现，也诞生了新的语言，我们也顺理成章地开始用新语言去建模。 这里，我省去长篇的对关系模型、范式模型的介绍，直接跳到应用场景，假设这个便利店用了现成的 ERP、CRM 系统，这些系统设计好了模型，数据会填充成如下的样子。 1. 订单表 2. 订单详情表 3. 商品详情表 数据量不大，分析人员写 SQL 直接对范式模型进行查询，算账分析无所不能，小几十万数据，速度完全 OK。 三、维度模型，为分析而生 范式模型很好地解决了快速记录和节约存储空间。 但事物都有两面性，当数据量大的时候，从范式模型中查询取数，就比较慢了。但数据量一大，就顶不住了。 人类社会，但凡出现问题，总会天降猛士。Innon 和 Kimball 等人提出来新方案：为数据分析设计一套新模型。 范式模型主要解决数据的插入和更新，维护一致性等问题，维度模型则解决大数据场景分析的问题，这两者也就是所谓的 OLTP 和 OLAP 。 通过一个荒诞的例子来理解两者的区别。 你家是个大家族，七大姑八大姨，平时需要打电话联系。范式建模：每个人只存自己同辈人以及各自子女的联系方式。如果叔叔想找侄子/侄女（你），只能通过你爸爸。维度建模：所有的亲戚联系方式都写到了一个家庭通讯录上，想找人，直接找通讯录。 这个例子现实生活不存在，主要想帮助大家理解两种模型的差异： 范式模型为了应对数据频繁变更的场景，数据存得零散。为了保证数据的一致性，还要符合一定的规范，我们常见的是三范式（3NF）。 维度模型会将数据冗余，把一些相关的数据存到一起，方便快速查询取数。 维度模型的出现，就是为了解决大数据量导致的查询慢的问题。 四、维度建模的四大要素 数据仓库领域的经典著作《维度建模工具箱》中，Kimball 定义了经典的维度建模的四步曲：选定业务过程、声明粒度、确定维度、构建事实。 1. 业务过程 很多数据仓库书籍都给出了业务过程的通用定义：业务过程是企业活动中的事件，如下单、支付、退款都是业务过程，业务过程是一个不可拆分的行为事件。 看完定义，我们就会犯难了，什么是企业活动中的事件？打开手机付款，选择支付宝和微信，这些操作算不算业务过程？ 这里，我们真得咬文嚼字，回归场景。交易的场景，有 2 个参与方：消费者和便利店。 便利店作为企业，如果它关心的结果只是消费者买了什么、买了多少，那消费者选择支付方式的事件，它完全不管，也不用记录。 但如果用户只开通了微信支付，没开通支付宝，因为支付问题导致没法成交，那企业肯定也会关心选择支付方式这个事件以及其结果。 业务过程，是不可拆分的事件，而且是基于分析目标进行选定的。 理解一个词，不能脱离情景，多尝试