企业数据仓库环境

企业数据仓库 (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 的我的项目，那么老本甚至可能暗藏在另一个我的项目或流动的估算中。然而，当一段时间过来，数据仓库 解决的数据量减少时，存储老本 也会减少。在某些状况下，这是以指数模式产生的，而且不只是包含增加新磁盘的老本。如果 数据仓库 减少了更多的数据，则须要更快的网络连接来拜访数据; 须要更多的计算能力来解决数据; 更好 (和更低廉) 的硬盘控制器须要拜访磁盘。
然而，一直增长的 存储老本 并不是 数据仓库 的次要老本因素。老本因素包含:

• 贮存老本
• 低质量老本
• 蹩脚打算的代价
• 更改业务需要的老本(参见下一节)

低质量和蹩脚打算的老本是一个更大的因素: 即便我的项目团队有对 数据仓库 进行了三思而行的布局并确保了品质，它对一直变动的业务需要大刀阔斧，除了预见性的布局。
当业务需要位于 数据仓库 的上游时，这一点尤其显著。正如后面介绍的，这不仅会对性能产生负面影响，而且还会进步保护的老本。业务需要不应该嵌入到 数据仓库 加载周期中，而应该向下挪动到 数据集市 加载中——更靠近业务用户。这容许团队变得麻利，管制保护和开发成本 (通过主动生成)，并对一直变动的业务需要提供更好、更疾速的响应。换句话说，它也管制了 数据集市 的生产成本。

团队的 敏捷性 与数据处理流程内建的复杂性成正比。通过将简单的业务需要拆散成各自的组件，架构的多个加载局部变得流线型; 到能够理论生成大多数实现的境地。这种拆散的机制在响应业务需要更改时提供了极其的 敏捷性。

其余业务要求

明天的商业环境的特点是迅速变动的条件和不确定性。因而，业务需要常常变动是很常见的。数据仓库 开发人员试图通过认真的布局和预期的设计来避免对 数据仓库 的更改。这种办法通常遵循传统的瀑布式软件开发办法。在这些办法中，通常有四个阶段：

1. 设置数据仓库的需要。
2. 数据仓库的架构布局与设计。
3. 开发数据仓库。
4. 测试数据仓库。

相比之下，麻利软件开发办法 被设计成通过应用客户反馈来迭代收敛解决方案的形式来改良软件。为了反对这一需要，数据仓库 必须适配灵便和适应更改。对现有 数据仓库 构造的更改不应使现有数据或应用程序生效。麻利办法 的一个次要长处是可能对业务变动做出快速反应，咱们将在《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施行侧重于自动化和生成模式，以节省时间，缩小谬误并进步 数据仓库 团队的生产率。