Data Vault 2.0 架构

Data Vault 2.0架构解决了上一节定义的可扩展性和可伸缩性维度，办法是改良一个典型的三层 数据仓库架构 ，这在《数据仓库架构》中曾经介绍过了。
正如咱们在《企业数据仓库环境》中所概述的，企业数据仓库 的次要目标是提供和显示信息——即在上下文中聚合、汇总和合并数据。为了强调这个最终的 EDW 指标，咱们更喜爱应用术语 信息集市 ，而不是 数据集市(这是 Bl 社区通常应用的术语)。

《数据仓库架构》中对典型架构的其余批改包含：

• 一个集结区，它不存储历史信息，也不对数据进行任何更改，除非须要对立的数据类型。
• 基于Data Vault 建模技术的数据仓库层。
• 依赖于 数据仓库层 的一个或多个 信息集市层。
• 一个可选的 指标库，用于捕捉和记录运行时信息。
• 可选的 业务仓库，用于存储利用了业务规定的信息。在许多状况下，业务规定在将数据转换为有用信息时会对数据进行转换或更改。这是另一种信息集市。
• 可选的 作业仓库，存储从业务零碎输出到数据仓库的数据。
• 托管式自服务 BI的性能容许业务用户在不波及 IT 的状况下，执行他们本人的数据分析工作，包含将信息回写到企业数据仓库层。

所有可选库 ( 指标库 、 业务数仓 和作业数仓 ) 都是 Data Vault 的一部分，并集成到 数据仓库层 中。DataVault2.0规范中的参考架构如图 2.2 所示。

图 2.2 DataVault2.0 架构

DataVault2.0 架构基于三层:

• 集结区，它从源零碎收集原始数据;
• 企业数据仓库层，建模为 DataVault2.0 模型；
• 信息交付层，应用星型模式和其余构造的信息集市。

这架构既反对源零碎的批量加载，也反对来自企业服务总线 (ESB) 或任何其余面向服务的架构 (SOA) 的实时加载。然而也能够将非结构化的 NoSQL 数据库系统集成到这种架构中。因为 DataVault2.0 的平台独立性，NoSQL 能够用于每个 数据仓库层 ，包含 集结区 、 企业数据仓库层 和信息交付层 。因而，能够将 NoSQL 数据库用作 集结区 ，并将数据加载到关系型DataVault 层 中。然而，它也能够通过散列业务主键以上述的多种形式与 数据仓库层 集成。在这种状况下，它将成为一个混合解决方案，信息集市 将应用来自这两个环境的数据。
然而，实时零碎和 NoSQL 零碎超出了本文的范畴。因而，咱们将集中于架构的关系局部。

与典型 数据仓库架构 最大的区别之一是，在构建 信息集市 时强制执行大多数业务规定，并将这些规定向最终用户转移。在 DataVault 中，硬业务规定和软业务规定是有区别的。这个区别将在下一节中探讨。

业务规定定义

在 Data Vault 2.0 中，咱们辨别了硬业务规定和软业务规定。一般来说，业务规定批改传入的数据以适应业务的需要。硬业务规定 和软业务规定 之间的区别是 ，硬业务规定 是对齐数据域的技术规定，即所谓的 数据类型匹配 。例如，一个典型的硬业务规定是截断比集结区表中定义的字段长度还长的源字符串。当从源零碎提取数据并加载到集结区时，将强制执行 硬业务规定 。这些业务规定只影响数据类型的施行(如字符串长度或 Unicode 字符)，但不转换任何值以适应业务的剖析需要(如在美国单位和公制单位之间转换)。硬业务规定的其余例子包含对来自大型机零碎或 XML 构造的分层 COBOL copybooks 进行规范化。此外，零碎列计算也是硬业务规定的例子。依据教训， 硬业务规定 永远不会扭转传入数据的含意，只扭转存储数据的形式。

与 硬业务规定 相同，软业务规定 强制执行业务用户申明的业务需要。这些业务规定更改数据或数据的含意，例如通过批改粒度或解释。例子包含数据聚合，例如将数据调配到诸如支出范畴、年龄组、客户细分等类别中，或合并来自多个起源的数据。软业务规定定义了如何聚合或整合数据。它们还定义如何转换数据以满足业务需要。

业务规定利用

因为咱们必须将源零碎的数据类型与 集结区 表的数据类型对齐，所以在加载 集结区 时必须强制执行 硬业务规定 (图 2.3)。这是在最新的执行将数据插入到 集结区 表, 因为数据库治理服务器将查看传入的数据的类型以及触发传入的数据无奈转换为 集结区 表数据定义中指定数据类型的列的异样。例如，如果咱们试图将字母和数字组合的客户编号插入整型的列，则会呈现这种状况，因为咱们冀望类型为“integer”的客户编号。咱们能够通过向将数据加载到 集结区 的 ETL 数据流中增加数据类型转换逻辑来反对这个过程。通过这样做，咱们也实现了 硬业务规定 。

图 2.3 软硬业务规定

硬业务规定 给咱们的 ETL 流程 带来了危险，因为如果数据违反了规定，并且没有思考到这种状况，那么 ETL 流程将进行并中断加载过程。这与只更改数据或数据含意的 软业务规定 不同。因而，咱们须要区别对待 硬业务规定 和软业务规定。咱们通过拆散这两种规定类型来实现这一点。

在典型的 数据仓库 零碎中，例如前一章形容的两层和三层 数仓架构 中，软业务规定 也在 数据仓库 加载过程的晚期利用。这是因为 数据仓库层 要么是 Kimball 格调的星型模式，要么是第三范式规范的 数据仓库 。为了将数据适应到这样的构造中，加载的 ETL 数据流必须转换数据以满足用户的业务需要。这种转换对软业务规定的实现有影响，包含所需的对传入数据的聚合或合并。业务规定的晚期实现改良了规定的通用应用程序，并通常进步了的数据品质。
然而，随着对这些业务规定的更改，问题就呈现了。在 数据仓库 的架构中实现业务规定的工夫越早，它在数据仓库的高层中所具备的依赖关系就越多。

思考以下来自航空业的示例: 飞机注册号码是飞机的标准化的字母和数字组合的标识符，在全世界范畴内应用。每个号码都有一个前缀，表明飞机注册的国家。例如, 注册号“D-EBUT”
的国家是来自德国 (因为前缀“D”)。来自德国的数字实际上是“智能钥匙”，这个概念在第 4 章“数据仓库建模”中有更具体的形容。以注册为“D-EBUT”的德国飞机为例，第二个字符表明该飞机是单引擎飞机。在美国，前缀“N”很常见。直到 1948 年 12 月 31 日，还有第二个前缀(号码中的第二个字母) 用来示意飞机的类别(见下表)。

例如，注册号为 N -X-211 的飞机注册在试验类。
然而，美国联邦航空局决定停止使用第二个前缀，当初公布的数字介于 3 (NIA)和 6 个字符 (N9999) 之间，没有任何其余含意，除了第一个前缀示意起源国家。事实上，第二个字母总是 1 到 9 之间的数字。

当初，考虑一下这个更改对 数据仓库 的影响。如果类别曾经从 (当初具备历史意义的)n 数字中提取进去，那么在将数据从 集结区 加载到规范化 数据仓库 之后，第二个字母将用于标识飞机类别，其中类别很可能是 aircraft 表中的一列。然而，一旦号码扭转，注册号码的第二个地位就只有 1 到 9 之间的数字，这是没有意义的。为了更新 业务规定，最简略的办法是引入一个新的 category(“未知类别”)，如果注册号码中的第二个字母是 1 到 9，就将这些飞机映射到该类别。然而，因为没有新的飞机类别，除了未知，齐全删除这一类别是正当的(除非你专一于剖析历史上的飞机)。如果思考到明天的飞机同时依照操作代码、适航等级和其余类别进行分类，那么就更有意义了，因而上表中的分类曾经过期。

因而，业务规定中的此更改须要用多个新类别替换类别。在规范化 数据仓库 中，咱们必须删除旧的类别列，并向飞机增加多个类别援用。在更改将数据从 集结区 加载到规范化 数据仓库 的 ETL 作业之后，咱们能够更改构建在 数据仓库层 之上的 信息集市 ，并批改 数据集市ETL 流程。当应用这种办法时，会呈现几个问题

• 咱们如何解决规范化数据仓库中的历史数据?
• 咱们在哪里保留历史数据以供当前剖析(如果业务在当前需要的话)?
• 咱们如何剖析历史飞机和古代飞机(商业决策)?
• 在同一个信息集市中会有多个维度(历史类和古代类)，还是会有多个历史类和古代类飞机的信息集市?
• 古代飞机历史类别的默认值是什么?
• 现代飞机的古代类别的默认值是什么?

在 DataVault2.0 架构中，飞机的分类将被加载到一个名为“卫星 ”的表中，该表蕴含描述性数据(咱们将在后续文章具体解释 DataVault2.0 建模的根本实体)。当源零碎中的逻辑发生变化时——在本例中是 N -Number 的格局——旧的卫星就敞开了(没有新数据加载到以后卫星中)。所有新数据都被加载到一个新的卫星上，该卫星的构造通过了更新，合乎源数据的构造。在此过程中，没有实现 业务规定 。加载了所有的数据。因为当初有两张表，一个保留历史数据，另一个保留新数据，在将数据从DataVault 加载到 信息集市 时很容易实现 业务规定 。建设一个用于剖析历史上的老飞机的 信息集市 和另一个用于剖析 1948 年当前建造的古代飞机的 信息集市 也很容易。

然而，当思考到须要调整以适应新的分类的 ETL 工作时，拆散硬规定和软规定的真正劣势就变得清晰起来。加载历史数据的 ETL 作业放弃不变，并筹备加载更多的历史数据 (例如，从新加载归档的立体文件)。新数据被加载到另一个指标(第二个 卫星 )，因而是“历史”ETL 流程的批改正本。除了 信息集市(及其加载流程)，其余都不须要更改。

集结区

集结区 用于将批处理数据加载到 数据仓库 中。它的次要目标是从源零碎中尽可能快地提取源数据，以缩小业务零碎的工作负载。此外，集结区 容许对源数据执行 SQL 语句，这可能不适用于间接拜访立体文件(如 CSV 文件或 Excel 表)。

留神，集结区 不蕴含历史数据，这与前一章中形容的传统架构不同。取而代之的是，集结区 中只存在下一个必须加载到 数据仓库层 的批处理。然而，这条规定有一个例外: 如果有多个批处理须要加载，例如，当周末产生谬误时，必须将过来几天的数据加载到 数据仓库 中，在 集结区 可能有多个批处理。在 集结区 中没有历史记录的次要目标是不用解决一直变动的数据结构。思考这样一个事实: 源表可能会随着工夫的推移而扭转。如果 集结区 保留了历史数据，这里必须有用于将加载过程定义到 数据仓库 的逻辑。这个逻辑 (实际上是业务规定) 将随着工夫的推移变得越来越简单。正如咱们在前一节中所形容的，Data Vault 2.0 架构 的指标是将简单的业务规定挪动到最终用户，以确保疾速适应更改。

集结区 由复制源系统结构的表组成。这包含源的所有表和列，包含主键。然而，用于确保源零碎中援用完整性的索引和外键是不反复的。此外，所有列都是可为空的，因为咱们心愿容许数据仓库从源零碎加载原始数据，包含可能存在于源零碎中的坏数据 (特地是立体文件)。利用于传入数据的惟一业务规定是所谓的 硬业务规定。通常的做法是保留源零碎中用于命名表和列的原始名称; 然而，这不是必须的。

除了源零碎中的列之外，集结区中的每个表还包含:

• 一个序列号
• 一个工夫戳
• 记录源
• 所有业务键及其组合的散列键计算

这些字段是将数据加载到下一层 ( 数据仓库层 ) 所需的 元数据信息 。 序列号 标识源零碎中数据的程序。当源零碎中的程序对于将数据加载到 数据仓库 很重要时，咱们能够应用它，例如 RSS 新闻订阅或不蕴含工夫戳信息的事务性数据。工夫戳是记录达到 数据仓库 时的日期和工夫。记录源示意产生数据记录的源零碎，散列键用于标识目标。后续文章将提供这些字段的详细描述。

数据仓库层

DataVault2.0 架构 中的第二层是 数据仓库，它的目标是保留所有历史的、时变的数据。

数据仓库 保留原始数据，除 硬业务规定 外，其余任何业务规定都不会批改这些数据。因而，数据是以源零碎提供的粒度存储的。数据是非易失的，源零碎中的每个更改都由数据仓库构造来追踪。来自多个源零碎的数据，以及一个源零碎中的数据，通过 业务键 进行集成，在后续文章进行探讨。与 信息集市 中面向主题的信息不同，数据仓库 中的数据是面向性能的。

在批量加载中，数据从 集结区 提供，而在实时加载中，数据间接从企业服务总线 (ESB) 或微服务等 SOA 架构中提供到 数据仓库 。然而，如前所述， 实时数据仓库 超出了本文的范畴。咱们将在后续文章介绍业务数据的加载，它也间接利用于 数据仓库 ，并遵循相似的模式。
数据仓库层 是在 DataVault2.0 建模技术 的根底上建模的，该技术将在后续文章探讨。
这一层通常称为 原始 DataVault 层 ，因为它蕴含应用Data Vault 2.0 模型 建模的原始数据。

信息集市层

与传统的 数据仓库 不同，DataVault2.0 架构 的数据仓库层 不是由终端用户间接拜访的。通常，终端用户只拜访以终端用户最喜爱的形式提供数据的 信息集市 。因为 企业数据仓库 的指标是向其最终用户提供有价值的信息，所以咱们在这一层应用术语 信息 而不是数据。信息集市 中的信息是面向主题的，能够是聚合表单、立体文件或宽表，也能够是为报告做筹备的数据，还能够是高度索引的、冗余的和品质荡涤后的数据。它通常遵循星型模式，并造成关系型报告和多维 OLAP 立方体的根底。因为最终用户只拜访 信息集市层 ，在 数据仓库 层中领有 DataVault 模型 对最终用户来说是通明的。如果最终用户须要第三范式的 规范化数据仓库 ，咱们也能够提供满足这些需要的 信息集市 。前端工具还可能将信息回写到 企业数据仓库层。

信息集市 的其余示例包含 异样信息集市 和元数据集市 。它们别离是 数据仓库 的异样信息中心 和元数据中心 。作为这些数据的核心也是与规范 信息集市 不同的非凡集市:
与 信息集市 不同的是，异样信息集市 和元数据集市 不能从原始数据仓库或任何其余数据源重建。然而, 他们是类似的, 因为最终用户, 如管理员, 应用这些集市剖析加载过程中的异样或 数据仓库 中的其余问题, 或 数据仓库 的元数据 存储, 它的起源和转化主导了 信息集市 中出现的信息。后续文章《加载维度信息集市 》，提供了对于如何从DataVault2.0 构造 的数据仓库 中加载 维度 OLAP 立方体 的信息集市 的宽泛探讨

指标库

在 Data Vault 2.0 架构中，后面的三个层（集结区 、 数据仓库层 和信息集市 ）是必须的（除了本书中笼罩到的实时案例）， 指标库 （本节中介绍）， 业务仓库 （见下节）和 作业仓库（见第下下节）是 Data Vault 2.0 架构的可选扩大。

指标库 用于捕捉和记录运行时信息，包含运行历史、过程指标和技术指标，如 CPU 负载、RAM 应用、磁盘 IO 指标和网络吞吐量。与数据仓库相似，指标库是依照 Data Vault 2.0 建模 技术建模的。数据是原始格局，零碎或过程驱动，不可审计，它可能包含 技术元数据 和 ETL 作业的技术指标或数据仓库的环境。在 指标库 的顶部，指标集市 向用户提供了 性能指标信息。

后续文章《元数据管理》包含一个示例，阐明如何在 ETL 加载数据期间跟踪审计信息，并将数据存储到指标库中。

业务仓库

因为利用于 Data Vault 2.0 构造 的一些业务规定往往会变得复杂，能够抉择将 业务仓库 构造增加到 数据仓库层 。 业务仓库 是一个基于 Data Vault 设计准则 的稠密建模数据仓库 ，但蕴含业务规定更改的数据。换句话说，业务仓库中的数据曾经被业务规定更改。在大多数状况下，业务仓库是 原始 Data Vault和 信息集市 之间的中间层，能够简化最终用户构造的创立
图 2.4 显示了 Data Vault 企业数据仓库之上的业务仓库。

图 2.4 Data Vault 企业数据仓库之上的业务仓库

这是因为 业务仓库 是在加载 信息集市 之前预加载的，从而简化了它们的加载过程。简单的业务规定 (软规定) 从原始数据仓库 和业务仓库 实体中获取数据。

尽管 业务仓库 是依照 Data Vault 2.0 设计 准则建模的，但它对源数据的可审核性没有雷同的要求。相同，能够在任何时候从 原始 Data Vault删除并从新生成 业务仓库 。 业务仓库 为输出数据到信息集市的开发人员提供 原始 Data Vault中的数据的整合视图。

与 指标库 相似，业务仓库 不存储在独自的层中。相同，它存储为 数据仓库层 中的 Data Vault 模型 的扩大。后续文章《加载维度信息集市》，展现了如何应用 业务仓库 来输出数据到 信息集市。

作业仓库

作业仓库 是DataVault的扩大，业务零碎能够间接拜访 DataVault(图 2.5)。有时，这样的零碎须要从 企业数据仓库 中检索数据，或者须要将数据写回 数据仓库 。示例包含主数据管理(MDM) 零碎，如微软的主数据服务 (MDS) 或元数据管理系统 。在这两种状况下，间接在数据仓库层上操作而不是应用 信息集市 或集结区 都具备劣势。其余状况包含间接剖析存储在 数据仓库层 中的原始数据的数据挖掘应用程序。通常，每当接口应用程序须要实时反对时，无论是读还是写，间接拜访作业仓库都是最佳抉择。

图 2.5 作业仓库

因而，集成来自面向服务架构 (SOA) 或企业服务总线 (ESB) 的实时数据将间接写入 作业仓库 。尽管咱们在本节的结尾将 作业仓库 定义为 DataVault 的扩大，但应用程序的接口间接从现有的 DataVault 构造中实现。因而，DataVault 构造 在某种程度上成为作业仓库构造。

托管式自助服务 BI

数据仓库 我的项目的一个常见教训是，在 数据仓库 打算获得初步胜利之后，业务对性能的需要越来越大。然而，因为 IT 团队资源无限，不是企业的所有申请都能够满足。在许多状况下，所申请的性能只对无限数量的业务用户重要或实用，或者对业务的影响很小。然而，它对那些要求它的人来说很重要。然而为了应用他们本人的 IT 资源，IT 必须对他们的申请进行优先级排序。因为提早或齐全抛弃新性能的影响。这种对业务申请的低响应减少了业务用户的不舒适感。
一种称为自助服务 BI 的办法容许终端用户齐全绕过它，因为它没有响应。在这种办法中，业务用户能够本人解决从业务零碎获取数据、集成和整合原始数据的整个过程。这种不足 IT 参加的自助服务办法存在许多问题:

• 间接拜访源零碎 : 最终用户不应该间接拜访源零碎中的数据。这将公开潜在公有的原始数据，并且容许拜访该数据可能会绕过平安拜访，而平安拜访是在访问控制列表 (ACL) 中实现的。
• 未集成的原始数据 : 当从多个源零碎获取数据时，业务用户将单独解决原始数据集成。如果手动执行(例如在 Excel 中)，这将成为一项乏味且容易出错的工作。
• 低数据品质 : 来自源零碎的数据常常存在数据品质方面的问题。在应用数据进行剖析之前，须要对其进行荡涤。同样，如果没有正确的工具，这可能成为最终用户的累赘。
• 未整合的原始数据: 为了剖析来自多个源零碎的数据，数据通常须要整合。如果没有这种整合，业务剖析的后果将毫无意义。
• 非标准化业务规定: 因为最终用户在自助服务 BI 中只解决原始数据，所以他们必须实现将原始数据转换为有意义的信息的所有业务规定。然而谁来查看这个实现是否与组织的其余局部统一呢?

在许多状况下，最终用户——即便他们是把握 SQL、MDX 和其余技术的高级用户——也没有可用的正确工具来解决这些工作。相同，很多工作都是手工实现的，而且很容易出错。

然而依据咱们的教训，齐全阻止这样的高级用户从源零碎获取数据、筹备数据并最终将数据报告给下层治理是不可能的。组织须要的是 IT 敏捷性和数据管理之间的斗争，容许高级用户以可用的品质疾速获取他们须要的数据。

为了克服这些问题，Data Vault 2.0规范容许有教训或高级业务用户对 数据仓库 的原始数据执行本人的数据分析工作。实际上，反对 Data Vault 2.0 的 IT 欢送业务用户应用 企业数据仓库 ( 原始 Data Vault 或业务仓库 ) 中可用的 数据 ，并应用本人的工具将 数据 转换为有意义的 信息。这是因为 IT 无奈在给定的工夫范畴内交付所申请的性能。

取而代之的是，IT 从业务零碎或其余数据源获取原始数据，并应用原始数据库的业务键将其集成。IT 还可能创立 业务仓库 构造，以提供模型各局部的对立视图或预计算要害性能指标(KPIs)，以确保这些计算之间的一致性。

而后，业务用户应用原始数据 (来自 原始 DataVault)和业务数据 (来自 业务仓库 ) 应用专用工具创立本地 信息集市 。这些工具从 企业数据仓库 检索数据，利用一组用户定义的业务规定，并将输入显示给最终用户。

这种办法称为 托管式自助服务 BI，是 Data Vault 2.0 规范 的一部分。在这种办法中，它倒退为一个服务组织，为那些高级用户在他们须要的工夫范畴内提供他们想要的数据。数据由业务键集成，如果最终用户须要，还能够进行整合和质量检查。整合和质量检查产生在进入 业务仓库 的过程中，正如咱们将在本书前面阐明的那样。业务仓库 还实现了一些最重要的业务规定。高级用户能够间接拜访 原始 Data Vault和 业务仓库，并且能够依据手头的工作抉择原始数据或通过整合、荡涤的数据。实际上，这两种类型的数据都曾经集成了，因而业务用户还能够将合并后的数据与来自特定源零碎的原始数据连接起来。

后续文章将演示将原始数据加载到 原始 Data Vault是非常容易的，包含应用 业务键 进行集成。事实上，它能够在短的冲刺迭代中实现，咱们将在《Data Vault 2.0 方法论 》中解释。当用户要求更多数据，而 数据仓库 中无奈提供这些数据时，能够将这些数据获取并集成到 原始 Data Vault中，以便为高级用户提供 托管式自助服务 BI工作。

其余个性

Data Vault 2.0 架构 提供了额定的性能，以反对实时 (RT) 和近实时 (NRT) 环境、非结构化数据和 NoSQL 环境。然而，对这些选项的形容超出了本博客的范畴。

本文介绍了 Data Vault 2.0 架构，它是Data Vault 2.0 架构 规范中的一项根本内容。接下来的文章将着重于我的项目方法论和 Data Vault 建模，这是Data Vault 2.0 架构 规范的另外两个根本支柱。