数仓系列-基本概念整理

内容整理自：

  1. 数据仓库的基本概念整理

一、数据仓库和数据集市

数据仓库(Data Warehouse)

  • 数据仓库（Data Warehouse） 是一种信息系统的资料储存理论， 此理论强调的是利用某些特殊的资料储存方式， 让所包含的资料特别有利于分析和处理， 从而产生有价值的资讯，并可依此做出决策。

  • 数据仓库是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策支持系统（DDS：Decision Support System，主要是报表系统）

  • 利用数据仓库的方式存放的资料，存入的资料必定包含时间属性，具有一旦存入， 便不会随时间发生变动的特性。但是数仓随着时间变化数据可能是不断增长变化的.

数据集市(Data Market)

是一个小型的部门或工作组级别的数据仓库

联系

数据仓库 数据集市
数据来源 遗留系统、OLTP系统、外部数据 数据仓库
范围 企业级 部门级别或工作组级别
主题 企业主题 部门或特殊的分析主题
数据粒度 最细的粒度 较粗的粒度
数据结构 规范化结构（第三范式） 星型模式、雪花模式、或两者混合
历史数据 大量的历史数据 适度的历史数据
优化 处理海量数据、数据探索 便于访问与分析、快速查询
索引 高度索引 高度索引

二、维度和度量

维度：
指审视数据的角度，它通常是数据记录的一个属性，例如时间、地点等。
一般是一组离散的值， 比如时间维度上的每一个独立的日期， 或者商品维度上的每一件独立的商品。 因此统计时可以把维度值相同的记录聚合在一起， 然后应用聚合函数做累加、 平均、 去重复计数等聚合计算

维度的基数(Cardinality)
指的是该维度在数据集中出现的不同值的个数。例如“国家”是一个维度，如果有200个不同的值，那么此维度的基数就是200。
通常一个维度的基数会从几十到几万个不等，个别维度如“用户ID”的基数会超过百万甚至千万。基数超过一百万的维度通常被称为超高基数维度（UltraHighCardinality，UHC）

度量：
基于数据所计算出来的考量值；它一般是连续的值，如总销售额、不同的用户数等。

举个例子:
一个SQL查询中，GroupBy的属性通常就是维度，而所计算的值则是度量。如下面的示例：

1
2
3
4
5
6
7
SELECT
department,
site_id,
sum(price) AS total_sales,
count(DISTINCT seller_id) AS sellers
FROM kylin_sales
GROUP BY department, site_id

上面的这个查询中，department和site_id是维度，sum（price）和count（distinct seller_id）是度量

三、Cube基本概念

给定一个数据模型，我们可以对其上的所有维度进行组合。对于N个维度来说，组合的所有可能性共有 2^n 种.

  • 对于一种维度的组合，将度量做聚合运算，然后将运算的结果保存为一个物化视图，称为Cuboid。
  • 所有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个Cube就是许多按维度聚合的物化视图的集合
  • Cube Segment是指针对源数据中的某一个片段， 计算出来的Cube数据。 通常数据仓库中的数据数量会随着时间的增长而增长， 而Cube Segment也是按时间顺序来构建的

四、Hierarchy、Level和Member

Cube就象一个坐标系，每一个Hierarchy代表了一个坐标轴，而Hierarchy中每一个Member代表了坐标轴上的一个值。下图以时间维度为例展示了Dimension的内部结构:
image.png

维是用于从不同角度描述事物特征的，一般维都会有多层（Level），每个Level都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：
image.png

以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。其中ID一般被视为代理主键（Agent），它只被用于作为唯一性标志，并且是多维模型中关联关系的代理者，在业务层面并不具有任何意义；NAME一般是业务主键（Business），在业务层面限制唯一性，一般作为数据装载（Load）时的关联键；而DESCRIPTION则记录了详细描述信息，在多维展示和分析时我们都会选择使用DESCRIPTION来表述具体含义

上面这个结构的维是无法直接应用于OLAP的,OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以每一个维必须有Hierarchy，至少有一个默认的，当然可以有多个，见下图：
image.png

有了Hierarchy，维里面的Level就有了自上而下的树形结构关系，也就是上层的每一个成员（Member）都会包含下层的0个或多个成员，也就是树的分支节点。这里需要注意的是每个Hierarchy树的根节点一般都设置成所有成员的汇总（Total），当该维未被OLAP中使用时，默认显示的就是该维上的汇总节点，也就是该维所有数据的聚合（或者说该维未被用于细分）。 Hierarchy中的每一层都会包含若干个成员（Member），还是以时间维，假设我们建的是2006-2015这样一个时间跨度的时间维，那么最高层节点仅有一个Total的成员，包含了所有这10年的时间，而年的那层Level中包含2006、2007…2015这10个成员，每一年又包含了4个季度成员，每个季度包含3个月份成员……这样似乎顺理成章多了，我们就可以基于Hierarchy做一些OLAP操作了

五、数据立方体(Data Cube)

数据立方体，是一种常用于数据分析与索引的技术；它可以对原始数据建立多维度索引，通过Cube对数据进行分析，可以大大加快数据的查询效率。

数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度。一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了与传统关系型数据库的二维表区别开来
image.png

基本操作

image.png

  • 钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图； 当然也可以钻取浙江省来查看杭州市、波市、温州市……这些城市的销售数据。

  • 上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。

  • 切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。

  • 切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。

  • 旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换

六、事实表和维度表

事实表(FactTable)

  • 事实表（FactTable）是指存储有事实记录的表，包含了每个事件的具体要素，以及具体发生的事情，如系统日志、销售记录等

  • 在事实表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录

  • 事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。

  • 发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。

维度表(DimensionTable)

  • 维表，有时也称查找表（LookupTable），是对事实表中事件的要素的描述信息

  • 它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理

  • 常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等

  • 每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性

七、OLAP和OLTP

OLAP(Online Analytical Process)

  • 联机分析处理， 以基于数据仓库多维度模型的基础上实现的面向分析的各类操作的集合， 而且能够弹性地提供上卷（Roll-up） 、 下钻（Drill-down） 和透视分析（Pivot） 等操作， 它是呈现集成性决策信息的方法， 多用于决策支持系统、 商务智能或数据仓库

  • 功能在于方便大规模数据分析及统计计算， 可对决策提供参考和支持

  • OLAP需要以大量历史数据为基础， 再配合上时间点的差异， 对多维度及汇整型的信息进行复杂的分析

  • OLAP需要用户有主观的信息需求定义， 因此系统效率较佳。

OLAP的概念， 在实际应用中存在广义和狭义两种不同的理解方式。 广义上的理解与字面上的意思相同， 泛指一切不会对数据进行更新的分析处理。 但更多的情况下OLAP被理解为其狭义上的含义， 即与多维分析相关， 基于立方体（Cube） 计算而进行的分析

类型

MOLAP(Multidimensional),多维OLAP

  • 将OLAP分析用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构，维的属性值被映射为多维数组的下标值或下标的范围，而汇总数据作为多维数组的值存储在数组的单元中。

  • 此结构在得到高度优化后，可以最大程度地提高查询性能。

  • 由于采用了新的存储结构，从物理层实现起，因此又被称为物理OLAP（Physical OLAP）；而RLOAP主要通过一些软件工具或中间软件实现，物理上仍采用关系数据库的存储结构，因此称为虚拟OLAP（Virtual OLAP）。

  • MOLAP的优势在于由于经过了数据多维预处理，分析中数据运算效率高，主要的缺陷在于数据更新有一定延滞。

ROLAP(Relational)，关系OLAP

  • 表示基于关系数据库的OLAP实现。以关系数据库为核心，以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表：一类是事实表，用来存储数据和维关键字；另一类是维表，即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。

  • 维表和事实表通过主关键字和外关键字联系在一起，形成了“星型模式”。

  • 对于层次复杂的维，为避免冗余数据占用过大的存储空间，可以使用多个表来描述，这种星型模式的扩展称为“雪花模式”。

  • 用作RLOAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展（cube、rollup）等。

HOLAP(Hybrid)混合型OLAP

表示基于混合数据组织的OLAP实现（Hybrid OLAP），用户可以根据自己的业务需求，选择哪些模型采用ROLAP，哪些采用MOLAP。

对比分析

一般来说，会将非常用或需要灵活定义的分析使用ROLAP方式，而常用、常规模型采用MOLAP实现。如将明细数据保留在关系数据库的事实表中，但是聚合后的数据保存在Cube中，聚合时需要比RLOAP更多的时间，查询效率比RLOAP高，但低于MLOAP

image.png

OLTP (On-line Transaction Processing)

  • 数据量少，DML频繁，并行事务处理多，但是一般都很短

  • 联机交易处理，更侧重于基本的、日常的事务处理，包括数据的增删改查

OLAP与OLTP区别

类似于数据库与数据仓库的区别：

  • 数据库系统的设计目标是事务处理。数据库系统是为记录更新和事务处理而设计，数据的访问的特点是基于主键，大量原子，隔离的小事务，并发和可恢复是关键属性，最大事务吞吐量是关键指标，因此数据库的设计都反映了这些需求
  • 数据仓库的设计目标是决策支持。历史的，摘要的，聚合的数据比原始的记录重要的多。查询负载主要集中在即席查询和包含连接，聚合等操作的复杂查询。相对于数据库系统来说，查询吞吐量和响应时间比事务处理吞吐量重要的多
数据处理类型 OLTP OLAP
面向对象 业务开发人员 分析决策人员
功能实现 日常事务处理 面向分析决策
数据模型 关系模型 多维模型
数据量 几条或几十条记录 百万千万条记录
操作类型 查询、插入、更新、删除 查询为主

八、元数据

元数据（Meta Data）是关于数据的数据，当人们描述现实世界的现象时，就会产生抽象信息，这些抽象信息便可以看作是元数据，元数据主要用来描述数据的上下文信息。通俗的来讲，假若图书馆的每本书中的内容是数据的话，那么找到每本书的索引则是元数据。按其描述对象的不同可以划分为三类元数据：技术元数据、业务元数据和管理元数据:

  • 技术元数据: 技术元数据是描述数据系统中技术领域相关概念、关系和规则的数据，主要包括对数据结构、数据处理方面的特征描述，覆盖数据源接口、数据仓库与数据集市存储、ETL、OLAP、数据封装和前端展现等全部数据处理环节；
  • 业务元数据: 业务元数据是描述数据系统中业务领域相关概念、关系和规则的数据，主要包括业务术语、信息分类、指标定义和业务规则等信息；
  • 管理元数据: 管理元数据是描述数据系统中管理领域相关概念、关系和规则的数据，主要包括人员角色、岗位职责和管理流程等信息。

具体参考链接: 聊一聊数据仓库中的元数据管理系统