迄今为止的旅程已经涉及了很多领域，将数据存储在数据湖仓库中是数据架构的新范式。第一章介绍了大数据的趋势，并讨论了需要一种新范式的原因。第二章概述了数据湖仓库架构，并讨论了数据湖仓库的七个层次。第三章侧重于在数据湖仓库中摄取和处理数据的方法。在本章中，我们将专注于将数据存储在数据湖中以及数据湖仓库架构的数据服务层。

从存储和性能的角度来看，数据存储至关重要。本章将首先提供关于数据如何存储在数据湖层的视图。接下来，我们将讨论数据湖中的不同数据存储，以及它们的需求和优势。然后，我们将探讨在数据湖中存储数据所使用的标准数据格式。最后，我们将专注于在数据服务层中为各种下游消费情境存储数据。本章将涵盖多种用于为基于SQL的环境提供数据的架构模式，同时也将涉及基于NoSQL的数据服务。

总之，本章将涵盖以下主题：

在数据湖层存储数据
在数据服务层存储数据

将数据存储在数据湖层

一旦数据被摄取到数据湖层，就需要进行正确的管理和存储。具有弹性的存储策略可以减少不必要的数据重复。此外，它确保为利益相关者提供基于需求的访问，并施加适当的安全控制以确保数据安全。因此，让我们首先探讨数据湖中各种数据存储。

数据湖层

数据湖层的数据被分隔存储在多个数据存储中。每个数据存储都有自己的目的和使用准则。如下图所示，数据湖层有四种类型的数据存储：

数据湖中的数据存储在分层文件结构中。分层文件结构创建了一个更像传统操作系统文件系统的文件夹，可以移动和重命名文件。此外，它便于在目录和子目录级别进行精细的基于角色的访问控制（RBAC）。

分层文件系统的层次结构如下图所示：

最顶层是包含一个或多个文件夹的目录。每个目录可以包含一个或多个形成第二层的文件夹。每个文件夹有一个或多个子文件夹，实际的数据文件存储在子文件夹中。分层文件系统使数据能够被划分和高效存储。如果基于文件夹和子文件夹对底层数据进行了分区，它还确保了更快的数据检索。数据湖的原始、中间和处理的数据存储都以分层文件组织的方式存储。然而，为了长期存储而设计的归档数据存储是否采用分层文件系统，取决于具体情况。现在，让我们详细了解这些数据存储/层次结构中的每一个。

原始数据存储

下图显示了原始数据存储是数据进入数据湖的第一个目的地：

原始数据存储是将源与数据湖仓库解耦的着陆区。源数据以适用于大数据处理的数据格式存储在原始数据存储中。这些格式的示例包括CSV、Apache Parquet和JSON。

从结构的角度来看，原始数据存储中的数据结构与源相同。这一原则意味着当源数据着陆到原始数据存储时，源数据中的行和列将被保留。如果源数据是非结构化的，数据格式将被保留。例如，如果图像是JPEG文件，它将以 .jpg 格式复制到数据湖存储中。原始数据存储也被称为铜质数据存储。

中间数据存储

第二个目的地是中间数据存储。以下图表显示了数据从原始数据存储移动到中间数据存储：

一旦数据进入原始数据存储，就需要进行处理。当原始数据经过处理时，它会经过许多中间阶段。例如，原始数据存储中的数据可以进行清理、过滤、聚合、追加等操作。这些被称为数据处理的中间阶段。妥善存储这些中间文件是明智的，有两个关键原因：

首先，如果需要重新启动处理作业，我们可以使用这些中间数据集。
其次，中间数据存储充当已处理数据存储的源。

我们可以使用优化过的计算能力来处理从中间数据存储到已处理数据存储的数据。数据存储的分隔确保对原始数据应用正确类型的计算过程。中间数据存储也被称为银质数据存储。

已处理数据存储

数据湖层的第三个数据存储是已处理数据存储。如下图所示，已处理数据存储是数据湖中的最后一个活跃（用于数据处理）层：

中间数据存储中的数据被聚合并存储在已处理数据存储中。已处理数据存储是数据已经被清理、聚合并准备好供使用的层次。然后对数据进行处理，已处理数据存储也可以被数据分析层访问，用于数据探索、临时查询、机器学习等分析活动。已处理数据存储也被称为金质数据存储。

存档数据存储

数据湖中的最后一层是存档数据存储。许多组织需要将数据存储以满足长期的需求。存档数据存储提供了这些需求的存储空间。此外，存档数据存储中的数据通常存储在不需要快速检索时间（也称为输入/输出）的更便宜的存储技术中。如下图所示，设置了一个存档计划，并定期触发将数据从原始、中间或已处理的数据存储传输到存档数据存储中进行长期存储。为了保持合理的价格性能平衡，从到达存储中检索数据的速度较慢，因为数据存储在更便宜的存储技术中。因此，明智地设置适当的存档计划，并确保只有不再活跃需要的数据被存档。

既然我们已经介绍了数据湖的不同层次，让我们来探讨一下数据湖中常用的一些数据格式。

常见的数据格式

在这个部分，我们将讨论用于在数据湖中存储结构化和非结构化数据的常见数据格式。

CSV格式

逗号分隔值（CSV）格式是一种常见的数据存储格式。 CSV文件基本上是一个包含制表符数据的分隔文本文件。该文件使用逗号来分隔字段之间的数据，逗号被称为分隔符。文件还可以使用其他类型的分隔符，如竖线（|）或制表符（\t）。CSV格式存在几十年了，仍然广泛用于数据存储。将数据存储为CSV格式有优势和劣势。将数据存储为CSV文件的主要优势如下：

CSV具有模式，且易于人工阅读，便于手动编辑。
CSV的实现相对简单，是一种易于解析的格式。
由于文件相对较小，CSV的处理速度较快。
各种紧缩方法可以与CSV很好地配合使用。

然而，CSV也有其劣势。将数据存储在CSV中的一些劣势包括：

CSV结构主要支持文本数据。CSV不支持复杂的数据结构，如数组或二进制数据。
在CSV文件中，数据以简单文本形式存储；文本和数值之间没有区别。
在CSV中表示二进制数据的标准方式。
CSV对特殊字符支持不好，且没有标准方式表示控制字符。

Parquet格式

在诸如CSV的基于行的文件格式中，数据存储为行。然而，面向行的存储对分析工作负载并不进行优化，因为需要扫描每一行以获取特定值。与基于行的存储相比，基于列的存储更适用于分析工作负载。以列的形式存储的数据在查询时从磁盘检索的数据量明显减少，因为查询将只检索相关列。基于列的存储还结合了高效的编码和压缩方法，以减少存储需求而不影响查询性能。Parquet是一种开源的、面向列的存储格式，可用于Apache Hadoop生态系统中的任何项目。Parquet文件格式针对大数据工作负载进行了优化，从头开始构建，以支持非常高效的压缩和编码方案。与CSV格式相比，Parquet格式具有明显的优势。Parquet格式的主要优势包括：

Parquet旨在提高存储和查询效率，相对于诸如CSV的基于行的存储。
CSV文件的一个缺点是无法处理复杂的嵌套结构。Parquet可以支持这些复杂的数据结构。此外，Parquet数据文件的布局经过优化，适用于处理每个文件中大量数据（在吉字节范围内）的查询。
如前所述，CSV的另一个缺点是其有限的压缩方法选项。另一方面，Parquet具有许多灵活的压缩选项和高效的编码方案，从而实现了高效的存储优化。
当需要以临时和交互的方式查询底层数据时，Parquet也能很好地工作。

JSON格式

在存储半结构化数据时，常常使用JavaScript对象表示法（JSON）格式。JSON是一种开放标准的文件格式和数据交换格式。它以易于人阅读的文本形式存储数据，并常被用作数据交换的主要格式，包括在网络上的应用。

其他格式

数据湖还可以存储非结构化数据，如视频、图像、音频文件和文本。它们的一些标准格式如下：

视频：长时间以来，视频使用的标准格式是MPEG-4 Part 14（也称为MP4）文件格式。MP4格式可以在较小的文件格式中存储许多数据结构，包括音频文件、视频文件、静态图像和文本。
图像：联合摄影专家组（JPEG）、标记图像文件格式（TIFF）和图形交换格式（GIF）是常用的图像文件格式。
音频：波形音频文件格式（WAV）和音频视频交互格式（AVI）是标准的音频数据格式。

既然我们已经介绍了数据湖层中使用的存储格式，让我们探讨数据存储的另一个方面------即在数据服务层存储数据。

将数据存储在数据服务层

一旦数据在数据湖中处理完毕，就需要提供给下游应用程序或利益相关者。以下图表显示了不同数据湖层次和数据服务层之间的交互：

让我们来探讨在数据服务层中可以使用的不同数据存储，以支持这些服务。

以下图表展示了如何使用不同的技术来利用不同的数据存储：

现在，让我们继续介绍基于SQL的服务。

基于SQL的服务

关系数据库管理系统（RDBMS）已经用于存储结构化数据多年。在现代数据分析的背景下，它们仍然有其重要地位。用于与RDBMS通信的结构化查询语言（SQL）广泛用于查询数据。基于SQL的数据库被用作数据服务层。它们可以以数据仓库或数据集市的形式出现，通常用于报告、数据分析和自助分析。根据系统的查询性能和成本优化，可以使用两种类型的基于SQL的数据库作为数据服务层。以下图表展示了两种基于SQL的数据库及其主要特征：

让我们详细探讨每一个。

SMP架构

第一种基于SQL的服务数据库是基于对称多处理器（SMP）架构的。这项技术包括计算、存储和网络元素。这些构建块已经发展得很成熟，以至于基于SMP的数据库现在可以以令人满意的价格支持小到中等规模的分析需求。以下图表显示了基于SMP的RDBMS的逻辑架构：

基于SMP的RDBMS具有共享资源，如内存、I/O、操作系统和磁盘。SMP是一种紧密耦合的架构，通过垂直扩展（增加内存或CPU）来扩展它。使用SMP架构有一些固有的优势，其中一些如下：

网络速度：所有SMP组件基本上包含在一个服务器中。这种融合意味着在组件之间通信时没有延迟。
无数据洗牌：由于数据存储在一个位置，因此无需洗牌数据，提高了延迟。
较少的故障点：SMP是一种紧密耦合的架构。其CPU、内存和I/O被融合在一起，作为一个单一单元工作。因此，它的故障点较少。
更新更快：由于数据在SMP架构中保持一致，当需要频繁更新时，它在RDBMS中可以有效应用所有构造，如原子性、一致性、隔离性和耐久性（ACID）属性、数据库触发器、索引等，全部在SMP系统内完成。然而，当用于大规模分析时，SMP架构也存在一些挑战：
性能：数据分析已成为一个大规模的领域，涉及到以PB为单位的数据。在单个服务器中，CPU和内存有其极限。随着数据量的增长，SMP的单片和紧密耦合的架构无法达到最佳性能。
可伸缩性：现代数据分析需要计算的可伸缩性和弹性。数据服务层需要根据查询类型和使用系统的消费者进行扩展。基于SMP的架构只能进行垂直扩展。这种可扩展性的限制限制了根据CPU或RAM使用量进行按需扩展的能力。如果我们想要添加更多的存储或CPU，基于SMP的数据服务层需要停机进行升级，这可能会产生中断。
成本：随着数据量的增长，在SMP架构下实现在最佳价格点上的可接受性性能水平变得具有挑战性。
可维护性：如前所述，SMP架构的单片特性意味着它呈现单点故障。由于弹性不是内建的，基于SMP的架构需要更多的维护以确保高可用性。 Microsoft SQL Server、Oracle、MySQL和Postgres DB是SMP数据库的一些示例。

现在，让我们深入研究另一种在现代数据分析架构中主要使用的基于SQL的数据服务层。

基于MPP的架构

基于大规模并行处理（MPP）的架构在处理数据时采用了一种不同的方法，采用了无共享的架构风格。以下图表展示了MPP背景下逻辑架构的典型示例：

大规模并行处理（MPP）架构采用了一种不同的方法来处理数据，并采用了无共享的架构风格。以下图表展示了MPP背景下逻辑架构的典型示例：

MPP架构将数据切分为多个块，并独立地处理每个块。每个处理单元都有自己的内存、CPU和存储。一个控制节点充当指挥官，并分配由每个处理单元处理的内容。控制节点还执行其他功能，例如 consolodating 来自多个处理单元的数据。MPP的主要特点如下：

MPP采用无共享的架构风格，每个处理单元都有自己的一组RAM、CPU和存储资源。此外，每个处理单元执行其查询处理（例如聚合、过滤等）。
MPP架构既可以横向扩展，也可以纵向扩展。只需增加节点的容量，就可以进行纵向扩展。MPP还可以通过向架构添加新的处理单元来进行横向扩展。
数据被分割并分布在多个存储节点上。每个存储节点上都有一个单独的处理单元。当存储基于云时，底层物理存储被划分为逻辑存储单元。
由于数据分布在多个单元中进行处理，MPP非常适用于大型数据集的分析。因此，在大数据分析中，使用MPP相比SMP有显著的优势。MPP架构的主要优势如下：
- 性能：由于MPP架构可以在水平和垂直方向上扩展，因此使用MPP更容易实现显著的性能改进。
- 可伸缩性：随着添加更多节点，MPP可以无缝地扩展。通常情况下，MPP通过添加新节点实现扩展而无需停机。SMP无法达到这种无缝可伸缩性。
- 成本：在MPP架构中，成本更易于管理。在SMP上执行大型数据集的分析变得成本高昂，因为随着内存的显著增加，系统变得更加昂贵。然而，在MPP中，以最优成本进行扩展并不是一个问题，因为可以添加新节点并实现横向扩展。

尽管有这些优势，基于MPP的数据服务层也存在一些缺点。其中一些缺点如下：

网络速度：MPP基础的数据服务层的所有节点都连接到网络结构。因此，连接可能会引入一些延迟，尽管这可能是最小的。
处理开销：在存储到基于MPP的数据服务层之前，需要对数据进行分区。然后，层中的每个节点执行其处理。然后需要合并处理后的数据。这些额外的步骤对于小型数据集会产生处理开销。
成本效益：对于较小的数据量，MPP可能不具有成本效益。因此，预计在性能优势变得明显之前，将达到最低数据量阈值。此阈值在不同技术之间有所不同。通常情况下，对于基于云的MPP解决方案，此阈值很小。

Azure Synapse、Teradata、Snowflake和Amazon Redshift是MPP数据库的一些示例。现在我们已经了解了基于SQL的数据服务，让我们讨论基于NoSQL的数据服务。

基于NoSQL的数据服务

数据服务层中的数据不仅用于分析。它可以用于实时数据服务，也可以作为API公开。我们之前讨论过的基于SQL的数据服务层并不是满足这些要求的理想数据服务层。NoSQL也可以用于这些要求。我们现在将简要讨论一些基于NoSQL的数据服务解决方案的常见类型。

文档数据库

文档数据库是一种NoSQL数据库，将数据存储在类似对象的文档中。JSON是文档数据库中典型的数据结构。在这种情况下，每个记录包含各种类型的数据，包括字符串、数字、布尔值、数组和对象。文档数据库可以在向数据库添加更多文档时进行扩展。因此，它们可以扩展并容纳大量数据。由于其灵活性和可扩展性，它们用于各种用例。

在需要灵活架构的情况下，文档数据库非常有帮助。它们提供快速查询、适合处理大数据的结构、灵活的索引和简化的数据库方法。此外，文档数据库可用作数据服务层，提供对数据的实时访问。这种模式广泛用于下游应用程序，如需要最小延迟和频繁更新的移动或Web应用程序。其中的示例可能是产品或服务目录，或提供个性化体验给最终用户的应用程序。MongoDB、DocumentDB和Cosmos DB是文档数据库的一些例子。

键-值存储

键-值存储使用关联数组作为构建块。每个项包含键和值。因此，键-值存储更适用于需要存储大量数据的用例。不需要执行复杂查询，但需要低延迟。

许多键-值存储的实现（如Redis）使用内存技术，使它们在缓存数据方面快速而有效。缓存中存储的数据示例可能是预先计算的值或存储在磁盘上的数据副本。缓存可以减少数据访问延迟，提高吞吐量，并减轻关系数据库的负载。键-值存储还用于实现在聊天和消息应用程序中经常使用的轻量级排队系统。键-值存储主要用于管理互联网规模应用程序的会话数据。这些类型的数据库可以提供亚秒级的延迟，并在设计上具有弹性。具有这些特征，它们用于处理互联网会话数据和任何其他低延迟应用程序。Redis和DynamoDB是流行的键-值存储。

宽列存储

与关系数据库类似，宽列存储使用表、行和列来存储数据。但是，与关系数据库不同，同一表中的行之间列的结构和内容可以有所不同。由于列格式在同一表的行之间可能有所不同，这提供了某些优势，如查询速度、数据模型的可扩展性和灵活性。宽列存储在需要对数据库进行大量写入而不需要联接数据或进行聚合的场景中表现出色。

宽列存储跟踪物联网（IoT）事件和历史，存储时间序列数据和事务日志。Apache Cassandra和HBase是常用的宽列存储。

数据共享技术

数据共享的概念在现代数据分析框架中日益受到关注。随着组织存储和策划越来越多的数据，有必要以受控且有结构的方式与内部和外部利益相关者分享这些数据。此外，组织还可以决定通过与第三方分享数据并从其使用中生成收入来实现数据的货币化。为了使组织能够实现这些好处，数据共享技术被用于以受控制的方式共享数据。以下图示了数据共享的过程。数据共享技术应该能够启用这一工作流程，并以一种受控制的方式促进数据共享：

数据共享工作流程包括以下步骤：

数据发布者使用数据共享技术发布数据。数据会附带其相关的条款、收费机制和使用条件。
数据请求者可以浏览数据目录并识别感兴趣的数据。一旦识别到数据，就会发送访问或获取数据的请求。
工作流程中的一个可选步骤是将请求发送给数据发布者。数据发布者可以批准或拒绝请求。当共享的数据是敏感的，并且需要对请求者进行审查时，这一步是至关重要的。
一旦数据使用得到发布者的批准，数据就被数据请求者使用。然后，数据可以根据使用条款使用。

现在，让我们继续介绍本章的总结。

总结

本章详细介绍了数据是如何存储在数据湖和数据服务层中的。在第一部分，我们讨论了数据是如何存储在数据湖层的。在接下来的一部分，我们讨论了数据湖中不同类型的数据存储和它们的相互作用。我们还深入探讨了在数据湖中存储数据的不同格式，讨论了每种格式的优缺点。

在接下来的一部分，我们聚焦于数据服务层。我们探讨了基于SQL的数据服务存储、基于NoSQL的服务存储以及数据共享的方法。最后，我们研究了数据服务层中每个不同组件的用例和技术。

下一章将聚焦于数据分析，我们将涵盖不同类型的分析以及从数据中获取洞见所使用的组件。

在数据湖仓库中存储和提供数据