Dwh 简明教程

Data Warehousing - Quick Guide

Data Warehousing - Overview

“数据仓库”这一术语最早由比尔·因蒙于 1990 年创造。根据因蒙的说法，数据仓库是主题导向、集成、随时间变化且不可变的数据集合。这些数据可帮助分析师在组织中做出明智的决策。

操作数据库每天都在频繁更改，原因是会发生交易。假设业务经理想要分析有关任何数据的先前反馈，例如产品、供应商或任何消费者数据，那么经理将没有可用数据进行分析，因为先前数据已因交易而更新。

数据仓库通过多维视图为我们提供概括和汇总数据。除了概括和汇总的数据视图外，数据仓库还为我们提供了联机分析处理 (OLAP) 工具。这些工具可以帮助我们以交互式且有效的方式分析多维空间中的数据。这种分析可生成数据概括和数据挖掘。

关联、聚类、分类、预测等数据挖掘功能可以与 OLAP 操作集成，以在多个抽象层级中增强交互式知识挖掘。这就是为什么数据仓库现在已成为数据分析和联机分析处理的重要平台。

Understanding a Data Warehouse

数据仓库是一个数据库，与组织的操作数据库分开存放。
数据仓库中没有频繁更新。
它拥有经整合的历史数据，可帮助组织分析其业务。
数据仓库可帮助高管们组织、理解和利用其数据以做出战略决策。
数据仓库系统可帮助集成不同的应用程序系统。
数据仓库系统可帮助分析经整合的历史数据。

Why a Data Warehouse is Separated from Operational Databases

数据仓库与操作数据库分开放置，原因如下−

操作数据库用于已知任务和工作负载，如搜索特定记录、索引等。而数据仓库查询通常很复杂，提供数据的一般形式。
操作数据库支持对多个事务的并发处理。操作数据库需要并发控制和恢复机制来确保数据库的鲁棒性和一致性。
操作数据库查询允许读取和修改操作，而 OLAP 查询只需对存储的数据进行 read only 访问。
操作数据库维护当前数据。而数据仓库则维护历史数据。

Data Warehouse Features

数据仓库的关键特性如下所述−

Subject Oriented − 数据仓库是面向主题的，因为它提供与主题相关的信息，而不是组织的持续运营。这些主题可以是产品、客户、供应商、销售、收入等。数据仓库不关注持续运营，而是关注为决策建模和分析数据。
Integrated − 数据仓库通过集成来自不同来源的数据构建而成，如关系数据库、平面文件等。此集成增强了对数据的有效分析。
Time Variant − 数据仓库中收集的数据已识别出特定的时间段。数据仓库中的数据提供了历史观点的信息。
Non-volatile − 非易失性是指当向其中添加新数据时以前的数据不会被擦除。数据仓库与操作数据库分开存储，因此操作数据库的频繁变化不会反映在数据仓库中。

Note − 数据仓库不需要事务处理、恢复和并发控制，因为它被物理存储并与操作数据库分开。

Data Warehouse Applications

如前所述，数据仓库帮助企业管理人员组织、分析并使用其数据进行决策。数据仓库是企业管理“闭环”反馈系统的计划执行评估的一部分。数据仓库广泛用于以下领域−

Financial services
Banking services
Consumer goods
Retail sectors
Controlled manufacturing

Types of Data Warehouse

信息处理、分析处理和数据挖掘是接下来讨论的三种数据仓库应用程序−

Information Processing − 数据仓库允许处理存储在其中的数据。可以通过查询、基本统计分析、使用交叉表、表格、图表或图形进行报告来处理数据。
Analytical Processing − 数据仓库支持对其中存储的信息进行分析处理。可以通过基本 OLAP 操作来分析数据，包括切片、下钻、上钻和旋转。
Data Mining − 数据挖掘通过查找隐藏的模式和关联、构建分析模型、执行分类和预测来支持知识发现。这些挖掘结果可以使用可视化工具呈现。

Sr.No.

Data Warehouse (OLAP)

Operational Database(OLTP)

它涉及对信息的处理。

It involves day-to-day processing.

OLAP 系统由知识工作者（如高管、经理和分析师）使用。

OLTP 系统由文员、DBA 或数据库专业人员使用。

用于分析业务。

它用于经营业务。

它专注于信息输出。

它专注于数据输入。

它基于星型模式、雪花模式和事实星座模式。

它基于实体关系模型。

它专注于信息输出。

It is application oriented.

It contains historical data.

It contains current data.

它提供汇总和合并的数据。

它提供原始和高度详细的数据。

它提供数据汇总和多维视图。

它提供详细的平面关系数据视图。

用户数量为数百。

用户数量为数千。

访问的记录数以百万计。

访问的记录数为几十。

数据库大小从 100GB 到 100 TB。

数据库大小从 100 MB 到 100 GB。

These are highly flexible.

It provides high performance.

Data Warehousing - Concepts

What is Data Warehousing?

数据仓库是构建和使用数据仓库的过程。数据仓库是通过集成来自多个异构源的数据构建的，这些源支持分析报告、结构化或即席查询以及决策。数据仓库涉及数据清理、数据集成和数据合并。

Using Data Warehouse Information

有有助于利用数据仓库中可用数据的决策支持技术。这些技术帮助高管快速有效地使用仓库。他们可以收集数据、分析数据并根据仓库中的信息做出决策。仓库中收集的信息可用于以下任何域中−

Tuning Production Strategies −通过比较季度或年度销售额，产品的策略可以很好地调整，管理产品组合。
Customer Analysis −客户分析是通过分析客户的购买偏好、购买时间、预算周期等来完成的。
Operations Analysis − 数据仓库也有助于客户关系管理和环境纠正。这些信息还允许我们分析业务运营。

Integrating Heterogeneous Databases

为了集成异构数据库，我们有两种方法−

Query-driven Approach
Update-driven Approach

Query-Driven Approach

这是集成异构数据库的传统方法。此方法用于在多个异构数据库之上构建包装器和集成器。这些集成器也被称为调解器。

Process of Query-Driven Approach

当向客户端发出查询时，元数据词典将查询转换为适用于所涉及各个异构网站的适当形式。
现在，将映射这些查询并将其发送到本地查询处理器。
来自异构站点的结果被集成到全局答案集中。

Disadvantages

查询驱动方法需要复杂的集成和过滤流程。
这种方法非常低效。
对于频繁的查询来说，成本非常高。
对于需要聚合的查询，这种方法也非常昂贵。

Update-Driven Approach

这是传统方法的替代方法。当今的数据仓库系统遵循更新驱动方法，而不是前面讨论的传统方法。在更新驱动方法中，来自多个异构源的信息会预先集成并存储在仓库中。该信息可用于直接查询和分析。

Advantages

此方法有以下优点：

这种方法提供了高性能。
数据在语义数据存储中预先复制、处理、集成、注释、汇总和重组。
查询处理不需要一个在本地源处理数据的界面。

Functions of Data Warehouse Tools and Utilities

以下是数据仓库工具和实用程序的功能−

Data Extraction − 涉及从多个异构源收集数据。
Data Cleaning − 涉及查找和更正数据中的错误。
Data Transformation − 涉及将数据从传统格式转换为仓库格式。
Data Loading − 涉及分类、汇总、合并、检查完整性以及构建索引和分区。
Refreshing − 涉及从数据源更新到仓库。

Note − 数据清理和数据转换是提高数据和数据挖掘结果质量的重要步骤。

Data Warehousing - Terminologies

在本章中，我们将讨论数据仓库中最常用的几个术语。

Metadata

元数据简单地定义为关于数据的数据。用于表示其他数据的数据称为元数据。例如，书籍的索引是书中内容的元数据。换句话说，我们可以说元数据是将我们引至详细数据的大致数据。

在数据仓库方面，我们可以将元数据定义如下 −

元数据是数据仓库的路线图。
数据仓库中的元数据定义了仓库对象。
元数据充当目录。此目录帮助决策支持系统定位数据仓库的内容。

Metadata Repository

元数据存储库是数据仓库系统的一个组成部分。它包含以下元数据 −

Business metadata − 它包含数据所有权信息、业务定义和更改策略。
Operational metadata − 它包括数据的时效性与数据谱系。数据的时效性指数据是活动、已存档还是已被清除。数据谱系是指数据迁移和在其上应用的转换的历史。
Data for mapping from operational environment to data warehouse − 它元数据包括源数据库及其内容、数据提取、数据分区、清理、转换规则、数据刷新和清除规则。
The algorithms for summarization − 它包括维度算法、粒度数据、聚合、汇总等。

Data Cube

数据立方体帮助我们在多维度表示数据。它通过维度和事实来定义。维度是企业按其保存记录的实体。

Illustration of Data Cube

假设一家公司希望借助销售数据仓库来跟踪销售记录，并按时间、项目、分支和位置。这些维度允许跟踪月度销售情况以及项目售出的分支。每个维度都关联一张表。这张表称为维度表。例如，“项目”维度表可能具有诸如项目名称、项目类型、项目品牌之类的属性。

下表表示公司关于时间、项目和位置维度的销售数据的二维视图。

但此处的此二维表中，我们只有时间和项目才具有记录。新德里的销售情况根据销售项目类型按时间和项目维度显示。如果我们希望根据更多维度（比如位置维度）查看销售数据，那么三维视图将很有用。下方的表格显示了关于时间、项目和位置的三维销售数据视图 −

以上三维表格可以如以下图形所示表示为三维数据立方体 −

Data Mart

数据超市包含组织范围内对组织中特定人群有价值的数据子集。换句话说，数据超市仅包含特定于特定人群的数据。例如，市场数据超市可能仅包含与项目、客户和销售有关的数据。数据超市局限于主题。

Points to Remember About Data Marts

用于实施数据市集的是基于 Windows 或 Unix/Linux 的服务器。它们在低成本服务器上实现。
数据市集的实施周期以短周期为单位，即以周为单位，而不是以月或年为单位。
如果数据市集的规划和设计不是全组织范围的，那么从长远来看，数据市集的生命周期可能很复杂。
数据市集的规模较小。
数据市集按部门定制。
数据市集的源是按部门结构组织的数据仓库。
Data marts are flexible.

下图显示了数据市集的图形表示形式。

Virtual Warehouse

对一个操作数据仓库的视图称为虚拟仓库。创建虚拟仓库很容易。创建虚拟仓库需要操作数据库服务器上有多余容量。

Data Warehousing - Delivery Process

数据仓库绝不是一成不变的；它会随着业务的扩展而不断发展。随着业务发展，其需求不断变化，因此必须设计一个数据仓库来应对这些变化。因此，数据仓库系统需要具有灵活性。

理想情况下，应该有一个交付流程来交付数据仓库。然而，数据仓库项目通常会受到各种问题的困扰，使得按照瀑布方法要求的严格有序的方式完成任务和交付成果变得困难。大多数时候，需求并没有被完全理解。只有在收集并研究所有需求后，才能完成架构、设计和构建组件。

Delivery Method

交付方法是为交付数据仓库而采用的联合应用程序开发方法的一种变体。我们对数据仓库交付流程进行了分阶段，以最大程度降低风险。我们将在此处讨论的方法并没有缩短整体交付时间表，而是确保在开发过程中逐步交付业务收益。

Note - 交付流程被分解成各个阶段以降低项目和交付风险。

下图解释了交付过程中的各个阶段 -

IT Strategy

数据仓库是战略性投资，需要一个业务流程来创收。IT 战略是获得和保留项目资金所必需的。

Business Case

商业案例的目的是估算企业在使用数据仓库时应考虑的收益。这些收益可能无法量化，但预计的收益需要明确表述。如果某个数据仓库没有明确的商业案例，那么该数据仓库在交付过程中的某个阶段可能会存在信誉问题。因此，在数据仓库项目中，我们需要了解投资的商业案例。

Education and Prototyping

在确定解决方案之前，各种组织会尝试数据分析概念，并自学数据仓库的价值。通过原型展示来满足这一目标。它有助于了解数据仓库的可行性和收益。小规模的原型展示活动可以促进教育过程的发挥，只要满足以下条件：

原型展示满足既定的技术目标。
在展示可行性概念后，可以不再采用该原型展示。
该活动涉及数据仓库的现有数据内容的一小部分。
活动时标没有必要。

以下几点对于产生早期版本并满足收益至关重要：

识别一个能够不断发展的架构。
重点在于业务需求和技术蓝图阶段。
将第一构建阶段的范围限制在满足业务需求的最低限度。
了解数据仓库的短期和中期需求。

Business Requirements

为提供高质量的交付成果，我们应确保了解整体需求。如果我们了解了短期和中期的业务需求，那么就能够设计一个解决方案来满足短期需求。随后可以将短期解决方案扩展至一个完整的解决方案。

此阶段确定以下方面：

应用于数据的业务规则。
数据仓库中信息所需的逻辑模型。
即时需求的查询配置文件。
提供该数据的源系统。

Technical Blueprint

此阶段需要交付一个满足长期需求的整体架构。该阶段还会交付应在短期内实施以实现业务收益的组成部分。蓝图需要识别以下内容：

The overall system architecture.
The data retention policy.
备份和恢复策略。
服务器和数据市集架构。
硬件和基础设施的容量计划。
数据库设计的组件。

Building the Version

在此阶段，生成第一个生产可交付成果。此生产可交付成果是数据仓库中最小的组成部分。这个最小组成部分增加了业务效益。

History Load

这是将所需的剩余历史记录加载到数据仓库中的阶段。在此阶段，我们不会添加新实体，但可能会创建其他物理表来存储增加的数据量。

让我们举个例子。假设构建版本阶段已交付了一个包括两个月历史记录的零售销售分析数据仓库。此信息将允许用户仅分析最近的趋势并解决短期问题。在这种情况下，用户无法识别每年的季节性趋势。为了帮助他这样做，可以从归档中加载过去两年的销售历史记录。现在，40GB 数据已扩展到 400GB。

Note − 备份和恢复过程可能会变得很复杂，因此建议在单独的阶段中执行此活动。

Ad hoc Query

在此阶段，我们配置一个用于操作数据仓库的临时查询工具。这些工具可以生成数据库查询。

Note − 建议在对数据库进行大幅修改时不要使用这些访问工具。

Automation

在此阶段，操作管理过程已完全自动化。这些内容包括：

将数据转换为适合分析的格式。
监视查询概要文件并确定适当的汇总以维持系统性能。
从不同的源系统中提取和加载数据。
从数据仓库中的预定义定义中生成汇总。
备份、恢复和存档数据。

Extending Scope

在此阶段，数据仓库已扩展以满足新的业务需求。范围可以通过两种方式扩展：

通过将其他数据加载到数据仓库中。
引入新的数据处理中心，同时使用现有的信息。

Note − 由于此阶段将涉及相当的工作量和复杂性，因此应单独执行。

Requirements Evolution

从交付流程的角度来看，需求总是可以更改的。它们不是一成不变的。交付流程必须支持这一点，并允许这些更改反映在系统中。

通过围绕业务流程内的数据使用来设计数据仓库，而不是围绕现有查询的数据需求来解决此问题。

该体系结构旨在随着业务需求而改变和增长，该流程作为一个伪应用程序开发流程运行，其中新需求不断输入到开发活动中，并生成部分可交付成果。这些部分可交付成果反馈给用户，然后重新加工，以确保整个系统不断更新，以满足业务需求。

Data Warehousing - System Processes

我们有用于应用于操作型数据库的固定数量的操作，并且我们有 use normalized data 、 keep table small 等明确界定的技术。这些技术适用于提供解决方案。但在决策支持系统中，我们不知道将来需要执行哪些查询和操作。因此，应用于操作型数据库的技术不适用于数据仓库。

在本章中，我们将讨论如何基于 Unix 和关系数据库等开放系统技术构建数据仓库解决方案。

Process Flow in Data Warehouse

有四个主要过程有助于建立一个数据仓库：

提取并加载数据。
清理和转换数据。
备份和存档数据。
管理查询并将其引导到适当的数据源。

Extract and Load Process

数据提取从源系统获取数据。数据加载提取提取的数据并将其加载到数据仓库中。

Note - 在将数据加载到数据仓库之前，必须对从外部源提取的信息进行重建。

Controlling the Process

控制流程包括确定何时开始数据提取和对数据进行一致性检查。控制流程确保工具、逻辑模块和程序按正确的顺序和时间执行。

When to Initiate Extract

数据在提取时需要处于一致状态，也就是说，数据仓库应向用户表示单一的、一致的信息版本。

例如，在电信部门的客户分析数据仓库中，将周三下午 8 点从客户数据库中提取的客户列表与周二下午 8 点之前的客户订阅事件合并是不合逻辑的。这意味着我们正在查找没有关联订阅的客户。

Loading the Data

在提取数据之后，将其加载到临时数据存储中，在那里对其进行清理并使其保持一致。

Note - 仅当所有数据源加载到临时数据存储中时，才执行一致性检查。

Clean and Transform Process

一旦数据被提取并加载到临时数据存储中，就该执行清理和转换了。以下是清理和转换涉及的步骤列表：

将加载的数据清理并转换为结构
Partition the data
Aggregation

Clean and Transform the Loaded Data into a Structure

清理并转换加载的数据有助于加快查询。它可以通过使数据一致来完成：

within itself.
与同一数据源中的其他数据一致。
与其他源系统中的数据一致。
与数据仓库中现有的数据搭配使用。

转换包括将源数据转换为结构。对数据进行结构化有助于提高查询性能并降低运行成本。数据仓库中包含的数据必须经过转换，以支持性能需求并控制持续的运行成本。

Partition the Data

这样将优化硬件性能并简化数据仓库管理。我们在此将每个事实表划分为多个单独分区。

Aggregation

需要聚合来加速通用查询。聚合依赖于大多数通用查询将分析详细数据的子集或聚合这一事实。

Backup and Archive the Data

为了在数据丢失、软件故障或硬件故障时恢复数据，有必要定期进行备份。归档涉及以一种可以根据需要快速恢复的方式从系统中删除旧数据。

例如，在零售销售分析数据仓库中，可能需要保留 3 年的数据，而最近 6 个月的数据会保留在线。在这样的情况下，通常需要能够对今年和去年逐月进行比较。在这种情况下，我们需要从归档中恢复一些数据。

Query Management Process

此流程执行以下功能−

manages the queries.
有助于加快查询执行时间。
将查询引导至最有效的数据源。
确保所有系统源以最有效的方式使用。
monitors actual query profiles.

仓库管理流程使用此流程生成的信息来确定要生成哪些聚合。此流程通常不会在将信息常规加载到数据仓库时运行。

Data Warehousing - Architecture

在本章中，我们将讨论用于数据仓库设计的数据仓库架构业务分析框架。

Business Analysis Framework

业务分析师从数据仓库中获取信息，以衡量绩效并做出关键调整，以便在市场中胜过其他业务持有人。拥有数据仓库可提供以下优势 −

由于数据仓库可以快速有效地收集信息，因此可以提高业务生产力。
数据仓库为我们提供了客户和物品的一致视图，因此可以帮助我们管理客户关系。
数据仓库还可以通过长期跟踪趋势和模式，以一致可靠的方式帮助降低成本。

要设计出一个有效率的数据仓库，我们需要了解和分析业务需求，并构建 business analysis framework 。每个人对数据仓库设计都有不同的看法。这些视图如下所示 −

The top-down view − 此视图允许选择数据仓库所需的相关信息。
The data source view − 此视图显示由操作系统捕获、存储和管理的信息。
The data warehouse view − 这一视图包含事实表和维度表。它表示存储在数据仓库中的信息。
The business query view − 这是从最终用户角度查看的数据。

Three-Tier Data Warehouse Architecture

一般来说，数据仓库采用三层架构。以下是数据仓库架构的三层。

Bottom Tier − 架构的最底层是数据仓库数据库服务器。它是关系数据库系统。我们使用后端工具和实用程序向底层馈送数据。这些后端工具和实用程序执行提取、清理、加载和刷新功能。
Middle Tier − 在中间层，我们有 OLAP 服务器，可以通过以下两种方式实现。通过关系 OLAP (ROLAP)，这是一种扩展的关系数据库管理系统。ROLAP 将多维数据上的操作映射到标准关系操作。通过多维 OLAP (MOLAP) 模型，直接实现多维数据和操作。
Top-Tier − 这一层是前端客户端层。这一层包含查询工具和报告工具、分析工具和数据挖掘工具。

下图描绘了数据仓库的三层架构 −

Data Warehouse Models

从数据仓库架构的角度来看，我们有以下数据仓库模型 −

Virtual Warehouse
Data mart
Enterprise Warehouse

Virtual Warehouse

对操作数据仓库的视图被称为虚拟仓库。构建虚拟仓库很容易。构建虚拟仓库需要操作数据库服务器上的过剩容量。

Data Mart

数据市包含组织范围内的数据子集。这一数据子集对特定组织群体有价值。

换句话说，我们可以声称数据市包含特定群体特有的数据。例如，营销数据市可能包含与项目、客户和销售相关的数据。数据市局限于主题。

关于数据市需要注意的要点 −

使用基于 Window 或 Unix/Linux 的服务器来实现数据市。它们在低成本服务器上实现。
实现数据市周期以短时间段（即以周而不是月或年为单位）衡量。
如果数据市未经全组织规划和设计，从长远来看其生命周期可能是复杂的。
数据市集的规模较小。
数据市集按部门定制。
数据市集的源是按部门结构组织的数据仓库。
Data mart are flexible.

Enterprise Warehouse

企业仓库收集有关整个组织的信息和主题
它为我们提供企业范围内的数据集成。
数据从操作系统和外部信息提供商集成。
此信息可能从几千兆字节到数百千兆字节、太字节或更大。

Load Manager

这一组件执行提取和加载流程所需的运算。

加载管理器的尺寸和复杂度在从一个数据仓库到其他数据仓库的具体解决方案中会各有不同。

Load Manager Architecture

加载管理器执行以下功能−

从源系统中提取数据。
快速加载已提取的数据到临时数据存储中。
执行与数据仓库中的数据结构类似的简单转换。

Extract Data from Source

数据是从操作数据库或外部信息的提供者中提取的。网关是用于提取数据的应用程序。它由底层的 DBMS 支持，允许客户端程序在服务器上生成要执行的 SQL。开放数据库连接 (ODBC)、Java 数据库连接 (JDBC) 是网关示例。

Fast Load

为了最小化总加载窗口，需要在尽可能短的时间内将数据加载到仓库中。
转换会影响数据处理速度。
在应用转换和检查之前，将数据加载到关系数据库中效果会更好。
实践证明网关技术并不合适，因为当涉及到大量数据时，它们往往表现不佳。

Simple Transformations

在加载时，可能需要执行简单的转换。在完成此操作后，我们就能够执行复杂的检查。假设我们正在加载 EPOS 销售交易，我们需要执行以下检查：

去除仓库中不需要的所有列。
将所有值转换为所需的数据类型

Warehouse Manager

仓库管理员负责仓库管理流程。它包含第三方系统软件、C 程序和 shell 脚本。

仓库管理器的尺寸和复杂度在具体解决方案中会各有不同。

Warehouse Manager Architecture

仓库管理员包括以下内容 -

The controlling process
带 SQL 的存储过程或 C
Backup/Recovery tool
SQL Scripts

Operations Performed by Warehouse Manager

仓库管理员分析数据，执行一致性和引用完整性检查。
针对基础数据创建索引、业务视图和分区视图。
生成新的聚合并且更新现有聚合。生成正规化。
将源数据转换并合并到已发布的数据仓库中。
备份数据仓库中的数据。
存档已达到捕获周期末尾的数据。

Note − 仓库管理员也会分析查询概要以确定指标和聚合是合适的。

Query Manager

查询管理器负责将查询引导到合适的表中。
通过将查询定向到合适的表格，可以提高查询和响应生成的速率。
查询管理器负责安排用户提出的查询的执行。

Query Manager Architecture

下图展示了查询管理器的架构。它包括以下内容：

通过 C 工具或 RDBMS 查询重定向
Stored procedures
Query management tool
通过 C 工具或 RDBMS 查询调度
通过第三方软件查询调度

Detailed Information

不保留详细的信息，而是将其汇总到下一个详细信息级别，然后存档至磁带。数据仓库的详细信息部分将详细的信息保存在星型雪花模式中。详细的信息加载到数据仓库以补充汇总数据。

下图以图形形式展示了详细的信息存储在哪以及如何使用。

Note - 如果详细的信息离线保存以最小化磁盘存储，在存档之前应确保数据已提取、清理并转换到星型雪花模式。

Summary Information

汇总信息是数据仓库的组成部分，存储预定义的汇总。这些汇总由仓库管理器生成。必须将汇总信息视为瞬态。为了对不断变化的查询概况做出响应，它会随时发生改变。

有关汇总信息的要点如下 −

汇总信息加速了常见查询的执行。
它增加了运营成本。
每当有新数据加载到数据仓库时，都需要更新它。
它可能没有进行备份，因为它可从详细信息中重新生成。

Data Warehousing - OLAP

在线分析处理服务器 (OLAP) 基于多维数据模型。它允许管理人员和分析人员通过快速、一致和交互方式获取信息的深刻见解。本章介绍 OLAP 的类型、OLAP 的操作、OLAP 与统计数据库和 OLTP 之间的差异。

Types of OLAP Servers

我们有四种类型的 OLAP 服务器 −

Relational OLAP (ROLAP)
Multidimensional OLAP (MOLAP)
Hybrid OLAP (HOLAP)
Specialized SQL Servers

Relational OLAP

ROLAP 服务器放置在关系型后端服务器和客户端前端工具之间。ROLAP 使用关系型或扩展关系型 DBMS 来存储和管理仓库数据。

ROLAP 包括以下内容 -

汇总导航逻辑的实现。
针对每个 DBMS 后端的优化。
Additional tools and services.

Multidimensional OLAP

MOLAP 使用基于数组的多维存储引擎来实现数据的多维视图。使用多维数据存储时，如果数据集稀疏，存储利用率可能会低。因此，许多 MOLAP 服务器使用两级数据存储表示来处理稠密和稀疏数据集。

Hybrid OLAP

混合 OLAP 是 ROLAP 和 MOLAP 的组合。它提供了 ROLAP 的较高可扩展性和 MOLAP 的更快计算。HOLAP 服务器允许存储详细信息的庞大数据量。汇总会单独存储在 MOLAP 存储中。

Specialized SQL Servers

专业 SQL 服务器在只读环境中为星型和雪花型架构上的 SQL 查询提供高级查询语言和查询处理支持。

OLAP Operations

由于 OLAP 服务器基于多维数据视图，因此我们将在多维数据中讨论 OLAP 操作。

以下是 OLAP 操作列表：

Roll-up
Drill-down
Slice and dice
Pivot (rotate)

Roll-up

汇总对数据立方体执行聚合，方式如下：

按维度的一个概念层次向上爬升
By dimension reduction

下图展示了汇总如何工作。

汇总通过按维度 location 的概念层次向上爬升执行。
最初的概念层次是“街道 < 城市 < 省份 < 国家”。
在汇总时，数据从城市级别按位置层次升序聚合到国家级别。
数据按城市分组，而不是按国家分组。
执行汇总时，会从数据立方体中移除一个或多个维度。

Drill-down

向下钻取是汇总的反向操作。按以下任一方式执行：

按维度的一个概念层次向下钻取
引入一个新维度。

下图展示了向下钻取如何工作：

向下钻取通过按维度 time 的概念层次向下钻取执行。
最初的概念层次是“天 < 月 < 季度 < 年”。
在向下钻取时，时间维度从季度级别降至月级。
执行向下钻取时，会从数据立方体中添加一个或多个维度。
它将数据从较少的详细数据导航到非常详细的数据。

Slice

分片操作从给定的立方体中选择一个特定的维度，并提供一个新的子立方体。请考虑以下显示分片工作原理的图表。

这里针对维度“时间”执行了分片，使用条件时间 =“Q1”。
它将通过选择一个或多个维度来形成一个新的子立方体。

Dice

切块从给定的立方体中选择两个或多个维度，并提供一个新的子立方体。请考虑以下显示切块操作的图表。

基于以下选择条件的切块操作涉及三个维度。

(位置 =“多伦多”或“温哥华”)
(时间 =“Q1”或“Q2”)
(项目 =“移动”或“调制解调器”)

Pivot

枢轴操作也称为旋转。它围绕视图中的数据轴旋转，以便提供数据的替代表示。请考虑以下显示枢轴操作的图表。

OLAP vs OLTP

Sr.No.

Data Warehouse (OLAP)

Operational Database (OLTP)

涉及对信息的此外处理。

Involves day-to-day processing.

OLAP 系统被知识工作者使用，例如高管、经理和分析师。

OLTP 系统由文员、DBA 或数据库专业人员使用。

有助于分析业务。

有助于运行业务。

它专注于信息输出。

它专注于数据输入。

基于星型架构、雪花型架构、架构和事实星座架构。

基于实体关系模型。

Contains historical data.

Contains current data.

提供汇总和合并后的数据。

提供原始和非常详细的数据。

提供汇总和多维的数据视图。

提供数据的详细且平坦的关联视图。

用户数量以百计。

用户数量以千计。

已访问记录的数量以百万计。

已访问记录的数量以十计。

数据库大小为 100 GB 至 1 TB

数据库大小为 100 MB 至 1 GB。

Highly flexible.

Provides high performance.

Data Warehousing - Relational OLAP

关系 OLAP 服务器位于关系后端服务器和客户端前端工具之间。为了存储和管理仓库数据，关系 OLAP 使用关系或扩展关系 DBMS。

ROLAP 包括以下内容 -

聚合导航逻辑实施
针对每个 DBMS 后端的优化
Additional tools and services

Points to Remember

ROLAP 服务器具有高度可扩展性。
ROLAP 工具可跨多个维度分析海量数据。
ROLAP 工具可存储和分析高度不稳定且可变的数据。

Relational OLAP Architecture

ROLAP 包含以下组件 −

Database server
ROLAP server
Front-end tool.

Advantages

ROLAP 服务器可以轻松地与现有 RDBMS 一起使用。
可以有效地存储数据，因为无法存储零事实。
ROLAP 工具不使用预计算的数据立方体。
微策略的 DSS 服务器采用 ROLAP 方法。

Disadvantages

Poor query performance.
可扩展性存在一些限制，具体取决于所采用的技术架构。

Data Warehousing - Multidimensional OLAP

多维 OLAP (MOLAP) 使用基于数组的多维存储引擎来获得数据的多维视图。使用多维数据存储，如果数据集稀疏，则存储利用率可能较低。因此，许多 MOLAP 服务器使用两级数据存储表示来处理密集和稀疏数据集。

Points to Remember −

MOLAP 工具处理信息时，响应时间一致，无论选择哪种汇总或计算级别。
MOLAP 工具需要避免为了存储用于分析的数据而创建关系数据库时遇到的许多复杂问题。
MOLAP 工具需要尽可能快的性能。
MOLAP 服务器采用两级存储表示来处理密集数据集和稀疏数据集。
将更密集的子立方体识别出来并存储为数组结构。
稀疏子立方体采用压缩技术。

MOLAP Architecture

MOLAP 包括以下组件：

Database server.
MOLAP server.
Front-end tool.

Advantages

MOLAP 允许对预计算的汇总数据进行最快的索引。
帮助连接到网络的用户，这些用户需要分析更大、定义更少的的数据。
使用更方便，因此 MOLAP 适用于缺乏经验的用户。

Disadvantages

MOLAP 无法包含详细数据。
如果数据集稀疏，则存储利用率可能会低。

MOLAP vs ROLAP

Sr.No.

MOLAP

ROLAP

Information retrieval is fast.

信息检索相对较慢。

使用稀疏数组来存储数据集。

Uses relational table.

MOLAP 最适合缺乏经验的用户，因为它非常容易使用。

ROLAP 最适合经验丰富的人员。

为数据立方体维护一个单独的数据库。

可能不需要超出数据仓库中可用空间以外的空间。

DBMS facility is weak.

DBMS facility is strong.

Data Warehousing - Schemas

模式是对整个数据库的逻辑描述。它包括所有记录类型记录的名称和说明，包括所有关联的数据项和聚合。与数据库非常相似，数据仓库也需要维护模式。数据库使用关系模型，而数据仓库则使用星形、雪花和事实星座模式。在本章中，我们将讨论数据仓库中使用的模式。

Star Schema

星形模式中的每个维度仅用一个“维度”表表示。
此维度表包含一组属性。
下图显示了公司的销售数据，相对于四个维度，即时间、项目、分支和位置。

中心有一个事实表。它包含四个维度中每个维度的键。
事实表还包含属性，即销售额和销售单元。

Note − 每个维度仅有一个维度表，并且每个表都包含一组属性。例如，位置维度表包含属性集 {location_key, street, city, province_or_state, country}。此约束可能会导致数据冗余。例如，“温哥华”和“维多利亚”这两个城市都位于加拿大不列颠哥伦比亚省。这些城市的条目可能会导致 province_or_state 和 country 属性的数据冗余。

Snowflake Schema

雪花模式中的一些维度表被归一化。
归一化将数据拆分为另外一些表。
与星形模式不同，雪花模式中的维度表被归一化。例如，星形模式中的项目维度表被归一化并拆分为两个维度表，即项目表和供应商表。

现在，项目维度表包含属性 item_key、item_name、type、brand 和 supplier-key。
供应商键链接到供应商维度表。供应商维度表包含属性 supplier_key 和 supplier_type。

Note − 由于雪花模式中的归一化，冗余已减少，因此易于维护并节省存储空间。

Fact Constellation Schema

事实星座有多个事实表。也称为星系模式。
下图显示了两个事实表，分别是销售和运输。

销售事实表与星形模式中的相同。
运输事实表有五个维度，分别是 item_key，time_key，shipper_key，from_location，to_location。
运输事实表还包含两个度量，分别是销售额和销售单位。
在事实表之间共享维度表也是可能的。例如，时间、项目和位置维度表在销售和运输事实表之间共享。

Schema Definition

多维模式使用数据挖掘查询语言 (DMQL) 定义。两个基元，多维数据集定义和维度定义，可用于定义数据仓库和数据市集。

Syntax for Cube Definition

define cube < cube_name > [ < dimension-list > }: < measure_list >

Syntax for Dimension Definition

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

Star Schema Definition

我们讨论过的星形模式可以使用数据挖掘查询语言 (DMQL) 如下定义：

define cube sales star [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state, country)

Snowflake Schema Definition

雪花模式可以使用 DMQL 如下定义：

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

Fact Constellation Schema Definition

事实星座模式可以使用 DMQL 如下定义：

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

Data Warehousing - Partitioning Strategy

分区旨在提高性能，便于数据管理。分区还有助于平衡系统的各种需求。它通过将每个事实表分区到多个单独的分区来优化硬件性能并简化数据仓库管理。在本章中，我们将讨论不同的分区策略。

Why is it Necessary to Partition?

分区出于以下原因非常重要 −

For easy management,
To assist backup/recovery,
To enhance performance.

For Easy Management

数据仓库中的事实表可能增长到数百个 GB 大小。如此巨大的事实表大小作为单个实体进行管理非常困难。因此它需要分区。

To Assist Backup/Recovery

如果我们不对事实表进行分区，那么我们就必须加载包含所有数据的完整事实表。分区允许我们只加载定期所需的数据。它减少了加载时间，并提高了系统的性能。

Note − 为了减少备份大小，可以将除当前分区外的所有分区标记为只读。然后，我们可以将这些分区置于无法修改的状态。然后可以对其进行备份。这意味着只需要备份当前分区。

To Enhance Performance

通过将事实表分区为数据集合，可以增强查询过程。查询性能得到增强，因为现在查询仅扫描那些相关的分区。它不必扫描整个数据。

Horizontal Partitioning

有各种方法可以对事实表进行分区。在水平分区中，我们必须牢记数据仓库可管理性的要求。

Partitioning by Time into Equal Segments

在这种分区策略中，事实表根据时间段进行分区。此处的每个时间段都代表业务中的一个重要保留期。例如，如果用户查询 month to date data ，那么将数据分区到按月细分的段中是合适的。我们可以通过删除其中的数据来重用分区表。

Partition by Time into Different-sized Segments

当访问过时的旧数据不频繁时采用这种划分。它作为一系列小分区实现，用于相对较新的数据，而较大的分区则用于非活动数据。

Points to Note

详细的信息仍可在网上获得。
物理表的数量保持相对较少，这种方法降低了运营成本。
这种技术适用于需要混合使用近期历史数据抽样的和挖掘整个历史数据的场景。
如果分区模式定期改变，这种技术并非适用，因为重新分区会增加数据仓库的运行成本。

Partition on a Different Dimension

事实表还可以根据时间维度之外的其他维度（如产品组、地区、供应商或任何其他维度）进行划分。让我们举个例子。

假设市场功能已按 state by state 方式被划分到不同的地区部门中。如果每个地区想要查询其区域内获取的信息，将事实表划分为区域分区会更有效。这会因为无需扫描不相关的信息而加速查询。

Points to Note

查询无需扫描不相关数据，因此会加快查询过程。
这种技术不适用于将来维度不会改变的情况。所以，值得确定维度将来不会改变。
如果维度改变，那么整个事实表将不得不重新分区。

Note - 我们建议仅根据时间维度进行分区，除非你确定建议的维度组在数据仓库的生命周期内不会改变。

Partition by Size of Table

当没有任何明确的维度可以将事实表进行分区时，我们应该 partition the fact table on the basis of their size. 我们将预先确定的尺寸设为一个临界点。当表超过预定的尺寸时，将创建一个新的表分区。

Points to Note

这种分区难以管理。
它需要元数据来识别每个分区中存储的数据。

Partitioning Dimensions

如果维度包含大量条目，则需要对维度进行分区。这里我们必须检查维度的尺寸。

考虑一个随着时间推移而变化的大型设计。如果我们需要存储所有变体以进行比较，该维度可能非常大。这肯定会影响响应时间。

Round Robin Partitions

在循环法中，当需要一个新分区时，旧的分区将被存档。它使用元数据来允许用户访问工具引用正确的表分区。

这种技术使得自动化数据仓库中的表管理功能变得容易。

Vertical Partition

垂直分区垂直划分数据。下图描绘了如何执行垂直分区。

垂直分区可以通过以下两种方式执行：

Normalization
Row Splitting

Normalization

规范化是数据库组织的标准关系方法。在此方法中，行合并到单行中，因此它减少了空间。看看以下表格，显示如何执行规范化。

规范化之前的表格

Product_id	Qty	Value	sales_date	Store_id	Store_name	Location	Region
30	5	3.67	3-Aug-13	16	sunny	Bangalore	S
35	4	5.33	3-Sep-13	16	sunny	Bangalore	S
40	5	2.50	3-Sep-13	64	san	Mumbai	W
45	7	5.66	3-Sep-13	16	sunny	Bangalore	S

规范化之后的表格

Store_id

Store_name

Location

Region

sunny

Bangalore

san

Mumbai

Product_id	Quantity	Value	sales_date	Store_id
30	5	3.67	3-Aug-13	16
35	4	5.33	3-Sep-13	16
40	5	2.50	3-Sep-13	64
45	7	5.66	3-Sep-13	16

Row Splitting

行拆分倾向于在分区之间保留一对一映射。行拆分的动机是通过减小其大小来加快对大表的访问速度。

Note − 在使用垂直分区时，确保在两个分区之间无需执行主要连接操作。

Identify Key to Partition

选择正确的分区键非常关键。选择错误的分区键将导致重新组织事实表。让我们举个例子。假设我们想要对以下表格进行分区。

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

我们可以选择对任何键进行分区。两个可能的键可以是

region
transaction_date

假设业务组织在 30 个地理区域，每个区域都有不同数量的分支机构。这将为我们提供 30 个分区，这是合理的。此分区足够好，因为我们的要求捕获表明绝大多数查询都限制在用户自己的业务区域。

如果我们按交易日期而不是按区域分区，那么每个区域的最新交易将位于一个分区中。现在，希望查看自己区域内数据的用户必须跨多个分区查询。

因此，值得确定正确的分区键。

Data Warehousing - Metadata Concepts

What is Metadata?

元数据简单地被定义为关于数据的数据。用于表示其他数据的数据称为元数据。例如，一本的索引充当了书中内容的元数据。换言之，我们可以说元数据是将我们引导到详细数据的汇总数据。就数据仓库而言，我们可以将元数据定义如下。

元数据是通往数据仓库的路线图。
数据仓库中的元数据定义了仓库对象。
元数据充当目录。此目录帮助决策支持系统定位数据仓库的内容。

Note − 在数据仓库中，我们创建元数据，用于给定数据仓库的数据名称和定义。在此元数据中，我们还创建其他元数据，用于对提取的任何数据的时间戳记进行时间戳记和提取数据的源。

Categories of Metadata

元数据可以大致分为三类 −

Business Metadata − 它具有数据所有权信息、业务定义和更改策略。
Technical Metadata − 它包含数据库系统名称、表和列名称和大小、数据类型和允许的值。技术元数据还包含结构信息，例如主键和外键属性以及索引。
Operational Metadata − 它包含数据的有效性和数据血统。数据的有效性是指数据是处于活动、归档还是已清除状态。数据血统是指迁移的数据的历史以及在其上应用的转换。

Role of Metadata

元数据在数据仓库中发挥着非常重要的作用。元数据在仓库中的作用与仓库数据的作用不同，但它扮演着重要的作用。下面解释了元数据的各种作用。

元数据充当目录。
此目录帮助决策支持系统查找数据仓库的内容。
元数据有助于在数据从操作环境转换为数据仓库环境时，实现数据映射决策支持系统。
元数据有助于在当前详细数据和高度汇总之间进行汇总。
元数据也有助于在轻度详细数据和高度汇总数据之间进行汇总。
元数据用于查询工具。
元数据用于提取和清理工具。
元数据用于报表工具。
元数据用于转换工具。
元数据在加载功能中起着重要作用。

下图显示了元数据的角色。

Metadata Repository

元数据存储库是数据仓库系统的一个组成部分。它具有以下元数据：

Definition of data warehouse − 它包含数据仓库结构的描述。该描述由架构、视图、层次结构、派生数据定义以及数据市场位置和内容定义。
Business metadata − 它包含数据所有权信息、业务定义和更改策略。
Operational Metadata − 它包含数据的有效性和数据血统。数据的有效性是指数据是处于活动、归档还是已清除状态。数据血统是指迁移的数据的历史以及在其上应用的转换。
Data for mapping from operational environment to data warehouse − 它包括源数据库及其内容、数据提取、数据分区清理、转换规则、数据刷新和清除规则。
Algorithms for summarization − 它包括度量算法、粒度数据、聚合、汇总等。

Challenges for Metadata Management

元数据的重要性不容忽视。元数据有助于提高报告的准确性、验证数据转换并确保计算准确性。元数据还强制终端用户遵守业务术语的定义。除了所有这些对元数据的应用，元数据也面临着挑战。以下讨论了部分挑战。

大型组织中的元数据分散在整个组织中。此元数据分布在电子表格、数据库和应用程序中。
元数据可以存在于文本文件或多媒体文件中。要将此数据用于信息管理解决方案，必须正确定义此数据。
没有业界公认的标准。数据管理解决方案供应商关注点很窄。
没有简单且公认的元数据传递方法。

Data Warehousing - Data Marting

Why Do We Need a Data Mart?

以下是创建数据市集的原因列表：

分区数据以实施 access control strategies.
通过减少要扫描的数据量来加速查询。
将数据细分为不同的硬件平台。
以适合用户访问工具的形式构建数据。

Note − 不要出于任何其他原因建立数据市集，因为数据市集的运营成本可能非常高。在建立数据市集之前，请确保数据市集策略适合你的特定解决方案。

Cost-effective Data Marting

按照以下步骤使数据市集具有成本效益：

Identify the Functional Splits
识别用户访问工具需求
Identify Access Control Issues

Identify the Functional Splits

在此步骤中，我们确定组织是否有自然的职能划分。我们寻找部门之间的划分，并确定各部门使用信息的方式是否与组织的其余部分隔离。我们举个例子。

考虑一个零售组织，其中每个商家负责最大化销售一组产品。为此，以下是有价值的信息 -

每日销售交易
每周销售预测
每日库存位置
每日股票变动

由于商家对他们不经手的产品不感兴趣，所以数据市集是处理的产品组感兴趣的数据的一个子集。下图显示了面向不同用户的数仓。

以下是在确定功能划分时需要考虑的问题 -

部门结构可能发生变化。
产品可能从一个部门切换到另一个部门。
商家可以查询其他产品的销售趋势，以分析销售情况。

Note - 我们需要确定使用数据市集的业务优势和技术可行性。

Identify User Access Tool Requirements

我们需要数据市集来支持 user access tools ，它们需要内部数据结构。此类结构中的数据不受数据仓库控制，但需要定期填充和更新。

有些工具直接从源系统填充，但有些工具不能。因此，需要识别超出工具范围的额外需求，以备将来使用。

Note - 为了确保所有访问工具中数据的一致性，不应直接从数据仓库填充数据，而是每个工具都必须有自己的数据市集。

Identify Access Control Issues

应该制定隐私规则，以确保只有经过授权的用户才能访问数据。例如，零售银行机构的数据仓库可确保所有帐户都属于同一法人实体。隐私法可能会迫使你完全禁止访问不属于特定银行的信息。

数据市集允许我们在数据仓库内物理分离数据段，从而构建一个完整的墙。为了避免可能的隐私问题，可以从数据仓库中删除详细数据。我们可以为每个法人实体创建数据市集，并通过数据仓库加载，同时提供详细的帐户数据。

Designing Data Marts

数据市集应设计为数据仓库中星型雪花模式的较小版本，并且应与数据仓库的数据库设计相匹配。它有助于控制数据库实例。

摘要以与在数据仓库内设计相同的方式进行数据市集。汇总表有助于利用星型雪花模式中的所有维度数据。

Cost of Data Marting

数据市集的成本度量如下 -

Hardware and Software Cost
Network Access
Time Window Constraints

Hardware and Software Cost

虽然数据集市创建在相同硬件上，但需要一些额外的硬件和软件。为了处理用户查询，它需要额外的处理能力和磁盘存储。如果在数据仓库中存在详细信息和数据集市，那么我们将面临额外的存储和管理复制数据的花费。

Note − 数据集市比聚合花费更高，因此它应当用作一种附加策略，而不是备选策略。

Network Access

数据集市可能位于数据仓库的不同位置，因此我们应当确保局域网或广域网有能力处理在 data mart load process. 内传输的数据量

Time Window Constraints

数据集市加载进程消耗可用时间窗口的程度取决于转换的复杂性和运送的数据量。确定有多少个数据集市取决于 −

Network capacity.
Time window available
传输的数据量
用于将数据插入数据集市的机制

Data Warehousing - System Managers

系统管理对于数据仓库的成功实施至关重要。最重要的系统管理器包括 −

System configuration manager
System scheduling manager
System event manager
System database manager
System backup recovery manager

System Configuration Manager

系统配置管理器负责数据仓库的设置和配置管理。
配置管理器的结构因操作系统而异。
在 Unix 配置结构中，配置管理器因供应商而异。
配置管理器具有单一的用户界面。
配置管理器界面允许我们控制系统的各个方面。

Note − 最重要的配置工具是 I/O 管理器。

System Scheduling Manager

系统调度管理器负责数据仓库的成功实施。其目的是调度临时查询。每个操作系统都有自己的调度器，并采用某种形式的批处理控制机制。系统调度管理器必须具备的功能列表如下 −

跨群集或 MPP 边界工作
处理时差
Handle job failure
Handle multiple queries
Support job priorities
重新启动或重新排队处理失败的任务
在任务完成时通知用户或流程
在系统中断期间维护任务计划
重新将任务排队到其他队列
支持队列的停止和启动
Log Queued jobs
Deal with inter-queue processing

Note − 上述列表可用作评估良好调度器的评估参数。

调度器必须能够处理的一些重要任务包括 −

每日和临时查询调度
执行常规报告要求
Data load
Data processing
Index creation
Backup
Aggregation creation
Data transformation

Note −如果数据仓库在一个群集或 MPP 体系结构上运行，那么系统调度管理器一定要能够跨体系结构运行。

System Event Manager

事件管理器是一种软件。事件管理器管理数据仓库系统上所定义的事件。我们无法手动管理数据仓库，因为数据仓库的结构非常复杂。因此，我们需要一种无需用户干预就能自动处理所有事件的工具。

Note −事件管理器监视事件发生并处理它们。事件管理器还会追踪这个复杂的数据仓库系统中可能出现的大量问题。

Events

事件是由用户或系统本身生成的活动。可以注意到，事件是一个定义活动的可度量、可观察的发生。

下面是一个需要追踪的常见事件列表。

Hardware failure
某些关键磁盘空间不足
A process dying
一个进程返回一个错误
CPU 使用率超出 805 阈值
数据库序列化点上的内部争用
缓冲区高速缓存命中率超出或低于阈值
一个表达到其最大尺寸
Excessive memory swapping
一个表因缺乏空间而无法扩展
Disk exhibiting I/O bottlenecks
临时或排序区域使用率达到某个阈值
其他任何数据库共享内存使用情况

事件最重要的事情是，它们应该能够自己执行。事件包定义预定义事件的过程。与每个事件关联的代码称为事件处理程序。此代码在发生事件时执行。

System and Database Manager

系统和数据库管理器可能是两个独立的软件，但它们执行相同的工作。这些工具的目标是自动化某些过程并简化其他过程的执行。选择系统和数据库管理器的标准如下 −

increase user’s quota.
向用户分配和解除角色
向用户分配和解除配置文件
perform database space management
监视和报告空间使用情况
整理碎片化和未使用的空间
添加并扩展空间
add and remove users
manage user password
管理汇总或临时表
将临时空间从用户分配或反分配
从旧的或过时的临时表回收空间
管理错误和跟踪日志
浏览日志和跟踪文件
重定向错误或跟踪信息
开启和关闭错误和跟踪记录
perform system space management
监视和报告空间使用情况
清理旧的和未使用的文件目录
add or expand space.

System Backup Recovery Manager

备份和恢复工具使用户操作和管理人员可以轻松备份数据。注意，系统备份管理器必须与正在使用的计划管理器软件集成。备份管理所需的重要功能如下：

Scheduling
Backup data tracking
Database awareness

仅进行备份以防止数据丢失。以下是要记住的重要事项：

备份软件将保留某种形式的数据库，其中记录了备份数据的时间和位置。
备份恢复管理器必须具有用于该数据库的良好前端。
备份恢复软件应识别数据库。
软件识别数据库后，便可通过数据库术语进行寻址，并且不会执行不可行的备份。

Data Warehousing - Process Managers

进程管理器负责维护进出数据仓库的数据流。有三种不同类型的进程管理器：

Load manager
Warehouse manager
Query manager

Data Warehouse Load Manager

加载管理器执行从数据库中提取和加载数据的所需操作。加载管理器的规模和复杂性因从一个数据仓库到另一个数据仓库的特定解决方案而异。

Load Manager Architecture

负载管理器执行以下函数 -

从源系统中提取数据。
将提取的数据快速加载到临时数据存储中。
执行与数据仓库中的数据结构类似的简单转换。

Extract Data from Source

数据是从操作数据库或外部信息提供程序中提取的。网关是指用于提取数据应用程序程序。它受底层 DBMS 支持，并允许客户端程序生成要在服务器上执行的 SQL。开放数据库连接 (ODBC) 和 Java 数据库连接 (JDBC) 都是网关的示例。

Fast Load

为了最大程度地缩短总加载时间窗，需要在尽可能最短的时间内将数据加载到仓库中。
转换会影响数据处理的速度。
在应用转换和检查之前，将数据加载到关系数据库中会更有效。
网关技术不适合，因为它们在涉及大数据量时效率很低。

Simple Transformations

在加载时，可能需要执行简单转换。在完成简单转换后，我们可以做复杂检查。假设我们正在加载 EPOS 销售交易，我们需要执行以下检查 -

去除仓库中不需要的所有列。
将所有值转换为所需的数据类型

Warehouse Manager

仓库管理员负责仓库管理流程，它由第三方系统软件、C 程序与 Shell 脚本组成。仓库管理员的大小和复杂性因具体解决方案而异。

Warehouse Manager Architecture

仓库管理员包括以下内容 -

The controlling process
带 SQL 的存储过程或 C
Backup/Recovery tool
SQL scripts

Functions of Warehouse Manager

仓库管理员执行以下函数 -

分析数据以执行一致性和引用完整性检查。
针对基础数据创建索引、业务视图和分区视图。
生成新聚合并更新现有聚合。
Generates normalizations.
将临时存储的源数据转换为并合并到已发布的数据仓库中。
备份数据仓库中的数据。
存档已达到捕获周期末尾的数据。

Note - 仓库管理员分析查询配置文件以确定索引和聚合是否合适。

Query Manager

查询管理器负责将查询指向合适的表。通过将查询指向合适的表，它可以加快查询请求和响应的过程。此外，查询管理器还负责调度用户发布的查询的执行。

Query Manager Architecture

查询管理器包括以下组件 -

通过 C 工具或 RDBMS 查询重定向
Stored procedures
Query management tool
通过 C 工具或 RDBMS 查询调度
通过第三方软件查询调度

Functions of Query Manager

它以用户能理解的形式向用户呈现数据。
它计划执行最终用户发布的查询。
它存储查询配置文件，以便仓库管理员确定哪些索引和聚合是合适的。

Data Warehousing - Security

数据仓库的目标是让用户可以轻松访问大量数据，从而让用户能够提取有关整个业务的信息。但我们知道，可以对数据应用一些安全限制，这可能会成为访问信息时的障碍。如果分析师对数据的看法受到限制，那么就不可能全面了解业务中的趋势。

可以汇总每个分析师的数据并传递给管理层，在管理层可以汇总不同的汇总。由于汇总汇总与整体汇总不同，因此有可能错过数据中的一些信息趋势，除非有人整体分析数据。

Security Requirements

添加安全功能会影响数据仓库的性能，因此尽早确定安全需求非常重要。在数据仓库正式投入使用后添加安全功能很困难。

在数据仓库的设计阶段，我们应该记住将来可能添加哪些数据源，以及添加这些数据源会产生什么影响。我们在设计阶段应该考虑以下可能性。

新数据源是否需要实施新的安全和/或审计限制？
是否添加了对已普遍可用的数据具有受限访问权限的新用户？

当未来的用户和数据源不明确时，会出现这种情况。在这种情况下，我们需要利用业务知识和数据仓库的目标来了解可能的条件。

以下活动会受到安全措施的影响 −

User access
Data load
Data movement
Query generation

User Access

我们需要先对数据进行分类，然后再根据用户可以访问的数据对用户进行分类。换句话说，用户会根据其可访问的数据进行分类。

Data Classification

可以使用以下两种方法对数据进行分类 −

可以根据其敏感性对数据进行分类。高度敏感的数据归类为高度受限，敏感性较低的数据归类为受限性较低。
还可以根据工作职责对数据进行分类。此限制仅允许特定用户查看特定数据。我们在此限制用户仅查看他们感兴趣并负责的数据部分。

第二种方法存在一些问题。为了理解，我们举个例子。假设您正在为银行构建数据仓库。请考虑存储在数据仓库中的数据是所有帐户的交易数据。问题是，谁可以查看交易数据。解决方案在于根据职能对数据进行分类。

User classification

下列方法可用于对用户分类 −

用户可以按照组织中的用户层次结构进行分类，即，用户可以按部门、科室、组等分类。
用户还可以根据其角色进行分类，其中根据角色将跨部门的人员归为一组。

Classification on basis of Department

让我们举一个数据仓库的示例，其中用户来自销售和营销部门。我们可以通过自上而下的公司视图进行安全管理，访问权限以不同部门为中心。但对不同级别的用户可能会有一些限制。此结构如下图所示。

但是，如果每个部门访问不同的数据，那么我们应该为每个部门单独设计安全访问权限。可以通过部门数据市实现此目的。由于这些数据市与数据仓库分离，因此我们可以在每个数据市上强制执行单独的安全限制。此方法如下图所示。

Classification Based on Role

如果数据通常对所有部门可用，那么遵循角色访问层次结构十分有用。换句话说，如果数据通常由所有部门访问，那么按照用户的角色应用安全限制。角色访问层次结构如下图所示。

Audit Requirements

审计是安全性的子集，也是一项成本高昂的活动。审计可能会导致系统的大量开销。为了及时完成审计，我们需要更多的硬件，因此，建议在可能的情况下关闭审计。审计要求可分类如下 −

Connections
Disconnections
Data access
Data change

Note −对于上述每个类别，都需要审计成功、失败或两者。从安全性的角度考虑，审计失败非常重要。审计失败很重要，因为它们可以突出显示未经授权或欺诈性访问。

Network Requirements

网络安全与其他安全性一样重要。我们不能忽视网络安全要求。我们需要考虑以下问题 −

在将数据传输到数据仓库之前有必要加密数据吗？
网络数据传输是否有路由限制？

这些限制需要谨慎考虑。以下是需要记住的要点 −

加密和解密过程将增加开销。这需要更多的处理能力和处理时间。
如果系统已经是一个负载系统，则加密成本可能很高，因为加密是由源系统承担的。

Data Movement

在移动数据时存在潜在的安全隐患。假设我们需要传输一些受限数据作为需要加载的平面文件。将数据加载到数据仓库时，会产生以下问题 −

平面文件存储在哪里？
谁有权访问该磁盘空间？

如果我们讨论这些平面文件备份，将出现以下问题 -

你备份加密版本还是解密版本？
是否需要将这些备份做成存储单独的特殊磁带？
谁可以访问这些磁带？

数据移动的其他一些形式（如查询结果集）也需要考虑。创建临时表时提出的问题如下 -

临时表应该存放在哪里？
你如何让此类表可见？

我们应该避免意外违背安全限制。如果一个可以访问受限数据的用户可以生成可访问的临时表，数据将对未授权用户可见。通过为有权访问受限数据的用户提供一个单独的临时区域，我们可以解决这个问题。

Documentation

审计和安全要求需要得到妥善的记录。这将被视为证明的一部分。本文件可包含从下列信息收集的所有信息 -

Data classification
User classification
Network requirements
数据移动和存储要求
All auditable actions

Impact of Security on Design

安全性会影响应用程序代码和开发时间表。安全性影响以下领域 -

Application development
Database design
Testing

Application Development

安全性会影响整体应用程序开发，并且也会影响数据仓库中加载管理器、仓库管理器和查询管理器等重要组件的设计。加载管理器可能需要检查代码以过滤记录并将其放在不同位置。也可能需要更多转换规则来隐藏某些数据。也可能需要额外的元数据来处理任何额外对象。

为了创建和维护额外的视图，仓库管理器可能需要额外的代码来实施安全性。可能必须将额外检查编码到数据仓库中，以防止数据仓库在不应该提供的位置移动数据时受到愚弄。查询管理器需要进行更改以处理任何访问限制。查询管理器需要了解所有额外视图和聚合。

Database design

数据库布局也会受到影响，因为在实施安全措施后，视图和表的数量会增加。增加安全性会增加数据库的大小，从而增加数据库设计和管理的复杂性。它还将增加备份管理和恢复计划的复杂性。

Testing

测试数据仓库是一个复杂且漫长的过程。向数据仓库中增加安全性也会影响测试时间复杂度。它在以下两个方面影响测试 -

这会增加集成和系统测试所需的时间。
增加了要测试的功能，这将增加测试套件的大小。

Data Warehousing - Backup

数据仓库是一个复杂的系统，它包含大量数据。因此，备份所有数据非常重要，以便日后可以根据要求进行恢复。在本章中，我们将讨论设计备份策略中的问题。

Backup Terminologies

在进一步操作之前，您应该了解下面讨论的一些备份术语。

Complete backup − 它同时备份整个数据库。此备份包括所有数据库文件、控制文件和日志文件。
Partial backup − 正如其名称所示，它并没有创建数据库的完整备份。部分备份在大型数据库中非常有用，因为它们允许采用一种策略，即数据库的不同部分以循环的方式逐日备份，以便整个数据库有效地每周备份一次。
Cold backup − 数据库完全关闭时进行冷备份。在多实例环境中，应该关闭所有实例。
Hot backup − 当数据库引擎启动并运行时进行热备份。热备份的要求因 RDBMS 而异。
Online backup − 它与热备份非常相似。

Hardware Backup

决定使用哪种硬件进行备份非常重要。备份和恢复处理速度取决于所使用的硬件、硬件连接方式、网络带宽、备份软件和服务器 I/O 系统的速度。在这里，我们将讨论一些可用的硬件选择及其优缺点。这些选择如下所示−

Tape Technology
Disk Backups

Tape Technology

磁带选择可以分为以下几类−

Tape media
Standalone tape drives
Tape stackers
Tape silos

Tape Media

磁带介质有几种，下表列出了部分磁带介质标准−

Tape Media

Capacity

I/O rates

DLT

40 GB

3 MB/s

3490e

1.6 GB

3 MB/s

8 mm

14 GB

1 MB/s

需要考虑的其他因素如下−

磁带介质的可靠性
每单位磁带介质的成本
Scalability
磁带系统升级的成本
每单位磁带介质的成本
磁带介质的保质期

Standalone Tape Drives

磁带驱动器可以通过以下方式连接 −

Direct to the server
As network available devices
Remotely to other machine

将磁带驱动器连接到数据仓库可能会存在问题。

考虑服务器是一个 48 个节点的 MPP 机器。我们不知道连接磁带驱动器的节点，也无法知道如何将它们分散在服务器节点上，以获得最佳性能，同时最大限度地减少服务器中断和内部 I/O 延迟。
将磁带驱动器连接为可用的网络设备要求网络能够胜任海量数据传输速率的任务。确保在需要时有足够的带宽。
远程连接磁带驱动器还需要高带宽。

Tape Stackers

将多个磁带加载到单个磁带驱动器的做法称为磁带堆叠器。堆叠器在处理完当前磁带后将其卸载，然后加载下一个磁带，因此一次只能访问一个磁带。价格和功能可能有所不同，但共同点是它们可以执行无人值守的备份。

Tape Silos

磁带孤岛提供大存储容量。磁带孤岛可以存储和管理数千个磁带。它们可以集成多个磁带驱动器。它们拥有标记和存储其存储磁带的软件和硬件。孤岛通过网络或专线远程连接非常常见。我们应确保连接的带宽能够胜任任务。

Disk Backups

磁盘备份的方法有 −

Disk-to-disk backups
Mirror breaking

这些方法用于 OLTP 系统中。这些方法最大程度地减少数据库停机时间，最大限度地提高可用性。

Disk-to-Disk Backups

在此，备份是在磁盘上进行，而不是在磁带上进行。磁盘到磁盘的备份出于以下原因进行 −

Speed of initial backups
Speed of restore

从磁盘备份数据到磁盘比备份到磁带快得多。然而，这是备份的中间步骤。稍后，数据将备份到磁带上。磁盘到磁盘备份的另一个优点是，它为你提供了最新备份的在线副本。

Mirror Breaking

其理念是，在工作日内对磁盘进行镜像以提升弹性。当需要备份时，可以中断其中一个镜像集。此技术是磁盘到磁盘备份的一种变体。

Note − 数据库可能需要关闭以确保备份的一致性。

Optical Jukeboxes

光盘自动换碟器允许将数据存储在近线上。此技术允许大量的光盘以与磁带堆叠器或磁带孤岛相同的方式进行管理。此技术的缺点是其写入速度比磁盘慢。但光盘介质提供了长寿命和可靠性，这使其成为归档的良好介质选择。

Software Backups

有可用于帮助备份过程的软件工具。这些软件工具作为一个包提供。这些工具不仅可以进行备份，还可以有效地管理和控制备份策略。市场上有许多软件包可用。其中一些列在以下表格中 −

Package Name

Vendor

Networker

Legato

ADSM

IBM

Epoch

Epoch Systems

Omniback II

Alexandria

Sequent

Criteria for Choosing Software Packages

选择最佳软件包的标准如下 −

随着增加磁带驱动器的扩展能力如何？
该软件包是否有客户端服务器选项，还是必须在数据库服务器上本身运行？
它可以在集群和 MPP 环境中运行吗？
需要何种程度的并行度？
该软件包支持哪些平台？
该软件包是否支持轻松访问磁带内容信息？
该软件包是否具有数据库感知功能？
该软件包支持哪些磁带驱动器和磁带介质？

Data Warehousing - Tuning

数据仓库不断发展，无法预测用户将来会发布什么查询。因此，调整数据仓库系统变得更加困难。在本章中，我们将讨论如何调整数据仓库的不同方面，例如性能、数据加载、查询等。

Difficulties in Data Warehouse Tuning

由于以下原因，调整数据仓库是一项困难的过程：

数据仓库是动态的；它永远不会保持恒定。
很难预测用户将来会发布什么查询。
业务需求会随着时间的推移而改变。
用户及其个人资料不断变化。
用户可以从一个组切换到另一个组。
仓库上的数据负载也会随着时间的推移而变化。

Note − 对数据仓库有全面的了解非常重要。

Performance Assessment

下面是有关性能的客观衡量标准。

Average query response time
Scan rates
每天查询所用时间
Memory usage per process
I/O throughput rates

以下为需要记住的要点。

必须在服务级别协议 (SLA) 中指定衡量标准。
如果响应时间已经优于所需响应时间，则尝试调优响应时间没有任何用处。
在进行性能评估时，必须有切合实际的期望非常重要。
同样重要的是，用户必须有切合实际的期望。
为了对用户隐藏系统的复杂性，应使用聚合和视图。
用户还可能编写您未进行调优的查询。

Data Load Tuning

数据加载是夜间处理的关键部分。在数据加载完成之前，不能运行其他任何操作。这是进入系统时的入口。

Note − 如果数据传输延迟或数据到达延迟，则整个系统都将受到严重影响。因此，首先调优数据加载非常重要。

有不同的数据加载调优方法，如下所述 −

一种非常常见的方法是使用 SQL Layer 插入数据。在此方法中，需要执行常规检查和约束。当数据插入到表中时，代码将运行以检查是否有足够的插入数据空间。如果没有足够的空间，则可能必须为这些表分配更多空间。这些检查需要花费时间并且需要大量的 CPU。
第二种方法是绕过所有这些检查和约束，并将数据直接置于预格式化块中。这些块稍后会被写入数据库。此方法比第一种方法更快，但它只能用于整个数据块。这可能导致一些空间浪费。
第三种方法是在将数据加载到已包含表的表中时，我们可以维护索引。
第四种方法表明，若要将数据加载到已包含数据的表中，请在数据加载完成后 drop the indexes & recreate them 。第三种方法和第四种方法之间的选择取决于已加载了多少数据以及需要重建多少索引。

Integrity Checks

完整性检查会极大地影响加载的性能。以下为需要记住的要点 −

必须限制完整性检查，因为它们需要强大的处理能力。
应在源系统中应用完整性检查，以避免数据负载性能下降。

Tuning Queries

数据仓库中有两种查询 −

Fixed queries
Ad hoc queries

Fixed Queries

固定查询定义明确。以下是固定查询的示例 −

regular reports
Canned queries
Common aggregations

数据仓库中固定查询的调整与关系数据库系统中的调整相同。唯一的区别在于要查询的数据量可能不同。在测试固定查询时，最好存储最成功的执行计划。存储这些执行计划将使我们能够发现不断变化的数据大小和数据偏斜，因为它将导致执行计划发生更改。

Note − 我们不能对事实表进行更多操作，但在处理维表或汇总时，可使用通常收集的 SQL 调整、存储机制和访问方法来调整这些查询。

Ad hoc Queries

要理解即席查询，了解数据仓库的即席用户非常重要。对于每个用户或用户组，你需要了解以下内容 −

组中的用户数
他们是否定期使用即席查询
他们是否经常使用即席查询
他们是否偶尔在未知的时间间隔使用即席查询。
他们倾向于运行的最大查询大小
他们倾向于运行的平均查询大小
他们是否需要钻取访问基础数据
每天的已用登录时间
每日使用高峰时间
他们在高峰每小时运行的查询数

Points to Note

跟踪用户个人资料并识别定期运行的查询非常重要。
同样重要的是，执行的调整不应影响性能。
识别频繁运行的类似查询和即席查询。
如果识别出这些查询，那么数据库将会改变，并且可以为那些查询添加新索引。
如果识别出这些查询，那么便可以为那些将会导致其有效执行的查询专门创建新的聚合。

Data Warehousing - Testing

测试对于数据仓库系统使其正确有效地工作非常重要。对数据仓库执行三项基本的测试级别：

Unit testing
Integration testing
System testing

Unit Testing

在单元测试中，每个组件都是单独测试的。
测试每个模块，即，过程、程序、SQL 脚本、Unix shell。
此测试由开发人员执行。

Integration Testing

在集成测试中，应用程序的各个模块被组合在一起，然后针对许多输入进行测试。
执行此测试以测试各个组件在集成后是否表现良好。

System Testing

在系统测试中，整个数据仓库应用程序一起进行测试。
系统测试的目的是检查整个系统是否正确地协同工作。
系统测试由测试团队执行。
由于整个数据仓库的大小非常大，因此通常可以在制定测试计划之前执行最小系统测试。

Test Schedule

首先，在制定测试计划的过程中创建测试计划。在此计划中，我们预测测试整个数据仓库系统所需的时间。

有不同的方法可用于创建测试计划，但没有一个是完美的，因为数据仓库非常复杂且庞大。此外，数据仓库系统本质上也在不断演变。在创建测试计划时可能面临以下问题：

一个简单的查询问题可能十分庞大，可能需要一整天甚至更长时间才能完成，即查询无法在所需的时间范围内完成。
可能存在硬件故障，如丢失磁盘，或人为错误，如意外删除表格或覆写大表格。

Note －由于上述困难，建议将您通常为测试分配的时间加倍。

Testing Backup Recovery

测试备份恢复策略极其重要。这是需要该测试的情况列表－

Media failure
表空间或数据文件的丢失或损坏
重做日志文件的丢失或损坏
控制文件的丢失或损坏
Instance failure
归档文件的丢失或损坏
表的丢失或损坏
Failure during data failure

Testing Operational Environment

需要测试大量方面。这些方面列在下面。

Security －安全测试需要单独的安全文档。此文档包含不允许的操作列表，并针对每个操作设计测试。
Scheduler －计划软件需要控制数据仓库的日常操作。它需要在系统测试期间加以测试。计划软件需要与数据仓库的界面，调度的器需要控制过夜处理和聚合管理。
Disk Configuration. －还需要测试磁盘配置以识别 I/O 瓶颈。测试应使用不同设置多次执行。
Management Tools. －系统测试期间，需要测试所有管理工具。这是要测试的工具列表活动管理器系统管理器数据库管理器配置管理器备份恢复管理器

Testing the Database

数据库通过以下三种方式进行测试－

Testing the database manager and monitoring tools －为了测试数据库管理器和监控工具，应将它们用于测试数据库的创建、运行和管理。
Testing database features －以下是我们要测试的功能列表－并行查询并行创建索引并行数据加载
Testing database performance －查询执行在数据仓库性能指标中发挥着非常重要的作用。需要定期运行固定查询集，并且应进行测试。为了测试即席查询，人们应该仔细查阅用户需求文档并全面了解业务。花时间测试业务可能针对不同索引和聚合策略提出的最棘手的查询。

Testing the Application

所有经理都应正确集成并开展工作，以确保端到端加载、索引、聚合和查询按预期工作。
每个管理器的每个功能都应正常工作
还需要对应用程序进行一段时间的测试。
还应测试周末和月底的任务。

Logistic of the Test

系统测试的目标是测试以下所有领域−

Scheduling software
Day-to-day operational procedures
Backup recovery strategy
Management and scheduling tools
Overnight processing
Query performance

Note − 最重要的一点是测试可伸缩性。如果不这样做，我们的系统设计在系统增长时将无法正常工作。

Data Warehousing - Future Aspects

以下是在数据仓库的未来方面。

正如我们所看到的，开放数据库的大小在过去几年中增长了大约一倍，这表明它包含显著的价值。
随着数据库规模的增长，对构成超大型数据库的估计也不断增长。
当今可用的硬件和软件无法将大量数据存储在线。例如，一条电信通话记录需要 10TB 的数据存储在线，而这仅仅是一个月记录的大小。如果需要保存销售、营销客户、员工等记录，那么大小将超过 100TB。
记录包含文本信息和一些多媒体数据。多媒体数据无法像文本数据那样轻松操作。搜索多媒体数据并非易事，而文本信息可以通过当今可用的关系软件检索。
除了大小规划之外，构建和运行不断增加的大型数据仓库系统也很复杂。随着用户数量增加，数据仓库的大小也会增加。这些用户还需要访问该系统。
随着互联网的发展，用户需要在线访问数据。

因此，未来数据仓库的形态将与当今创建的形态大不相同。