架构师指南：现代 Datalake 参考架构

这篇文章的缩写版本于 2024 年 3 月 26 日出现在 The New Stack 上。

旨在最大化其数据资产的企业正在采用可扩展、灵活和统一的数据存储和分析方法。这一趋势是由企业架构师推动的，他们的任务是制定符合不断变化的业务需求的基础设施。现代数据湖体系结构通过将数据湖的可伸缩性和灵活性与数据仓库的结构和性能优化集成来满足这一需求。这篇文章是理解和实施现代数据湖架构的指南。

什么是现代数据湖？

现代数据湖是一半数据仓库和一半数据湖，对所有事情都使用对象存储。这听起来像是一种营销技巧 - 将两个产品放在一个包中并称之为新产品 - 但本文中将介绍的数据仓库比传统的数据仓库更好 - 它使用对象存储 - 因此，它在可伸缩性和性能方面提供了对象存储的所有好处。采用这种方法的组织只需为他们需要的东西付费（通过对象存储的可扩展性促进），如果需要极快的速度，他们可以为其底层对象存储配备通过高端网络连接的 NVMe 驱动器。

以这种方式使用对象存储的原因是 Apache Iceberg、Apache Hudi 和 Delta Lake 等开放表格式（OTF）的兴起，这些规范一旦实施，就可以无缝地将对象存储用作数据仓库的底层存储解决方案。这些规范还提供了传统数据仓库中可能不存在的功能，例如快照（也称为时间旅行）、架构演变、分区、分区演变和零拷贝分支。

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

因此，新式数据湖不仅仅是一个数据仓库和一个数据湖，它位于一个具有不同名称的包中。总的来说，它们提供了比传统数据仓库或独立数据湖更多的价值。

概念架构

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

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

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

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

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

混凝土建筑

本节的目的是通过具体的开源示例来为我们的参考架构设计奠定基础。对于渴望潜入并开始建造的建筑师来说，下面显示的项目和产品可以在概念验证中免费使用。当您的 POC 毕业到一个有朝一日将在生产中运行的资助项目时，请务必检查 POC 中使用的所有软件的开源许可证和使用条款。

关于数据源的几句话

为您的现代 Datalake 提供数据的应用程序、设备和供应商有多种形式，其数据也是如此。本地现代应用程序可能能够使用 AVRO 和 Parquet 等格式实时流式传输结构良好的数据。另一方面，较旧的遗留应用程序可能只能批量发送简单文件，例如 XML、JSON 和 CSV。数据供应商可能根本不发送数据 - 期望他们的客户检索数据。

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

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

现代数据湖需要能够高效可靠地与所有这些数据源进行交互，从而将数据传输到 Data Lake Storage 或 Data Warehouse Storage。载入数据是我们体系结构的引入层的主要用途。这要求引入层支持能够接收流数据和批处理数据的各种协议。接下来，让我们研究一下这一层的组件。

引入层

引入层是通往新式 Datalake 的入口。它负责将数据摄取到数据存储层中。来自为新式数据湖的数据仓库端设计源的源的结构化数据可以绕过数据湖，并将其数据直接发送到数据仓库。另一方面，没有以这种方式设计源的源将需要将其数据发送到数据湖，在将其引入数据仓库之前可以对其进行转换。

引入层应该能够接收和检索数据。内部业务线（LOB）应用程序可能已被授予通过流式处理或批处理发送其数据的授权。对于这些应用程序，引入层需要提供用于接收数据的终结点。但是，数据供应商和其他外部数据源可能不太愿意提供数据。引入层还应提供计划的检索功能。例如，数据供应商可能会在每个月的第一天提供新的数据集。计划的检索功能将允许引入层在正确的时间连接和下载数据。

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

流式引入很棒，但在许多情况下，不需要实时见解。在这些情况下，批处理或小批量处理工作正常，并且实现起来要简单得多。对于批量上传，S3 API 是您的最佳选择。MinIO 符合 S3 标准，当前向 S3 终端节点发送批处理数据的任何数据源都将“按原样”工作，只需切换到 MinIO 数据湖后进行连接更改。但是，许多组织可能仍然更喜欢 FTP/SFTP，因为它的简单性和在高度受限的环境中运行的能力。MinIO 还支持 FTP 和 SFTP。此接口允许数据源将数据发送到 MinIO，就像将数据发送到 FTP 服务器一样。从应用程序或用户的角度来看，使用 SFTP 将数据移动到 MinIO 是无缝的，因为从策略、安全性等角度来看，一切都基本相同。

数据存储层

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

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

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

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

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

处理层

处理层包含现代 Datalake 支持的所有工作负载所需的计算。在较高级别上，计算有两种类型：数据仓库的处理引擎和分布式机器学习的集群。

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

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

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

可选语义层

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

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

此图层是可选的。数据源很少且结构良好的源的组织可能不需要语义层。结构良好的源是包含直观的字段名称和准确的字段描述的源，可以很容易地从数据源中提取并加载到数据仓库中。结构良好的源还应在源头实施数据质量检查，以便仅将质量数据传输到现代数据湖。

但是，如果大型组织具有许多数据源，在设计架构和源时，元数据是事后才想到的，则应考虑实现语义层。此图层中可以使用的许多产品都提供了帮助组织填充元数据目录的功能。此外，在复杂行业中运营的组织应考虑语义层。例如，金融服务、医疗保健和法律等行业大量使用非日常用语的术语。当这些特定于域的术语用作表名和字段名时，数据的基本含义可能难以确定。

消费层

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

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

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

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

数据分析涉及对数据的分析，以提取见解、识别趋势并做出预测。它更具前瞻性，旨在了解某些事件发生的原因以及未来可能发生的事情。数据分析与数据科学重叠，因为它结合了统计分析和机器学习技术。

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

安全

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

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

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

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

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

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

密钥管理服务器 - 为了确保静态和传输中的安全性，新式数据湖使用密钥管理服务器（KMS）。KMS 是一种服务，负责生成、分发和管理用于加密和解密的加密密钥。