【企业数据仓库】企业数据仓库的消亡

数据仓库和商业智能在许多（如果不是的话）致力于将数据转化为有意义的商业价值的见解的大型组织中发挥着重要作用。数据仓库是从各种来源收集和管理数据以提供有意义的业务见解的过程。商业智能包括用于提供这些见解的战略和技术。这两个领域都可以被视为数据管理的一部分。它们与其他数据管理领域紧密交织在一起，在很大程度上依赖于数据集成。

简要背景

数据仓库在90年代开始流行，最初是一种收集数据并将其整合为统一形式的常见做法，目的是为组织创造一个一致的真相版本。这种一致的真相成为公司内部商业决策的重要来源。

这种决策得到了另一种趋势——商业智能的支持。Gartner定义的商业智能是“一个总括性术语，包括应用程序、基础架构和工具，以及能够访问和分析信息以改进和优化决策和性能的最佳实践”。商业智能最初是以一种很好的方式生成数据和简单的报告，但在后期引入了自助服务，具有更高级的功能，如内存处理和可预测功能。

许多企业组织严重依赖数据仓库。其中许多是在过去十年中开发的。它们被认为是一种关键资产，用于许多日常流程，并在公司内的数据消耗和分发中发挥着重要作用。在这篇文章中，我将解释一些流行的方法和共同特征，并揭示企业数据仓库的概念，这在规模上是不同的。

警告：在我们继续的过程中，我需要给你一个警告。我坚信，企业数据仓库（EDW）很快就会灭绝。而不是数据仓库本身的基本概念，因为数据统一的必要性，将大量数据带入特定环境的必要性始终存在。但即将消亡的是使用数据仓库进行企业范围的数据集成、消费和分发。我会在这篇文章中解释原因。

数据仓库

许多公司仍在大力投资数据仓库。然而，使用数据仓库体系结构的大小和规模可能存在显著差异。在我告诉你我对这个体系结构的看法之前，让我们退一步，从头开始。

什么是数据仓库？

什么是数据仓库？数据仓库的核心概念是由IBM研究人员Barry Devlin和Paul Murphy于1988年提出的。随着计算机系统变得更加复杂和数据量的增加，需要一个体系结构模型来支持来自操作系统的数据流，以支持决策环境。几年后，Bill Inmon出版了一本书，并对数据仓库的用途给出了更具体的定义：“数据仓库是一种面向主题的、集成的、时变的和非易失性的数据集合，用于支持管理层的决策过程。”

随着数据仓库越来越受欢迎，具有不同定义的模型的变体开始出现，我喜欢将数据仓库定义为“将来自不同来源的（历史）数据协调到中央存储库并进行管理的系统，其主要目标是支持决策过程”。从这句话中，我们可以提取出一些重要的特征。从单词central可以得出结论，在数据仓库中，数据被聚集在一起并集中存储。在许多情况下，这确实是真的，但一些技术趋势允许以其他方式开发数据仓库，例如数据虚拟化。从和谐这个词我们可以得出数据是集成的、统一的和一致的。这意味着需要额外的组件来收集、清理、修复、转换和存储数据。通过声明不同的来源，我们明确了数字是复数，因此数据仓库现在或将来不会只用于从单个来源收集数据。

Bill Inmon曾说过“数据仓库概念的一大吸引力在于存在单一版本的真相”。这个单一版本的真相意味着使用了一个单一的词汇表，所有用户都必须同意数据仓库中使用的所有数据的含义和定义。我们稍后将更详细地介绍这一词汇方面。

这听起来很全面，但为什么你首先想要一个数据仓库？有什么好处？为了更好地理解数据仓库为什么有用，我们需要退后一步，解释一些关键驱动因素，并首先更仔细地了解事务和分析系统是如何工作的。

OLTP（在线事务处理）

传统上，应用程序和数据库的空间被划分为两个世界。许多应用程序开始时是事务性的或可操作的，就像计算机世界开始时需要处理事务和存储记录一样。这些系统使流程更加高效，因为它们能够取代传统的卡片目录和许多手动流程。银行系统、机票预订系统、订单管理系统、客户系统、电信系统、医疗保健系统、购物系统等。这些应用程序因其关键的操作作用而被称为在线交易处理（OLTP）系统。

对于OLTP系统来说，重要的是必须保证一致性和稳定性。想象一下，你经营着一家大型地区电信公司，而电信系统却瘫痪了。影响可能是巨大的。客户无法再拨打电话、接听电话、接收短信等。如果系统停机时间过长，业务模式将受到影响。客户失去信任而离开。因此，OLTP系统是为数据完整性、系统稳定性和可用性而设计的。绝大多数符合ACID。

我们可以从OLTP系统中观察到，（操作）工作负载通常是可以预测的。我们知道OLTP系统是如何使用的，以及预期的典型负载是什么。查询相对简单，检索到的数据量相对较低：读取记录、更新记录、删除记录等。底层物理数据模型是基于这些可预测的查询设计的。OLTP系统中的表通常是标准化的。理想情况下，每个属性只存储一次。

这种规范化的设计有一些缺点：操作系统的设计并不是为了提供领域或业务中正在发生的事情的可代表的全面视图。对于复杂的问题，从高度规范化的数据模型中提取数据往往很困难，而且需要大量的性能。复杂的问题需要更多的数据和数据组合。编写这样的查询需要将许多表连接或分组在一起。这些类型的查询通常相当占用性能，因此执行过多的查询会带来达到性能限制的风险。如果是这样，系统就会变得不可预测，这是我们最不希望看到OLTP系统发生的事情，因为我们需要提供信任。

具有高完整性和高可用性性能的结果是OLTP系统是昂贵的。它们通常无法保留大量数据，因此数据生命周期管理对于保持它们的健康和适用性非常重要。通常，未使用的数据会被删除或移动到辅助位置。从这个辅助位置数据，如果它再次变得相关，总是可以放回原处。

OLTP系统是传统数据库划分方式的一部分。另一部分是OLAP系统，将在下一节中讨论。

OLAP（在线分析处理）

业务用户希望通过检查大型且更复杂的数据集合来分析数据，以便做出业务决策。由于OLTP系统价格昂贵，并且可以实现不同的目的，因此通常的最佳实践总是将数据取出，并将其转移到另一个环境中。其他环境（不同的系统和数据库）将用于在线分析处理（OLAP）：复杂的分析处理。由于离线分析通常不太关键，因此完整性和可用性要求可能不那么严格。考虑到这一点，您可以说OLAP系统通常比OLTP系统便宜。

在OLTP系统中，数据是为了完整性和冗余性而存储和优化的，但在OLAP中，我们会针对分析性能进行优化。由于我们主要进行重复读取，几乎不进行任何写入，因此通常会优化以更密集地读取数据。可以对数据进行复制，以促进各种分析场景的不同读取模式。OLAP数据库中的表通常不是高度规范化的，而是经过预处理和非规范化的结构：表是扁平的、稀疏的，并且包含更多的冗余副本。重复存储数据。这听起来无效，但当数据在逻辑上分组并物理存储在一起时，系统更容易处理数据并更快地交付结果。由于OLAP系统价格较低，我们可以使用更多的数据存储。

注意：有些系统结合了OLTP和OLAP。这些系统被称为混合事务/分析处理，这是Gartner创建的一个术语。尽管这些系统在外部看起来像是新兴的体系结构，但在内部，通常仍然有两个数据库。一个数据库是为许多具有高更新率的小型事务而设计的。另一个（内存中）数据库处理分析工作负载的复杂查询。这种将命令与查询分离的方法与CQRS非常相似。

OLAP系统通常还用于通过存储来自OLTP系统的未使用或不太频繁使用的数据来促进数据生命周期管理。这样做有两个原因。第一个原因是历史数据很有价值，因为为了进行分析，我们经常会回顾过去。性能是第二个原因。OLTP系统将其数据复制到OLAP系统后，通过删除冗余副本进行清理。这种维护活动使OLTP系统更有效，因为如果表包含的数据更少，查找和查询将运行得更快。

在OLAP系统中，来自多个OLTP系统的数据通常被汇集在一起，因为业务用户或数据分析师通常希望对数据进行组合。这需要一种协调或统一的形式，因为系统使用不同的上下文，具有不同的数据结构。

什么是操作数据存储？业务数据存储（ODS）通常用于业务分析和报告。ODS具有OLTP和OLAP系统的一些特性。“操作”一词使ODS更接近OLTP系统，因为它们的目的是深入了解操作性能和活动。它们主要继承OLTP系统的上下文。

OLAP系统的特点是ODS旨在消除分析工作负载，而分析工作负载是由专门的、预测性较差的分析和报告引起的。另一个特征是ODS通常比OLTP系统保留更多的历史数据。还有一个特点是ODS可以集成来自其他系统的小部分数据。这意味着在设计消耗臭氧层物质时也可能涉及到一体化或协调方面。

然而，一般来说，ODS更接近于它们所处的主要OLTP系统的设计。表格结构通常是相似的。因此，ODS与数据仓库不同，因为它们通常只使用来自一个OLTP系统的数据，而不像数据仓库那样容纳来自多个来源的数据。

多源系统的协调是通往数据仓库的一座很好的桥梁，因为它们还考虑到了历史需求，将数据整合成一种协调的形式，并促进了分析活动。因此，数据仓库也可以归类为OLAP。

 

数据仓库是如何工作的？

现在我们知道数据仓库将来自多个来源的数据统一为一个集成的数据模型（事实的单一版本），是时候更深入一点了。在接下来的部分中，我想讨论构建和操作数据仓库的一些常见特征和样式。最流行的款式是由行业领袖Bill Inmon和Ralph Kimball开发的。

Inmon风格

Bill Inmon的观点是，任何可能有用的数据都应该存储在一个单一的通用数据模型中，该模型将是企业的“单一真相来源”。这个真相来源使用了一个整数和有效的存储模型，通常是3NF结构。从这个单一的真相来源，为特定的项目、用例或部门做出选择（子集）。这个选择的子集被称为数据集市，它针对用例的读取性能进行了优化。

Kimball风格

Ralph Kimball的观点是，数据仓库必须是维度数据的集合或集合，这些数据是来自源系统的事务数据的副本。由于数据仓库用于各种用例，Kimball有“一致维度”的概念，这是不同消费者共享和使用的关键维度。

在接下来的部分中，我们将更仔细地研究这两种样式，以及设计和构建数据仓库时始终需要的一些通用组件。我们将从暂存层开始，然后讨论数据仓库的其余部分。

暂存区

要设计数据仓库，需要一些额外的组件。在Inmon和Kimball方法中，必须首先提取数据并将其存储（暂存）在中间存储区域中，然后才能进行处理。这种让数据首先“着陆”的环境被称为暂存区，如下图所示。

暂存区总是位于数据源和数据目标之间，这些数据源和目标通常是数据仓库。它们用于解耦系统，并在提取、转换和加载（ETL）过程中发挥重要作用。暂存区可以通过不同的方式实现，不同于关系数据库和文件存储。此外，数据捕获方式的实现也可能有所不同：推送数据、提取数据或使用CDC。数据通常以原始操作格式提供，尽管在此模型也可能存在变化。我稍后再谈这个。

暂存区域通常也用于保留历史副本。这对于重新处理场景非常有用，在数据仓库损坏并且需要从更长的时间段重建的情况下。较旧数据传递（历史副本）的数量可能因暂存区域而异。我见过一些用例，其中所有的数据交付，包括更正，都必须保存数年以供审计。在其他用例中，我看到在成功处理或经过一段固定时间后，暂存区域被清空（非持久性）。清理可以节省存储空间和成本。

暂存区在数据质量领域也发挥着重要作用。在开始将数据摄入数据仓库之前，建议首先验证所有数据。如果任何源丢失或数据无效，则可以暂时停止或暂停处理。可以要求来源再次提交或对数据进行更正。一旦满足所有验收标准，就可以真正开始处理数据并将其引入数据仓库的集成层。

集成层

在成功检查所有数据并满足暂存层的所有验收标准后，数据就可以集成到集成层中了。在这里，所有经过清理、更正、丰富和转换的数据都使用统一的上下文存储在一个集成的通用模型中。它是统一的，这意味着统一已经应用于格式、类型、命名、结构和关系。此外，历史数据预计将在该层中，尽管与暂存区的不同之处在于数据已转换，不再是原始数据。

集成层以及数据的存储和结构化方式也是Inmon和Kimball样式不同的地方。

Inmon风格

在Inmon风格中，所有数据首先进入（中心）集成层，该集成层具有标准化的关系模型。这意味着数据已针对冗余进行了优化。您可以争辩说，这一层与我们在OLTP中讨论的数据模型相似，您是对的。它代表了交易系统，但以一种协调的方式，这意味着统一应用于格式、字段名称、数据类型、关系等。这一实现需要进行大规模的前期数据建模，以调整所有不同的源系统结构，并将其转换为一个协调统一的数据模型。从阶段到集成层的步骤通常会导致特定而复杂的ETL逻辑。

Inmon样式还引入了数据集市。在数据存储在集成层中之后，将为消费者创建额外的层。这些（表示）层被称为数据集市或维度数据集市。它们通常只包含集成层数据的一个子集。它们也特定于一个用例、一组或一组用户。数据集市中的数据通常是按维度结构组织的，因为它已经针对读取性能进行了优化。数据集市通常使用多维数据集来实现，尽管它们也可以使用关系数据库（使用星形和雪花模式）来实现。数据集市的附加层有一个好处：数据集市与集成层解耦。如果谨慎地对集成层进行更改，则不应影响数据集市，从而影响数据消费者。

Inmon的风格有几个缺点。第一个缺点是开发时间通常很长。设计一个整数和规范化模型需要时间，因为所有不同的源系统都需要仔细映射。完整性和一致性是重要的驱动因素。随着源的大小和数量开始增加，具有依赖关系的关系数量也会大幅增加。这可能会导致设计中的级联效应：无尽的父子复杂性或结构。

另一个缺点是，如果必须将新数据添加到数据集市，那么数据总是必须首先添加到集成层。由于开发需要时间，并且必须小心地对集成层进行更改，因此需要新数据的用户必须等待（很长时间）。下面的列表总结了Inmon风格的优点和缺点。

好处

• 由于集成层的（高度）规范化模型，数据冗余度非常低。
• 数据集市与集成层解耦。
• 一致的设计，非常适合历史数据。
• 大多数工程师都熟悉3NF规范化原理。

不利因素

• 开发时间更长。需要复杂的ETL逻辑来将数据映射到集成层的重规范化模型。
• 数据摄取的更高耦合性引入了依赖性，要求同时摄取所有源。这降低了摄入的并行性和灵活性。
• 新关系的发展。由于所有表的引用完整性，因此存在大量ETL负载依赖关系。
• 如果来源消失或发生重大变化，引用完整性将成为一个问题。

Inmon样式与Kimball样式的区别主要在于集成层。

Kimball风格

在Kimball样式中，集成层中的数据与事务系统中存储数据的方式不同。当数据被复制到集成层时，它已经针对读取性能进行了优化。数据更加扁平、稀疏，因此与Inmon风格的数据集市结构有相似之处。与Inmon相比，这里的区别在于集成层是维度表的集合，这些维度表是数据集市的组成部分。数据集市只是不同表与一些附加表的逻辑区分或选择，以将所有内容链接在一起。在这种方法中，数据仓库是所有单个数据集市的组合。这样做的好处是可以更好地理解这些维度表，因为绝大多数的父子结构都减少了。

Kimball风格的一个重要方面是数据在逻辑上被分组为所谓的事实和维度。事实是定量的数字：销售数字、金额、计数等。维度代表业务实体，因此客户、产品、员工、合同等。通过将事实和维度联系在一起，创建了一个星形模式。从概念上讲，这些与数据集市相同，不同之处在于它们位于同一集成层，并共享相同的底层数据库技术。Kimball模型的好处是，这种风格比Inmon具有更高的短期灵活性。通常，用户不需要等待数月或数年才能开始消费。

尽管数据是有组织的主题区域，用户更容易理解，但Kimball风格也有一些缺点。由于每个数据集市都是为特定的用户组创建的，因此通常需要许多额外的表来创建更具体的星形模式。由于用户将有更多相互冲突的需求，因此将需要更多的“辅助”表。

在Kimball中，更多耦合的可能性也更高：用户可以开始重用其他用例或用户的集成逻辑或辅助表。因此，随着规模的增长和用户数量的增加，复杂性也在增长。因此，即使是结构的微小变化也会对所有用户产生很大影响。

另一个含义是，在加载数据时，在加载维度之前出现的事务（事实）可能会出现问题。最后，由于表上应用了高级别的非规范化，更新和删除可能会占用大量性能。在下表中，我列出了Kimball风格的所有高级优点和缺点。

好处

• 更适合于多维分析。
• 按照业务主题领域进行组织，这使得非it用户更容易理解。
• 与Inmon相比，开发时间更快，因为只有一个ETL过程可以将数据加载到最终的数据模型中。
• 在链接聚合点方面具有更大的灵活性。

不利因素

• 表示层没有解耦。重用或共享辅助表会导致更紧密的耦合。
• 在维度表之前加载事务（事实）时存在引用完整性问题。
• 由于非规范化，更新和删除的成本更高。如果数据更新不正确，完整性也可能成为问题。
• 更大的数据量（与Inmon相比）。

基于这两种方式的优缺点，工程师们开始试验并结合不同的方法。一个例子可以是核心数据仓库模型，它是基于Inmon的，但扩展了基于Kimball的维度表。Data Vault技术是对这些替代方法的补充。

Data Vault样式

Data Vault最初由Dan Linstedt创建，在北欧特别流行。Linstedt将数据仓库定义为一组面向细节的、历史跟踪的、唯一链接的规范化表，这些表支持一个或多个业务功能领域。此定义中没有尝试将数据保管库用于清理或集成的数据。没有做出任何努力来协调源系统之间的数据模型差异。相反，数据保管库依赖于下游体系结构组件来显示可用于分析的数据。

数据保险库通过集线器、卫星和链接表解决了Inmon和Kimball的灵活性问题。通过分离的表，数据存储更加解耦，允许并行数据加载，并在执行更改时具有更大的灵活性。关系可以很容易地被丢弃并在运行中重新创建，新系统可以在没有任何中断的情况下集成到现有模型中。

这些灵活性的改进也有一个缺点：数据保险库本身并不直接适用于特定的查询和分析，因为查询所有的集线器、卫星和链路，将它们连接在一起，是性能密集型的。在大多数情况下，它需要一个额外的表示层或数据集市层。

Data Vault中的表数明显高于3NF建模。它要求需要更多的ETL作业来确保不同表之间的隔离和引用完整性。这增加了复杂性，使工程师更难理解数据仓库是如何设计的。像Wherescape这样的公司可以通过元数据生成ETL作业来帮助解决这些问题。

最后一个方面是没有严格或正式的标准。Data vault在概念上描述得很好，但人们使用的是实现变体。Dan Linstedt、Kent Graziano和Hans Hultgren都是该领域的专家，他们都主张数据库的不同性，这会带来在大型项目中应用冲突风格的风险。

下面的列表包含data vault的高级优点和缺点。

好处

• 更能适应变化。更高的灵活性
• 适合实时使用。解耦实现并行处理
• 可以使用更灵活和增量的开发方法

不利因素

• 使用Data Vault建模技术时需要大量连接。这可能是一个真正的性能打击。需要额外的“表示层”或“数据集市层”。
• 由于最佳实践和方法各不相同，需要更有经验的工程师和就指导方针达成强有力的一致意见
• 需要更多的ETL作业和表。这可能会增加复杂性并减少概述。混合方法也会让工程师更有创造力，从长远来看，这会带来额外的复杂性和不一致性

数据仓库因其集成层和复杂的数据模型而区别于其他应用程序。它们消耗、组合、协调和集成数据。这些集成技术需要数据建模专业知识，这通常与设计和开发常规应用程序不同。

获取数据

如果不从不同来源提取数据，就无法创建数据仓库。在前面的部分中，我们了解了暂存区的作用，以便于数据以不同的格式汇集在一起。我们没有讨论的是这些数据源的格式或结构。

一种常见的传递数据的格式是使用源系统的原始（相同）格式。通常会提供完整的数据集合，因此最终得到的是平面文件形式的所有表的完整原始提取。这种交付风格的一个缺点是与源系统的内部数据结构高度耦合，因为它们是相同的表示。如果源系统更改其结构，则处理数据可能不再有效。

向数据仓库交付数据的另一种方法是商定某种形式的抽象，以降低耦合风险。结构可以约定得更简单，可以有固定的格式。这些更改至少消除了每当源系统更改其结构时进程中断的情况。

一种更极端的抽象形式是要求源系统使其数据交付符合集成层的格式。此方法中来自源系统的文件必须以与数据仓库完全相同的格式交付。我认为这种抽象形式也是高度耦合的，因为当集成层发生变化时，它要求所有源同时发生变化。

注意：大多数商业供应商（Oracle、SAP、Siebel等）的操作系统都使用高度专业化和规范化的数据模型，这些模型会随着每个发布周期的变化而变化。这些数据模型很难解释。人们知道如何解释这些数据模型并将其映射到数据仓库中，从而过上了体面的生活。

为了使数据集成更容易，通常会选择标准化的格式。逗号分隔值（CSV）和Parquet是最受欢迎的两种选择，因为大多数数据库和ETL工具都可以使用这种格式。XML和JSON也可以使用，但这些格式通常会产生更多的开销，因为其中包含了大量元数据。

使用完整提取的另一种选择是根据数据更改或增量请求或提取数据。这种方法只提供更改后的数据。一种流行的设计模式是使用变更数据捕获（CDC），它得到了不同供应商的良好支持，可以使用各种机制：基于时间戳、基于版本、基于指标等等。

ETL功能

收集完所有数据后，下一步是将数据集成到集成层中。数据需要被清理、映射并转换到数据仓库的统一数据模型中。这需要ETL工具，并且可以通过几种方法来实现。

最常见的方法是使用商业ETL工具从暂存区提取数据，转换并加载到集成层。Informatica、SQL Server Integration Services、Ab Initio、Infosphere Information Server、Talend、Pentaho和Oracle Data Integrator是许多大型企业的热门选择。这些工具具有广泛的功能、大量的数据库连接器、调试和测试功能，通常具有直观的外观。他们可以将数据提取到自己的本地环境中，也可以将工作委托给目标数据库。这些商用工具的一个常见缺点是紧密耦合。一旦您为数据仓库选择了ETL供应商，您就与该供应商结下了不解之缘。

ETL工具的另一种选择是自己构建一个ETL框架。我见过很多公司，他们从元数据存储库中生成ETL代码（Java、Oracle的PL/SQL、Teradata的SQL等）。将所有集成逻辑编码并存储在源代码存储库（如git）中也并不罕见。一些公司试图实现商业供应商所提供的功能，包括直观的基于web的前端、调试功能、数据跟踪和跟踪、沿袭等。自己构建ETL工具的好处是松耦合。只要您遵守常用的开放标准ANSI SQL，您就可以随时取代数据仓库的数据库技术。“自己动手”的场景需要高技能的工程师进行维护和开发。随着时间的推移，工程师可能会离职。具有ETL知识的商业供应商的资源通常更容易吸引。

数据仓库生态系统中的ETL处理通常不允许有很多变化。通常使用单个产品或框架。由于复杂性，ETL工具也很可能被安排在固定的时间窗口中运行。由于性能原因，处理时间通常很长。生态系统是静态的另一个原因是，许多企业害怕对ETL进行重大更改：代码通常很大，非常复杂，因为它是经过多年开发而演变而来的。

数据虚拟化

在介绍了这篇博文之后，我提到了一些技术趋势改变了数据仓库的构建方式。其中一项技术是数据虚拟化：数据保持不变，源可以作为一个数据库进行访问和查看，而无需以批处理为导向来物理提取和复制数据。详细地说，有一个数据虚拟化层，它将自己呈现为一个集成层，通过虚拟地和运行时提取、转换和集成数据来缓存数据。这项技术附带了一个应用程序组件：一个虚拟化引擎，它处理所有传入的查询，确定最佳缓存策略，知道如何访问不同的数据存储技术，知道如何集成数据等等。在引擎盖下，有很多元数据用于构建抽象。我在下面的图片中看到了这种技术。

尽管这种技术看起来很有吸引力，但它也有潜在的缺点：

取出过多的数据可能会导致OLTP系统故障或变得不稳定。数据虚拟化通过“缓存”数据来解决这一风险，这意味着一个副本被保存到虚拟化引擎中，但这种模式并不能完全消除风险。当路由过多的查询时，仍然可能会损害OLTP系统。或者，你可以加快这些速度，但这可能非常昂贵，因为操作系统比分析系统相对更昂贵。

数据虚拟化层导致了更紧密的耦合。如果源系统发生更改，也需要立即更改数据虚拟化层。视图或其他层可能会有所帮助，但任何更改仍然需要源系统所有者和维护数据虚拟化层的工程师之间的交叉协调。

消费者直接受到数据质量的影响，数据虚拟化不允许您创建新数据，如果您想进行更正，则需要创建新数据。

数据虚拟化依赖于网络。在具有大量网络和跳数（通过额外的网络设备）的高度分布式环境中，延迟预计会增加。此外，还有耦合，因此如果网络出现故障，集成层就会断开。

数据虚拟化不是对数据生命周期管理的补充。它无法将不相关的数据移出底层系统。它要求所有历史数据都保留在OLTP系统中，从长远来看，这使得数据虚拟化成为一种昂贵的解决方案。或者，您可以将数据移到辅助位置，然后在虚拟化层中再次组合，但这种方法会增加复杂性，因为您需要开发和维护几个抽象层。

数据虚拟化受到底层支持技术的限制，该技术通常是关系数据库管理系统。尽管数据虚拟化可以读取许多数据库系统，但如果需要，它通常不允许创建文档、键值、列式和图形数据库端点。

对于密集和可重复的查询，数据虚拟化使用更多的计算能力，因为在查询数据时会实时进行转换。缓存技术可以减少这种情况，但在对数据进行物理转换和存储后使用数据时，计算能力总是更具可比性。

注意：一些数据库供应商提供数据库（虚拟）查询层，也称为数据虚拟化层。该层对数据库进行抽象并优化数据以获得更好的读取性能。另一个抽象的原因是为了更好的安全性而拦截查询。亚马逊雅典娜就是一个例子。

尽管存在这些缺点，但数据虚拟化可以帮助迁移场景。使数据库虚拟化并成为新功能的一部分可以减轻痛苦。数据虚拟化也是实时的，因此与ETL工具相比，对于相对少量的数据来说速度更快，ETL工具需要在消费发生之前处理和持久化所有数据。

商业智能

我们还没有过多详细讨论的最后一个功能是商业智能（BI）工具，它用于生成见解并呈现结果，以实现平稳的商业决策。随着数据仓库随着越来越多的数据开始出现，它们变得相当流行。这些年来，他们还扩大了自己的能力。最初的版本只包括简单的报告和仪表板功能，但后来的版本提供了强大的可视化功能，支持自助服务、智能缓存技术和预测分析。因此，商业智能并不排除（预测性和规范性）高级分析：这两个学科都是互补的，可以相互加强。

现代商业智能工具在可使用的来源数量方面也相当灵活。传统上，BI工具与数据仓库的耦合更紧密，但以后的几代工具能够从多个更高种类的源系统中提取和组合数据。BI工具也可以只提取更改，并将数据保存更长时间到所谓的立方体中。这些多维数据集与数据虚拟化有一些相似之处，因为它们还抽象了底层源，可以直接提取数据或缓存数据。

OLAP、ROLAP、MOLAP和HOLAP之间有什么区别？多维数据集也称为OLAP多维数据集，是对数据进行预处理和预汇总的集合，可大大缩短查询时间。OLAP（在线分析处理）是指使数据易于访问以进行分析决策的专用系统或工具。OLAP多维数据集是由元数据定义的逻辑结构。多维表达式（MDX）是一种流行的基于元数据的查询语言，支持您查询这些OLAP多维数据集。供应商提供各种OLAP产品，您可以将其分为三类：

• ROLAP（关系在线分析处理）：ROLAP产品和关系数据库紧密合作，支持OLAP。星型模式结构通常用于扩展和调整底层关系数据库结构，以将其自身呈现为OLAP服务器。
• MOLAP（多维在线分析处理）：MOLAP产品通过将数据放入立方体结构中来提供多维数据分析。此模型中的数据经过高度优化，以最大限度地提高查询性能。
• HOLAP（混合在线分析处理）：HOLAP产品将MOLAP和ROLAP结合在一起，对大多数数据使用关系数据库，对最密集的数据（通常是数据的一小部分）使用单独的多维数据库。

现代BI工具还可以通过允许您在其“存储层”中集成（ETL）和持久化数据，而不是在数据仓库中集成和存储数据，使数据与它们保持紧密联系。我个人的建议是，当数据需要重用时，只将数据存储在数据仓库中。对于短期和一次性的集成练习，更建议在业务智能解决方案内部进行集成。

您已经了解了很多关于数据仓库如何工作、集成层的组织以及数据是如何获取和使用的。在下一节中，我们将讨论数据湖，有些人称之为第二代数据存储库。

Data Lake

随着数据量和对更快见解的需求的增长，工程师们开始研究其他概念。数据湖开始成为访问原始数据和更大数据量的替代方案。通过按原样提供数据，无需首先构建数据，任何消费者都可以决定如何使用数据，以及如何转换和集成数据。

数据湖和数据仓库都被认为是集中的（整体的）数据存储库，但它们不同，因为数据湖在数据转换、清理和结构化之前存储数据。因此，模式通常是在读取数据时确定的，而不是在固定结构中加载数据。它们还支持多种格式：结构化、半结构化和非结构化。

数据仓库和数据湖之间更大的区别在于所使用的底层技术。数据仓库通常使用关系数据库系统进行设计，而数据湖通常使用分布式数据库或NoSQL系统进行设计。Hadoop是一个受欢迎的选择，因为它运行在商品硬件上，因此具有成本效益。它还具有高度的可扩展性、开源和模块化，具有多种数据库类型和分析框架。

使用公共云服务也是构建数据湖的热门选择。最近，在容器基础设施之上的分布式和完全管理的云规模数据库简化了大规模管理集中式数据存储库的任务，同时增加了弹性和成本优势。

如上图所示，许多数据湖从原始源系统收集纯的、未经修改的原始数据。转储原始数据（确切的数据副本）速度很快，使数据分析师和科学家能够快速访问。然而，原始数据的复杂性在于，用例总是需要重新处理数据。必须解决数据质量问题，需要进行聚合，并需要与其他数据进行富集，以将数据带入新的环境。这引入了大量可重复的工作，也是数据湖通常与数据仓库相结合的原因。

在这种数据湖组合中，数据仓库充当净化和协调数据的高质量存储库，而数据湖充当分析环境，保存各种原始数据以便于分析，如数据发现、数据科学和处理非结构化数据。当组合在一起时，结果或见解会流回数据仓库，而数据湖是为原始数据构建并（手动）操作的。

通过了解什么是数据湖，我们可以进入下一节，在这一节中，我想讨论数据仓库和数据湖在组织中的应用规模。

企业数据仓库和数据湖的陷阱

随着人们开始看到数据仓库的好处，计划和范围变得越来越大。公司指示人们去培训设施，准备开始建造一些大型建筑。业务用户被要求将他们的所有需求交付给中央数据仓库工程团队。启动了提供企业数据仓库（EDW）的大型项目。EDW是一个中央数据仓库，其目标是创建单一版本的真相，并为整个组织的所有报告和数据分析需求提供服务。

尽管下图是企业数据仓库的高级表示，但您可以看到许多集成点、集成步骤和依赖关系的复杂性。一旦企业数据仓库开始增长，其复杂性就会呈指数级增长。在你知道之前，你最终会陷入一种不舒服的境地，变化被视为瓶颈。

在接下来的部分中，我想讨论一些广泛的观察结果和故障模式。在我们继续之前，我想请你深呼吸，把你的偏见放在一边。将大量数据纳入特定环境的数据统一需求始终存在，但我们必须考虑的是我们希望应用这一学科的规模。这真的是在任何用户或应用程序使用所有数据之前集中处理所有数据的最佳方式吗？

单一规范模型和不必要的模式翻译

EDW要求数据提供者和数据消费者就单个（企业）规范数据模型达成一致。在我看来，这一单一版本的真相是公司无法扩大规模的最大问题。在大型生态系统中，存在许多不同的环境。构建一个能满足每个人需求的集成层是一个巨大的挑战，因为它需要每个人都同意。公司越大，你看到的冲突就越多，达成一致和保持一致所需的时间就越长。

我对规模协调的第二大问题是价值的丧失。工程师在建立数据仓库时需要做出解释。例如，合同的开始日期是什么？有很多可能的答案。开始日期可以是合同的合法签署日期，也可以是系统的预订数据。开始日期也可以是法律部门给出的批准日期。它可以是开始使用的日期，也可以是第一次付款的开始日期。这些定义的含义在不同部门之间存在差异，并且在系统中具体实现的可能性相对较高。我们要么最终制造了许多变化，要么接受了差异和不一致。我们添加的数据越多，定义中出现的冲突和不一致越多，协调就越困难。很有可能你最终会得到一个对每个人都毫无意义的统一环境。

另一个问题是，数据和上下文在集成过程中被丢弃。一个域中非常特定的值范围被映射到具有较少详细信息的范围，以支持另一个域，聚合由详细信息组成，或者省略字段。对于机器学习等高级分析来说，忽略这些细节是一个大问题。分析模型，如机器学习，可以更精确地处理详细的数据。

附加转换步骤

当大规模使用数据仓库时，第二个问题是需要额外的转换步骤。数据总是必须首先集成到数据仓库中，然后才能使用。这一步骤意味着需要大量的等待时间，因为在数据仓库中，几乎所有组件之间都存在继承耦合。表具有对其他表的引用，表具有对ETL作业的依赖关系。一个表中的更改通常会强制其他表和ETL作业中的更改产生连锁反应。这种复杂性需要大量的工作和增加等待时间，这开始让人们富有创造力。

什么是一个大泥球？一个“大泥团”是一个结构随意、杂乱、邋遢、胶带和打包线的意大利面条代码丛林。这是一个普及的术语，最早由布莱恩·富特和约瑟夫·约德创造。一个巨大的泥球描述了一个系统体系结构，它是单片的，难以理解，难以维护，并且由于其许多依赖性而紧密耦合。下图显示了说明这一点的依赖关系图。每一行表示两个软件组件之间的关系。

数据仓库及其集成层、无数的表、关系、脚本、ETL作业和调度流，往往以混乱的依赖关系网告终。这些复杂性使得你经常会在一段时间后陷入他们所说的一个大泥团。

为了节省时间，工程师可能会建议绕过集成层，将数据从源系统直接映射到数据集市。另一种可能建议在两个不同的、已经存在的数据集市之上构建一个数据集市，因为更改集成层需要太多时间。这种技术债务（未来返工）将在以后造成问题。建筑变得更加复杂，人们对为了按时交付而创造的所有创造力和快捷方式都失去了洞察力。

引爆点

数据仓库的特点是其来源和消费者数量呈指数级复杂度。添加的源越多，进行更改就越困难。这一原则同样适用于数据消费者入口点的数量。如果您有许多数据集市位于集成层的顶部，那么对集成层进行更改可能会产生很大的影响，因为它的更改会对数据集市产生影响，而数据集市需要与所有数据消费者密切协调。

我还看到了一个“临界点”：一旦你到达一定数量的源和数据集市，敏捷性就会降至几乎为零。整合大量的资源需要巨大的协调和统一。几个月的发布周期对于复杂的数据仓库系统来说并不是例外。

无休止的利益相关者讨论

由于变更的紧密耦合和漫长的发布周期，利益相关者排队等候，必须就优先级达成一致。我看到工程师和业务用户之间进行了长时间的讨论，以就数据仓库中新数据的优先级或集成层的更改达成一致。这些讨论不会增加任何直接的商业价值。

苛刻的消费者

单片平台的灵活性问题引入了消费者不耐烦的习惯。向EDW和数据湖添加数据可能需要很长时间，因此用户开始要求消耗所有数据。访问所有数据可以消除等待时间过长的风险。我见过数据集市，其中几乎包含来自集成层的所有数据。所有数据集市的存储空间总和成为集成层所需的所有存储的倍数。这并不能使体系结构具有成本效益。

我还看到业务和IT用户同时访问数据集市和集成层。用户在数据集市和集成层之上构建视图，以快速满足他们的需求。这些视图再次暴露给其他用户。最终，可以看到无尽的层叠效应。用户在不知道数据的确切来源的情况下提取数据。

消费者通常没有设定任何要求。提供数据是因为业务用户有要求，否则将进行升级。如果没有达到时间线，通常会创建点对点接口。

协调压力

大规模运营数据仓库和数据湖的另一个问题是，需要工程师和IT用户协调数据交付。源可能会更改，接口可能会断开，这需要升级以修复问题。我也见过工程师自己处理问题的情况。例如，修复暂存层中的数据，以便将数据正确加载到数据仓库中。这些修复是永久性的，随着时间的推移，在数据处理开始之前，必须应用数百个额外的脚本。这些脚本不是值得信赖的ETL过程的一部分，也无法追溯。预计这将对血统和透明度产生重大影响。

数据质量和治理

数据治理通常也是一个问题，因为谁拥有数据仓库中的数据？如果源系统出现故障，数据被破坏，谁负责？当出现问题时，许多源系统工程师会指向数据仓库工程师，因为他们会将数据转换为系统所有者不知道的东西。反之亦然，数据仓库工程师指责源系统所有者提供了不正确的数据。

数据质量，所有权讨论的另一个要点。因为在数据被转换后，源系统所有者无法识别它。源系统所有者将糟糕的数据质量归咎于DWH工程师。在许多实现中，我看到数据仓库工程师负责数据质量。数据在加载到数据仓库之前或之后是固定的。特别是出于完整性的原因，正确设置表之间的关系非常重要。但事实是什么数据？用户开始将操作系统的数据和结果与数据仓库的数据进行比较。没有人知道真相到底是什么。操作系统和数据仓库之间的数据质量可能会出现严重差异，以至于没有人信任数据。

历史数据

历史数据的数据生命周期管理也是一个问题。因为EDW被视为真相的档案，操作系统在知道数据将保留在仓库中的情况下，会清理不相关的数据。如果运营系统需要根据自己的历史数据制作分析报告，会发生什么？在许多情况下，ODS可以满足这一需求，但我也看到一些公司为此目的使用EDW。这带来了一个有趣的模式。首先，业务数据被移动并转换为一个统一的模型。其次，相同的数据被传输并转换回（逆向工程）其原始上下文。

对于操作高级分析，通常需要历史数据。由于机会之窗往往转瞬即逝，预计它会很快出现。为此目的使用数据仓库通常是一个问题，因为它们通常要处理数小时的数据。

数据离开集中式平台

集中保存和管理数据是一个问题，因为组织的需求非常多样化，种类繁多：不同类型的解决方案、不同规模的团队、不同类型的知识、从防御到进攻的不同需求等等。由于激增，将所有东西放在一起是一个大问题。

EDW和数据湖与所选的底层解决方案或技术紧密相连，这意味着需要不同读取模式的消费者总是需要将数据导出到其他环境。随着供应商环境的变化和新型数据库的出现，这些单一平台变得越来越分散，总是被迫导出数据。这一趋势破坏了高效使用“单一中央存储库”的概念。因此，创建了点解决方案，并且数据仓库的底层硬件仅用于ETL处理和数据持久性。这是一种真正的浪费，因为数据仓库系统通常使用非常昂贵的硬件，并针对密集的查询进行了优化。

在数据被携带并被丰富之后，它通常也被进一步分发。这意味着数据消费者开始充当数据提供者。对于大规模环境中的数据消费者来说，这种情况可能会非常令人困惑，因为数据来源于哪里？一些消费者在没有意识到数据也被间接消费的情况下开始消费。这使得链条更长，因此更脆弱。

数据的进一步分布和扩散也带来了另一个问题。许多数据消费者不知道在哪里可以找到正确的数据，因为数据分布分散在整个组织中。操作系统是否适合查找？企业数据仓库？数据湖？或者可能是另一个数据消费者，他们可能已经对数据做了稍微更好的准备？用户对数据使用最快的路线，即距离最短、阻力最小的路线。EDW和数据湖变成了意大利面条式的建筑。其他人则称之为一个大泥球。不协调的更改、不受监管的增长和数据分发会损害整个企业数据体系结构。一致性、洞察力和最重要的灵活性都会丧失。

数据提供商没有洞察力

EDW和数据湖往往缺乏对特定消费和进一步分发的洞察力，尤其是当数据是在DWH生态系统中进行时。有了新的监管，如GDPR或CCPA，深入了解消费和分发是很重要的，因为你想解释哪些个人数据被谁消费以及用于什么目的。从逻辑上讲，数据的创建和来源应该从哪里开始，责任就从哪里开始。企业数据仓库的问题在于，数据提供者没有控制权，洞察力有限。无法控制数据消耗，也无法深入了解数据的进一步分布或数据的用途。

服务导向单独实施

在许多组织中，面向服务的API的创建是由一个独立的团队通过企业规范模型来处理的。这很奇怪，因为面向服务和EDW都使用和依赖相同的操作系统。一个单独的实现创建了两个不同版本的真相。这可能导致组织中的两个阵营和两个不同的词汇表，它们具有不同的数据含义。然而，最初的来源和它们的背景仍然是一样的。

痴迷的福音派与古典思想家

这似乎有点夸张，但企业数据仓库也有传道者。大多数数据计划一开始都有很多好的意图，但当时间不那么繁忙时，工程师们会继续绘制数据。整合数据不再是为了数据消耗，而只是为了数据本身。数据集成成了一种爱好。副作用是，各种数据仓库变得不必要的复杂，而且太难维护。其中一些传道者只是在讨论建模技术，而不是关注业务用户及其需求。业务用户感觉没有被完全理解，因此造成了缺乏信任。

另一个问题是企业数据仓库和数据湖团队如何与传统的软件工程师组装在一起。许多都具有数据库管理员（DBA）背景，用于设计整体结构。他们被困在过去，缺乏当今的现代技能，如数据操作、领域驱动设计、分布式和进化设计思维、数据版本控制、CI/CD和自动化测试经验等。因此，扩大和满足当今的现代需求是一个挑战。

参考模型

许多EDW通常建立在“预制”、现成的行业特定数据模型之上。例如，IBM、Teradata、Oracle和Microsoft为不同的行业提供这些数据模型。我对这些特定于行业的数据模型的问题是，它们是供应商的真相版本，而不是您的。其中许多模型过于详细和充满了假设。这些细节要求您只使用键来填充许多空表。因此，集成层变得非常大和复杂。

逻辑数据仓库

还有一种将EDW（数据湖）与数据虚拟化相结合的方法。它们被一个额外的虚拟抽象层“补充”。对底层集成复杂性进行了抽象，并创建了新的集成数据视图。这些可以跨越操作系统和许多其他应用程序。Gartner研究总监Henry Cook称这种设计模式为逻辑数据仓库。尽管不必向企业数据仓库添加新数据在短期内会带来灵活性方面的好处，但从长远来看，这将是一个灾难性的失败。

首先，通过抽象来替代复杂的集成逻辑是很诱人的，但所有潜在的复杂性仍然存在，包括所有的操作和技术开销。其次，它通过直接旁路将数据平台扩展到操作系统和特定数据源，同时直接重用数据平台的部分内容。正如您所了解到的，这些操作系统中的许多都没有针对密集的读取访问进行优化，也无法保留大量的历史数据。第三，与操作系统、数据平台和虚拟化产品都存在紧密耦合。对数据平台或操作系统的底层物理结构的更改，如果没有仔细协调，将立即破坏逻辑层。最后，所有的数据集成仍然是“漏斗式”的，因为数据虚拟化只是维护企业数据模型的另一个ETL工具。

尽管技术已经发生了变化，但将数据虚拟化与数据湖、企业数据仓库以及所有ETL相结合的整个概念才是问题的根源。数据被移动到一个整体，需要每个人都等待，所有的更改都要精确协调，而不允许用例进行优化，也不允许选择最适合用例需求的适合用途的技术。

从数据湖操作用例

许多公司都把所有的希望都放在了大数据生态系统上，它将来自各种源系统的原始和非结构化数据汇集在一起，可能还附带了EDW。分析用例预计将在湖中运行，综合视图预计将在EDW中着陆。这种方法带来了许多挑战：

• 被拉入数据湖的数据通常是原始的，很可能是所有不同应用程序的复杂表示。它可以包括（一万）个表，不可理解的值和封装在数据中的应用程序逻辑。此外，由于继承的结构是相同的副本，因此与源系统之间存在紧密耦合。应用程序更改风险会立即破坏数据湖环境。
• 数据湖中的分析模型通常在原始（非结构化）和协调数据上进行训练。数据科学家在技术上通过手工或在他们的数据科学项目中筛选、创建数据并操作这些数据管道和模型，这并非不可想象。因此，数据湖具有巨大的风险。
• 在许多情况下，需要将分析结果带回EDW进行报告。这要求我们处理两种不同的数据模型：原始数据模型和统一、协调的EDW版本。由于这些结构完全不同，因此需要另一条管道来修复所有不一致之处。
• 数据湖通常是一个单一的平台，由许多不同的（其他）用例共享。由于其与硬件的紧密耦合、兼容性挑战、共享库和配置，这些平台很难维护。

我总结的挑战只是大数据项目失败率如此之高的几个原因。管理阻力、内部政治、缺乏专业知识以及安全和治理挑战是分析从未投入生产的其他一些原因。

知识隔离和集中设计

构建集中式数据平台（如EDW或数据湖）的最大问题之一是团队的组织方式：具有数据工程技能的人与具有领域和业务知识的人是分开的。在许多情况下，这些人也是产生和了解数据的人。

通过孤立所有的数据专业人员，创建了一个烟囱。所有的知识都是孤立的，不允许其他团队利用数据。数据生命周期和心跳必须进行调整，以满足中央规定的要求。一个团队拥有所有基础设施，而这些基础设施仅对该中心团队可用。一个团队必须改变一切，运行一切，维护一切，修复一切等等。正是这种炉灶阻碍了组织的规模扩大。

总结

数据仓库将继续存在，因为在特定环境下协调来自不同来源的数据的需求将始终存在。通过暂存数据进行解耦的模式不会消失。就像清理、修复和转换模式的步骤一样。根据用例的需要，任何风格的Inmon或Kimball都可以很好地应用。技术趋势，如元数据驱动的ELT、数据虚拟化、云、分布式处理、用于富集的机器学习，将改变数据仓库，但不会带来负面影响。

我们必须考虑管理数据的方式。像企业数据仓库这样的大筒仓将灭绝，因为它们无法扩展。紧密耦合的集成层、上下文丢失和密集的数据消耗将迫使公司寻找替代方案。数据湖架构是另一个极端，它引入了原始数据。原始的、被污染的数据随时可能改变，这将迫使实验和用例永远无法投入生产。Raw本身承载了大量可重复的工作。

此外，孤立和单一的思维也是一个问题，这不允许公司扩大规模。孤立的数据专业人员创建烟囱。与具有领域和业务知识的人员分离会导致协调问题。

所需要的是一个平衡且管理良好的数据管理环境，该环境允许通过使用多种技术进行变化。它必须为域提供洞察力和灵活性，以适应和分发数据，同时保持解耦。我在一系列文章中概述了现代趋势如何影响数据集成以及您需要什么类型的体系结构来实现可扩展性(https://medium.com/@piein/data-management-at-scale-91111a1a7d83）和《规模数据管理》一书第2版。