数据仓库 - 快速指南

---

---

数据仓库 - 概述

“数据仓库”一词最早由Bill Inmon于1990年提出。根据Inmon的定义，数据仓库是面向主题的、集成的、随时间变化的、非易失性的数据集合。这些数据帮助分析人员在组织中做出明智的决策。

运营数据库每天都会因为发生的交易而频繁变化。假设一位企业高管想要分析以往关于任何数据的反馈，例如产品、供应商或任何消费者数据，那么这位高管将没有可用的数据进行分析，因为以往的数据由于交易已被更新。

数据仓库为我们提供多维度视图的泛化和整合数据。除了数据的泛化和整合视图外，数据仓库还为我们提供联机分析处理 (OLAP) 工具。这些工具帮助我们在多维空间中进行交互式和有效的 数据分析。这种分析导致数据泛化和数据挖掘。

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

理解数据仓库

• 数据仓库是一个数据库，它与组织的运营数据库分开存放。

• 数据仓库不会频繁更新。

• 它拥有整合的历史数据，这有助于组织分析其业务。

• 数据仓库帮助高管组织、理解和使用他们的数据以做出战略决策。

• 数据仓库系统有助于整合各种应用程序系统。

• 数据仓库系统有助于整合历史数据的分析。

为什么数据仓库与运营数据库分开

数据仓库与运营数据库分开存放的原因如下：

• 运营数据库是为众所周知的任务和工作负载（例如搜索特定记录、索引等）而构建的。相比之下，数据仓库查询通常很复杂，并且它们呈现出数据的通用形式。

• 运营数据库支持并发处理多个事务。运营数据库需要并发控制和恢复机制来确保数据库的健壮性和一致性。

• 运营数据库查询允许读写操作，而OLAP查询只需要对存储数据的**只读**访问。

• 运营数据库维护当前数据。另一方面，数据仓库维护历史数据。

数据仓库特性

下面讨论数据仓库的关键特性：

• **面向主题** - 数据仓库面向主题，因为它提供围绕主题的信息，而不是组织的正在进行的运营。这些主题可以是产品、客户、供应商、销售、收入等。数据仓库不关注正在进行的运营，而是关注数据的建模和分析以进行决策。

• **集成** - 数据仓库是通过整合来自异构数据源（例如关系数据库、平面文件等）的数据来构建的。这种集成增强了数据的有效分析。

• **随时间变化** - 数据仓库中收集的数据与特定时间段相关联。数据仓库中的数据提供从历史角度来看的信息。

• **非易失性** - 非易失性意味着在添加新数据时不会擦除以前的数据。数据仓库与运营数据库分开存放，因此运营数据库中的频繁更改不会反映在数据仓库中。

**注意** - 数据仓库不需要事务处理、恢复和并发控制，因为它与运营数据库物理隔离并单独存储。

数据仓库应用

如前所述，数据仓库帮助企业高管组织、分析和使用他们的数据进行决策。数据仓库是企业管理计划-执行-评估“闭环”反馈系统中的一个组成部分。数据仓库广泛应用于以下领域：

• 金融服务
• 银行服务
• 消费品
• 零售业
• 受控制造业

数据仓库类型

信息处理、分析处理和数据挖掘是下面讨论的三种数据仓库应用程序类型：

• **信息处理** - 数据仓库允许处理其中存储的数据。可以通过查询、基本统计分析、使用交叉表、表格、图表或图形进行报告来处理数据。

• **分析处理** - 数据仓库支持对其存储信息的分析处理。可以通过基本OLAP操作（包括切片和切块、向下钻取、向上钻取和透视）来分析数据。

• **数据挖掘** - 数据挖掘通过查找隐藏的模式和关联、构建分析模型、执行分类和预测来支持知识发现。可以使用可视化工具来呈现这些挖掘结果。

数据仓库 - 概念

什么是数据仓库？

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

使用数据仓库信息

有一些决策支持技术可以帮助利用数据仓库中可用的数据。这些技术帮助高管快速有效地使用仓库。他们可以收集数据，对其进行分析，并根据仓库中提供的信息做出决策。仓库中收集的信息可用于以下任何领域：

• **调整生产策略** - 通过比较季度或年度销售额来重新定位产品和管理产品组合，可以很好地调整产品策略。

• **客户分析** - 通过分析客户的购买偏好、购买时间、预算周期等来进行客户分析。

• **运营分析** - 数据仓库还有助于客户关系管理和进行环境修正。这些信息还允许我们分析业务运营。

集成异构数据库

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

• 查询驱动方法
• 更新驱动方法

查询驱动方法

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

查询驱动方法的过程

• 当向客户端发出查询时，元数据字典会将查询转换为参与的各个异构站点适用的形式。

• 现在这些查询被映射并发送到本地查询处理器。

• 来自异构站点的结果被集成到全局答案集中。

缺点

• 查询驱动方法需要复杂的集成和过滤过程。

• 这种方法非常低效。

• 对于频繁的查询，这种方法非常昂贵。

• 对于需要聚合的查询，这种方法也非常昂贵。

更新驱动方法

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

优点

这种方法具有以下优点：

• 这种方法提供高性能。

• 数据在语义数据存储中预先复制、处理、集成、注释、汇总和重构。

• 查询处理不需要接口来处理本地源的数据。

数据仓库工具和实用程序的功能

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

• **数据提取** - 涉及从多个异构源收集数据。

• **数据清洗** - 涉及查找和纠正数据中的错误。

• **数据转换** - 涉及将数据从旧格式转换为仓库格式。

• **数据加载** - 涉及排序、汇总、整合、检查完整性以及构建索引和分区。

• **刷新** - 涉及从数据源到仓库的更新。

**注意** - 数据清洗和数据转换是提高数据质量和数据挖掘结果的重要步骤。

数据仓库 - 术语

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

元数据

元数据简单地定义为关于数据的数据。用于表示其他数据的那些数据被称为元数据。例如，书籍的索引作为书籍内容的元数据。换句话说，我们可以说元数据是引导我们走向详细数据的汇总数据。

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

• 元数据是数据仓库的路线图。

• 数据仓库中的元数据定义了仓库对象。

• 元数据充当目录。此目录帮助决策支持系统定位数据仓库的内容。

元数据仓库

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

• 业务元数据 - 包含数据所有权信息、业务定义和变更策略。

• 操作元数据 - 包括数据的有效性和数据血缘。数据的有效性是指数据处于活动状态、已归档或已清除。数据血缘是指数据迁移的历史记录以及对其应用的转换。

• 从操作环境到数据仓库的映射数据 - 此元数据包括源数据库及其内容、数据提取、数据分区、清洗、转换规则、数据刷新和清除规则。

• 汇总算法 - 包括维度算法、粒度数据、聚合、汇总等。

数据立方体

数据立方体帮助我们以多个维度表示数据。它由维度和事实定义。维度是企业保存记录的实体。

数据立方体的示例

假设一家公司希望借助销售数据仓库跟踪销售记录，这些记录涉及时间、商品、分支机构和地点。这些维度允许跟踪每月的销售额以及商品在哪个分支机构销售。每个维度都关联一个表。此表称为维度表。“商品”维度表可能具有商品名称、商品类型和商品品牌等属性。

下表显示了公司关于时间、商品和地点维度的销售数据的二维视图。

但在此二维表中，我们只有关于时间和商品的记录。新德里的销售额按时间和商品维度显示，根据销售商品的类型显示。如果我们想查看包含另一个维度（例如地点维度）的销售数据，则三维视图将非常有用。下表显示了关于时间、商品和地点的三维销售数据视图。

上表可以表示为如下所示的三维数据立方体：

数据市场

数据市场包含对组织中特定人群有价值的组织范围数据的子集。换句话说，数据市场只包含特定群体的数据。例如，市场营销数据市场可能只包含与商品、客户和销售相关的数据。数据市场限于主题。

关于数据市场的要点

• 使用基于 Windows 或 Unix/Linux 的服务器来实现数据市场。它们是在低成本服务器上实现的。

• 数据市场的实施周期以较短的时间段衡量，即以周而不是月或年来衡量。

• 从长远来看，如果数据市场的规划和设计不是全组织范围的，那么它们的生命周期可能会很复杂。

• 数据市场规模较小。

• 数据市场由部门定制。

• 数据市场的来源是部门结构化的数据仓库。

• 数据市场灵活。

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

虚拟仓库

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

数据仓库 - 交付流程

数据仓库从来都不是静态的；它随着业务的扩展而发展。随着业务的发展，其需求不断变化，因此必须设计数据仓库以适应这些变化。因此，数据仓库系统需要灵活。

理想情况下，应该有一个交付流程来交付数据仓库。但是，数据仓库项目通常会遇到各种问题，这些问题使得难以按照瀑布方法要求的严格和有序的方式完成任务和交付成果。大多数情况下，需求并不完全了解。只有在收集和研究所有需求后，才能完成体系结构、设计和构建组件。

交付方法

交付方法是为交付数据仓库而采用的联合应用程序开发方法的变体。我们已经对数据仓库交付流程进行了分阶段处理，以最大程度地降低风险。我们在这里将讨论的方法不会缩短整体交付时间，但确保通过开发流程逐步交付业务利益。

注意 - 交付流程被分成多个阶段，以降低项目和交付风险。

下图解释了交付流程中的各个阶段：

IT战略

数据仓库是战略性投资，需要业务流程来产生效益。需要 IT 战略来获取和保留项目的资金。

商业案例

商业案例的目标是估算使用数据仓库应获得的业务效益。这些效益可能无法量化，但需要明确说明预计效益。如果数据仓库没有明确的商业案例，那么业务在交付过程的某个阶段往往会遇到信誉问题。因此，在数据仓库项目中，我们需要了解投资的商业案例。

教育和原型设计

组织会尝试数据分析的概念，并在确定解决方案之前了解拥有数据仓库的价值。这是通过原型设计来解决的。它有助于了解数据仓库的可行性和效益。只要满足以下条件，小规模的原型设计活动就可以促进教育过程：

• 原型解决了定义的技术目标。

• 在显示可行性概念后，可以丢弃原型。

• 该活动处理数据仓库最终数据内容的一小部分。

• 活动时间表并不关键。

为了尽早发布并交付业务利益，请记住以下几点。

• 确定能够发展的架构。

• 关注业务需求和技术蓝图阶段。

• 将第一构建阶段的范围限制在交付业务利益的最低限度。

• 了解数据仓库的短期和中期需求。

业务需求

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

在此阶段确定以下方面：

• 应用于数据的业务规则。

• 数据仓库中信息的逻辑模型。

• 对直接需求的查询配置文件。

• 提供此数据的源系统。

技术蓝图

此阶段需要交付满足长期需求的整体架构。此阶段还会交付必须在短期内实施才能获得任何业务利益的组件。蓝图需要确定以下内容。

• 整体系统架构。
• 数据保留策略。
• 备份和恢复策略。
• 服务器和数据市场架构。
• 硬件和基础设施的容量规划。
• 数据库设计的组件。

构建版本

在此阶段，将生成第一个生产交付成果。此生产交付成果是数据仓库的最小组件。此最小组件增加了业务利益。

历史加载

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

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

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

临时查询

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

注意 - 建议在数据库正在大幅修改时不要使用这些访问工具。

自动化

在此阶段，运营管理流程将完全自动化。这些将包括：

• 将数据转换为适合分析的形式。

• 监控查询配置文件并确定适当的聚合以维护系统性能。

• 从不同的源系统提取和加载数据。

• 从数据仓库中的预定义定义生成聚合。

• 备份、还原和存档数据。

扩展范围

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

• 通过将其他数据加载到数据仓库中。

• 通过使用现有信息引入新的数据市场。

注意 - 此阶段应单独执行，因为它涉及大量的努力和复杂性。

需求演变

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

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

该架构旨在根据业务需求进行更改和扩展，其运行过程类似于伪应用程序开发过程，不断将新需求输入到开发活动中，并生成部分可交付成果。这些部分可交付成果将反馈给用户，然后进行返工，确保整个系统持续更新以满足业务需求。

数据仓库 - 系统流程

我们需要对操作数据库应用固定数量的操作，并且我们有明确定义的技术，例如**使用规范化数据**、**保持表较小**等。这些技术适用于交付解决方案。但在决策支持系统的情况下，我们不知道将来需要执行哪些查询和操作。因此，应用于操作数据库的技术不适用于数据仓库。

本章将讨论如何在开放系统技术（如 Unix 和关系数据库）之上构建数据仓库解决方案。

数据仓库中的流程

数据仓库包含四个主要流程：

• 提取和加载数据。
• 数据清洗和转换。
• 数据备份和归档。
• 管理查询并将它们定向到相应的数据源。

提取和加载流程

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

注意 - 在将数据加载到数据仓库之前，必须重建从外部来源提取的信息。

流程控制

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

何时启动提取

提取数据时，数据需要处于一致状态，即数据仓库应向用户呈现信息的单个一致版本。

例如，在电信行业的客户画像数据仓库中，将星期三晚上 8 点从客户数据库中获取的客户列表与星期二晚上 8 点之前的客户订阅事件合并是不合逻辑的。这意味着我们将找到没有关联订阅的客户。

数据加载

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

注意 - 只在所有数据源都已加载到临时数据存储区后才执行一致性检查。

清洗和转换流程

将数据提取并加载到临时数据存储区后，就可以进行清洗和转换。以下是清洗和转换步骤：

• 将加载的数据清洗并转换到特定的结构
• 数据分区
• 数据聚合

将加载的数据清洗并转换到特定的结构

清洗和转换加载的数据有助于加快查询速度。可以通过使数据保持一致来实现：

• 自身内部一致。
• 与同一数据源中的其他数据一致。
• 与其他源系统中的数据一致。
• 与仓库中现有的数据一致。

转换涉及将源数据转换为特定结构。对数据进行结构化处理可以提高查询性能并降低运营成本。数据仓库中包含的数据必须经过转换才能满足性能要求并控制持续的运营成本。

数据分区

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

数据聚合

需要聚合来加快常用查询的速度。聚合依赖于这样一个事实，即大多数常用查询将分析详细数据的子集或聚合。

数据备份和归档

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

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

查询管理流程

此流程执行以下功能：

• 管理查询。

• 帮助加快查询执行速度。

• 将查询定向到其最有效的数据源。

• 确保以最有效的方式使用所有系统资源。

• 监控实际查询概要。

在此过程中生成的信息由仓库管理流程用于确定要生成的聚合。此流程通常不在将信息定期加载到数据仓库期间运行。

数据仓库 - 架构

本章将讨论数据仓库设计和架构的业务分析框架。

业务分析框架

业务分析师从数据仓库获取信息来衡量绩效并进行关键调整，以便在市场上胜过其他业务持有者。拥有数据仓库具有以下优势：

• 由于数据仓库可以快速有效地收集信息，因此可以提高业务效率。

• 数据仓库为我们提供了客户和商品的一致视图，因此有助于我们管理客户关系。

• 数据仓库还有助于通过长期跟踪趋势和模式以一致可靠的方式降低成本。

为了设计有效且高效的数据仓库，我们需要理解和分析业务需求并构建**业务分析框架**。每个人对数据仓库的设计都有不同的看法。这些观点如下：

• **自顶向下视图** - 此视图允许选择数据仓库所需的相关信息。

• **数据源视图** - 此视图显示操作系统捕获、存储和管理的信息。

• **数据仓库视图** - 此视图包括事实表和维度表。它表示存储在数据仓库中的信息。

• **业务查询视图** - 这是从最终用户的角度来看待数据的视图。

三层数据仓库架构

数据仓库通常采用三层架构。以下是数据仓库架构的三层：

• **底层** - 架构的底层是数据仓库数据库服务器。它是关系数据库系统。我们使用后端工具和实用程序将数据馈送到底层。这些后端工具和实用程序执行提取、清洗、加载和刷新功能。

• **中间层** - 在中间层，我们有 OLAP 服务器，可以通过以下两种方式实现。

  • 通过关系 OLAP (ROLAP)，它是一个扩展的关系数据库管理系统。ROLAP 将多维数据上的操作映射到标准关系操作。

  • 通过多维 OLAP (MOLAP) 模型，它直接实现多维数据和操作。

• **顶层** - 此层是前端客户端层。此层包含查询工具和报表工具、分析工具和数据挖掘工具。

下图描述了数据仓库的三层架构。

数据仓库模型

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

• 虚拟仓库
• 数据市集
• 企业仓库

虚拟仓库

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

数据市场

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

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

关于数据市集需要注意的几点：

• 使用基于 Windows 或 Unix/Linux 的服务器来实现数据市集。它们在低成本服务器上实现。

• 数据市集的实现周期以较短的时间段来衡量，即以周而不是以月或年来衡量。

• 如果数据市集的规划和设计不是组织范围的，那么从长远来看，其生命周期可能会很复杂。

• 数据市场规模较小。

• 数据市场由部门定制。

• 数据市场的来源是部门结构化的数据仓库。

• 数据市集很灵活。

企业仓库

• 企业仓库收集跨越整个组织的所有信息和主题。

• 它为我们提供企业范围的数据集成。

• 数据集成自操作系统和外部信息提供商。

• 此信息的大小可能从几 GB 到数百 GB、TB 或更多。

加载管理器

此组件执行提取和加载过程所需的操作。

加载管理器的规模和复杂性因特定数据仓库解决方案而异。

加载管理器架构

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

• 从源系统提取数据。

• 将提取的数据快速加载到临时数据存储区。

• 执行简单的转换，使其结构类似于数据仓库中的结构。

从源提取数据

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

快速加载

• 为了最大限度地减少总加载窗口，需要以尽可能快的速度将数据加载到仓库中。

• 转换会影响数据处理速度。

• 在应用转换和检查之前，将数据加载到关系数据库中更有效。

• 网关技术被证明不适用，因为当涉及大量数据时，它们的性能往往不高。

简单的转换

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

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

仓库管理器

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

仓库管理器的规模和复杂性因特定解决方案而异。

仓库管理器架构

仓库管理器包括以下内容：

• 控制流程
• 存储过程或带有 SQL 的 C 代码
• 备份/恢复工具
• SQL脚本

仓库管理员执行的操作

• 仓库管理员分析数据以执行一致性和参照完整性检查。

• 针对基础数据创建索引、业务视图、分区视图。

• 生成新的聚合并更新现有的聚合。生成规范化。

• 将源数据转换并合并到已发布的数据仓库中。

• 备份数据仓库中的数据。

• 存档已达到捕获寿命结束的数据。

注意 − 仓库管理员还会分析查询配置文件，以确定索引和聚合是否合适。

查询管理器

• 查询管理器负责将查询定向到合适的表。

• 通过将查询定向到合适的表，可以提高查询速度和响应生成速度。

• 查询管理器负责调度用户提出的查询的执行。

查询管理器架构

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

• 通过C工具或RDBMS进行查询重定向
• 存储过程
• 查询管理工具
• 通过C工具或RDBMS进行查询调度
• 通过第三方软件进行查询调度

详细信息

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

下图显示了详细信息存储位置及其使用方法的图示。

注意 − 如果离线保存详细信息以最大限度地减少磁盘存储空间，我们应确保数据在存档之前已提取、清理并转换为星型雪花模式。

汇总信息

汇总信息是数据仓库的一部分，用于存储预定义的聚合。这些聚合由仓库管理员生成。汇总信息必须视为瞬态的。它会随时发生变化，以响应不断变化的查询配置文件。

关于汇总信息需要注意的几点如下：

• 汇总信息可以加快常用查询的性能。

• 它会增加运营成本。

• 每当将新数据加载到数据仓库中时，都需要更新它。

• 它可能没有备份，因为它可以从详细信息中重新生成。

数据仓库 - OLAP

联机分析处理服务器 (OLAP) 基于多维数据模型。它允许管理人员和分析师通过快速、一致且交互式地访问信息来深入了解信息。本章涵盖 OLAP 的类型、OLAP 的操作、OLAP 与统计数据库以及 OLTP 之间的区别。

OLAP 服务器类型

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

• 关系型 OLAP (ROLAP)
• 多维 OLAP (MOLAP)
• 混合 OLAP (HOLAP)
• 专用 SQL 服务器

关系型 OLAP

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

ROLAP 包括以下内容：

• 聚合导航逻辑的实现。
• 针对每个 DBMS 后端的优化。
• 其他工具和服务。

多维 OLAP

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

混合 OLAP

混合 OLAP 是 ROLAP 和 MOLAP 的组合。它提供了 ROLAP 的更高可扩展性和 MOLAP 的更快计算速度。HOLAP 服务器允许存储大量详细信息。聚合分别存储在 MOLAP 存储中。

专用 SQL 服务器

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

OLAP 操作

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

以下是 OLAP 操作的列表：

• 上卷
• 下钻
• 切片和切块
• 透视（旋转）

上卷

上卷以以下任何一种方式对数据立方体执行聚合：

• 通过沿着维度概念层次结构向上移动
• 通过维度缩减

下图说明了上卷的工作原理。

• 通过沿着位置维度概念层次结构向上移动来执行上卷。

• 最初的概念层次结构是“街道 < 城市 < 省份 < 国家”。

• 在上卷时，数据通过从城市级别到国家级别上移位置层次结构来聚合。

• 数据按城市而不是国家分组。

• 执行上卷时，将从数据立方体中删除一个或多个维度。

下钻

下钻是上卷的逆操作。它通过以下任何一种方式执行：

• 通过沿着维度概念层次结构向下移动
• 通过引入新维度。

下图说明了下钻的工作原理：

• 通过沿着时间维度概念层次结构向下移动来执行下钻。

• 最初的概念层次结构是“天 < 月 < 季度 < 年”。

• 在下钻时，时间维度从季度级别下降到月级别。

• 执行下钻时，将向数据立方体中添加一个或多个维度。

• 它将数据从较少详细的数据导航到高度详细的数据。

切片

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

• 此处使用条件时间 = “Q1”对维度“时间”执行切片。

• 它将通过选择一个或多个维度来形成一个新的子立方体。

切块

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

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

• （位置 = “多伦多”或“温哥华”）
• （时间 = “Q1”或“Q2”）
• （项目 =“移动电话”或“调制解调器”）

透视

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

OLAP 与 OLTP

数据仓库 - 关系型 OLAP

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

ROLAP 包括以下内容：

• 聚合导航逻辑的实现
• 针对每个 DBMS 后端的优化
• 其他工具和服务

要点

• ROLAP 服务器高度可扩展。

• ROLAP 工具分析跨多个维度的大量数据。

• ROLAP 工具存储和分析高度易变和可更改的数据。

关系型 OLAP 架构

ROLAP 包括以下组件：

• 数据库服务器
• ROLAP 服务器
• 前端工具。

优点

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

缺点

• 查询性能差。

• 根据使用的技术架构，可扩展性存在一些限制。

数据仓库 - 多维 OLAP

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

要点：

• 无论选择的汇总或计算级别如何，MOLAP 工具都能以一致的响应时间处理信息。

• MOLAP 工具需要避免创建关系数据库以存储分析数据的许多复杂性。

• MOLAP 工具需要尽可能快的性能。

• MOLAP 服务器采用两级存储表示来处理密集型和稀疏型数据集。

• 识别更密集的子立方体并将其存储为数组结构。

• 稀疏子立方体采用压缩技术。

MOLAP 架构

MOLAP 包括以下组件：

• 数据库服务器。
• MOLAP 服务器。
• 前端工具。

优点

• MOLAP 允许对预先计算的汇总数据进行最快索引。
• 帮助需要分析更大、更不确定数据的联网用户。
• 易于使用，因此 MOLAP 适用于没有经验的用户。

缺点

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

MOLAP 与 ROLAP

数据仓库 - 模式

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

星型模式

• 在星型模式中，每个维度都只用一个维度表表示。

• 该维度表包含一组属性。

• 下图显示了公司关于四个维度（时间、项目、分支和位置）的销售数据。

• 中心有一个事实表。它包含每个四个维度的键。

• 事实表还包含属性，即销售美元和销售单位。

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

雪花模式

• 雪花模式中的一些维度表已进行规范化。

• 规范化将数据拆分为附加表。

• 与星型模式不同，雪花模式中的维度表是规范化的。例如，星型模式中的项目维度表被规范化并拆分为两个维度表，即项目表和供应商表。

• 现在，项目维度表包含属性item_key、item_name、type、brand和supplier-key。

• 供应商键链接到供应商维度表。供应商维度表包含属性supplier_key和supplier_type。

注意 - 由于雪花模式中的规范化，冗余减少了，因此易于维护并节省存储空间。

事实星座模式

• 事实星座有多个事实表。它也称为星系模式。

• 下图显示了两个事实表，即销售和运输。

• 销售事实表与星型模式中的相同。

• 运输事实表具有五个维度，即item_key、time_key、shipper_key、from_location、to_location。

• 运输事实表还包含两个度量，即销售美元和销售单位。

• 也可以在事实表之间共享维度表。例如，时间、项目和位置维度表在销售和运输事实表之间共享。

模式定义

使用数据挖掘查询语言 (DMQL) 定义多维模式。可以使用两个基本元素，立方体定义和维度定义，来定义数据仓库和数据市场。

立方体定义语法

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

维度定义语法

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

星型模式定义

我们可以使用数据挖掘查询语言 (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)

雪花模式定义

可以使用 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))

事实星座模式定义

可以使用 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

数据仓库 - 分区策略

进行分区是为了提高性能并方便数据管理。分区还有助于平衡系统的各种需求。它通过将每个事实表分成多个单独的分区来优化硬件性能并简化数据仓库的管理。本章将讨论不同的分区策略。

为什么需要分区？

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

• 易于管理；
• 辅助备份/恢复；
• 提高性能。

易于管理

数据仓库中的事实表的大小可能会增长到数百 GB。如此巨大的事实表很难作为一个实体来管理。因此，它需要分区。

辅助备份/恢复

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

注意 - 为减少备份大小，当前分区以外的所有分区都可以标记为只读。然后，我们可以将这些分区置于无法修改的状态。然后可以备份它们。这意味着只需要备份当前分区。

提高性能

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

水平分区

事实表有多种分区方式。在水平分区中，我们必须记住数据仓库的可管理性要求。

按时间划分为相等的部分

在此分区策略中，事实表基于时间段进行分区。这里每个时间段代表业务中的一个重要保留期。例如，如果用户查询**月度至今数据**，则将数据划分为月度部分是合适的。我们可以通过删除其中的数据来重复使用分区表。

按时间划分为不同大小的部分

这种分区是在很少访问陈旧数据的情况下进行的。它实现为一组用于相对当前数据的小分区，以及用于非活动数据的大分区。

需要注意的几点

• 详细信息在线提供。

• 物理表的数量保持相对较小，从而降低了运营成本。

• 此技术适用于需要混合使用最近历史数据挖掘和整个历史数据挖掘的情况。

• 此技术不适用于分区配置文件定期更改的情况，因为重新分区会增加数据仓库的运营成本。

按不同维度分区

事实表也可以基于时间以外的维度进行分区，例如产品组、区域、供应商或任何其他维度。让我们举个例子。

假设市场职能已细分为不同的区域部门，例如**按州**划分。如果每个区域都希望查询在其区域内捕获的信息，则将事实表划分为区域分区将被证明更有效。这将导致查询速度加快，因为它不需要扫描不相关的信息。

需要注意的几点

• 查询不必扫描不相关的数据，从而加快了查询过程。

• 此技术不适用于维度在未来不太可能发生变化的情况。因此，确定维度在未来不会发生变化是值得的。

• 如果维度发生变化，则必须重新分区整个事实表。

注意 - 我们建议仅基于时间维度进行分区，除非您确定建议的维度分组在数据仓库的生命周期内不会发生变化。

按表大小分区

当没有明确的依据可以根据任何维度对事实表进行分区时，我们应该**根据其大小对事实表进行分区**。我们可以将预定大小设置为临界点。当表超过预定大小时，将创建一个新的表分区。

需要注意的几点

• 这种分区难以管理。

• 它需要元数据来识别每个分区中存储的数据。

分区维度

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

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

循环分区

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

此技术使在数据仓库中轻松自动化表管理功能。

垂直分区

垂直分区垂直分割数据。下图描述了如何进行垂直分区。

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

• 规范化
• 行分割

规范化

规范化是数据库组织的标准关系方法。在这种方法中，行折叠成单行，因此它减少了空间。请查看以下显示如何执行规范化的表。

规范化之前的表

规范化后的表

行分割

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

注意 - 使用垂直分区时，请确保不需要在两个分区之间执行主要的连接操作。

确定分区的键

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

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

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

• 区域
• 交易日期

假设业务分布在30个地理区域，每个区域的支行数量不同。这将给我们带来30个分区，这是合理的。这种分区方案足够好，因为我们的需求捕获显示，绝大多数查询都限制在用户自己的业务区域内。

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

因此，确定正确的分区键非常重要。

数据仓库 - 元数据概念

什么是元数据？

元数据简单地定义为关于数据的数据。用于表示其他数据的数据被称为元数据。例如，书籍的索引充当书籍内容的元数据。换句话说，我们可以说元数据是引导我们获取详细数据的汇总数据。在数据仓库方面，我们可以将元数据定义如下：

• 元数据是数据仓库的路线图。

• 数据仓库中的元数据定义了仓库对象。

• 元数据充当目录。此目录帮助决策支持系统定位数据仓库的内容。

注意 - 在数据仓库中，我们为给定数据仓库的数据名称和定义创建元数据。除了这些元数据之外，还会为任何提取的数据的时间戳、提取数据的来源创建附加元数据。

元数据的类别

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

• 业务元数据 - 它包含数据所有权信息、业务定义和变更策略。

• 技术元数据 - 它包括数据库系统名称、表和列的名称和大小、数据类型和允许的值。技术元数据还包括结构信息，例如主键和外键属性以及索引。

• 操作元数据 - 它包括数据的有效性和数据血统。数据的有效性是指数据是活动状态、已归档还是已清除。数据血统是指数据迁移的历史记录以及应用于它的转换。

元数据的角色

元数据在数据仓库中扮演着非常重要的角色。元数据在仓库中的作用与仓库数据不同，但它起着重要的作用。元数据的各种作用解释如下：

• 元数据充当目录。

• 此目录帮助决策支持系统定位数据仓库的内容。

• 当数据从操作环境转换为数据仓库环境时，元数据帮助决策支持系统进行数据映射。

• 元数据有助于在当前详细数据和高度汇总的数据之间进行汇总。

• 元数据还有助于在轻度详细数据和高度汇总的数据之间进行汇总。

• 元数据用于查询工具。

• 元数据用于提取和清洗工具。

• 元数据用于报表工具。

• 元数据用于转换工具。

• 元数据在加载功能中发挥着重要作用。

下图显示了元数据的角色。（此处应插入图表）

元数据仓库

元数据仓库是数据仓库系统不可或缺的一部分。它包含以下元数据：

• 数据仓库的定义 - 它包括对数据仓库结构的描述。该描述由模式、视图、层次结构、派生数据定义以及数据市场位置和内容定义。

• 业务元数据 - 它包含数据所有权信息、业务定义和变更策略。

• 操作元数据 - 它包括数据的有效性和数据血统。数据的有效性是指数据是活动状态、已归档还是已清除。数据血统是指数据迁移的历史记录以及应用于它的转换。

• 从操作环境到数据仓库的映射数据 - 它包括源数据库及其内容、数据提取、数据分区清理、转换规则、数据刷新和清除规则。

• 汇总算法 - 它包括维度算法、粒度数据、聚合、汇总等。

元数据管理的挑战

元数据的重要性怎么强调都不为过。元数据有助于提高报告的准确性，验证数据转换，并确保计算的准确性。元数据还向业务最终用户强制执行业务术语的定义。尽管元数据有这些用途，但它也面临挑战。下面讨论其中一些挑战。

• 大型组织中的元数据分散在整个组织中。这些元数据分散在电子表格、数据库和应用程序中。

• 元数据可能存在于文本文件或多媒体文件中。为了将这些数据用于信息管理解决方案，必须对其进行正确的定义。

• 没有行业通用的公认标准。数据管理解决方案供应商关注面狭窄。

• 没有简单易行且公认的元数据传递方法。

数据仓库 - 数据市场

为什么我们需要数据市场？

以下是创建数据市场的理由：

• 对数据进行分区以实施访问控制策略。

• 通过减少要扫描的数据量来加快查询速度。

• 将数据分割到不同的硬件平台。

• 以适合用户访问工具的形式组织数据。

注意 - 不要因为其他任何原因创建数据市场，因为数据市场操作成本可能非常高。在进行数据市场之前，请确保数据市场策略适合您的特定解决方案。

经济高效的数据市场

请遵循以下步骤，使数据市场经济高效：

• 识别功能分割
• 识别用户访问工具需求
• 识别访问控制问题

识别功能分割

在此步骤中，我们确定组织是否有自然的功能分割。我们寻找部门分割，并确定部门使用信息的方式是否倾向于与组织的其余部分隔离。让我们举个例子。

考虑一个零售组织，每个商家负责最大限度地提高一组产品的销售额。为此，以下信息非常有价值：

• 每日销售交易
• 每周销售预测
• 每日库存状况
• 每日库存变动

由于商家对他们不经手的产品不感兴趣，因此数据市场是与相关产品组相关的部分数据子集。下图显示了不同用户的元数据。（此处应插入图表）

以下是确定功能分割时需要考虑的问题：

• 部门的结构可能会发生变化。

• 产品可能会从一个部门转移到另一个部门。

• 商家可以查询其他产品的销售趋势，以分析销售情况。

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

识别用户访问工具需求

我们需要数据市场来支持需要内部数据结构的用户访问工具。此类结构中的数据不受数据仓库的控制，但需要定期填充和更新。

有些工具可以直接从源系统填充数据，但有些工具不行。因此，需要确定未来工具范围之外的其他需求。

注意 - 为了确保所有访问工具之间的数据一致性，数据不应直接从数据仓库填充，而每个工具都必须拥有自己的数据市场。

识别访问控制问题

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

数据市场允许我们通过物理隔离数据仓库内的部分数据来构建完整的隔离墙。为避免可能的隐私问题，可以从数据仓库中删除详细数据。我们可以为每个法律实体创建数据市场，并通过数据仓库加载它，其中包含详细的帐户数据。

设计数据市场

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

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

数据市场成本

数据市场的成本度量如下：

• 硬件和软件成本
• 网络访问
• 时间窗口约束

硬件和软件成本

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

注意 - 数据市场比聚合更昂贵，因此应将其用作附加策略，而不是替代策略。

网络访问

数据市场可能位于与数据仓库不同的位置，因此我们应确保局域网或广域网具有处理数据市场加载过程中传输的数据量的能力。

时间窗口约束

数据市场加载过程在多大程度上会占用可用时间窗口，取决于转换的复杂性和正在传输的数据量。确定有多少数据市场取决于：

• 网络容量。
• 可用时间窗口
• 正在传输的数据量
• 用于将数据插入数据市场的机制

数据仓库 - 系统管理员

系统管理对于成功实施数据仓库是强制性的。最重要的系统管理员是：

• 系统配置管理员
• 系统调度管理员
• 系统事件管理员
• 系统数据库管理员
• 系统备份恢复管理员

系统配置管理员

• 系统配置管理员负责管理数据仓库的安装和配置。

• 配置管理员的结构因操作系统而异。

• 在 Unix 配置结构中，管理员因供应商而异。

• 配置管理员具有单一用户界面。

• 配置管理员的界面允许我们控制系统的各个方面。

注意 - 最重要的配置工具是 I/O 管理器。

系统调度管理员

系统调度管理员负责数据仓库的成功实施。其目的是调度临时查询。每个操作系统都有自己的调度程序，具有一定的批处理控制机制。系统调度管理员必须具备的功能列表如下：

• 跨集群或 MPP 边界工作
• 处理国际时差
• 处理作业失败
• 处理多个查询
• 支持作业优先级
• 重新启动或重新排队失败的作业
• 作业完成后通知用户或进程
• 在系统中断期间维护作业调度
• 将作业重新排队到其他队列
• 支持启动和停止队列
• 记录排队的作业
• 处理队列间处理

注意 - 以上列表可用作评估优秀调度程序的评估参数。

调度程序必须能够处理的一些重要作业如下：

• 每日和临时查询调度
• 执行定期报表需求
• 数据加载
• 数据处理
• 索引创建
• 备份
• 聚合创建
• 数据转换

注意 − 如果数据仓库运行在集群或MPP架构上，则系统调度管理器必须能够跨架构运行。

系统事件管理器

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

注意 − 事件管理器监控事件的发生并处理它们。事件管理器还会跟踪此复杂数据仓库系统中可能出现的大量问题。

事件

事件是由用户或系统本身生成的动作。需要注意的是，事件是定义动作的可测量、可观察的发生。

以下是需要跟踪的常见事件列表。

• 硬件故障
• 某些关键磁盘空间不足
• 进程终止
• 进程返回错误
• CPU使用率超过80%阈值
• 数据库序列化点上的内部竞争
• 缓冲区缓存命中率超过或低于阈值
• 表达到最大尺寸
• 过度内存交换
• 由于空间不足，表无法扩展
• 磁盘出现I/O瓶颈
• 临时或排序区域的使用达到某个阈值
• 任何其他数据库共享内存使用情况

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

系统和数据库管理器

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

• 增加用户的配额。
• 为用户分配和取消分配角色
• 为用户分配和取消分配配置文件
• 执行数据库空间管理
• 监控和报告空间使用情况
• 整理碎片化和未使用的空间
• 添加和扩展空间
• 添加和删除用户
• 管理用户密码
• 管理汇总表或临时表
• 为用户分配或取消分配临时空间
• 回收旧的或过时的临时表的空间
• 管理错误和跟踪日志
• 浏览日志和跟踪文件
• 重定向错误或跟踪信息
• 启用和禁用错误和跟踪日志记录
• 执行系统空间管理
• 监控和报告空间使用情况
• 清理旧的和未使用的文件目录
• 添加或扩展空间。

系统备份恢复管理器

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

• 调度
• 备份数据跟踪
• 数据库感知

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

• 备份软件将保留某种形式的数据库，记录数据片段的备份位置和时间。

• 备份恢复管理器必须具有良好的前端数据库。

• 备份恢复软件应该具有数据库感知能力。

• 了解数据库后，软件就可以用数据库术语来处理，并且不会执行不可行的备份。

数据仓库 - 流程管理器

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

• 加载管理器
• 仓库管理器
• 查询管理器

数据仓库加载管理器

加载管理器执行将数据提取并加载到数据库中所需的运算。加载管理器的规模和复杂性因不同数据仓库的特定解决方案而异。

加载管理器架构

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

• 从源系统提取数据。

• 将提取的数据快速加载到临时数据存储区。

• 执行简单的转换，使其结构类似于数据仓库中的结构。

从源提取数据

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

快速加载

• 为了最大限度地缩短总加载时间，需要以最快速度将数据加载到仓库中。

• 转换会影响数据处理速度。

• 在应用转换和检查之前，将数据加载到关系数据库中更有效。

• 网关技术不适用，因为当涉及大量数据时，它们效率低下。

简单的转换

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

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

仓库管理器

仓库管理器负责仓库管理流程。它由第三方系统软件、C程序和shell脚本组成。仓库管理器的规模和复杂性因特定解决方案而异。

仓库管理器架构

仓库管理器包括以下内容：

• 控制流程
• 存储过程或带有 SQL 的 C 代码
• 备份/恢复工具
• SQL脚本

仓库管理器的功能

仓库管理器执行以下功能：

• 分析数据以执行一致性和引用完整性检查。

• 针对基础数据创建索引、业务视图、分区视图。

• 生成新的聚合并更新现有的聚合。

• 生成规范化。

• 将临时存储区的源数据转换并合并到已发布的数据仓库中。

• 备份数据仓库中的数据。

• 存档已达到捕获寿命结束的数据。

注意 − 仓库管理器分析查询配置文件以确定索引和聚合是否合适。

查询管理器

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

查询管理器架构

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

• 通过C工具或RDBMS进行查询重定向
• 存储过程
• 查询管理工具
• 通过C工具或RDBMS进行查询调度
• 通过第三方软件进行查询调度

查询管理器的功能

• 它以用户理解的形式向用户呈现数据。

• 它调度最终用户发布的查询的执行。

• 它存储查询配置文件，以允许仓库管理器确定哪些索引和聚合是合适的。

数据仓库 - 安全性

数据仓库的目标是使大量数据易于用户访问，从而允许用户提取有关整个业务的信息。但我们知道，对数据可能施加某些安全限制，这可能会成为访问信息的障碍。如果分析师对数据的视图受到限制，则不可能捕获业务内趋势的完整画面。

可以对来自每个分析师的数据进行汇总，然后传递给管理层，管理层可以对不同的汇总进行聚合。由于汇总的聚合可能与整体聚合不同，因此除非有人对整体数据进行分析，否则可能会错过数据中的一些信息趋势。

安全需求

添加安全功能会影响数据仓库的性能，因此尽早确定安全需求非常重要。数据仓库上线后很难添加安全功能。

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

• 新的数据源是否需要实施新的安全和/或审计限制？

• 是否添加了对现有公开可用数据具有受限访问权限的新用户？

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

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

• 用户访问
• 数据加载
• 数据移动
• 查询生成

用户访问

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

数据分类

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

• 可以根据数据的敏感性对数据进行分类。高度敏感的数据被归类为高度限制，而不太敏感的数据被归类为限制较少。

• 还可以根据职能对数据进行分类。此限制仅允许特定用户查看特定数据。在这里，我们限制用户只能查看他们感兴趣且负责的那部分数据。

第二种方法存在一些问题。为了理解这一点，让我们举一个例子。假设您正在为一家银行构建数据仓库。假设数据仓库中存储的数据是所有账户的交易数据。这里的问题是，谁被允许查看交易数据。解决方案在于根据职能对数据进行分类。

用户分类

可以使用以下方法对用户进行分类：

• 可以根据组织中用户的层次结构对用户进行分类，即可以按部门、科室、组等对用户进行分类。

• 还可以根据用户的角色对用户进行分类，根据其角色对跨部门的人员进行分组。

基于部门的分类

让我们以一个数据仓库为例，其用户来自销售和市场部门。我们可以通过自上而下的公司视图来实现安全性，访问权限集中在不同的部门。但是，不同级别的用户可能会有一些限制。此结构如下图所示。

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

基于角色的分类

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

审计要求

审计是安全的一个子集，是一项成本高昂的活动。审计可能会给系统带来沉重的开销。为了及时完成审计，我们需要更多硬件，因此，建议尽可能关闭审计。审计要求可以分类如下：

• 连接
• 断开连接
• 数据访问
• 数据更改

注意 - 对于上述每一类，都需要审计成功、失败或两者兼而有之。从安全原因的角度来看，失败的审计非常重要。审计失败很重要，因为它们可以突出未经授权或欺诈性的访问。

网络要求

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

• 在将数据传输到数据仓库之前，是否有必要对其进行加密？

• 对数据可以采取哪些网络路由有限制吗？

需要仔细考虑这些限制。以下是需要记住的几点：

• 加密和解密过程会增加开销。这需要更多的处理能力和处理时间。

• 如果系统已经是负载较高的系统，则加密成本可能很高，因为加密是由源系统承担的。

数据移动

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

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

如果我们谈论这些平面文件的备份，则会提出以下问题：

• 您是备份加密版本还是解密版本？
• 这些备份是否需要制作到单独存储的特殊磁带上？
• 谁有权访问这些磁带？

还需要考虑其他形式的数据移动，例如查询结果集。创建临时表时提出的问题如下：

• 临时表应该保存在哪里？
• 如何使这样的表可见？

我们应该避免意外违反安全限制。如果具有访问受限数据的用户可以生成可访问的临时表，则未经授权的用户可以查看数据。我们可以通过为具有访问受限数据的用户提供单独的临时区域来克服这个问题。

文档

需要对审计和安全要求进行适当的记录。这将被视为证明的一部分。此文档可以包含从以下方面收集的所有信息：

• 数据分类
• 用户分类
• 网络要求
• 数据移动和存储要求
• 所有可审计的操作

安全对设计的影响

安全性会影响应用程序代码和开发时间。安全性会影响以下方面：

• 应用程序开发
• 数据库设计
• 测试

应用程序开发

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

为了创建和维护额外的视图，仓库管理器可能需要额外的代码来强制执行安全性。可能需要将额外的检查编码到数据仓库中，以防止它被欺骗地将数据移动到不应提供数据的位置。查询管理器需要更改以处理任何访问限制。查询管理器需要了解所有额外的视图和聚合。

数据库设计

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

测试

测试数据仓库是一个复杂且漫长的过程。向数据仓库添加安全性也会影响测试时间复杂度。它会通过以下两种方式影响测试：

• 它会增加集成和系统测试所需的时间。

• 需要测试的附加功能会增加测试套件的大小。

数据仓库 - 备份

数据仓库是一个复杂的系统，它包含大量数据。因此，重要的是要备份所有数据，以便根据需要在将来将其用于恢复。在本章中，我们将讨论设计备份策略中的问题。

备份术语

在继续之前，您应该了解下面讨论的一些备份术语。

• 完整备份 - 它同时备份整个数据库。此备份包括所有数据库文件、控制文件和日志文件。

• 部分备份 - 顾名思义，它不会创建数据库的完整备份。部分备份在大型数据库中非常有用，因为它们允许一种策略，即数据库的各个部分每天以循环方式进行备份，以便每周有效地备份整个数据库一次。

• 冷备份 - 冷备份是在数据库完全关闭时进行的。在多实例环境中，所有实例都应关闭。

• 热备份 - 热备份是在数据库引擎运行时进行的。热备份的要求因 RDBMS 而异。

• 在线备份 - 它与热备份非常相似。

硬件备份

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

• 磁带技术
• 磁盘备份

磁带技术

磁带选择可以分类如下：

• 磁带介质
• 独立磁带驱动器
• 磁带堆栈器
• 磁带库

磁带介质

存在多种磁带介质。下表列出了一些磁带介质标准：

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

• 磁带介质的可靠性
• 每单位磁带介质的成本
• 可扩展性
• 磁带系统升级成本
• 每单位磁带介质的成本
• 磁带介质的保存期限

独立磁带驱动器

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

• 直接连接到服务器
• 作为网络可用设备
• 远程连接到其他机器

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

• 假设服务器是 48 节点 MPP 机器。我们不知道连接磁带驱动器的节点，也不知道如何将它们分布在服务器节点上以获得最佳性能，同时最大限度地减少服务器中断和内部 I/O 延迟。

• 将磁带驱动器连接为网络可用设备需要网络能够处理巨大的数据传输速率。确保在您需要时有足够的带宽可用。

• 远程连接磁带驱动器也需要高带宽。

磁带堆栈器

将多个磁带加载到单个磁带驱动器中的方法称为磁带堆栈器。堆栈器在完成当前磁带后卸载它并加载下一盘磁带，因此一次只能访问一盘磁带。价格和功能可能会有所不同，但常见的功能是它们可以执行无人值守的备份。

磁带库

磁带库提供大型存储容量。磁带库可以存储和管理数千盘磁带。它们可以集成多个磁带驱动器。它们具有标记和存储所存储磁带的软件和硬件。磁带库通常通过网络或专用链路远程连接。我们应该确保连接的带宽能够胜任这项工作。

磁盘备份

磁盘备份的方法是：

• 磁盘到磁盘备份
• 镜像中断

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

磁盘到磁盘备份

这里备份是在磁盘上而不是磁带上进行的。磁盘到磁盘备份的原因如下：

• 初始备份速度
• 恢复速度

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

镜像中断

我们的目标是将磁盘镜像，以提高工作日的数据恢复能力。当需要备份时，可以将其中一个镜像集分离出来。此技术是磁盘到磁盘备份的一种变体。

注意 − 为保证备份的一致性，可能需要关闭数据库。

光盘库

光盘库允许数据进行近线存储。这项技术允许以与磁带机或磁带库相同的方式管理大量光盘。这项技术的缺点是写入速度比磁盘慢。但光学介质具有长寿命和可靠性，使其成为归档的良好介质选择。

软件备份

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

选择软件包的标准

选择最佳软件包的标准列在下面：

• 随着磁带驱动器的增加，产品的可扩展性如何？
• 该软件包是否具有客户端-服务器选项，或者它必须在数据库服务器本身上运行？
• 它是否可以在集群和MPP环境中工作？
• 需要多少程度的并行性？
• 该软件包支持哪些平台？
• 该软件包是否支持轻松访问有关磁带内容的信息？
• 该软件包是否了解数据库？
• 该软件包支持哪些磁带驱动器和磁带介质？

数据仓库 - 调优

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

数据仓库调优的难点

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

• 数据仓库是动态的；它永远不会保持不变。

• 很难预测用户将来要发布什么查询。

• 业务需求会随着时间而变化。

• 用户及其配置文件不断变化。

• 用户可以从一个组切换到另一个组。

• 仓库上的数据负载也会随着时间而变化。

注意 − 掌握数据仓库的完整知识非常重要。

性能评估

以下是性能的客观衡量指标列表：

• 平均查询响应时间
• 扫描速率
• 每天查询所用的时间
• 每个进程的内存使用量
• I/O吞吐率

以下是需要记住的几点。

• 有必要在服务级别协议 (SLA) 中指定这些指标。

• 如果响应时间已经优于所需时间，则尝试调整响应时间是没有用的。

• 进行性能评估时，必须要有现实的期望。

• 用户也必须要有可行的期望。

• 为了向用户隐藏系统的复杂性，应使用聚合和视图。

• 用户也可能编写您尚未对其进行调优的查询。

数据加载调优

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

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

下面将讨论各种数据加载调优方法：

• 非常常见的方法是使用SQL层插入数据。在这种方法中，需要执行正常的检查和约束。当数据插入表中时，代码将运行以检查是否有足够的存储空间来插入数据。如果可用空间不足，则可能需要为这些表分配更多空间。这些检查需要时间来执行，并且对CPU的消耗很大。

• 第二种方法是绕过所有这些检查和约束，并将数据直接放置到预格式化的块中。这些块稍后写入数据库。它比第一种方法快，但它只能与整个数据块一起工作。这可能会导致一些空间浪费。

• 第三种方法是在将数据加载到已包含数据的表中时，我们可以维护索引。

• 第四种方法是，要将数据加载到已经包含数据的表中，则在数据加载完成后删除索引并重新创建它们。第三种方法和第四种方法之间的选择取决于已经加载了多少数据以及需要重建多少索引。

完整性检查

完整性检查会严重影响加载的性能。以下是需要记住的几点：

• 需要限制完整性检查，因为它们需要大量的处理能力。

• 应在源系统上应用完整性检查，以避免数据加载性能下降。

查询调优

数据仓库中有两种查询：

• 固定查询
• 临时查询

固定查询

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

• 定期报表
• 预定义查询
• 常用聚合

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

注意 − 我们不能对事实表做更多的事情，但在处理维度表或聚合时，可以使用通常的SQL调整、存储机制和访问方法集合来调整这些查询。

临时查询

要了解临时查询，重要的是要知道数据仓库的临时用户。对于每个用户或用户组，您需要了解以下内容：

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

需要注意的几点

• 重要的是跟踪用户的配置文件并识别定期运行的查询。

• 同样重要的是，所执行的调优不会影响性能。

• 识别经常运行的相似和临时查询。

• 如果识别出这些查询，则数据库将发生更改，并且可以为这些查询添加新索引。

• 如果识别出这些查询，则可以专门为这些查询创建新的聚合，这将导致其高效执行。

数据仓库 - 测试

测试对于数据仓库系统至关重要，以确保其正确有效地工作。数据仓库上执行了三个基本的测试级别：

• 单元测试
• 集成测试
• 系统测试

单元测试

• 在单元测试中，每个组件都会单独进行测试。

• 每个模块，即过程、程序、SQL脚本、Unix shell 都将进行测试。

• 此测试由开发人员执行。

集成测试

• 在集成测试中，应用程序的各个模块将组合在一起，然后针对多个输入进行测试。

• 它用于测试各个组件在集成后是否运行良好。

系统测试

• 在系统测试中，整个数据仓库应用程序将一起进行测试。

• 系统测试的目的是检查整个系统是否一起正常工作。

• 系统测试由测试团队执行。

• 由于整个数据仓库的规模非常大，通常在测试计划可以执行之前，只能执行最少的系统测试。

测试计划

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

有不同的方法可用于创建测试计划，但没有一种是完美的，因为数据仓库非常复杂且规模庞大。此外，数据仓库系统本身也在不断发展。在创建测试计划时，可能会遇到以下问题：

• 一个简单的问题可能会有一个很大的查询，可能需要一天或更长时间才能完成，即查询没有在期望的时间范围内完成。

• 可能出现硬件故障，例如丢失磁盘或人为错误，例如意外删除表或覆盖大型表。

注意 − 由于上述困难，建议始终将您通常允许的测试时间加倍。

测试备份恢复

测试备份恢复策略极其重要。以下是需要此测试的场景列表：

• 介质故障
• 表空间或数据文件丢失或损坏
• 重做日志文件丢失或损坏
• 控制文件丢失或损坏
• 实例故障
• 归档文件丢失或损坏
• 表丢失或损坏
• 数据故障期间发生故障

测试操作环境

需要测试许多方面。这些方面列在下面。

• 安全性 − 需要单独的安全文档进行安全测试。此文档包含不允许的操作列表以及为每个操作设计测试。

• 调度程序 − 需要调度软件来控制数据仓库的日常操作。它需要在系统测试期间进行测试。调度软件需要与数据仓库接口，这需要调度程序来控制夜间处理和聚合的管理。

• 磁盘配置。 − 还需要测试磁盘配置以识别I/O瓶颈。应使用不同的设置多次执行测试。

• 管理工具。 − 需要在系统测试期间测试所有管理工具。以下是需要测试的工具列表。

  • 事件管理器
  • 系统管理器
  • 数据库管理器
  • 配置管理器
  • 备份恢复管理器

测试数据库

数据库以以下三种方式进行测试：

• 数据库管理器和监控工具测试 − 要测试数据库管理器和监控工具，应将其用于测试数据库的创建、运行和管理。

• 数据库功能测试 − 以下是我们必须测试的功能列表：

  • 并行查询

  • 并行创建索引

  • 并行数据加载

• 数据库性能测试 − 查询执行在数据仓库性能指标中扮演着非常重要的角色。需要定期运行一组固定的查询，并且应该对其进行测试。为了测试临时查询，应该仔细阅读用户需求文档并完全理解业务。需要花时间测试业务可能针对不同索引和聚合策略提出的最棘手的查询。

应用程序测试

• 所有管理器都应正确集成并协同工作，以确保端到端的加载、索引、聚合和查询能够按预期工作。

• 每个管理器的每个功能都应正常工作。

• 还需要对应用程序进行一段时间内的测试。

• 还应测试周末和月末任务。

测试的逻辑

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

• 调度软件
• 日常操作程序
• 备份恢复策略
• 管理和调度工具
• 夜间处理
• 查询性能

注意 − 最重要的点是测试可扩展性。未能做到这一点将导致我们设计的系统在系统增长时无法工作。

数据仓库 - 未来展望

以下是数据仓库的未来展望。

• 正如我们所看到的，开放式数据库的大小在过去几年中增长了大约两倍，这表明它包含着巨大的价值。

• 随着数据库规模的增长，构成超大型数据库的估算值也在不断增长。

• 当今可用的硬件和软件不允许保留大量在线数据。例如，电信呼叫记录需要保留 10TB 的在线数据，这仅仅是一个月记录的大小。如果需要保留销售、市场营销客户、员工等记录，那么大小将超过 100TB。

• 记录包含文本信息和一些多媒体数据。多媒体数据不像文本数据那样容易操作。搜索多媒体数据并非易事，而文本信息可以通过当今可用的关系软件检索。

• 除了规模规划外，构建和运行规模不断增长的数据仓库系统也很复杂。随着用户数量的增加，数据仓库的大小也会增加。这些用户也将需要访问系统。

• 随着互联网的发展，用户需要在线访问数据。

因此，数据仓库的未来形态将与今天正在创建的形态大相径庭。