企业数据仓库环境

企业数据仓库(EDW)是从普通数据仓库演变而来的，它们已在[上篇文章]中进行了描述。
企业数据仓库试图表示组织的所有业务数据及其业务规则，而不是将重点放在单个主题域进行分析。然后以业务用户可以使用所有所需主题域的方式显示仓库中的数据。接下来的部分将介绍企业数据仓库的常见业务需求。

可访问

对EDW的访问，要求最终用户能够通过建议的客户端工作站连接到数据仓库。连接必须是即时的、按需的和高性能的。然而，对用户来说，访问比可用性重要得多，尤其是对业务用户来说:应该容易理解系统提供的信息的含义，包括对数据仓库内容的正确标签。它还包括
使用顺手的应用去分析、呈现和使用数据仓库提供的信息的可用性。

多主题域

由于企业的每个职责或部门对要分析的数据都有不同的需求，因此企业数据仓库必须提供多个主题域，以满足各个用户的需求。每个主题域都包含与用户相关的数据。数据是按需求使用的，数据仓库提供了预期的真相版本，这意味着它遵循需求的信息定义。
为了实现这个目标，主题域所需的所有原始数据都被集成、清洗并加载到企业数据仓库中。然后，它用于构建为特定主题域开发的数据集市。这种数据集市也称为依赖数据集市，因为它们依赖于数据仓库作为数据的来源。相反，独立的数据集市直接从业务系统中获取数据。由于这种方法需要与构建数据仓库相同的清洗和集成工作，因此从中央数据仓库加载数据通常更简单。

真相的单一版本

整合组织中所有可用的业务数据的目的是为其数据提供一个单一的真相版本。在一个传统的组织中，可以使用许多业务系统，甚至普通的数据仓库。虽然其中一些系统是集成的，但在业务数据库中存储的数据往往不一致。这可能是由于同步延迟或错误、业务数据的手动输入或不同的原始数据源。其结果是在组织中存在不同版本的真相，例如关于客户的收货地址。在将数据加载到企业数据仓库时，由业务部门决定如何清洗数据，这通常需要选出哪些是主要系统或数据源。在某些情况下，基于业务规则的自动选择和验证就足够了;在其他情况下，需要手动选择来实现验证过的单一版本的真相。
企业数据仓库的一致性、单一版本的真实性是数据仓库用户所要求达到的重要目标。然而，不同的部门往往要求一个独特的版本的真相，因为都有着“什么是真相”不同的定义。这就是为什么企业数据仓库提供了多个主题域，如前一节所述。每个主题域在所需的上下文中为其单个用户提供所需的信息。

事实的单一版本

“事实的单一版本”的目标是提供组织信息的一个集成的、清洗的版本，即给定上下文中的聚合和浓缩数据，而“事实的单一版本”的目标是在任何时候都提供所有数据。在这种情况下，EDW应该存储并潜在地提供对组织任务至关重要的所有原始数据(参见下一节)。这本书的主要作者是数据仓库行业中最早倡导这一理念的人之一，特别是由于遵循这一理念的考虑。最终，它导致了DataVault的发明，是建立DataVault2.0模型的关键原则，并在原始DataVault中实现了。
在审计和遵从性要求下，事实的单一版本也很重要，这在审计与合规节中有介绍。我们将在本书后面了解到，基于DataVault的数据仓库提供两种版本:真相的单一版本和事实的单一版本，即部门各视图的版本和企业视图的版本。

至关重要的资产

由于数据仓库作为战略业务决策基础的重要性，中央数据仓库已成为一种至关重要的企业资产。此外，数据仓库不仅为业务决策提供聚合数据;它们还将丰富的信息反馈给运营系统，以支持交易处理，创建个性化报价，并呈现促销活动的情况。
要成为至关重要的企业资产，还要求数据仓库的数据质量必须达到一定的水平。如果源系统没有提供所需质量的原始数据，那么数据仓库的工作就是修复数据质量问题，并通过数据清洗、数据集成或任何其他有用的方法来提高数据质量。

可扩展性

可扩展性，是指数据仓库架构能够适应更高的数据量和必须满足的用户不断增加的需求。构建架构的方式应该支持添加更多的数据，不仅是更多的数据量，而且是更复杂的数据。如果数据量的增长超过了硬件的能力，那么应该可以跨多台机器部署数据仓库，并充分利用增加硬件的方式来增强数据仓库的能力。这个概念被称为大规模并行处理(MPP)。如果架构是不可扩展的，那么在达到一定的构建级别时，增加更多的硬件没有用的或作用甚微的。
数据仓库中的另一个问题是，由于存在依赖关系，更改数据仓库通常很复杂。虽然构建数据仓库的第一个版本很容易，但第二个版本需要更多的时间。这是因为数据仓库的架构在构建时并没有考虑到这些变化。
数据仓库架构节讨论几种数据仓库架构。我们将在后续文章中“可扩展的数据仓库构架”中提出一种替代架构。该架构的优势在于它的可扩展性，可以吸收对数据模型的更改，以及其他优势。

大数据

大数据不仅仅是“大量数据”或“我能处理的更多数据”。我们将大数据定义为具有三个特征的数据:数据量大、快速和多样性。
第一个特征是数据量大。一些人所说的“大数据”通常意味着这些数据比他所习惯处理的要多得多。然而，这种说法是非常主观的。对于一个人或一个公司来说，大数据可能是GB级的原始数据，但对于装载TB级甚至PB级数据的人来说，这是相当小的数据。实时加载数据有不同的需求，因此与夜间批量加载数据或接近实时加载数据相比，大数据的定义也不同(近实时意味着来自业务系统的数据在通常15分钟的时间范围内可以在数据集市中获得)。大数据的定义也取决于数据仓库可用的硬件。

大数据的第二个特征是快速。这不仅仅是因为源系统中有大量可用的静态数据。加载这些数据可能会成为一项复杂的任务。然而，存储在业务系统中的数据经常变化。源系统中可用的数据越多，对其应用的更改就越多。因此，典型的大数据项目必须处理大量的更新、数据更改或添加到源系统的新数据。

第三个特点是多样性。大数据通常没有相同的结构。相反，大数据的数据结构可能会随着时间的推移而改变，或者，如“非结构化”数据集(如文本、多媒体)，根本没有普通的结构:非结构化数据集使用其他类型的结构，如语言结构，而不是使用列和行作为关系表。从计算的角度来看，这些结构被认为是非结构化的，因为其结构不像关系表中那样明显。在其他情况下，有来自许多不同的小数据源的数据，这些数据的总和是具有多种数据结构的“大数据”。

由于现在可用的数据越来越多，数据仓库结构不仅必须能够扩展(指容量)，还应该能够处理传入数据的速度和多样性。在其他情况下，数据总是在运动中:我们的意思是，它目前正在以比实际数据资产更小的包进行处理或传输。
以TCP/IP网络上的数据传输为例:需要传输的数据通常被分割成较小的块并存储在IP包中，然后在网络上传输。这给大数据带来了其他问题，因为数据在网络设备中流入和流出。为了分析数据，必须收集、组合和聚合数据——在某些情况下是实时的。这提高了大数据的架构和规划的标准，并导致了性能问题，下一节将讨论这些问题。

性能问题

数据仓库的另一个问题是系统的性能。在将新一批源数据加载到数据仓库时，性能非常重要，因为加载过程包括在可用的时间范围内清洗数据并将数据集成到现有数据中。通常，这个时间限制在没有用户使用系统的时候，通常是在夜间。另一个性能的原因是数据仓库的可用性，这取决于系统对分析性用户查询的响应时间。

数据仓库系统的性能受到数据库系统在磁盘上存储数据的方式的影响:数据存储在具有固定数据大小的页面中。例如，SQLServer 为每个页面定位8 KB的磁盘空间。每个页面保存特定表的一些记录，表越宽，表的列越多，一个页面能容纳的行就越少。为了访问给定行中给定列的内容，必须读取该数据块所在的整个页面。由于数据仓库中经常使用的分析查询通常聚合信息，因此必须读取许多页才能访问一行的内容。汇总的一个典型例子是对给定区域的销售额进行汇总;这可以是发票总数这一栏的总和。
如果表中有许多列，则必须读取执行聚合时不需要的大量数据。因此，数据仓库的一个目标是减少列的宽度，以提高性能。类似的概念也适用于将新数据加载到数据仓库中。
提高数据仓库系统性能的其他方法包括:(1)并行化方法加载模式和(2)MPP设置中的数据分布在多个节点上，比如在NoSQL数据库中。第一个选项的目标是一次加载多个表，而不是一个接一个地加载表。第二个选项通过将数据分布到多个节点来提高性能。
这两种方法对DataVault2.0在此类环境中的成功至关重要，并且影响了相比于初始版本(DataVault1.0)的DataVault建模的更改。

复杂性

由于许多业务需求，数据仓库系统常常存在复杂性问题。技术复杂性问题来自三个方面:来源问题、转换问题和目标问题。

来源问题是数据提取系统产生的问题。以下是问题的典型例子。

源系统的可用性有限
跨系统连接、筛选或聚合。
源数据中的索引问题。
缺少源键，甚至缺少整个源数据集。
错误的或超出范围的源数据。
源系统数据结构的复杂性。
源系统的CPU、RAM和磁盘负载。
事务记录锁。

在转换数据以满足目标的期望时，会出现转换问题。通常，以下操作直接在转换中执行:

清洗。
数据质量管理和数据对齐。
连接、整合、聚合和过滤。
序列赋值常常导致缺乏并行性。
数据类型修正和错误处理。
排序问题，包括需要大型缓存、频繁的磁盘溢出和巨大的键。
直接在源数据转换中应用业务规则。
一个数据流中的多个目标或源。
单一转换瓶颈。

问题的最后一个区域位于的目标。当将数据加载到目标时，会出现这些问题，包括:

缺乏数据库调优
导致死锁的索引更新。
在一个数据流中执行插入、更新和删除语句。这迫使这些语句按照特定的顺序执行，从而阻碍了并行化。
一次装载多个目标
广泛的目标，如1.2.8性能问题中讨论的
对目标分配缺乏控制

产生这些问题的一个常见原因是，许多数据仓库系统试图在一个加载周期中实现大量的工作，而不是将工作分开。其结果是许多加载过程变得过于复杂，从而降低了总体性能并增加了维护成本。最后，它还会影响整个团队的敏捷性和性能，因为他们必须解决这些问题，而不是实现新特性。

审计与合规

数据仓库的一个典型需求是能够提供关于存储在系统中的数据的来源和提取时间的信息。这一需求有各种各样的原因:

数据仓库开发人员试图追踪潜在的数据异常和理解数据流转过程。
数据的价值取决于数据源或数据的年龄。此信息可以在业务规则中使用。
合规性要求对作为业务决策基础的信息的数据流和流程进行跟踪。必须清楚数据来自何处以及何时加载到数据仓库。
然而，Inmon提出了在数据仓库中不添加可审计性的原因：
审计要求数据被加载到数据仓库中，如果没有这些要求，数据仓库是不会加载的。
可能会更改要加载到数据仓库中的数据的时间。例如，如果数据仓库将是唯一提供审计功能的地方，它可能需要将所有更改加载到业务数据中，而不是许多数据仓库项目中典型的每日批量加载。
当需要审计功能时，备份和恢复需求会发生巨大的改变。
审计数据源迫使数据仓库以最低粒度加载源数据。

我们的意见是，审计应该仅限于回答以下问题:

这个特定的数据资产是从哪里提取的?
什么时候提取数据?
提取数据的过程是怎样的?
这些数据在哪里使用?

数据仓库不应该回答业务系统如何获取数据的问题。这个答案通常只能由源系统本身提供。只有在某些情况下，数据仓库才会接收到关于用户和记录创建或修改时间的信息。如果数据仓库可以使用此数据，则我们倾向于仅为信息目的存储此信息。
为了支持数据仓库的可审计性，我们在数据中添加元信息来跟踪数据源和加载日期和时间。然而，回答数据在何处使用的问题要复杂得多，因为数据集市经常聚合数据以创建供业务用户使用的信息。为了让数据仓库维护者能够回答这些问题，数据仓库流程应该简单易懂。

成本

数据仓库的另一个挑战是保持成本尽可能低，因为一般来说，我认为这是管理的一个成本因素。数据仓库的成本受到许多因素的影响，从存储成本到低质量和规划不良的成本。另一个成本因素是业务需求会随时间变化，这就要求数据仓库适应这些变化的需求。
在数据仓库中，存储成本常常是一个未计入的成本因素。在数据仓库项目的开始阶段，成本通常很低。如果数据仓库是从一个影子IT项目开始的，即由业务驱动、由外部IT顾问实施、绕过内部IT的项目，那么成本甚至可能隐藏在另一个项目或活动的预算中。然而，当一段时间过去，数据仓库处理的数据量增加时，存储成本也会增加。在某些情况下，这是以指数形式发生的，而且不只是包括添加新磁盘的成本。如果数据仓库增加了更多的数据，则需要更快的网络连接来访问数据;需要更多的计算能力来处理数据;更好(和更昂贵)的硬盘控制器需要访问磁盘。
然而，不断增长的存储成本并不是数据仓库的主要成本因素。成本因素包括:

储存成本
低质量成本
糟糕计划的代价
更改业务需求的成本(参见下一节)

低质量和糟糕计划的成本是一个更大的因素:即使项目团队有对数据仓库进行了深思熟虑的规划并确保了质量，它对不断变化的业务需求束手无策，除了预见性的规划。
当业务需求位于数据仓库的上游时，这一点尤其明显。正如前面介绍的，这不仅会对性能产生负面影响，而且还会提高维护的成本。业务需求不应该嵌入到数据仓库加载周期中，而应该向下移动到数据集市加载中——更接近业务用户。这允许团队变得敏捷，控制维护和开发成本(通过自动生成)，并对不断变化的业务需求提供更好、更快速的响应。换句话说，它也控制了数据集市的生产成本。

团队的敏捷性与数据处理流程内建的复杂性成正比。通过将复杂的业务需求分离成各自的组件，架构的多个加载部分变得流线型;到可以实际生成大多数实现的地步。这种分离的机制在响应业务需求更改时提供了极端的敏捷性。

其他业务要求

今天的商业环境的特点是迅速变化的条件和不确定性。因此，业务需求经常变化是很常见的。数据仓库开发人员试图通过仔细的规划和预期的设计来防止对数据仓库的更改。这种方法通常遵循传统的瀑布式软件开发方法。在这些方法中，通常有四个阶段：

设置数据仓库的需求。
数据仓库的架构规划与设计。
开发数据仓库。
测试数据仓库。

相比之下，敏捷软件开发方法被设计成通过使用客户反馈来迭代收敛解决方案的方式来改进软件。为了支持这一需求，数据仓库必须适配灵活和适应更改。对现有数据仓库结构的更改不应使现有数据或应用程序失效。敏捷方法的一个主要优点是能够对业务变化做出快速反应，我们将在《Data Vault 2.0方法论》中学习。

为了支持数据仓库工程师和数据仓库业务用户，需要一套工具来查询、分析和呈现信息。例如报表工具、查询分析器、OLAP(在线分析处理)浏览器、数据挖掘工具等。也包括SQLServer等的这些开箱即用的工具。

另一个业务需求是项目团队应对团队成员自然波动的能力。数据仓库中一个重要的成功因素是在团队中保留数据仓库成员的知识和技能，而不管关键成员的退休或退出。对此的解决方案包括一个文档化良好的数据仓库系统和一个易于理解的设计。另一个解决方案是使用来自微软等主要供应商的商业智能(BI)解决方案。这在业界是众所周知的，并得到了其他供应商和咨询公司的支持。

这些是Data Vault 2.0的主要组成部分，以及其中包含的创新。DV2.0通过定义关于建模，实现，方法和架构的标准和最佳实践，解决了大数据、NoSQL、性能、团队敏捷性、复杂性和许多其他问题。

Data Vault 2.0简介

Data Vault实际上代表了一个商业智能系统。Data Vault系统的真实名称是:通用基础仓库架构。该系统包括与设计、实现和管理数据仓库相关的许多方面。对Data Vault 1.0的一些历史研究表明，Data Vault 1.0高度关注数据仓库建模，也就是说，致力于构建原始企业数据仓库的物理和逻辑数据模型。另一方面，Data Vault 2.0进行了扩展，并包含了许多必要的组件，这些组件是数据仓库和商业智能取得成功的关键。这些组件包括:

Data Vault 2.0建模——为性能和可扩展性对模型进行了更改
Data Vault 2.0方法论——遵循Scrum和敏捷最佳实践
Data Vaul 2.0架构——包括NoSQL系统和大数据系统
Data Vault 2.0实施——基于模式，自动化，生成CMMI 5

这些组件中的每一个都在企业数据仓库项目的整体成功中扮演着关键角色。这些组件与业界已知的、经过时间考验的最佳实践相结合从CMMI(能力成熟度模型集成)，六西格玛，TQM(全面质量管理)和PMP(项目管理专业)。Data Vault 2.0建模现在包括了一些改变，允许模型与NoSQL和大数据系统进行无缝交互。Data Vault 2.0方法论侧重于2到3周的冲刺周期，并针对可重复数据仓库的要求进行调整和优化。Data Vault2.0架构包括NoSQL、实时反馈和用于非结构化数据处理和大数据集成的大数据系统。Data Vault 2.0实施侧重于自动化和生成模式，以节省时间，减少错误并提高数据仓库团队的生产率。