现代数据湖本质上是数据仓库和数据湖的结合体，并且**所有内容都使用对象存储**（对象存储）。这听起来可能像是一个营销策略——将两种产品打包成一个，并将其称为新产品——但本文中介绍的数据仓库比传统数据仓库更优秀，因为它使用了对象存储，因此在可扩展性和性能方面具备了对象存储的所有优势。采用这种方法的组织只需为其所需内容付费（由对象存储的可扩展性提供便利），如果需要极速性能，他们还可以为其底层对象存储配备通过高端网络连接的 NVMe 驱动器。

这种对象存储的使用得益于开放式表格式 (OTF) 的兴起，例如 Apache Iceberg、Apache Hudi 和 Delta Lake，这些格式一旦实现，就能使对象存储无缝地用作数据仓库的基础存储解决方案。这些规范还提供了传统数据仓库可能不存在的功能，例如快照（也称为时光倒流）、模式演变、分区、分区演变和零复制分支。

但是，如上所述，现代数据湖不仅仅是一个花哨的数据仓库——它还包含用于非结构化数据的**数据湖**。OTF 还提供了与数据湖中外部数据的集成。这种集成允许在需要时将外部数据用作 SQL 表——或者可以使用高速处理引擎和熟悉的 SQL 命令将外部数据转换并路由到数据仓库。

因此，现代数据湖不仅仅是数据仓库和数据湖的打包产品，并赋予了其不同的名称。它们共同提供了比传统数据仓库或独立数据湖所能提供的更多价值。

概念架构

分层是一种方便的方式来展示现代数据湖所需的所有组件和服务。分层提供了一种清晰的方式来对提供类似功能的服务进行分组。它还允许建立层次结构，将消费者置于顶部，将数据源（及其原始数据）置于底部。现代数据湖的层级，从上到下依次为：

• **消费层** - 包含高级用户用于分析数据的工具。还包含将以编程方式访问现代数据湖的应用程序和 AI/ML 工作负载。
• **语义层** - 用于数据发现和治理的可选元数据层。
• **处理层** - 此层包含查询现代数据湖所需的计算集群。它还包含用于分布式模型训练的计算集群。通过利用存储层在数据湖和数据仓库之间进行的集成，可以在处理层进行复杂的转换。
• **存储层** - 对象存储是现代数据湖的主要存储服务；但是，MLOP 工具可能需要其他存储服务，例如关系数据库。如果您正在追求生成式 AI，则需要向量数据库。
• **摄取层** - 包含接收数据所需的各种服务。高级摄取层将能够根据预定的时间表检索数据。现代数据湖应该支持各种协议。它还应该支持以流和批处理方式到达的数据。简单的和复杂的数据转换都可以在摄取层进行。
• **数据源** - 数据源层从技术上讲不是现代数据湖解决方案的一部分，但它包含在此文中，因为构建良好的现代数据湖必须支持各种数据源，这些数据源具有发送数据的不同功能。

下图以可视化的方式描述了上述所有层级以及实现这些层级可能需要的所有功能。这是一个端到端的架构，其中平台的核心是现代数据湖。此架构不仅关注处理层和存储层，还展示了摄取、转换、发现、治理和使用数据的所需组件。还包括支持依赖于现代数据湖的重要用例所需的工具，例如 MLOps 存储、向量数据库和机器学习集群。

本文中使用的方法的概念性非常重要。如果上图使用了产品名称，那么意义就会丢失。产品名称很少是为了表达意义而选择的——相反，它们是为了提高品牌知名度和记忆力而选择的。为此，我们的概念架构使用简单的名词，其中提供的功能是直观的。下一节将为熟悉当今市场上更流行的大数据项目和产品的读者提供一个具体实施的示例。但是，鼓励读者在为其组织做出决策时参考概念图。

最后，图中没有箭头。箭头通常表示数据流和依赖关系。显示所有可能的数据流和依赖关系会不必要地使图表复杂化。更好的方法是在用例的上下文中查看数据流和依赖关系。一旦在用例的上下文中隔离了一些组件，那么就可以更清晰地说明数据流和依赖关系。

具体架构

本节的目的是使用具体的开源示例来巩固我们参考架构的设计。对于渴望深入研究并开始构建的架构师来说，下面显示的项目和产品可以在概念验证中免费使用。当您的概念验证升级为一个获得资金的项目，并将在未来投入生产时，请务必检查在您的概念验证中使用所有软件的开源许可证和使用条款。

关于数据源的一些话

为您的现代数据湖提供数据的应用程序、设备和供应商种类繁多，它们的数据也是如此。内部现代应用程序可能能够使用 AVRO 和 Parquet 等格式实时传输结构良好的数据。另一方面，较旧的遗留应用程序可能只能以批处理的方式发送简单的文件，例如 XML、JSON 和 CSV。数据供应商可能根本不发送数据——而是期望他们的客户检索数据。

移动应用程序、网站、物联网设备和社交媒体应用程序通常会将其应用程序日志和其他遥测数据（使用统计信息）发送到您的摄取层。日志分析是现代数据湖的常用用例。此外，它们还可以发送图像和音频文件以在 AI/ML 工作负载中使用。

最后，希望利用生成式 AI 的组织需要将文件共享和门户（例如 SharePoint Portal Server 和 Confluence）中的文档存储在数据湖中。

现代数据湖需要能够有效且可靠地与所有这些数据源交互——将数据发送到数据湖存储或数据仓库存储。数据入库是摄取层架构的主要目的。这要求您的摄取层支持各种协议，能够接收流数据和批处理数据。接下来，让我们研究一下此层的组件。

摄取层

摄取层是您现代数据湖的入口。它负责将数据摄取到数据存储层。来自为现代数据湖的数据仓库端设计其数据馈送的源可以绕过数据湖，并将数据直接发送到数据仓库。另一方面，未以这种方式设计其数据馈送的源需要将其数据发送到数据湖，在那里可以对其进行转换，然后再摄取到数据仓库。

摄取层应该能够接收和检索数据。内部业务线 (LOB) 应用程序可能已获得通过流式传输或批处理发送数据的授权。对于这些应用程序，摄取层需要提供接收数据的端点。但是，数据供应商和其他外部数据源可能不愿意交付数据。摄取层还应提供计划的检索功能。例如，数据供应商可能会在每个月的第一天提供新的数据集。计划的检索功能将允许摄取层在正确的时间连接并下载数据。

流式传输是将数据传输到现代数据湖或任何目标的最佳方式。流式传输意味着以一种使其具有弹性、可用性和高性能的方式部署消息服务。消息服务通常提供一种排队机制，仅在成功存储消息后才确认消息的接收。然后，该服务将“恰好一次”地将消息传递到下游服务，该服务负责将消息中的数据保存到数据仓库或数据湖。（注意：一些消息服务提供“至少一次”传递，要求下游服务对数据源实现幂等更新。务必检查您最终使用的服务的细则。）这种摄取方式特别好的一点是，如果下游服务失败并且没有确认已成功处理消息，则该消息将重新出现在队列中以供将来摄取。消息服务还为重复失败的消息提供“死信队列”。

流式摄取很棒，但在许多情况下，不需要实时洞察。在这些情况下，批处理或小批量处理效果很好，并且实施起来也简单得多。对于批处理上传，S3 API 是您的最佳选择。MinIO 兼容 S3，任何当前将批处理数据发送到 S3 端点的数据源都可以在切换到 MinIO 数据湖后“照常工作”，只需更改连接即可。但是，许多组织可能仍然更喜欢 FTP/SFTP，因为它简单且能够在高度受限的环境中运行。MinIO 还支持 FTP 和 SFTP。此接口允许数据源以与发送数据到 FTP 服务器相同的方式将数据发送到 MinIO。从应用程序或用户的角度来看，使用 SFTP 将数据移到 MinIO 是无缝的，因为一切都基本相同——从策略、安全性等方面。

数据存储层

数据存储层是所有其他层依赖的基础。其目的是可靠地存储数据并高效地提供服务。现代数据湖的数据湖端将有一个对象存储服务，数据仓库端也将有一个对象存储服务。

如果需要，可以通过使用存储桶将数据仓库存储与数据湖存储分开，将这两个对象存储服务组合到对象存储的一个物理实例中。但是，如果处理层将对这两个存储服务施加不同的工作负载，请考虑将它们分开并安装在不同的硬件上。例如，常见的数据流是让所有新数据都进入数据湖。一旦进入数据湖，就可以对其进行转换并摄取到数据仓库，在那里可以被其他应用程序使用并用于数据科学、商业智能和数据分析的目的。如果这是您的数据流，那么您的现代数据湖将对您的数据仓库施加更多负载，您需要确保它运行在高端硬件（存储设备、存储集群和网络）上。

外部表功能允许数据仓库和处理引擎读取数据湖中的对象，就像它们是SQL表一样。如果数据湖用作原始数据的着陆区，那么此功能以及数据仓库的SQL功能可用于在将原始数据插入数据仓库之前对其进行转换。或者，外部表可以“按原样”使用，并与数据仓库内的其他表和资源连接，而无需将其移出数据湖。这种模式有助于节省迁移成本，并且可以通过将数据保留在一个位置来解决一些数据安全问题，同时将其提供给外部服务。  

大多数MLOP工具都结合使用对象存储和关系数据库来支持MLOps。例如，MLOP工具应存储训练指标、超参数、模型检查点和数据集版本。模型和数据集应存储在数据湖中，而指标和超参数则更有效地存储在关系数据库中。 

如果您正在探索生成式AI，则需要为您的组织构建一个自定义语料库。它应包含其他人没有的知识文档，并且只应使用真实准确的文档。此外，您的自定义语料库应使用向量数据库构建。向量数据库索引、存储并提供对文档及其向量嵌入的访问，这些向量嵌入是文档的数值表示。向量数据库有助于语义搜索，这是检索增强生成（RAG）所必需的，RAG是一种由生成式AI利用的技术，用于将自定义语料库中的信息与大型语言模型（LLM）的训练参数内存相结合。 

处理层

处理层包含现代数据湖支持的所有工作负载所需的计算能力。从高层次来看，计算能力分为两种：数据仓库的处理引擎和分布式机器学习的集群。 

数据仓库处理引擎支持针对数据仓库存储中的数据分布式执行SQL命令。摄取过程的一部分转换也可能需要处理层中的计算能力。例如，一些数据仓库可能希望使用Medallion架构——其他数据仓库可能选择使用带有维度表的星型模式。这些设计通常需要在摄取期间对原始数据进行大量的ETL操作。

现代数据湖中使用的数据仓库将计算与存储分离。因此，如果需要，多个处理引擎可以存在于单个数据仓库数据存储中。（这与传统的关联数据库不同，在关联数据库中，计算和存储紧密耦合，并且每个存储设备都有一个计算资源。）处理层的可能设计是为消费层中的每个实体设置一个处理引擎。例如，一个用于商业智能的处理集群，一个用于数据分析的单独集群，以及另一个用于数据科学的集群。每个处理引擎都将查询相同的数据仓库存储服务——但是，由于每个团队都有自己的专用集群，因此它们不会相互争夺计算资源。如果商业智能团队正在运行计算密集型的月末报表，那么它们将不会干扰其他团队可能正在运行的每日报表。

机器学习模型，尤其是大型语言模型，如果以分布式方式进行训练，则可以更快地完成训练。机器学习集群支持分布式训练。分布式训练应与MLOps工具集成，以进行实验跟踪和检查点。

可选的语义层

语义层帮助企业理解其数据。语义层位于处理层（从存储层提供数据）和消费层（包含正在查找数据的工具和应用程序）之间。它就像一个翻译器，弥合了业务语言和用于描述数据的技术术语之间的差距。它还有助于数据专业人员和业务用户查找与最终用户报表或AI/ML数据集创建相关的相关数据。

在最简单的形式中，语义层可以是数据目录或数据的有序清单。数据目录通常包括原始数据源位置（血缘关系）、模式、简短描述和详细描述。更强大的语义层可以通过整合策略、控制和数据质量规则来提供安全、隐私和治理。

此层是可选的。拥有少量数据源且数据源具有良好结构的数据馈送的组织可能不需要语义层。良好结构的数据馈送是指包含直观的字段名称和准确的字段描述的数据馈送，这些字段可以轻松地从数据源中提取并加载到数据仓库中。良好结构的数据馈送还应在源处实施数据质量检查，以便仅传输高质量数据到现代数据湖。

但是，拥有许多数据源的较大组织（在设计模式和馈送时将元数据视为事后想法）应考虑实施语义层。许多可用于此层的产品提供了有助于组织填充元数据目录的功能。此外，在复杂行业运营的组织也应考虑使用语义层。例如，金融服务、医疗保健和法律等行业大量使用非日常用语。当这些特定领域的术语用作表名和字段名时，数据的潜在含义可能难以确定。  

消费层

让我们通过查看最顶层（消费层）中运行的工作负载并讨论以下各层如何支持其特定用例来结束我们对现代数据湖层的介绍。下面许多工作负载通常可以互换使用或同义——这很不幸，因为在调查其需求时，最好有精确的定义。在下文的讨论中，我将精确描述每个功能，然后将其与现代数据湖的功能相匹配。

应用程序 - 自定义应用程序可以通过编程方式将SQL查询发送到现代数据湖，为最终用户提供自定义视图。这些可能是与在图底部作为数据源提交原始数据的相同应用程序。现代数据湖应支持的一个用例是允许应用程序提交原始数据、清理数据、将其与其他数据组合，并最终快速提供数据。应用程序可以使用使用现代数据湖数据训练的模型。这是现代数据湖应支持的另一个用例。应用程序应能够将原始数据发送到现代数据湖，对其进行处理，并将其发送到模型训练管道——然后，模型可用于在应用程序中进行预测。

数据科学是对数据的学习。数据科学家设计数据集，并可能设计将被训练和用于推理的模型。数据科学家还使用数学和统计学中的技术进行特征工程。特征工程是一种改进用于训练模型的数据集的技术。现代数据湖拥有一个非常巧妙的功能，即零拷贝分支，它允许数据像在Git存储库中分支代码一样进行分支。顾名思义，此功能不会复制数据——而是利用用于实现数据仓库的开放表格式的元数据层来创建数据唯一副本的外观。数据科学家可以尝试分支——如果他们的实验成功，那么他们可以将其分支合并回主分支，供其他数据科学家使用。

商业智能通常是回顾性的，提供对过去事件的见解。它涉及使用报表工具、仪表板和关键绩效指标（KPI）来提供对业务绩效的视图。BI所需的大量数据是聚合数据，创建这些数据可能需要大量的计算能力。 

数据分析另一方面，涉及分析数据以提取见解、识别趋势并进行预测。它更具有前瞻性，旨在了解某些事件发生的原因以及未来可能发生的情况。数据分析与数据科学重叠，因为它包含统计分析和机器学习技术。 

机器学习 - 机器学习工作负载是ML团队运行其实验和MLOps团队测试并将模型提升到生产环境的地方。进行机器学习研究和原型设计的团队与定期将模型投入生产的团队的需求之间通常存在相当大的差异。仅进行研究和实验工作的团队通常可以使用最少的ML-Ops工具，而将模型投入生产的团队将需要更加严格的工具和流程。

安全

现代数据湖必须为用户和服务提供身份验证和授权。它还应为静态数据和动态数据提供加密。本节将探讨这些安全方面。

数据湖和数据仓库都必须支持身份和访问管理（IAM）解决方案，以促进身份验证和授权。现代数据湖的两部分都应使用相同的目录服务来跟踪用户和组，允许用户在登录数据湖和数据仓库的用户界面时出示其公司凭据。对于编程访问，由于每个产品都需要不同的连接类型，因此需要提供的身份验证凭据将有所不同。同样，用于授权的策略也将有所不同，因为底层资源和操作是不同的。数据湖需要对存储桶和对象以及存储桶和对象操作进行授权。另一方面，数据仓库需要对表和与表相关的操作进行授权。

数据湖身份验证 - 每个与数据湖的连接都需要验证身份，并且数据湖应与组织的身份提供商集成。由于数据湖是符合S3标准的对象存储，因此应使用AWS签名版本4协议。对于编程访问，这意味着每个希望访问管理API或S3 API（例如PUT、GET和DELETE操作）的服务都必须提供有效的访问密钥和密钥。 

数据湖授权 - 授权是限制已认证客户端可以在数据湖上执行的操作和资源的行为。符合S3标准的对象存储应使用基于策略的访问控制（PBAC），其中每个策略描述一个或多个规则，这些规则概述了用户或用户组的权限。数据湖应支持S3特定的操作和条件来创建策略。默认情况下，MinIO拒绝访问用户分配或继承的策略中未明确引用的操作或资源。

数据仓库身份验证 - 与数据湖类似，每个连接到数据仓库的请求都必须经过身份验证，并且数据仓库应与组织的身份提供商集成以对用户进行身份验证。数据仓库可能会提供以下用于程序访问的选项：ODBC 连接、JDBC 连接或 REST 会话。每个选项都需要一个访问令牌。

数据仓库授权 - 数据仓库应支持针对数据仓库中发现的表、视图和其他对象的的用户、组和角色级别的访问控制。这允许根据用户的 ID、组或角色配置对单个对象的访问权限。

密钥管理服务器 - 为了确保数据在存储和传输过程中的安全，现代数据湖使用密钥管理服务器 (KMS)。KMS 是一种服务，负责生成、分发和管理用于加密和解密的加密密钥。

摘要

这就是现代数据湖从数据源到消费的五个层级。本文探讨了现代数据湖的概念参考架构。目标 - 为组织提供构建平台的战略蓝图，该平台可以有效地管理和提取其庞大而多样化的数据集的价值。现代数据湖结合了传统数据仓库和灵活数据湖的优势，提供了一个统一且可扩展的解决方案，用于存储、处理和分析数据。如果您想与 MinIO 团队深入了解建议使用哪些组件，请随时通过 hello@min.io 与我们联系。