整理的数仓的一些基本问题，不定期更新
0x01 什么是数据仓库
数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合
数据仓库是将源系统数据抽取、转化、清洗，存储到维度模型中的系统，为分析决策提供查询、分析的支持
上述两个定义，第一个是inmon书中的定义，第二个是kimball中的定义，现在对数仓的定义一般结合两者，inmon的定义是数仓的定位，而具体的操作方法是按照kimball的定义来的
0x02 为什么建数仓
数仓是一个系统，当数据问题到达一定规模，都需要一个系统来帮助我们更有效率的完成问题，例如OA系统，CRM销售系统都是类似的，而数仓能帮助我们更有效率的完成整个数据的查询、分析、产出报表、用数据驱动业务等功能
0x03 维度模型和范式模型
范式模型也叫关系模型，遵循第三范式，构建实体表和表之间的关系，能减少数据的冗余
维度模型，将表的概念抽象成事实和维度表，面向业务过程，一般是宽表
范式建模的表一般比较分散，能减少数据冗余，但是关联查询效率不是很高
维度模型的表一般将事实表做成宽表，按照业务过程，易于构造，灵活方便，所以现在互联网公司为了快速响应需求，一般都使用维度建模构建宽表
0x04 数据仓库基本分层
一般分三层ODS、DW、APP
ODS是操作型数据，一般从源系统拉去数据直接导入ods层，为了方便追踪，一般不会做过多处理
DW是数据仓库层，一般分DWD、DWS、DWM层
APP是应用层，一般直接供用户查看、使用
DWD：数仓明细层，ods经过清洗，落地这一层，一般是最细粒度
DWS：数据汇总层，对dwd的轻微聚合，对一些可累加的指标进行聚合，增加复用性
DWM：数据集市层，宽表，一般按照主题整合几个汇总层，做成宽表，通常能满足大部分的分析需求
一般不能跨层取数，即APP不能从ODS层取，可以从DW内的任意层取，但是一般DWM和DWS满足不了需求时，才会从DWD直接取数，并且需要评估DWM、DWS的设计，这个需求是否能做到上层
0x05 为什么要用DWS
DWS是对dwd中可累加指标进行聚合，按业务过程来设计的，方便DWM后续的复用
0x06 数据仓库和数据中台的区别
数据中台时包含数据仓库的，仓库一般是整合数据，为业务服务，提供的只是数据，而中台是一种整合能力，为各产品提供数据能力的支持
0x07 数据库三大范式
第一范式：字段的原子性，即每个字段都不能在分解，例如学生信息字段（学生id、学生姓名）不满足第一范式
第二范式：所有字段都依赖所有主键
第三范式：所有字段都直接依赖主键，不能间接依赖，例如学生表中，年级id、年级，年级字段就是间接依赖
通常范式模型满足第三范式，主要消除冗余，例如每个学生都有年级，年级就可以做成另一个实体，通过年级id来关联
0x08 CDM、LDM、PDM概念
CDM：概念模型，只是概念
LDM：逻辑模型，具体到表的说明，表之间的逻辑关系
PDM：物理模型，具体的表设计模型
0x09 拉链表
拉链表是针对数据仓库中表的存储方式定义的，就是在一张表中以天为单位，记录每条数据从开始到现在的所有状态变化信息。
实际操作方法就是增加两个字段start_time和end_time，表示有效开始日期和有效结束日期，
| 用户编号 | 手机号 | t_start_time | t_end_time |
|---|---|---|---|
| 1 | 111 | 2019-09-13 | 2019-09-14 |
| 1 | 123 | 2019-09-15 | 2019-09-15 |
| 1 | 113 | 2019-09-15 | 9999-01-01 |
| 2 | 222 | 2019-09-14 | 9999-01-01 |
| 3 | 333 | 2019-09-13 | 2019-09-15 |
| 3 | 313 | 2019-09-16 | 9999-01-01 |
根据start_time和end_time就可以取到每天当时的历史数据，
例如：用户1在2019-09-13和2019-09-14的手机号是111，在2019-09-15的手机号是123，之后是113
要构造这样的拉链表，需要一张全量数据表和一张每天的增量数据表，增量表包含每天新增的数据和每天更新的数据，一般可以通过binlog解析
0x10 退化维度
退化维度指一些常用的维度属性，直接放在事实表上，避免了查询的关联操作
0x11 多值维度
通常事实表和维度表都是多对一的关系，即一个维度对应多个事实，一个事实对应一个维度，多值维度指事实和维度是对多对多关系或一对多关系，即一个事实可能对应多个维度。
这种情况一般要尽量避免，可以重新设计看能不能降低事实表粒度，也可以设计桥接表（类似于多对多之间的关系表）
0x12 缓慢变化维度
维度表中随着时间变化的维度字段称为缓慢变化维度，例如用户维度表，用户名可能是变化的，对应到事实表，是展示最新的用户名还是历史的用户名，就是一个问题。一般有以下几种处理方式
1、直接覆盖，永远只保存最新的数据
2、增加新行，每次变化都用新行表示
3、增加字段，例如用户维度表增加字段曾用名
0x13 数据总线
1、企业数据仓库总线架构
总线架构是kimball的多维体系架构三大关键性概念之一，另外两个是一致性维度和一致性事实
多维体系架构在设计之初，需要由架构师设计出在整个数仓体系内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实。一致性维度就好比企业范围内的一组总线，所以叫总线架构
2、企业数据仓库总线矩阵
总线矩阵是实现总线架构的工具，行表示业务过程，列表示一致性维度，点标记上业务过程是否与维度相关。
总线矩阵能清晰的表示业务过程与维度的关系，也能方便的添加业务过程和一致性维度
0x14 如何建数仓
这里参考阿里的建仓流程
1、业务调研，需求分析（针对数据分析师、运营、维护进行调研），定义指标（维度、粒度），通常需要产出定义原子指标和派生指标的文档
原子指标=业务过程+度量
派生指标=时间周期+修饰词+原子指标
2、划分数据域，数据域是面向分析的，将业务过程和维度进行整合抽象的集合
| 数据域 | 业务过程 |
|---|---|
| 会员店铺域 | 注册、登录、装修、开店、关店 |
| 商品域 | 发布、上架、下架、重发 |
| 日志域 | 曝光、浏览、点击 |
| 交易域 | 下单、支付、发货、确认收货 |
| 服务域 | 商品收藏、拜访、培训、优惠券领用 |
| 采购域 | 商品采购、供应链管理 |
3、明确数据域下有哪些业务过程后，需要定义维度，并基于维度构建总线矩阵
4、根据指标设计明细层和汇总层
以一个实际例子说明，例如教材商城数仓，
1、整理各业务方需求
| 业务方 | 大概需求 |
|---|---|
| 学科 | 学科老师主要需要统计各个学科、年级、版本的教材销售量 |
| 供应链 | 供应链主要需要统计商品各个SKU销售量，以及出库、入库量、滞销率等 |
| 营销 | 营销老师关心各个机构、机构省份购买的教材量 |
| 三阶课 | 三阶课这边关心三阶课类教材的销量 |
| 财务 | 财务想要了解每种教材的收入，包括普通教材、定制教材、三阶课教材等 |
2、整理数据域，这里主要围绕销量来，所以都归为交易域
3、整理维度、构建总线矩阵
| 业务过程\一致性维度 | sku_code | 学科 | 商品种类 | 机构 | 机构所在省份 |
|---|---|---|---|---|---|
| 下单 | Y | Y | Y | Y | Y |
| 发货 | Y | Y | Y | Y | Y |
| 确收 | Y | Y | Y | Y | Y |
根据总线矩阵可以设计，DWD层以每笔订单sku粒度，商品、机构维度，购买量为度量
DWS层可以设计成以，学科购买量、机构购买量、商品各种类购买量
DWM层根据实际需求自由组装
