数仓基础概念

数据仓库

什么是数据仓库？

数据仓库，英文名称为Data Warehouse，关于数据仓库概念的标准定义业内认可度比较高的，是由数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

技术发展历程

阶段	时间	描述
开始阶段	20世纪70年代-80年代中期	MIT的研究员提出将业务处理系统和分析系统分开的技术架构设计原则，DEC公司结合MIT的研究结论，建立了TA2（Technical Architecture2）规范，该规范定义了分析系统的四个组成部分：数据获取、数据访问、目录和用户服务
全企业集成	1988年	为解决全企业集成问题，IBM公司第一次提出了信息仓（InformationWarehouse）的概念
企业级数据仓库	1991	Bill Inmon出版了他的第一本关于数据仓库的书《Building the Data Warehouse》，标志着数据仓库概念的确立
数据集市	1994-1996	由于企业级数据仓库设计、实施困难，建设者只考虑建设企业级数据仓库的一部分，Ralph Kimball的书《The Datawarehouse Toolkit》提出数据模型优化详细指导意见，掀起数据集市狂潮
争吵与混乱	1996-1997	企业级数据仓库与部门级数据集市争吵（Bill派和Kimball派），同时引出了新的应用如：ODS
合并	1998-2001	Bill Inmon推出新的BI架构：CIF（Corporation information factory）,把Kimball数据集市也包容进来，Kimball也承认了Bill,CIF的核心思想把整个架构分成不同的层次，同时对ODS,DW,DM,进行了详细的描述
未来	2001~	1. 战略决策到战术决策的发展：对DW的实时性和可获得性要求更高，要求7*24*365 2.需求更加多样化，要求有不同的架构和应用层次以适应不同的需求 3. 数据量膨胀，对数据建模、数据组织和层次划分提出更高要求

数据仓库特点

• 主题性

  不同于传统数据库对应于某一个或多个项目，数据仓库根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织。这里的主题怎么来理解呢？比如对于滴滴出行，“司机行为分析”就是一个主题，对于链家网，“成交分析”就是一个主题。

• 集成性

  数据仓库中存储的数据是来源于多个数据源的集成，原始数据来自不同的数据源，存储方式各不相同。要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换（ETL）的过程。

• 稳定性

  数据仓库中保存的数据是一系列历史快照，不允许被修改。用户只能通过分析工具进行查询和分析。

• 变化的

  数据仓库会定期接收新的集成数据，反应出最新的数据变化。这和稳定性特点并不矛盾。

OLAP和OLTP的区别

面向业务的数据库常称作OLTP，面向分析的数据仓库亦称为OLAP

数据处理大致可以分成两大类：

联机事务处理OLTP（on-line transaction processing）、
联机分析处理OLAP（On-Line Analytical Processing）。
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

• OLTP

也叫联机事务处理（Online Transaction Processing）

​ 表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。

• OLAP

也叫联机分析处理（Online Analytical Processing）系统

​ 有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。

• DML

数据操纵语言（Data Manipulation Language, DML）

​ 数据操纵语言（Data Manipulation Language, DML）是SQL语言中，负责对数据库对象运行数据访问工作的指令集，以INSERT、UPDATE、DELETE三种指令为核心，分别代表插入、更新与删除，是开发以数据为中心的应用程序必定会使用到的指令，因此有很多开发人员都把加上SQL的SELECT语句的四大指令以“CRUD”来称呼。

DML 的主要功能即是访问数据，因此其语法都是以读取与写入数据库为主，除了INSERT以外，其他指令都可能需搭配WHERE指令来过滤数据范围，或是不加WHERE指令来访问全部的数据。

比较项	操作型（OLTP）	分析性（OLAP）
关注	细节	综合或提炼
模型	实体 – 关系（E-R）	星型或雪花
操作	可更新	只读，只追加
操作粒度	操作一个单元	操作一个集合
场景	面向事务	面向分析
数据量	小	大
需求	日常操作	决策需求
业务方向	客户信息、订单等查询	客户登录间隔时间，市场细分等

数据分层

为什么要分层？

1. 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
2. 数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
3. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
4. 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5. 屏蔽原始数据的异常。
6. 屏蔽业务的影响，不必改一次业务就需要重新接入数据。

数据体系中的各个表的依赖就像是电线的流向一样，我们都希望它是规整、流向清晰、便于管理的，如下图：

但是，最终的结果大多却是依赖复杂、层级混乱，想梳理清楚一张表的声称途径会比较困难，如下图：

怎样分层？

具体分层细节不在展开，之后会做详细讲解

我们从理论上来做一个抽象，可以把数据仓库分为下面三个层，即：数据运营层、数据仓库层和数据产品层。

1. ODS 全称是 Operational Data Store，操作数据存储

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

但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪（例如有一条数据中人的年龄是 300 岁，这种属于异常数据，就需要提前做一些处理）、去重（例如在个人资料表中，同一 ID 却有两条重复数据，在接入的时候需要做一步去重）、字段命名规范等一系列操作。

2. 数据仓库层(DW)，是数据仓库的主体

在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。这一层和维度建模会有比较深的联系。

dw层还可以更加细分为：dwd和dws层

• DWD：Data Warehouse Detail，明细数据层。
• DWS：Data Warehouse Summary，汇总数据层。

3. 数据产品层（APP），这一层是提供为数据产品使用的结果数据

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

元数据

元数据（Metadata）是关于数据的数据。

在数据仓库系统中，元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：

• 技术元数据（Technical Metadata）
• 业务元数据（Business Metadata）

技术元数据

技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息：

数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
业务系统、数据仓库和数据集市的体系结构和模式
汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；
由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。

业务元数据

业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息；具体包括以下信息：

• 企业概念模型

这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。

• 多维数据模型

这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。
业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。

数据模型

什么是数据建模

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

为什么需要数据建模

• 进行全面的业务梳理，改进业务流程

  在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。

• 建立全方位的数据视角，消灭信息孤岛和数据差异

  通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。

• 解决业务的变动和数据仓库的灵活性

  通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。

• 帮助数据仓库系统本身的建设

  ​通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。

数仓建模阶段划分

• 业务建模: 生成业务模型，主要解决业务层面的分解和程序化。
• 领域建模: 生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
• 逻辑建模: 生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
• 物理建模: 生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

数仓建模方法

具体的实操单独出文章

范式建模法（ThirdNormal Form，3NF）

范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

维度建模法

维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）

实体建模法

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

星型模型架构 VS 雪花模型架构

星型模型

一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。

优点： 查询效率高

缺点： 数据冗余多

如下图：销售数据仓库中的星型模型

雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上，就像多个雪花连接在一起

优点： 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能**

缺点： 效率低，有些统计就需要通过表的联接才能产生

如下图：销售数据仓库中的雪花型模型

总结：**星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。**星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

主题和主题域

主题

主题是与传统数据库的面向应用相对应的，是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。

每一个主题对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。面向主题的数据组织方式， 就是在较高层次上对分析对象数据的一个完整并且一致的描 述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。所谓较高层次是相 对面向应用的数据组织方式而言的， 是指按照主题进行数据组织的方式具有更高的数据抽象 级别。 与传统数据库面向应用进行数据组织的特点相对应， 数据仓库中的数据是面向主题进行组织的。主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。

主题域(数据域)

主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。

主题域、主题、实体间关系

主题设计是对主题域进一步分解，细化的过程。主题域下面可以有多个主题，主题还可以划分成更多的子主题，而实体则是不可划分的最小单位。主题域、主题、实体的关系如下图所示：

如何应用？

持续更新

参考

• 数据仓库百度百科
• 数据仓库技术的发展历程，数仓发展历史
• 数据仓库、主题域、主题概念与定义
• 什么是数据仓库
• 木东居士-如何优雅地设计数据分层
• 数据仓库与元数据
• 数据仓库学习（二）——数据仓库建模