数据仓库-面向分析、挖掘的存储系统(OLAP)。

0 数仓用途

  • 整合公司所有业务数据，建立统一的数据中心
  • 产生业务报表，用于作出决策
  • 为网站运营提供运营上的数据支持
  • 可以作为各个业务的数据源，形成业务数据互相反馈的良性循环
  • 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果
  • 开发数据产品，直接或间接地为公司盈利

1 基本特征

数据仓库是面向主题的（Subject-Oriented ）、集成的（Integrated）、非易失的（Non-Volatile）和时变的（Time-Variant ）数据集合，用以支持管理决策。

  • 面向主题

数据仓库是面向主题的,数据仓库通过一个个主题域将多个业务系统的数据加载到一起，为了各个主题（如：用户、订单、商品等）进行分析而建，操作型数据库是为了支撑各种业务而建立。

  • 集成性

数据仓库会将不同源数据库中的数据汇总到一起,数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与整合，这一步是数据仓库建设中最关键、最复杂的一步(ETL)，要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致等等。

  • 稳定性(不可更新)

操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留(反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的数据)，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

  • 动态性(随时间变化)

数据仓库数据会随时间变化而定期更新，不可更新是针对应用而言，即用户分析处理时不更新数据。每隔一段固定的时间间隔后，抽取运行数据库系统中产生的数据，转换后集成到数据仓库中。随着时间的变化，数据以更高的综合层次被不断综合，以适应趋势分析的要求。当数据超过数据仓库的存储期限，或对分析无用时，从数据仓库中删除这些数据。关于数据仓库的结构和维护信息保存在数据仓库的元数据(Metadata)中，数据仓库维护工作由系统根据其中的定义自动进行或由系统管理员定期维护。

2 数仓演变

https://stor.51cto.com/art/202005/617634.htm

数据仓库 - 图1

3 数仓分层

前期 ODS+DM 就可以了，将所有数据同步过来，然后直接开发些应用层的报表；当DM层的内容多了以后，想要重用，就会再拆分一个公共层出来，变成三层架构。

3.1 分层原因

  • 清晰数据结构

每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。

  • 数据血缘追踪

简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。

  • 减少重复开发

规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。

  • 把复杂问题简单化

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

  • 屏蔽原始数据的异常

屏蔽业务的影响，不必改一次业务就需要重新接入数据。

3.2 分层参考

image.png

4 数仓建模

经典的2套理论：

  • 范式建模

Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。

  • 维度建模

Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构。
维度建模，一般都会提到星型模型、雪花模型，星型模型做OLAP分析很方便。

数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据，实际开发时会整合2种方式去使用。
当然，还有些其他(不常用)的，像Data Vault模型、Anchor模型

  • 星型模型

    由 事实表 与 维度表 组成。 a) 事实表 由 键值 和 度量值 组成, 即由维度编码和事实数据组成, 能体现实际数据或详细数值。 image.png b) 维度表由 主键 和 属性 组成，即维度表格里存放了具有独立属性和层次结构的数据，由维度编码和对应的维度说明(标签); 一个维度表只能有一个主键，且主键的值不能重复； 一个维度表可以包含多个属性，且这些属性可以进行扩展； 一般我们用DIM来表示维度表; 一般情况下，事实表和维度表都是1对多的关系。 数据仓库 - 图4

  • 雪花模型

    雪花模型是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。——百度百科

  • 星座模型

    星座模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。事实星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型。——百度百科

  • 宽表

    宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。——百度百科

  • 聚合表

    在事实表基础上，根据维度表的属性对事实表度量值进行统计分析（例如累加、计数、均值、极值等）而形成的数据表，一般是为了提高查询效率而提前形成的数据集。

  • 编码表（码表）

    编码表专门针对代码与实际含义的关联关系而形成的数据集，某种意义上来说，编码表可认为是结构较简单、内容较固定的维度表，主键为代码（编码），属性为实际含义。编码表各系统间差别较大，构建数据仓库时可以参考国家标准、地方标准或行业标准进行编码表设计。

5 其他

5.1 数仓与数据湖

特性 数据仓库 数据湖
数据 来自事务系统、运营数据库和业务线应用程序的关系数据 来自 IoT 设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据
架构方式 通常从事务系统中提取。在将数据加载到数据仓库之前，会对数据进行清理与转换存储。
存储数据之前定义架构(清理和规范化数据)。		 数据为非结构化的，所有数据都保持原始形式，存储所有数据，并且仅在分析时再进行转换。
在存储数据之后定义架构。
组织方式 捕获结构化数据并将其按模式组织。 捕获半结构化和非结构化数据。
适用 因为它具有高度结构化，非常适用于月度报告等BI、可视化与数据分析操作用途 非常适合深入分析的非结构化数据。数据科学家可能会用具有预测建模和统计分析、机器学习等功能的高级分析工具。
性价比 更快查询结果会带来较高存储成本 更快查询结果只需较低存储成本
优缺点 优点：结构化，主题化、高性能、可重复性、持续使用
缺点：灵活度低		 优点：数据收集容易，便于探索、创新、灵活性高。
缺点：数据沼泽、数据质量、清洗成本高

数据湖的理念很好，但是它现在还缺乏像数据仓库那样，有一整套方法论为基础，有一系列具有可操作性的工具和生态为支撑。正因如此，目前把Hadoop用来对特定的、高价值的数据进行处理，构建数据仓库的模式，取得了较多的成功；

在实际应用中，数据湖并不是替代数仓的概念，而是互补的。
数据湖提供统一存储，全量数据分析，
数仓提供基于业务系统，严谨的数据分析。

5.2 数据处理架构

  • Lambda 架构

整合离线和实时计算。 Lambda 架构分三层： Batch Layer(批处理)、Speed Layer(速度)、 Serving Layer(服务)
数据仓库 - 图5
数据仓库 - 图6

  • Kappa 架构

将实时和离线代码统一起来，方便维护而且统一了数据口径的问题。
但在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
数据仓库 - 图7
数据仓库 - 图8

数据仓库 - 图9

  • IOTA 架构

略

5.3 实际应用

在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标(比如金额相关)使用 Lambda 架构用批处理重新计算，增加一次校对过程。
数据仓库 - 图10
[

](https://blog.csdn.net/haotian1685/article/details/89891715)
[

](https://blog.csdn.net/BeiisBei/article/details/105723188)