数据仓库基础

一、数据仓库定义

数据仓库，英文名称为Data Warehouse，可简写为DW。

关于数据仓库概念的标准定义业内认可度比较高的，是由数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出：

中文定义：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

英文定义：A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions.

二、数据仓库整体架构

观点一：

数据仓库强调分层。主要包含数据采集层、数据存储层、数据共享层、数据应用层。

观点二：

数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用：

　数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

1. 数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。

2.数据存储与分析

　源数据通过ETL的日常任务调度导出，并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议，就是到底数据仓库需不需要储存细节数据，一方的观点是数据仓库面向分析，所以只要存储特定需求的多维分析模型；另一方的观点是数据仓库先要建立和维护细节数据，再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导入的数据必须经过整理和转换使其面向主题。简单地解释下：

(1).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在数据仓库就得不偿失；

(2).为什么要存细节数据？细节数据是必需的，数据仓库的分析需求会时刻变化，而有了细节数据就可以做到以不变应万变，但如果我们只存储根据某些需求搭建起来的数据模型，那么显然对于频繁变动的需求会手足无措；

(3).为什么要面向主题？面向主题是数据仓库的第一特性，主要是指合理地组织数据以方面实现分析。对于源数据而言，其数据组织形式是多样的，像点击流的数据格式是未经优化的，前台数据库的数据是基于OLTP操作组织优化的，这些可能都不适合分析，而整理成面向主题的组织形式才是真正地利于分析的，比如将点击流日志整理成页面（Page）、访问（Visit或Session）、用户（Visitor）三个主题，这样可以明显提升分析的效率。

3.数据共享

指的是数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库

4.数据应用

业务用户通过BI产品进行应用。

5.实时计算

在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架

6.任务调度与监控

任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。

7.元数据管理

元数据（Meta Date），其实应该叫做解释性数据，或者数据字典，即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。

数据仓库建设步骤：

1.系统分析，确定主题

确定一下几个因素：

·操作出现的频率，即业务部门每隔多长时间做一次查询分析。

·在系统中需要保存多久的数据，是一年、两年还是五年、十年。

·用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。

·用户所能接受的响应时间是多长、是几秒钟，还是几小时。

2.选择满足数据仓库系统要求的软件平台

选择合适的软件平台，包括数据库、建模工具、分析工具等。有许多因素要考虑，如系统对数据量、响应时间、分析功能的要求等，以下是一些公认的选择标准：

·厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。

·数据库对大数据量（TB级）的支持能力。

·数据库是否支持并行操作。

·能否提供数据仓库的建模工具，是否支持对元数据的管理。

·能否提供支持大数据量的数据加载、转换、传输工具（ETT）。

·能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。

3.建立数据仓库的逻辑模型

具体步骤如下：

（1）确定建立数据仓库逻辑模型的基本方法。

（2）基于主题视图，把主题视图中的数据定义转到逻辑数据模型中。

（3）识别主题之间的关系。

（4）分解多对多的关系。

（5）用范式理论检验逻辑数据模型。

（6）由用户审核逻辑数据模型。

4.逻辑数据模型转化为数据仓库数据模型

具体步骤如下：

（1）删除非战略性数据：数据仓库模型中不需要包含逻辑数据模型中的全部数据项，某些用于操作处理的数据项要删除。

（2）增加时间主键：数据仓库中的数据一定是时间的快照，因此必须增加时间主键。

（3）增加派生数据：对于用户经常需要分析的数据，或者为了提高性能，可以增加派生数据。

（4）加入不同级别粒度的汇总数据：数据粒度代表数据细化程度，粒度越大，数据的汇总程度越高。粒度是数据仓库设计的一个重要因素，它直接影响到驻留在数据仓库中的数据量和可以执行的查询类型。显然，粒度级别越低，则支持的查询越多；反之，能支持的查询就有限。

5.数据仓库数据模型优化

数据仓库设计时，性能是一项主要考虑因素。在数据仓库建成后，也需要经常对其性能进行监控，并随着需求和数据量的变更进行调整。

优化数据仓库设计的主要方法是：

·合并不同的数据表。

·通过增加汇总表避免数据的动态汇总。

·通过冗余字段减少表连接的数量，不要超过3~5个。

·用ID代码而不是描述信息作为键值。

·对数据表做分区。

6.数据清洗转换和传输

由于业务系统所使用的软硬件平台不同，编码方法不同，业务系统中的数据在加载到

在设计数据仓库的数据加载方案时，必须考虑以下几项要求：

·加载方案必须能够支持访问不同的数据库和文件系统。

·数据的清洗、转换和传输必须满足时间要求，能够在规定的时间范围内完成。

·支持各种转换方法，各种转换方法可以构成一个工作流。

·支持增量加载，只把自上一次加载以来变化的数据加载到数据仓库。

7.开发数据仓库的分析应用

建立数据仓库的最终目的是为业务部门提供决策支持能力，必须为业务部门选择合适的工具实现其对数据仓库

信息部门所选择的开发工具必须能够：

·满足用户的全部分析功能要求。数据仓库中的用户包括了企业中各个业务部门，他们的业务不同，要求的分析功能也不同。如有的用户只是简单的分析报表，有些用户则要求做预测和趋势分析。

·提供灵活的表现方式。分析的结果必须能够以直观、灵活的方式表现，支持复杂的图表。使用方式上，可以是客户机/服务器方式，也可以是浏览器方式。

事实上，没有一种工具能够满足数据仓库的全部分析功能需求，一个完整的数据仓库系统的功能可能是由多种工具来实现，因此必须考虑多个工具之间的接口和集成性问题，对于用户来说，希望看到的是一致的界面。

8.数据仓库的管理

只重视数据仓库

数据库管理需要考以下几个方面：

·安全性管理。数据仓库中的用户只能访问到他的授权范围内的数据，数据在传输过程中的加密策略。

·数据仓库的备份和恢复。数据仓库的大小和备份的频率直接影响到备份策略。

·如何保证数据仓库系统的可用性，硬件还是软件方法。

·数据老化。设计数据仓库中数据的存放时间周期和对过期数据的老化方法，如历史数据只保存汇总数据，当年数据保存详细记录。

然而，元数据管理贯穿于整个系统的建设过程中，元数据是描述数据的数据。在数据采集阶段，元数据主要包括下列信息：

·源数据的描述定义：类型、位置、结构。

·数据转换规则：编码规则、行业标准。

·目标数据仓库的模型描述：星型/雪花模型定义，维/事实结构定义。

·源数据到目标数据仓库的映射关系：函数/表达式定义。

·代码：生成转换程序、自动加载程序等。

在数据管理阶段，元数据主要包括下列信息：

·汇总数据的描述：汇总/聚合层次、物化视图结构定义。

·历史数据存储规则：位置、存储粒度。

·多维数据结构描述：立方体定义、维结构、度量值、钻取层次定义等。

在数据展现阶段，元数据主要包括以下信息：

·报表的描述：报表结构的定义。

·统计函数的描述：各类统计分析函数的定义。

·结果输出的描述：图、表输出的定义。

元数据不但是独立存放，而且对用户是透明的，标准元数据之间可以互相转换。

閱讀更多 小可愛100w 的文章

關鍵字: 软件 恩门 数据仓库