[数据仓库] 数仓概念合集[转载]

虽然作为数据分析或者商业分析师并不需要去做数据仓库，但在企业实际工作中，或多或少，还是需要接触或对接数仓部门，如提出需求、了解相关表的字段含义等，所以今天我们就简单说下数据分析师需要了解的 数据仓库基础知识。

1 维度建模理论与数仓分层思想

1.1 维度建模

1.1.0 维度表

维：是观察事物的角度，根据维的数据结构，将维分成三种类型：单级维，多级维和通用维。

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

  • 按照作用范围划分，维度表可以分为主题域维表和主题集维表。主题域维表作用于整个主题域，在此主题域下的任何主题集都可以使用；而主题集维表，只能在此主题集下才可以使用。

数仓的好坏取决于维度的设置, 分析能力取决于维度的质量和深度.

属性应该包含真实使用的词汇, 而不是令人感到迷惑的缩写, 尽量少使用代码/缩写, 而是多使用文本.

  • 维度表(示例: 时间维度表)：

1.1.1 维度建模

ODS 层因为保留原始数据, 所以和业务数据库 (关系模型) 一样是关系模型.
DWD 层即进行了维度建模, 将下面的模型 ↓

转化为了下面的维度模型, 即以事实表为中心, 周围有一圈的维度表 ↓

维度模型中的表数据 (数据特征) 可能有冗余, 但查询时一般只需要进行事实表和维度表进行 join, 不用 join 太多表, 查询性能更好

1.1.2 维度建模的分类、策略选择

在维度建模的基础上又细分为三种模型：星型模型、雪花模型、星座模型。

但生产中事实表不可能只有一张, 所以多个事实表多个维度表结合形成了星座模型:↓

1.1.3 维度模型的好处

  • Understandability: 表结构简单, 分析人员更好理解事实与维度数据的表结构;
  • Performance: 减少 join, 提高查询性能;
  • 方便进行 OLAP 多维分析: 后续数仓中单纯的聚合值意义不大, 一般需要计算某些维度下的聚合值才有意义, 比如 select 维度 agg(事实) from table group by 维度.

1.1.4 维度模型的扩展

维度模型对数据关系的变化也具有很高的适应性. 当发生以下变化时, 不需要改变现存的 BI 查询或应用, 就可以方便地适应, 且查询结果不会有任何改变:

  • 如果新增的事实与存在的事实表粒度一致时, 可以创建新列;
  • 如果新增的维度表与事实表的粒度一致, 可以通过在事实表中建立新的外键列, 可以将新的维度关联到已经存在的事实表上.
  • 如果某维度表新增的维度列, 直接在维度表上建立新列即可;
  • 可以使事实表的粒度更原子化, 方法是在维度表上增加属性, 然后以更细的粒度重置事实表, 小心保存事实表及维度表的别名.

1.1.5 维表的特征

  • 维表的范围很宽 (具有多个属性, 列比较多, 一般都是宽表 50 ~ 100 个), 比如将日期或者商品相关的字段全部放入一个表里;
  • 通常以层次关系表示.
  • 跟事实表相比, 行数相对较小: 通常 < 10万条;
  • 内容相对固定 (跟事实表对比): 像事实表, 比如订单表, 每下单一次就增加一行, 每天增加很多. 但维度表比如商品表, 即每天的商品表, 改变并不大, 因为每天商品基本一样, 不可能说每天上架大量的商品. 还有些编码表, 地区表和时间表等都不会变.
  • 同步策略: 除了某些特殊不变的维度表只在第一次初始化的时候全量同步一次, 其他的维度表一般来说每日全量同步. 注意: 像用户维度表使用的是拉链表, 这个需要注意一下, 还有拉链表是否需要分区等等, 待探讨.

1.1.X 星型模型与 OLAP

如果, DW 采用了星型模式建模, 或 OLAP 建模, 都可以说是利用了维度的概念, 他们对维度的认识是一样的, 只是物理实现上不一样.
OLAP 一般用于即席查询, 通常会进行与计算, 索引策略和其他的优化方法; 同时有很多比 SQL 更好的分析函数, 使得OLAP的查询和分析性能更好, 不需要提出新的查询.

但是, 一般在 OLAP 之前, 我们还是会将详细的, 原子的信息加载到星型模型中, 然后由此建立 OLAP 分析模型.

  • 星型模型

主要包含事实表, 以及通过主键/外键关系与之关联的【维度表】

  • OLAP模型：

联机分析处理 ( OLAP) 多维数据库是实现在多维数据库之上的多维结构, 它与星型模型内容等价, 或者说来源于星型模型.
多维数据库也是包含维度属性和事实表, 但它能够使用比 SQL 语言具有更强的分析能力的语言访问, 比如 XMLA 和 MDX 等.
OLAP 多维数据库通常是部署 DW/BI 的最后步骤, 或者作为基于多个原子关系型模式的聚集结构.

1.2 事实表

1.2.1 事实表的定义

事实表中的每行数据代表一个业务事件或业务度量, 比如下单, 支付, 退款, 评价等.

事实表一般包含两部分字段:

  • 维度字段. 即与维表相连接的外键, 通常具有两个和两个以上的外键, 外键之间表示维表之间多对多的关系.
  • 度量值. 即具有可加性的数值型的度量值, 像可统计次数, 个数, 金额等. 例如, 订单事件中的下单金额.

事实表的特征:

  • 数据量：非常的大;
  • 内容相对地窄: 列数较少;
  • 经常发生变化, 每天会新增加很多.

1.2.2 事实度量

最终计算通常在 DW 的上层或 OLAP 多维数据库层.

可加

最主要是数值类型和可加类型:

  • 数值类型: 销售额
  • 可加类型: 销售量

这些都可以按照某些维度, 比如时间维度进行聚合, 这是最关键的.

半可加

半可加度量可以对某些维度进行汇总, 但不能对所有维度进行汇总.
比如, 差额是常见的半可加事实, 除了时间维度外, 他们可以跨所有维度进行加法操作.

不可加

比率是最常见的不可加度量.
一般对于这种, 非可加度量一般拆解为其全完可加分量.

数仓分层

  • 为何数据仓库要分层？
数据分层是数据仓库设计中十分重要的一个环节，优秀的分层设计能够让整个数据体系更易理解和使用。而目前网络中大部分可以被检索到相关文章只是简单地提及数据分层的设计，或缺少明确而详细的说明，或缺少可落地实施的方案，或缺少具体的示例说明。

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
复杂问题简单化：将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复。
屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。

ODS层 / 贴源层

数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。

一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

ODS层数据还起到一个数据备份作用,如果是比较特殊行业,在ODS层的数据会保留一年甚至多年.不过普通公司一般就保存3–6个月,看数据量和存储压力以及存储预算决定.日志数据估算,如日活100万用户,每个用户访问1次,每次操作5min,每个用户平均3秒一条日志数据,一条数据1kb.最后体积是100w1560/31kb=100w*100kb=97656.25MB=95.36GB;

DW层（Data Warehouse）

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。

DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Service）层。

数据明细层：DWD（Data Warehouse Detail）

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性，后文会举例说明。

数据中间层：DWM（Data WareHouse Middle）

该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。

直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

数据服务层：DWS（Data WareHouse Service）

又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

数据应用层：ADS（Application Data Store）

在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

数仓技术

ETL / Kettle

事实(数据)表 / 明细(数据)表 / 维度(数据)表 / 指标表

维度表

统计指标时，通常地，需着重考虑的维度:
地区范围，时间范围（N年？当年？当月？当日？），统计单位
  • 地区: 国家 / 省(自治区) / 州市 / 区县 / 乡镇(街道) / 村居
  • 时间: 年 / 月 / 日 / 时 / 分 / 秒
  • 单位: 元/年 | 元/月 | 元/次 | 次/年 | 次/月 | ...

维度退化

维度 / 度量

维度： 字符串/日期类型的字段
度量： 数值型字段

拉链表

数据湖、数据集市

X 参考文献

posted @ 2021-01-12 00:26  千千寰宇  阅读(451)  评论(0)  编辑  收藏  举报