到了21世纪中期，我已经使用关系型数据库多年了，但我从未接触过关系型数据仓库。我当时在一家公司担任数据库管理员（DBA），该公司使用会计软件包管理其财务交易。该软件包的报告功能有限且运行缓慢，因此公司希望提高性能，创建仪表板来分析数据，并将其财务数据与自制应用程序的数据相结合，以更好地了解业务状况。

我的雇主聘请了一家咨询公司来构建这个被称为"关系型数据仓库"的东西，并且在改变了我职业生涯方向的一次决定中，邀请我帮助他们。我们制作了仪表板，节省了最终用户大量的时间，并增加了他们以前从未拥有过的商业见解。当我看到他们脸上的激动之情时，我知道我找到了自己的新激情。我改变了我的职业方向，专注于数据仓库，从未回头看过。

什么是关系型数据仓库？

关系型数据仓库（RDW）是您集中存储和管理大量结构化数据的地方，这些数据从多个数据源复制过来，用于历史和趋势分析报告，以便您的公司能够做出更好的业务决策。它被称为关系型，因为它基于关系模型，这是数据库中广泛使用的一种数据表示和组织方法。在关系模型中，数据被组织成表（也称为关系，因此得名）。这些表由行和列组成，其中每一行代表一个实体（如客户或产品），每一列代表该实体的一个属性（如名称、价格或数量）。它被称为数据仓库，因为它收集、存储和管理来自各种来源的大量结构化数据，如事务性数据库、应用系统和外部数据源。

并非所有的数据仓库都基于关系模型。非关系型数据仓库包括列式、NoSQL 和图形数据仓库等类型。然而，关系型数据仓库更受欢迎，被广泛采用，主要是因为关系数据库几十年来一直是主导的数据管理范式。关系模型非常适合于结构化数据，在业务应用程序中很常见。由于 SQL 的广泛使用，关系型数据仓库也因此受欢迎，SQL 已经成为多年来关系型数据仓库的标准语言。

RDW 充当许多主题领域的中央存储库，并包含真理的单一版本（SVOT）。SVOT 是数据仓库中的一个关键概念，它指的是创建组织数据的统一、一致的视图的实践。这意味着数据仓库中的所有数据都以标准化的结构化格式存储，并代表信息的单一、准确版本。这确保所有用户都能访问相同的信息，消除任何差异或不一致性，消除数据孤立。这提高了组织内的决策制定、协作和效率。它还降低了因使用不一致的数据源而产生的错误和误解的风险。

想象一下，如果没有数据仓库，直接从多个源系统生成报告，甚至可能还有一些 Excel 文件。如果报告查看者质疑数据的准确性，您能告诉他们什么呢？"真理"可能分散在如此多的源系统中，以至于难以追踪数据的来源。此外，某些报告将为相同数据提供不同的结果，例如，如果两个报告使用复杂的逻辑从多个源中提取数据，并且逻辑更新不正确（或根本没有更新）。将所有数据集中存储在一个地方意味着数据仓库是真理的唯一来源；对于报告数据的任何疑问都可以通过数据仓库回答。保持 SVOT 对于希望充分利用其数据潜力的组织至关重要。

如果整个公司使用数据仓库（DW），通常称为企业数据仓库（EDW）。这是数据仓库的更全面、更强大的版本，旨在支持整个组织的需求。虽然标准 DW 可能支持一些业务单位，并且在整个组织中有许多 DW，但 EDW 使用更广泛的数据源和数据类型来支持所有业务单位。EDW 提供了组织所有数据的单一、统一视图。

图 4-1 说明了拥有数据仓库的一个主要原因。左图显示了在没有数据仓库的情况下，从多个应用程序中运行报告是多么具有挑战性。每个部门都运行一个报告，收集与每个应用程序关联的所有数据库的数据。因此，会运行大量查询，可能会出现性能问题和错误数据。这很混乱。右图显示，将所有应用程序数据复制到 EDW 中后，每个部门都可以轻松运行报告，而不会影响性能。

通常，构建数据仓库时，您将创建数据流水线，执行三个步骤，称为提取、转换和加载（ETL）：

数据流水线从源系统（如数据库和平面文件）提取数据。
然后对提取的数据进行转换或操作，以符合目标系统的要求（在本例中，符合数据仓库的要求）。这可能涉及清理、过滤、聚合或组合来自多个来源的数据。
转换后的数据被加载到数据仓库中。数据库管理员（DBA）可以使数据库和字段名称更有意义，这样终端用户就可以更轻松、更快速地创建报告。

数据仓库不是什么？

现在您已经了解了数据仓库的含义，让我们通过查看不应被视为数据仓库的解决方案来澄清其目的（尽管我多次看到人们这样做）：

带有DW前缀的数据库

数据仓库不是仅仅将操作系统中的源数据库复制一份，并在文件名中添加DW后缀。例如，假设您复制了一个名为Finance的数据库，其中包含50个操作表，并将复制命名为DW_Finance，然后使用这50个表来构建报表。这将导致数据仓库被设计用于操作数据，而实际上您需要的是为分析数据进行设计。对于分析数据，您拥有更好的读取性能，并且可以创建数据模型，使最终用户更容易构建报表。（我将在下一节中详细解释。）

包含联合视图

数据仓库不是多个来自各种源系统的表的复制，通过SQL视图进行联合。（联合是通过SQL UNION语句完成的，它将两个或多个SELECT语句的结果合并成一个结果集。）例如，如果从三个包含客户信息的源系统中复制数据，则会在数据仓库中得到三个表，分别为CustomerSource1，CustomerSource2和CustomerSource3。因此，您需要创建一个名为CustomerView的视图，该视图是对表CustomerSource1，CustomerSource2和CustomerSource3进行联合的SELECT语句。您需要对其他表（例如产品和订单）重复此过程。

相反，应将三个表的数据复制到数据仓库中的一个表中，这需要额外的工作来创建适合所有三个表的数据模型。在这一点上，您可能希望使用主数据管理（MDM），在第6章中有解释，以防止重复项并提高可访问性和性能。

"倾倒场"

数据仓库不是表的倾倒场。许多情况下，当公司没有数据仓库，而最终用户希望从几个源系统的数据子集创建报表时，会出现这种情况。为了迅速帮助他们，IT部门的人员毫不犹豫地创建了一个数据仓库，将这两个源系统的数据复制到数据仓库中。然后其他最终用户看到了第一个最终用户获得的好处，他们希望从同样的源系统以及其他一些源系统获取额外的数据来创建自己的报表。因此，IT人员再次迅速将所请求的数据复制到数据仓库中。这一过程一遍又一遍地重复，直到数据仓库变成了一团混乱的数据库和表。

因此，许多数据仓库最初是为几个用户量身定制的解决方案，然后变成了全公司规模但设计不佳的数据仓库。有更好的方法。相反，当第一个最终用户请求出现时，请评估您公司的报告需求。了解该请求是否真的是一次性的，或者是否应该是构建企业数据仓库的开始。如果是这样，这是向高级领导展示为什么您公司需要数据仓库的机会。如果是这样，请坚持认为您需要足够的前期时间来设计一个可以支持多个数据源和最终用户的数据仓库。（使用"为什么使用关系型数据仓库？"来支持您的观点。）

自上而下的方法

在关系数据仓库（RDW）中，你会在前期做大量工作，使数据能够用于创建报告。在之前进行所有这些工作是一种被称为自上而下方法的设计和实施方法论。这种方法适用于历史类型的报告，在这种报告中，你试图确定发生了什么（描述性分析）以及为什么会发生（诊断性分析）。在自上而下方法中，你首先确立数据仓库的整体规划、设计和架构，然后再开发具体的组件。该方法强调了在着手开发数据仓库之前定义企业范围的愿景和理解组织的战略目标和信息需求的重要性。

描述性分析和诊断性分析是业务中常用的两种重要的数据分析类型。描述性分析涉及分析数据以描述过去或当前事件，通常通过摘要统计或数据可视化来实现。这种类型的分析用于了解过去发生了什么，并识别数据中的模式或趋势，有助于决策。

诊断性分析用于调查过去事件的原因，通常是通过检查不同变量或因素之间的关系来实现的。这种类型的分析可以确定问题的根本原因或诊断可能影响业务绩效的问题。

假设一家公司希望分析过去一年的销售数据。描述性分析将涉及计算摘要统计数据，如总销售收入、平均每日销售额以及按产品类别的销售情况，以了解发生了什么。相比之下，诊断性分析将审查因素之间的关系（例如销售和营销支出，或季节性和客户人口统计信息），以了解为什么销售在一年中波动。通过结合这两种方法，公司可以更深入地了解他们的数据并做出更明智的决策。

图4-2显示了典型RDW的架构。ETL用于将数据从多个来源摄入到RDW中，然后可以进行报告和其他分析。

自上而下方法通常涉及以下步骤：

提前制定一些假设。从清晰了解企业战略开始。然后确保你知道你想向数据提出什么问题。
确定业务需求。确定组织的目标、目标和关键绩效指标（KPI）。收集和分析各部门和用户的信息需求。你也可以将这一步看作是定义你的报告需求。
设计数据仓库架构。基于业务需求，为数据仓库创建一个高级架构，包括其结构、数据模型和数据集成流程。这些将成为你的技术要求。
开发数据模型。为数据仓库设计详细的数据模型，考虑各种数据实体之间的关系和数据的粒度。
构建架构。为数据仓库开发适当的数据库、模式、表格和字段。这是之前描述的称为写入模式的方法。
开发ETL。开发ETL过程，从各种源系统中提取数据，将其转换为所需格式，并加载到数据仓库中。
开发和部署BI工具和应用程序。实施BI工具和应用程序，允许用户访问、分析和报告存储在数据仓库中的数据。
测试和完善数据仓库。进行测试以确保数据质量、性能和可靠性。根据需要进行任何必要的调整，以优化系统。
维护和扩展数据仓库。随着组织需求的变化，相应地更新和扩展数据仓库。

自上而下方法有一些优势，如对组织数据需求的全面了解，更好的数据一致性和改进的治理。然而，它也可能耗时和资源密集，交付价值需要的时间比数据湖采用的自下而上方法长，数据湖的方法在第5章中有描述。现代数据仓库架构，在第10章中描述，结合了自上而下和自下而上方法。

为什么要使用关系型数据仓库？

使用RDW可以更轻松地构建任何类型的商业智能解决方案，因为商业智能解决方案可以直接从RDW中提取数据，而无需创建复杂的逻辑从多个源系统中提取数据。此外，它们也不必清理或连接数据，因为RDW已经完成了这些工作。从RDW构建的商业智能解决方案可以是数据集市（它包含特定人群的RDW数据子集，如第6章所述），可聚合数据以加快查询和报告速度，甚至可在Microsoft Excel中使用。

总之，有了RDW，您已经有了一个坚实的基础来构建。让我们详细了解一下从使用RDW中可以获得的一些主要好处：

减轻生产系统的压力

您可能以前遇到过这个问题：用户打来怒气冲冲的电话，抱怨通过订单输入应用程序插入订单花费了很长时间。您查看后发现，另一个用户正在通过订单输入应用程序运行报告，占用了应用程序所在服务器上的所有资源。特别是当允许用户创建自定义查询并编写糟糕的SQL时，这种情况尤其常见。

通过将订单输入应用程序数据库复制到DW并对其进行优化，您可以让所有报告和自定义查询都针对DW运行，从而完全避免这个问题，特别是如果用户需要运行针对多个应用程序数据库的报告。

优化读取访问

应用程序数据库会被优化以支持所有的增删改查操作，因此数据的读取速度不会像它本应该的那样快。另一方面，数据仓库是一种"写一次，多次读取"的系统，主要用于数据的读取。因此，可以针对读取访问进行优化，特别是对于运行报告或查询时经常发生的耗时的顺序磁盘扫描。有许多数据库技术可用于加速DW的读取访问，其中一些可能会影响写入访问，但我们不需要关注这一点。

集成多个数据源

集成多个数据源以创建更有用的报告的能力是构建DW的更重要的原因之一。将所有数据放在一个地方而不是分散在各种数据库中不仅使报告生成变得更加容易，而且极大地提高了报告的性能。

运行准确的历史报告

没有DW，应用程序的最终用户通常会在每个月的特定日期（通常是最后一个工作日）运行他们的所有报告。然后，他们将其保存到磁盘上，以便将来参考。例如，用户想查看几个月前的报告，列出了按州划分的客户销售额。然而，一位客户最近搬到了另一个州。如果用户运行当前的报告，它将错误地显示客户在新州的销售额，而不是旧州的销售额（因为他们在数据库中的记录已经更新为新州）。因此，用户必须查看保存的旧报告，而不是运行当前报告。

DW可以通过跟踪客户的移动（通过跟踪客户位置历史和起始日期和结束日期）以及需要跟踪的任何其他字段（例如，雇主或收入）来解决这个问题。现在，用户可以今天运行一个报告，但要求它以过去某个日期的数据为基础，报告将准确无误。此外，不再需要每月保存报告文件。

重新构建和重命名表格

许多应用程序数据库的表格和字段名称非常难以理解，特别是旧的ERP和CRM产品（想想表格名称，例如T116和字段名称，例如RAP16）。在数据仓库中，您可以将这些源表格中的数据复制到更易于理解的地方（例如，将T116替换为Customer）。您还可以为所有表格设计更好的数据模型。当用户不必翻译晦涩的表格和字段名称时，他们将能够更轻松地创建报告。

防止应用程序升级带来的影响

想象一下，如果没有DW，用户将创建报告来自应用程序数据库。一切都运行良好，突然之间，许多报告开始出现错误。原来是应用程序进行了升级，安装了一个新版本，其中重新命名了一些表格和字段。因此，您现在必须逐个检查每个报告，共计几百个，然后重新命名更改后的表格和字段。这可能需要几个月的时间，导致许多沮丧的最终用户。即使在那之后，任何被忽略的报告可能仍然会出现错误。

DW可以保护您免受此影响。应用程序升级后，只需更新从应用程序数据库复制数据到DW的ETL - 这是一个快速的任务。报告不需要更改。用户在ETL修复之前看不到任何新数据，但是他们的报告不会出现错误。

减少安全性问题

没有DW，您的团队需要为每个最终用户提供对其需要用于报告目的的每个应用程序数据库的安全访问权限。可能会有几十个;提供访问权限的过程可能需要几周，有时甚至可能仍然无法获得所需的所有权限。有了DW，每个最终用户只需要访问适当的表格，提供这一点要快得多，也更容易。

保留历史数据

许多生产系统限制了它们保存的历史数据的数量（例如，最近三年的数据）。它们这样做是为了节省空间和提高性能，并且在某些情况下，是为了符合法规。较老的数据通常会每年或每月清除一次。另一方面，DW可以保存所有历史记录，因此您永远不必担心运行报告以获取旧年份的数据而找不到任何数据。

主数据管理（MDM）

当您从多个源系统收集数据时，很多时候您需要使用MDM删除重复记录，例如客户、产品和资产等。（有关MDM的更详细解释，请参见第6章。）DW是执行MDM的理想地点。此外，许多MDM工具还允许您创建层次结构（例如，公司→部门→员工），从而增加了主数据的价值。

通过填补源系统中的空洞提高数据质量

尽管应用程序所有者说的内容与事实并不一致（我听到他们多次说"我们的数据很干净"），但您会发现从各种源系统获取的许多数据需要进行清理。例如，订单输入应用程序可能需要客户的出生日期，如果输入数据的人不知道客户的出生日期，他们可能会输入未来的日期或100多岁的日期，以便能够完成订单。或者，也许应用程序不检查输入的两位数州代码的准确性。源系统中总是有很多"空洞"。您不仅可以清理DW中的数据，还可以通知维护应用程序的人员有关其系统中空洞的信息，以便他们可以解决问题。通过这种方式，您可以防止将来录入错误数据。

消除IT参与报告创建

这回到了第3章提到的自助式商业智能：构建一个适当的DW将消除需要让IT参与构建报告的需要，并将此任务交给最终用户处理。没有了IT资源有限的瓶颈，报告和仪表板可以更快地构建。而且IT将感激不用再创建报告，而可以致力于更有趣的项目！

使用关系型数据仓库（RDW）存在的缺点

总会存在取舍，以下是建立 RDW 时需要考虑的缺点：

复杂性数据仓库（DW）可能非常复杂且耗时，设计、构建和维护都需要专业技能和资源，这可能会增加成本。
高成本实施数据仓库可能成本高昂，需要在硬件、软件和人员方面进行重大投资。持续的维护和升级也可能增加成本。
数据集成挑战整合来自不同来源的数据可能具有挑战性，因为可能涉及到不同的数据格式、结构和质量问题。这可能会导致花费时间和精力进行数据清洗和预处理。此外，某些数据，例如来自物联网设备的流数据，太难以被摄入到 RDW 中，因此这些信息的潜在洞见可能会丢失。
耗时的数据转换要将数据加载到 DW 中，可能需要对其进行转换以符合仓库的数据模型。这个过程可能会耗费大量时间，而数据转换中的错误可能导致分析结果不准确。
数据延迟由于 DW 设计用于处理大量数据，它们处理速度可能比其他类型的数据库慢。这可能导致数据延迟，即仓库中的数据与源数据库的最新更改不一致。
维护窗口对于 RDW，通常需要一个维护窗口。加载和清理数据非常资源密集，如果用户同时尝试运行报告，性能将会非常慢。因此，在维护期间，用户必须被锁定在仓库之外，以防止 24/7 访问。如果在维护窗口期间发生任何问题，例如 ETL 作业失败，您可能需要延长维护窗口。如果用户尝试运行报告但仍被锁定，那么他们会感到沮丧，无法完成工作。
限制的灵活性数据仓库设计用于支持特定类型的分析，这可能限制了它们对其他类型数据处理或分析的灵活性。可能需要集成额外的工具或系统来满足特定需求。
安全性和隐私问题在集中位置存储大量敏感数据可能会增加数据泄露和隐私侵犯的风险，因此需要强有力的安全措施。

填充数据仓库

因为输入到数据仓库的源表会随着时间而变化，所以数据仓库需要反映这些变化。这听起来似乎很简单，但实际上需要做出许多决定：提取（或拉取）数据的频率是多少，使用什么提取方法，如何物理提取数据，以及如何确定自上次提取以来哪些数据发生了变化。我将简要讨论每一个问题。

提取数据的频率

更新数据仓库的频率主要取决于源系统的更新频率以及最终用户需要报告数据的时效性。通常，最终用户不希望看到当天的数据，而更倾向于获取截至前一天结束的所有数据。在这种情况下，您可以在源系统数据库更新完成后的每个夜间使用ETL工具运行作业，创建一个夜间维护窗口来进行所有数据传输。如果最终用户需要在白天进行更新，则需要更频繁的提取，例如每小时一次。

需要考虑的一点是每次提取的数据量。如果数据量非常大，更新数据仓库可能需要太长时间，因此您可能希望将更新拆分为较小的块，并进行更频繁的提取和更新（例如，每小时而不是每天）。此外，从源系统传输大量数据可能需要太长时间，特别是如果源数据位于本地，而您没有从源系统到互联网的大型管道。这是您可能希望从每晚的大型传输转向白天较小的小时传输的另一个原因。

提取方法

提取数据有两种方法。让我们分别看一下：

1. 完全提取

在完全提取中，所有数据都完全从一个或多个源系统中提取出来。这对较小的表格效果最好。由于此提取反映了源系统上当前可用的所有数据，因此无需跟踪更改，使得此方法非常易于构建。源数据按原样提供，并且您不需要任何额外的信息（例如，时间戳）。

2. 增量提取

在增量提取中，您只提取自指定时间以来已更改的数据（例如，上次提取或财政期末之后的数据），而不是整个表。这对大型表格效果最好，并且仅当可以识别所有更改的信息时才有效（下文讨论）。

对于大多数源系统，您将同时使用这两种方法。

无论是进行完全提取还是增量提取，提取数据有两种方式：在线和离线。

在线提取中，提取过程可以直接连接到源系统以访问源表，或者它可能连接到一个中间系统，该系统以预配置的方式存储数据的更改（例如，以事务日志或更改表的形式）。

但是，并非总是可以直接访问源系统。在这种情况下，数据在原始源系统外进行分级处理，并由源系统发起的提取例程创建（例如，一个主机执行对表的提取例程，并将数据存储在文件系统的文件夹中）。提取的数据通常放置在以定义的通用格式（例如，CSV或JSON）为基础的平面文件中。

如何确定自上次提取以来发生了哪些数据更改

遗憾的是，许多源系统很难识别最近修改的数据并进行增量提取。以下是几种从源系统中识别最近修改的数据并实施增量提取的技术。这些技术可以与讨论的数据提取方法结合使用。某些技术基于源系统的特性；其他可能需要对源系统进行修改。在实施之前，源系统的所有者应仔细评估任何技术：

时间戳

时间戳是最理想的选择，也是最容易实现的。一些操作系统中的表具有时间戳列，其中包含给定行上次修改的时间和日期，从而很容易确定最新的数据。在关系数据库中，时间戳列通常具有时间戳或日期时间数据类型，以及类似于时间戳或上次修改的列名。源应用程序将填充此列。如果没有，您可以设置关系数据库，在保存记录时默认为当前日期，或者您可以添加数据库触发器来填充该列。

更改数据捕获

大多数关系数据库支持更改数据捕获（CDC），它记录应用于数据库表的INSERT、UPDATE和DELETE操作，并根据关系数据库的事务日志生成更改表记录，记录发生了什么变化，何时发生变化。如果您需要几乎实时的数据仓库，其中您可以在几秒钟内看到对源系统的更改在数据仓库中的反映，CDC可以成为关键的启用技术。

分区

一些源系统使用范围分区，其中源表根据日期键进行分区，这样可以很容易地识别新数据。例如，如果您正在从按天分区的订单表中提取数据，那么很容易识别当前或前一天的数据。

数据库触发器

您可以在单个表上添加INSERT、UPDATE和DELETE触发器，并让这些触发器将有关记录更改的信息写入"更改表"中。这类似于更改数据捕获，因此如果您的数据库产品支持CDC，请使用CDC；否则，请使用触发器。

MERGE语句

最不理想的选择是从源系统进行完全提取到DW中的临时区域，然后使用MERGE语句将此表与来自源系统的以前的完全提取进行比较，以识别更改的数据。您将需要将所有源字段与所有目标字段进行比较（或使用哈希函数）。如果数据量很大，这种方法可能不会对源系统产生重大影响，但可能会给DW带来重大负担。如果没有其他选择，通常这种选择是最后的选择。

关系数据仓库的消亡已经被极大夸大

大约在2010年初，IT界开始质疑是否还需要关系数据仓库，提出了"关系数据仓库已死"的问题。许多人理解这个问题是在询问企业是否仍然需要数据仓库。正如本章所指出的，确实需要。但实际上，这个问题实际上是关于数据仓库架构的------你是否可以仅使用数据湖，还是应该同时使用数据湖和关系数据仓库？

当数据湖首次出现时，它们是建立在Apache Hadoop技术上的，而主要是Hadoop供应商宣布了关系数据仓库的消亡。"只需将所有数据放入数据湖，摆脱关系数据仓库"，他们建议道。如第2章所述，尝试这样做的项目都以失败告终。

多年来，我一直认为关系数据仓库将永远是必需的，因为数据湖都是基于Hadoop的，而且存在太多的限制。但是一旦诸如Delta Lake（见第12章）这样的解决方案变得可用，并且数据湖开始使用比Hadoop更好、更易于使用的产品（见第16章），我开始看到一些情况下可以在没有关系数据仓库的情况下实现解决方案。这种类型的解决方案是数据湖仓库架构，将在第12章中介绍。

然而，仍然有许多情况需要关系数据仓库。虽然数据湖技术将继续改进，从而减少或消除绕过关系数据仓库的担忧（见第12章），但我们永远不会完全放弃关系数据仓库。我认为有三个原因。首先，从数据湖报告仍然比从数据仓库报告更加困难。其次，关系数据仓库继续满足用户的信息需求并提供价值。第三，许多人使用、依赖和信任数据仓库，并不想用数据湖替换它们。

数据湖为数据科学家和自助数据消费者（"高级用户"）提供了丰富的数据来源，并且很好地满足了分析和大数据的需求。但并非所有的数据和信息工作者都想成为高级用户。大多数人仍然需要集成良好、系统清洗、易于访问的关系数据，其中包括一个捕获事物如何随着时间推移或发展的历史记录。这些人最适合使用数据仓库。

总结

本章介绍了第一种广泛使用的技术解决方案，用于集中来自多个来源的数据并对其进行报告：关系数据仓库（RDW）。RDW通过提供一个集中的数据存储库和检索库，彻底改变了企业和组织管理数据的方式，实现了更高效的数据管理和分析。通过以结构化方式存储和组织数据，RDW允许用户快速轻松地生成复杂的查询和报告，提供宝贵的洞见，支持关键决策制定。

如今，关系数据仓库仍然是许多数据架构的基本组成部分，并且在各行各业广泛应用，从金融和医疗保健到零售和制造业都有所体现。接下来的一章将讨论下一个成为数据集中和报告的重要因素的技术：数据湖。

解读数据架构——关系型数据仓库