数据仓库的基本概念整理

  |   0 评论   |   4,852 浏览


数据仓库和数据集市

数据仓库(Data Warehouse)

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

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

  • 利用数据仓库的方式存放的资料, 具有一旦存入, 便不会随时间发生变动的特性, 此外, 存入的资料必定包含时间属性, 通常一个数据仓库中会含有大量的历史性资料, 并且它可利用特定的分析方式, 从其中发掘出特定的资讯。

    image.png

数据集市(Data Market)

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

image.png

数据仓库与数据集市的区别

image.png

维度和度量

维度和度量是数据分析中的两个基本概念。

维度是指审视数据的角度,它通常是数据记录的一个属性,例如时间、地点等。 

度量是基于数据所计算出来的考量值;它通常是一个数值,如总销售额、不同的用户数等。 分析人员往往要结合若干个维度来审查度量值,以便在其中找到变化规律。

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


SELECT
part_dt,
lstg_site_id,
sum(price) AS total_selled,
count(DISTINCT seller_id) AS sellers
FROM
kylin_sales
GROUP BY
part_dt,
lstg_site_id


上面的这个查询中,part_dt和lstg_site_id是维度,sum(price)和count(distinctseller_id)是度量

维度(Dimension)

维度一般是一组离散的值, 比如时间维度上的每一个独立的日期, 或者商品维度上的每一件独立的商品。  因此统计时可以把维度值相同的记录聚合在一起, 然后应用聚合函数做累加、 平均、 去重复计数等聚合计算

度量(Measure)

度量就是被聚合的统计值,也是聚合运算的结果,它一般是连续的值,如图1-2中的销售额,抑或是销售商品的总件数。

通过比较和测算度量,分析师可以对数据进行评估,比如今年的销售额相比去年有多大的增长,增长的速度是否达到预期,不同商品类别的增长比例是否合理等

image.png

维度的基数(Cardinality)

指的是该维度在数据集中出现的不同值的个数;

例如“国家”是一个维度,如果有200个不同的值,那么此维度的基数就是200。

通常一个维度的基数会从几十到几万个不等,个别维度如“用户ID”的基数会超过百万甚至千万。

基数超过一百万的维度通常被称为超高基数维度(UltraHighCardinality,UHC)


Cube中所有维度的基数都可以体现出Cube的复杂度, 如果一个Cube中有好几个超高基数维度,那么这个Cube膨胀的概率就会很高。 在创建Cube前需要对所有维度的基数做一个了解,这样就可以帮助设计合理的Cube

Hierarchy、Level和Memeber

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

image.png

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

image.png

以时间维为例,时间维一般会包含年、季、月、日这几个Level,每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性,这几个公共属性不仅适用于时间维,也同样表现在其它各种不同类型的维。 其中ID一般被视为代理主键(Agent),它只被用于作为唯一性标志,并且是多维模型中关联关系的代理者,在业务层面并不具有任何意义;NAME一般是业务主键(Business),在业务层面限制唯一性,一般作为数据装载(Load)时的关联键; 而DESCRIPTION则记录了详细描述信息,在多维展示和分析时我们都会选择使用DESCRIPTION来表述具体含义。这3个属性一般是所有Level都会共用的,而比如用于描述星期几的属性weekid可能只会用于“日期”这层,因为年月都不具备这一信息。 所以图中我将Attributes放到了一个层面上,就如同是不同的Level从底层的多个Attributes中选取自身所需的属性,Attributes层是包含着各个Level的共有和特有属性的集合。

上面这个结构的维是无法直接应用于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操作了。

每个Hierarchy都包含了一个树形结构,但维中也可以包含多个Hierarchy,正如上图所示,维中的Hierarchy相互独立地构建了自己的树形结构。还是以时间维为例,时间维可以根据日历(Calendar)时间组建日历的Hierarchy,也可以根据财务(Fiscal)时间组建财务的Hierarchy, 而其中财务季度的划分可能并不与日历一致,基于这种多样的Hierarchy,我们在组建多维模型时可以按需选择合适的,比如给财务部的数据分析模型选用财务Hierarchy,而其他部门的分析人员显然希望看到日历样式的Hierarchy,这样就完美地满足了不同的需求。多种的Hierarchy划分同样适用于产品维,根据产品类型、产品规格等划分 Hierarchy,对于按多种条件的产品筛选和检索是十分有效的

 


Cube、 Cuboid和Cube Segment

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

对于一种维度的组合,将度量做聚合运算,然后将运算的结果保存为一个物化视图,称为Cuboid。

所有维度组合的Cuboid作为一个整体,被称为Cube。所以简单来说,一个Cube就是许多按维度聚合的物化视图的集合

image.png

数据立方体(Data Cube)

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

数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维,但多维模型不仅限于三维模型,可以组合更多的维度

一方面是出于更方便地解释和描述,同时也是给思维成像和想象的空间;另一方面是为了与传统关系型数据库的二维表区别开来

image.png

基本操作

image.png

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

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

  3. (Slice):选择维中特定的值进行分析,比如只选择电子产品的销售数据,或者2010年第二季度的数据。

  4. 块(Dice):选择维中特定区间的数据或者某批特定值进行分析,比如选择2010年第一季度到2010年第二季度的销售数据,或者是电子产品和日用品的销售数据。

  5. 旋转(Pivot):即维的位置的互换,就像是二维表的行列转换,如图中通过旋转实现产品维和地域维的互换。


长方体Cuboid

在Kylin中特指在某一种维度组合下所计算的数据

计算Cuboid, 即按维度来聚合销售额。 如果用SQL语句来表达计算Cuboid[Time, Location], 那么SQL语句如下: 

SELECT
	Time,
	Location,
	Sum(GWV) AS GWV
FROM
	Sales
GROUP BY
	Time,
	Location

计算的结果保存为物化视图,所有Cuboid物化视图的总称就是Cube

Cube Segment

是指针对源数据中的某一个片段, 计算出来的Cube数据。 通常数据仓库中的数据数量会随着时间的增长而增长, 而Cube Segment也是按时间顺序来构建的

事实表和维度表

事实表(FactTable)

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

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

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

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

维度表(DimensionTable)

维表,有时也称查找表(LookupTable),是对事实表中事件的要素的描述信息;

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

常见的维度表有:日期表(存储与日期对应的周、月、季度等的属性)、地点表(包含国家、省/州、城市等属性)等

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

star_schema.png

数据模型

参考《维度建模法

OLAP和OLTP

OLAP(Online Analytical Process)

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

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

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

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

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

类型

按照其存储器的数据存储格式,可以分为以下3类

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

三者的对比


优势

缺点

ROLAP

没有大小限制
现有的关系数据库的技术可以沿用.
可以通过SQL实现详细数据与概要数据的存储
现有关系型数据库已经对OLAP做了很多优化,包括并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL 的OLAP扩展(cube,rollup)等大大提高ROALP的速度

一般比MDD响应速度慢
不支持有关预计算的读写操作
SQL无法完成部分计算
无法完成多行的计算
法完成维之间的计算

MOLAP

性能好、响应速度快
专为OLAP所设计
支持高性能的决策支持计算
复杂的跨维计算
多用户的读写操作
行级的计算

增加系统复杂度,增加系统培训与维护费用
受操作系统平台中文件大小的限制,难以达到TB 级(只能10~20G)
需要进行预计算,可能导致数据爆炸
无法支持维的动态变化
缺乏数据模型和数据访问的标准

HOLAP

基于混合数据组织的OLAP实现,如低层是关系型的,高层是多维矩阵型的。这种方式具有更好的灵活。holap结构不应该是molap与rolap结构的简单组合,而是这两种结构技术优点的有机结合,能满足用户各种复杂的分析请求。

迄今为止,对holap还没有一个正式的定义

OLTP(On-line Transaction Processing)

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

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

OLAP与OLTP区别

类似于数据库与数据仓库的区别:数据库系统的设计目标是事务处理。数据库系统是为记录更新和事务处理而设计,数据的访问的特点是基于主键,大量原子,隔离的小事务,并发和可恢复是关键属性,最大事务吞吐量是关键指标,因此数据库的设计都反映了这些需求。

数据仓库的设计目标是决策支持。历史的,摘要的,聚合的数据比原始的记录重要的多。查询负载主要集中在即席查询和包含连接,聚合等操作的复杂查询。相对于数据库系统来说,查询吞吐量和响应时间比事务处理吞吐量重要的多。

数据处理类型OLTPOLAP
面向对象业务开发人员分析决策人员
功能实现日常事务处理面向分析决策
数据模型关系模型多维模型
数据量几条或几十条记录百万千万条记录
操作类型查询、插入、更新、删除查询为主


BI(Business Intelligence)

商务智能, 指用现代数据仓库技术、 在线分析技术、 数据挖掘和数据展现技术进行数据分析以实现商业价值

大致上来讲,BI就是利用各种技术来辅助于商业决策,它需要以数据仓库的数据为基础,通过OLAP系统来做分析,必要时还需要一些数据挖掘的方法来挖掘更深层次的价值。


读后有收获可以支付宝请作者喝咖啡