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日，还有第二个前缀(号码中的第二个字母)用来表示飞机的类别(见下表)。

字母	美国1948年12月的飞机分类前缀描述
C	商业和私人飞机
G	滑翔机
R	受限制的（如竞技飞机）
X	实验

例如，注册号为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架构标准的另外两个基本支柱。