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架构规范的另外两个根本支柱。