什么是数据仓库?

大数据 专栏收录该内容
23 篇文章 2 订阅

为什么需要数据仓库?

       传统的数据库中,存放的数据都是一些定制性数据较多,表是二维的,一张表可以有很多字段,字段一字排开,对应的数据就一行一行写入表中,特点就是利用二维表表现多维关系。

       但这种表现关系的上限和下限就定死了,比如QQ的用户信息,直接通过查询info表,对应的username、introduce等信息即可,而此时我想知道这个用户在哪个时间段购买了什么?修改信息的次数?诸如此类的指标时,就要重新设计数据库的表结构,因此无法满足我们的分析需求。

       在产品脑图中可以很清晰的看到根据业务需求设计所需的字段,因此也导致数据库是根据业务需求进行设计

       那么有的会问,为什么一开始就不考虑好这个扩展性呢?为什么数据库一开始就不以数据仓库的形式设计?

       首先数据仓库,从字面上理解就可以感受到这是一个很大的空间,而且存储的物品很杂,里面会存放酱油、沐浴露、洗发精等物品,而数据库是存放酱油、盐等厨房用品,洗浴又是一个数据库。

       另外一个就是,国内互联网的发展,一开始大家都是做个软件出来,大家一起用,这个时候只要满足的了需求即可,现今不止是需求还有用户的体验等各种方面,需要根据这些分析指标做调整。

小结:

       数据库是跟业务挂钩的,而数据库不可能装下一个公司的所有数据,因此数据库的设计通常是针对一个应用进行设计的。

       数据仓库是依照分析需求、分析维度、分析指标进行设计的。

 

什么是数据仓库?

       数据仓库(Data Warehouse)简称DW或DWH,是数据库的一种概念上的升级,可以说是为满足新需求设计的一种新数据库,而这个数据库是需容纳更多的数据,更加庞大的数据集,从逻辑上讲数据仓库和数据库是没有什么区别的。

       为企业所有级别的决策制定过程,提供所有类型数据支撑的战略集合,主要是用于数据挖掘和数据分析,以建立数据沙盘为基础,为消灭消息孤岛和支持决策为目的而创建的。

数据仓库发展过程

       2000年初,国内是简单的报表阶段,这个阶段主要是汇总一些数据,解决业务人员想要的报表。

       如:销售额:xxx万元、销售量:20000件

 

       2010年,数据集市阶段,进行一定的数据采集、整理,按照某业务部门的需求进行采集、整理,按照业务人员需要,进行多维度报表的展现,能够提供特定的领导决策数据。

       如:1月~3月销售额:xxx万元、4月~6月销售额:xxx万元

      

       2015年,各大公司开始注重用户体验,物流效率等问题,这个时候进入数据仓库阶段,主要按照数据模型,对整个企业的数据进行采集、整理,提供跨部门,完整一致性的业务报表数据,能够通过数据仓库生成对业务具有指导性的数据,为决策者提供更全面的数据。

       如:某个月某个地区的用户数量下降,某个月某个地区的用户数量上升。

 

数据仓库特点

面向主题

       是企业系统信息中的数据综合、归类并进行分析的一个抽象,对应企业中某一个宏观分析领域所涉及的分析对象。

       比如购物是一个主题,那么购物里面包含用户、订单、支付、物流等数据综合,对这些数据要进行归类并分析,分析这个对象数据的一个完整性、一致性的描述,能完整、统一的划分对象所设计的各项数据。

       如果此时要统计一个用户从浏览到支付完成的时间时,在购物主题中缺少了支付数据或订单数据,那么这个对象数据的完整性和一致性就可能无法保证了。

 

数据集成

       数据仓库的数据是从原有分散的数据库中的数据抽取而来的。

       操作型数据和支持决策分析型(DSS)数据差别甚大,这里需要做大量的数据清洗与数据整理的工作。

       第一:每一个主题的源数据在原有分散数据库中的有许多重复和不一致,且不同数据库的数据是和不同的应用逻辑捆绑的。

       第二:数据仓库中的综合性数据不能从原有的数据库系统直接得到,因此在数据进入数据仓库之前要进过统一和综合。(字段同名异意,异名同义,长度等)

 

不可更新

       数据仓库的数据主要是提供决策分析用,设计的数据主要是数据查询,一般情况下不做修改,这些数据反映的是一段较长时间内历史数据的内容,有一块修改了影响的是整个历史数据的过程数据。

       数据仓库的查询量往往很大,所以对数据查询提出了更高的要求,要求采用各种复杂的索引技术,并对数据查询的界面友好性和数据凸显性提出更高的要求。

 

随时间不断变化

       数据仓库中的数据不可更新是针对应用来说,从数据的进入到删除的整个生命周期中,数据仓库的数据是永远不变的。

       数据仓库的数据是随着时间变化而不断增加新的数据。

       数据仓库随着时间变化不断删去久的数据内容,数据仓库的数据也有时限的,数据库的数据时限一般是60 ~ 90天,而数据仓库的数据一般是5年~10年。

       数据仓库中包含大量的综合性数据,这些数据很多是跟时间有关的,这些数据特征都包含时间项,以标明数据的历史时期。

 

数据仓库和数据库的区别

       数据库的操作:一般称为联机事务处理OLTP(On-Line Transaction Processing),是针对具体的业务在数据库中的联机操作,具有数据量较少的特点,通常对少量的数据记录进行查询、修改。

       数据仓库的操作:一般称为联机分析处理OLAP(On-Line Analytical Processing),是针对某些主题(综合数据)的历史数据进行分析,支持管理决策

比较项

操作型(OLTP)

分析性(OLAP)

关注

细节

综合或提炼

模型

实体 – 关系(E-R)

星型或雪花

操作

可更新

只读,只追加

操作粒度

操作一个单元

操作一个集合

场景

面向事务

面向分析

数据量

需求

日常操作

决策需求

业务方向

客户信息、订单等查询

客户登录间隔时间,市场细分等

 

数据仓库常用系统架构

 

       ODS层(临时存储层):这一层做的工作是贴源,而这些数据和源系统的数据是同构,一般对这些数据分为全量更新和增量更新,通常在贴源的过程中会做一些简单的清洗,

       DW层(数据仓库层):将一些数据关联的日期进行拆分,使得其更具体的分类,一般拆分成年、月、日,而ODS层到DW层的ETL脚本会根据业务需求对数据进行清洗、设计,如果没有业务需求,则根据源系统的数据结构和未来的规划去做处理,对这层的数据要求是一致、准确、尽量建立数据的完整性。

       APP层(引用层):提供报表和数据沙盘展示所需的数据。

 

为什么要分层?

       在未分层的情况下,数据之间的耦合性与业务耦合性是不可避免的,当源业务系统的业务规则发生变化时,可能影响整个数据的清洗过程。

       数据分层简化了数据清洗的过程,每一层的逻辑变得更加简单和易于理解,当发生错误或规则变化时,只需要进行局部调整。

通过大量的预处理来提升应用系统查询速度,进而提升的用户体验,因此数据仓库会冗余大量的数据,是典型的空间换时间的策略。

 

元数据

       在操作数据仓库时,操作的都是元数据,而元数据分为技术元数据和业务元数据。

       技术元数据:是指数据仓库开发、管理、维护相关的数据,描述了数据的原信息,转换描述、数据映射、访问权限等。

       业务元数据:为管理层和业务分析人员服务,从业务的角度描述数据,包括行业术语、数据的可用性、数据的意义等。

       元数据的存储有常用的两种,一种是以数据集为基础,每一个数据集有对应的元数据文件,每一个元数据文件对应数据集的元数据内容,另一种是以数据库为基础,由若干项组成,每一项标识元数据的一个元素。

 

 

为什么需要为数据仓库建模?

       进行全面的业务梳理时,我们可以通过业务模型,全面了解业务结构及运行情况,按照业务特定的规律分门别类和程序化,改进业务的流程

       通过模型的建设,我们可以很清晰的看到数据之间内在的关联关系,从而建立起全方位的数据视角,并消灭信息孤岛数据差异化的问题,进而保证数据的一致性。

       模型可以很好的帮助我们分离出底层技术的实现和上层业务的展现,当上层业务发生变化时,通过数据模型,底层的技术实现可以适应的了业务的变动,进而解决数据库的灵活性

       在模型中可以很好的看出开发人员和业务人员之间的系统建设范围的界定,及未来的规划

 

什么是数据模型?

       数据模型是数据关系的一种映射, 就是将业务之间的关系,用模型图形化的描绘出来,而不再是脑海的一个模糊的关系。

       在设计数据仓库模型和架构时,我们需要懂具体的技术,也需要了解行业的知识和经验来帮助我们对业务进行抽象、处理,进而生成各个阶段的模型。

 

数据模型架构

 

       在大体上,我们将数据模型分为5大块。

       系统记录域:数据仓库业务数据存储区,保证数据的一致性。

       内部管理域:用于内部管理的元数据,统一的元数据管理。

       汇总域:这里的数据来自系统记录域的汇总,保证分析域的主题分析性能,满足部分报表查询。

       分析域:各个业务部分的具体主题业务分析,可以单独存储在相应的数据集市中。

       反馈域:用于相应的前端的反馈数据,视业务的需要设置这个域。

 

维度和指标(度量)

       维度和指标时数据分析领域常用的概念,亦是在设计数据仓库过程中需要考虑的。

       维度就是数据的观察角度,即从哪个角度去分析问题,看待问题。

       指标(度量)就是从维度的基础上去衡算这个结果的值。

       比如银行采集数据:

时间(维度)

分行(维度)

存款额(指标)

1999年

A分行

1000W

2000年

A分行

2000W

2001年

A分行

3000W

1999年

B分行

500W

2000年

B分行

1600W

2001年

B分行

3300W

       维度一般是一个离散的值,比如时间维度上每一个独立的日期或地域,因此统计时,可以把维度相同记录的聚合在一起,应用聚合函数做累加、均值、最大值、最小值等聚合计算。

       指标(度量)就是被聚合的通计算,即聚合运算的结果,一般是一个连续的值。

       比如我们可以从银行的存款额和企业的贷款额之间的计算,推算出目前的市场状况是如何,如果企业的贷款额高,银行的存款额也高,说明人们不愿意消费了,都把钱存起来,企业产品卖不出去,要发工资,那么自然要贷款了,这只是一个例子,具体还需要结合很多数据做分析。

 

事实表和维度表

       事实表和维度表是在设计数据仓库过程中需要考虑的。

       事实表(Fact Table)是指存储有事实记录的表,如系统的日志、销售记录、用户访问日志等信息,事实表的记录是动态的增长的,所以体积是大于维度表。

       用户访问日志(事实表):用户名、url、时间…

       维度表(Dimension Table)也称为查找表(Lookup Table)是与事实表相对应的表,这个表保存了维度的属性值,可以跟事实表做关联,相当于是将事实表中经常重复的数据抽取、规范出来用一张表管理,常见的有日期(日、周、月、季度等属性)、地区表等,所以维度表的变化通常不会太大。

       维度表的存在缩小了事实表的大小,便于维度的管理和CURD维度的属性,不必对事实表的大量记录进行改动,并且可以给多个事实表重用。

       省份表(维度表):北京市、广东省、上海市…

 

数据模型建立过程

 

       业务模型:业务分解和程序化,确定好业务的边界及业务流程,如订单、支付都是一个单独的业务模块

       领域模型:业务概念的抽象、分组,整理分组之间的关联,比如用户购物的业务,抽成一个更大的模型,这个模型一般相对于行业。

       逻辑建模:领域模型中的业务概念实体化,并考虑实体的具体属性及实体与实体之间的关系,比如订单(订单号、付款人…)和支付(金额、支付时间…)的关系。

       物理模型:解决实际应用的落地开发、上线等问题,及性能等一些具体的技术问题。

 

范式建模法

       数据仓库的概念模型(域模型)应该包含企业数据模型的概念模型(域模型)之间的关系,以及各主题域的定义。

       数据仓库的概念模型(域模型)应该比业务系统的主题域模型范围更加广。

       在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类、关系等,在某些时候反而限制了数据仓库模型的灵活性,在底层数据向数据集市汇总时,需要进行一定的变通。

 

维度建模法

       维度建模法的特点在于需要进行大量的数据预处理、预计算,因此会导致大量的数据处理工作,而且业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理、预计算,使用时直接调用计算好的结果,进而导致大量的数据冗余,最大的作用就是解决了性能的问题。

 

实体建模法

       实体建模法是一种抽象客观世界的方法,细分为一个个实体,以及实体之间的关系,将一个业务划分为3个过程,因此只能局限在业务建模和领域建模的阶段,因此到了逻辑建模阶段和物理建模阶段,则是范式和维度建模的发挥了。

 

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

       当设计好概念模型时,就要根据概念模型设计逻辑模型,而在设计逻辑模型是,通常根据事实表和维度表的关系,将常见的模型架构分为星型模型和雪花型模型。

       星型模型架构是一种非正规化的结构,特点是有一张事实表,多张维度表,是不存在渐变维度的,事实表和维度表通过主外键相关联,维度表之间是没有关联,因为维度表的数据冗余,所以统计查询时不需要做过多外部连接。

        雪花模型架构就是将星型模型中的某些维度表抽取成更细粒度的维度表,然后让维度表之间也进行关联,通过最大限度的减少数据存储量以及联合较小的维度表来改善查询性能。

 

 

      《怎样分析数据致提高产出?》https://blog.csdn.net/Su_Levi_Wei/article/details/103794163

 

学习数据仓库的好书,很经典。 目录: 目录 译者序 审、译者简介 前言 第1章 决策支持系统的发展 1 1.1 演化 1 1.2 直接存取存储设备的产生 2 1.3 个人计算机/第四代编程语言技术 3 1.4 进入抽取程序 3 1.5 蜘蛛网 4 1.6 自然演化体系结构的问题 5 1.6.1 数据缺乏可信性 5 1.6.2 生产率问题 8 1.6.3 从数据到信息 10 1.6.4 方法的变迁 11 1.7 体系结构设计环境 12 1.7.1 体系结构设计环境的层次 13 1.7.2 集成 14 1.8 用户是谁 15 1.9 开发生命周期 15 1.10 硬件利用模式 16 1.11 建立重建工程的舞台 16 1.12 监控数据仓库环境 17 1.13 小结 19 第2章 数据仓库环境 20 2.1 数据仓库的结构 22 2.2 面向主题 23 2.3 第1天到第n天的现象 26 2.4 粒度 28 2.4.1 粒度的一个例子 29 2.4.2 粒度的双重级别 31 2.5 分割问题 34 2.6 样本数据库 34 2.7 数据分割 35 2.8 数据仓库中的数据组织 37 2.9 数据仓库—标准手册 41 2.10 审计数据仓库 41 2.11 成本合理性 41 2.12 清理仓库数据 42 2.13 报表体系结构设计环境 42 2.14 机遇性的操作型窗口 43 2.15 小结 44 第3章 设计数据仓库 45 3.1 从操作型数据开始 45 3.2 数据/过程模型体系结构设计环境 49 3.3 数据仓库数据模型 50 3.3.1 数据模型 52 3.3.2 中间层数据模型 54 3.3.3 物理数据模型 58 3.4 数据模型反复开发 59 3.5 规范化/反规范化 60 3.6 数据仓库中的快照 65 3.7 元数据 66 3.8 数据仓库中的管理参照表 66 3.9 数据周期 67 3.10 转换集成的复杂性 70 3.11 触发数据仓库记录 71 3.11.1 事件 72 3.11.2 快照的构成 72 3.11.3 一些例子 72 3.12 简要记录 73 3.13 管理大量数据 74 3.14 创建多个简要记录 75 3.15 从数据仓库环境到操作型环境 75 3.16 正常处理 75 3.17 数据仓库数据的直接访问 76 3.18 数据仓库数据的间接访问 76 3.18.1 航空公司的佣金计算系统 76 3.18.2 零售个性化系统 78 3.18.3 信用审核 80 3.19 数据仓库数据的间接利用 82 3.20 星型连接 83 3.21 小结 86 第4章 数据仓库中的粒度 87 4.1 粗略估算 87 4.2 粒度划分过程的输入 88 4.3 双重或单一的粒度? 88 4.4 确定粒度的级别 89 4.5 一些反馈循环技巧 90 4.6 粒度的级别—以银行环境为例 90 4.7 小结 95 第5章 数据仓库技术 96 5.1 管理大量数据 96 5.2 管理多介质 97 5.3 索引/监视数据 97 5.4 多种技术的接口 97 5.5 程序员/设计者对数据存放位置的控制 98 5.6 数据的并行存储/管理 99 5.7 元数据管理 99 5.8 语言接口 99 5.9 数据的高效装入 99 5.10 高效索引的利用 100 5.11 数据压缩 101 5.12 复合键码 101 5.13 变长数据 101 5.14 加锁管理 102 5.15 单独索引处理 102 5.16 快速恢复 102 5.17 其他的技术特征 102 5.18 DBMS类型数据仓库 102 5.19 改变DBMS技术 104 5.20 多维DBMS数据仓库 104 5.21 双重粒度级 109 5.22 数据仓库环境中的元数据 109 5.23 上下文内容 111 5.24 上下文信息的三种类型 111 5.25 捕获管理上下文信息 113 5.26 刷新数据仓库 113 5.27 小结 114 第6章 分布式数据仓库 116 6.1 引言 116 6.2 局部数据仓库 118 6.3 全局数据仓库 119 6.4 互斥数据 121 6.5 冗余 123 6.6 全
第1章 决策支持系统的发展 1.1 演化 1.2 自然演化式体系结构的问题 1.3 开发生命周期 1.4 硬件利用模式 1.5 为重建工程创造条件 1.6 监控数据仓库环境 1.7 小结 第2章 数据仓库环境 2.1 数据仓库的结构 2.2 面向主题 2.3 第1天到第n天的现象 2.4 粒度 2.5 探查与数据挖掘 2.6 活样本数据库 2.7 分区设计方法 2.8 数据仓库中的数据组织 2.9 审计与数据仓库 2.10 数据的同构/异构 2.11 数据仓库中的数据清理 2.12 报表与体系结构化环境 2.13 各种环境中的操作型窗口 2.14 数据仓库中的错误数据 2.15 小结 第3章 设计数据仓库 3.1 从操作型数据开始 3.2 数据/过程模型与体系结构化环境 3.3 数据仓库数据模型 3.4 数据模型与迭代式开发 3.5 规范化/反向规范化 3.6 元数据 3.7 数据周期——时间间隔 3.8 转换集成的复杂性 3.9 数据仓库记录的触发 3.10 概要记录 3.11 管理大量数据 3.12 创建多个概要记录 3.13 从数据仓库环境到操作型环境 3.14 数据仓库数据的直拉操作型访问 3.15 数据仓库数据的间接访问 3.16 数据仓库数据的间接使用 3.17 星形连接 3.18 支持操作型数据存储 3.19 需求Zachman框架 3.20 小结 第4章 数据仓库中的粒度 4.1 粗略估算 4.2 规划过程的输入 4.3 溢出存储器中的数据 4.4 确定粒度级别 4.5 一些反馈循环技巧 4.6 确定粒度级别的几个例子 4.7 填充数据集市 4.8 小结 第5章 数据仓库技术 5.1 管理大量数据 5.2 管理多种介质 5.3 索引监控数据 5.4 多种技术的接口 5.5 程序员/设计者对数据存放位置的控制 5.6 数据的并行存储管理 5.7 语言接口 5.8 数据的有效装裁 5.9 有效利用索引 5.10 数据压缩 5.11 复合主键 5.12 变长数据 5.13 加锁管理 5.14 只涉及索引的处理 5.15 快速恢复 5.16 其他的技术特征 5.17 DBMS类型数据仓库 5.18 改变DBMS技术 5.19 多维DBMS数据仓库 5.20 在多种存储介质上构建数据仓库 5.21 数据仓库环境中元数据的角色 5.22 上下文内容 5.23 刷新数据仓库 5.24 测试问题 5.25 小结 第6章 分布式数据仓库 第7章 主管信息系统数据仓库 第8章 外部数据数据仓库 第9章 迁移到体系结构化环境 第10章 数据仓库Web 第11章 非结构化数据数据仓库 第12章 大型数据仓库 第13章 关系模型多维模型数据库设计基础 第14章 数据仓库高级话题 第15章 数据仓库的成本论证投资回报 第16章 数据仓库ODS 第17章 企业信息依从准则数据仓库 第18章 最终用户社区 第19章 数据仓库设计的复查要目
©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值