精心设计的架构是任何强大信息技术（IT）系统的基石，数据湖仓也不例外。上一章阐明了现代数据分析平台的需求。该章还讨论了数据湖仓的演变。本章将专注于数据湖仓的关键要素。 该章将首先描述数据湖仓的系统背景。然后，它将研究与数据湖仓交互的参与者和系统。 接下来，我们将讨论数据湖仓的逻辑架构，包括七个层次。然后，本章将深入探讨数据湖仓架构的各种组件，并详细说明每个元素。本章的最后一节将重点介绍五个神圣的架构原则，为实施数据湖仓提供一个框架。 总之，本章涵盖以下主题：
- 为数据湖仓开发系统背景
- 开发逻辑数据湖仓架构
- 制定架构原则
为数据湖仓开发系统背景
系统背景图显示与系统交互的不同实体。在下面的案例中，系统是一个数据湖仓：
前面的图表显示了与数据湖仓进行交互的关键实体（系统或角色）。与数据湖仓的交互分为两个部分，如下所述：
- 数据提供方：向数据湖仓提供数据的系统或角色
- 数据使用方：从数据湖仓消费数据的系统或角色
让我们详细查看这些实体。
数据提供方
数据提供方是将数据导入数据湖仓库的任何系统或参与者。任何生成数据的系统都可能是数据提供方。以下列举了一些典型的数据提供方：
- 运营系统： 任何生成数据的系统都可能是数据提供方。通常，在线事务处理（OLTP）系统生成并存储事务数据。这类系统中的数据以高度规范化的方式存储在关系数据库中。由于数据高度规范化，设计优化以有效捕获和更新事务。这些系统不适用于分析。OLTP系统在所有组织中普遍存在，并构成结构化数据存储的大部分。然而，并非所有操作数据都是关系型的。操作数据存储的另一种形式包括非关系型（NoSQL）数据库。NoSQL数据库中的数据不是表格形式的。它被设计为以灵活的模式存储数据，并且其结构可以根据输入数据类型迅速适应。这些数据库以各种格式存储数据，包括键-值对、图形和JavaScript Object Notation（JSON）。
- 文本数据： 在涉及到非结构化数据/文档时，文本数据是最主要的非结构化数据类型。这种数据包括文档和纯文本，如手写笔记。通过自然语言处理（NLP），人工智能（AI）的一个成熟分支，我们可以从文本数据中提取丰富的见解。AI算法在分析文本方面变得越来越复杂。
- 流数据： 数据不仅存在于静止状态。有一类数据是在运动中的。流数据意味着在固定时间内不断从系统传输的数据。流数据包括来自任何物联网（IoT）设备的遥测数据，来自社交媒体平台（Twitter、Facebook（Meta）、YouTube等）的连续数据流，来自金融交易平台的持续数据以及传输位置信息的地理空间服务。如果实时分析这种数据，这种数据可以满足一系列用例，如复杂事件处理（CEP）、情感分析、关键字检测等。
- 媒体数据： 媒体数据包括与语音、视频和图像相关的各种数据结构。我们可以使用音频数据来实现诸如语音识别、语音到文本翻译和实时语音翻译等用例。媒体数据还包括视频和图片，我们可以用来执行广泛的用例。卷积神经网络（CNN）等AI算法已经发展到可以更适合于识别图像中的对象的程度，超过了人类。通过大量的视频和图像数据，AI技术被用于实现从物体检测到自动驾驶等先进用例。
我们已经了解了典型的数据提供方以及这些数据类型可以完成的一些用例。现在，让我们关注谁是将使用数据湖仓库中数据的利益相关者。
以下表格总结了关键的数据提供方、数据类型以及典型的用例：
接下来，让我们看看谁将使用这些数据。
数据使用者
一旦数据被摄入数据湖仓库，各利益相关方将以其原始或经过转换的形式使用它。这些利益相关方将从数据湖仓库中提取数据以实现特定目的。每个使用数据湖仓库的消费者都有个人动机。一个良好架构的数据湖仓库应该能够满足每个利益相关方的需求。让我们看一下从数据湖仓库中提取数据的一些典型人员和系统，如下所示：
数据科学家：我们看到首批使用数据湖仓库的人是数据科学家，他们从数据湖仓库中提取数据以测试他们可能想要证明或反驳的各种假设。数据科学家处理各种类型的数据：结构化、非结构化、原始和经过处理的。数据湖仓库需要能够确保数据对于特定用途易于识别，用户必须精通多种编程语言和技术，包括Python、R和结构化查询语言（SQL），而且架构需要为这些用户提供创建和测试模型的正确平台。
分析师：使用数据湖仓库的第二类人员是分析师。他们主要受业务驱动，寻找业务问题的答案，并精通报告工具或基于SQL的语言。他们主要处理经过处理的数据，日常工作包括进行业务分析。通过查询、聚合和切片/切块数据，主要是清理和处理过的数据，完成这项任务。数据湖仓库应该满足这类用户，并为他们提供执行有效和无缝数据分析的平台。
管理人员：数据湖仓库的重度用户的第三类人员是需要定期报告进行业务决策的管理人员。他们深入研究被聚合并专门针对业务需求的处理过的数据。他们可能对技术有一定了解，可能需要一个游乐场来使用商业智能（BI）工具创建他们的报告或分析。这些人通常通过报告系统提取他们的报告。
报告系统：数据湖仓库的另一个关键消费者是报告系统。报告系统间接为想订阅定期、临时或自助报告的人提供服务。此外，可能还有其他类型的报告系统用于监管报告。这些系统定期从数据湖仓库中提取数据，然后将报告存储以供交付。
下游应用系统：随着数据从上游应用程序摄入数据湖仓库，下游应用程序也会消费处理过的信息。这些应用程序可以是在线事务处理（OLTP）系统，也可以是另一个数据仓库或数据湖，其目标与企业数据湖仓库（EDL）不同。通常，用于下游消费的数据将周期性地从数据湖仓库中提取，或者通过可行的机制推送到目标。
基于应用程序编程接口（API）的系统：数据湖仓库还需要能够以API的形式暴露数据。数据湖仓库处理各种类型的数据，需要为多个内部和外部系统提供服务。虽然对于某些消费者而言，紧密耦合的交付机制可能有效，但基于API的数据消费是一种可扩展且实际的选择。此外，基于API的系统还可以暴露由组织之外的外部利益相关方使用的数据。
数据共享系统：数据共享系统代表一种新型的数据消费机制。当数据作为数据市场的一部分被消费或共享时，就会使用这种机制。在订阅其消费之前，数据共享机制也用于达成有关数据使用的具体条款。以下表总结了数据消费者的主要动机和典型要求：
那么，现在我们知道谁可能会使用我们的湖仓库，让我们开始考虑如何构建它。
制定一个合理的数据湖仓库架构
我们已经讨论了数据湖仓库系统的上下文。现在让我们深入研究制定一个合理的数据湖仓库逻辑架构。逻辑架构关注集成以满足特定功能需求（FR）和非功能性需求（NFR）的组件。它被抽象到一个技术无关的层次，侧重于组件功能。逻辑架构关注两种类型的需求，如下所示：
- FR是满足特定业务或领域驱动行为的需求。这些类型的需求是由特定业务功能的任务和需求驱动的。
- NFR是规定系统在特定上下文中需要满足的标准的需求。例如，典型的NFR包括特定查询预计完成的时间、数据加密的要求等。
一个良好设计的系统确保它被设计来满足NFR，而不会进行太多的权衡。以下图表描述了数据湖仓库的逻辑架构： 如前图所示，数据湖仓库架构具有七个层次，它们紧密结合在一起形成一个良好设计的数据湖仓库。现在让我们详细研究这些层次中的每一个。
数据摄入层
首个详细介绍的层次是数据摄入层。这一层是外部数据提供者与数据湖仓库之间的集成点。如下图所示，有两种类型的数据摄入服务：
以下是对这两种服务的更详细解释：
批处理数据摄入服务：批处理摄入意味着数据定期被摄入到数据湖仓库中。摄入的频率可能从几分钟到几天不等。定期摄入的频率将取决于许多因素，包括非功能性需求（NFRs）、数据源生成数据的能力以及数据源推送数据或允许服务拉取数据的能力。典型的运营系统要求将数据推送或拉入数据湖仓库。在批处理摄入数据时，一个关键的考虑因素是源系统的可用性以进行数据摄入，以及摄入的批处理数据的大小。这两个因素将影响数据如何被摄入到数据湖仓库中。
实时数据摄入服务：实时数据摄入服务使数据在生成时被拉入到数据湖仓库中。实时数据是一种不断流动的数据，因此必须识别感兴趣的数据并将其拉入数据湖仓库进行存储或实时处理。实时摄入通常包括排队服务，如Kafka，它可以将实时流分组并临时存储为队列以进行摄入。流服务还用于通过变更数据捕获（CDC）不断捕获数据库中的数据变化。在摄入流数据时，与流数据吞吐量和延迟相关的要求变得重要。
数据湖层
一旦数据摄入层摄入数据，就需要将其存储，并对其执行各种转换，以便为使用进行数据转换。最终，数据被安置在数据湖中。您可以在这里看到对这一层的可视化表示：
数据湖层具有四个重要的存储类别，如下所述：
原始数据：原始数据存储是数据从数据提供者那里落地的地方。顾名思义，数据以其自然形式存储在原始数据存储区。因此，数据保持其源格式、结构和内容的真实性。原始数据存储还使您能够将数据生成器与数据湖仓库解耦。
中间数据：随着数据穿过数据湖仓库并进行转换，会创建中间数据集。这些中间数据集可以是瞬时的或持久的。这些数据集可以存储在数据湖层中，并加速数据处理。中间数据还使数据处理管道对于完全重启具有免疫性。
处理过的数据：一旦数据经过转换，我们可以将生成的数据集存储在数据湖中。然后可以使用此数据集进行服务或分析。处理过的数据适用于下游消费。然而，在数据湖层中，处理过的数据提供了相对较低的存储成本。它还使数据科学家和分析师能够在不对服务层造成负担的情况下使用处理过的数据进行实验或分析。
存档数据：用于洞察的数据通常是热数据。热数据意味着用于存储数据的存储技术确保更好的吞吐量和可访问性。然而，并非所有数据都需要是热数据。不用于分析但需要存储的数据可以移动到更便宜的存储技术中。这种数据称为存档数据。
数据处理层
为了能够为洞察消费，数据需要进行转换或处理。数据处理服务负责将摄入的数据转换为可以提供给利益相关方的形式。您可以在这里看到对这一层的可视化表示：
有两种类型的数据处理服务，如下所述：
批处理数据处理服务：批处理数据处理定期处理数据，无需最终用户交互。数据首先落地到原始数据区。一旦数据落地到原始数据区，批处理处理服务就会提取原始数据并执行所需的转换。批处理数据处理服务需要按需提供，并可以根据您的需求进行扩展。
流数据处理服务：另一种处理是流数据处理。这捕获实时流数据并在不需要数据落地或存储到磁盘的情况下进行处理。所有流处理都在内存中进行，数据几乎实时地进行转换。典型的流数据处理服务还具有一个消息排队层，间断地捕获数据流并将其排队进行进一步处理。当数据流被摄入并处理时，原始数据被发送到数据湖存储区作为一条路径。另一条路径执行实时处理，并将输出发送给下游消费。最终，转换后的数据也被推送到数据湖层进行持久存储。
接下来，让我们介绍数据服务层。
数据服务层
一旦数据被处理，就需要为下游消费提供服务。信息可供各种利益相关方使用，每个利益相关方都有根据其需求定制的要求。您可以在以下图表中看到构成这一层的服务：
一般而言，有四种类型的数据服务服务，如下所述：
数据仓库服务：第一种数据服务服务是数据仓库服务。数据仓库服务提供经过清理和转换的数据，可用于多种目的。首先，它作为报告和商业智能的层。其次，它是查询业务或数据分析的平台。第三，它作为存储需要在线和可用的历史数据的仓库。最后，它还作为其他可能满足特定部门需求的下游数据集市的转换数据源。
实时数据服务：第二种服务类型是提供实时数据。实时数据服务用于为各种下游应用提供服务。此类应用的一些示例包括移动系统、向下游应用提供实时数据（如客户关系管理系统）、网站或移动应用上的推荐引擎以及实时的异常检测系统（如欺诈检测）。实时数据服务以多种技术格式呈现，在正确提供的情况下，可以为业务增加巨大的价值。
基于API的数据服务：用于共享数据的第三种服务是基于API的数据服务。API是一种接口，允许应用程序使用一组简单的命令与外部服务交互。数据也可以作为API交互的一部分提供。由于数据暴露给多个外部服务，基于API的方法可以扩展到与外部服务安全地共享数据。通过API提供的数据以JSON格式提供，因此使用API提供数据的技术应能够支持JSON格式。例如，NoSQL数据库可以存储此类数据。
数据共享服务：第四种服务是数据共享服务。数据共享服务以任何格式和任何大小，从组织内部或其他组织的多个来源共享数据。此类服务提供了共享数据所需的控制，并允许创建数据共享策略。它还以结构化的方式启用数据共享，并提供完整的可见性，了解数据如何共享以及如何使用。数据共享系统使用API进行数据共享。
数据分析层
数据分析层涉及从数据中提取洞察的服务。它们充当分析师、数据科学家和商业智能用户的游乐场，用于创建报告、进行分析，并进行人工智能/机器学习模型的实验。您可以在以下图表中看到构成这一层的服务：
数据分析层有三种类型的服务，如下所述：
分析沙盒服务：分析沙盒是一个让数据科学家和分析师使用其工具进行数据实验的场所。沙盒应该提供不同类型的工具，用于基于SQL的分析和开发机器学习模型。该层还应与数据湖层和数据服务层实现无缝集成。该层应根据需求按需启动和关闭一组工具，以促进快速实验。
人工智能和机器学习（AI-ML）服务：在现代数据分析平台中，AI和ML服务是关键组件。AI-ML服务允许数据科学家构建、训练和部署可投入生产的AI-ML模型。该层还提供维护和监视这些模型的框架。此外，它为团队在构建这些模型时进行协作提供了能力。该服务应能够根据需要进行缩放，并能够促进自动模型部署和运营。
商业智能（BI）服务：BI服务自企业数据仓库（EDW）时代以来就存在。在数据湖仓库架构中，它们履行相同的功能。此服务涉及用于创建报告、执行数据可视化和促进自助商业智能的工具和技术。它主要侧重于创建当前和历史运营的不同表格或视觉视图。
数据治理层
“垃圾进，垃圾出” 的原则对于数据湖仓库也是适用的。数据湖仓库中的数据需要得到适当的管理，而这一层负责处理这个问题。您可以在这里看到其可视化表示：
有四个组件有助于确保数据湖仓库不会变成数据沼泽。如下所述：
数据策略管理：第一个组件不是技术组件，而是一组数据政策和标准。数据政策是一组描述控制数据湖仓库中的标准、安全性、完整性、质量和使用规则的陈述。
数据目录和整理服务：数据目录和整理是组织数据清单的过程，以便可以轻松识别数据。该服务确保所有源系统数据、数据湖中的数据和数据仓库、数据处理管道以及从数据湖仓库中提取的输出都得到适当的目录整理。将数据目录服务视为数据的“Facebook”——一个可以获取有关数据湖仓库内容的视觉信息的地方，包括有关数据之间关系和数据经历的转换线的信息。
数据质量服务：存储或摄入数据湖仓库的任何数据都必须具有决定数据的可靠性和可用性的数据质量评分。有许多参数可以确定数据的质量。其中一些参数包括数据的完整性、数据的一致性和数据的准确性。数据质量服务确保数据是完整、一致和准确的。
数据安全层
数据湖仓库架构的最后一层是数据安全层。数据安全本身非常重要，其重要性无法过分强调。您可以在以下图表中看到构成这一层的服务：
数据安全层有四个关键组件，如下所述：
身份和访问管理（IAM）服务：对数据湖仓库的访问必须是安全的，并且必须基于需求。IAM服务充当访问数据湖仓库的门户。IAM服务确保访问数据湖仓库的授权和身份验证是安全可靠的。它提供防范恶意登录尝试的防御措施，并通过基于风险的访问控制、身份保护工具和强大的身份验证选项来保护凭据，而不会干扰生产力。
数据加密服务：数据加密是一种安全方法，其中信息被编码，只有具有正确加密密钥的用户才能访问或解密。当数据存储在云中时，数据加密是必不可少的。使用不同种类的算法对数据进行加密。加密提供了对静态数据的数据保护。它防止各种类型的网络攻击，并保护敏感数据。数据加密也可能是组织在数据治理和合规性工作中所需的。因此，数据安全层需要具有根据需要加密和解密数据的工具。
数据脱敏服务：许多数据子集需要进行脱敏，以保护个人的身份或隐私。此类数据包括电子邮件、社会身份号码、信用卡号等。数据脱敏是创建数据的加密但可读版本的一种方式。其目标是在不需要实际数据时保护敏感数据并提供功能替代。数据安全层需要具有根据需要对这些敏感数据进行脱敏和解脱敏的工具。
网络安全服务：数据湖仓库中的数据需要始终保持安全。对数据的访问应该受到控制，以拒绝任何未经授权的访问。还需要确保在外部网络与数据湖仓库之间流动的数据是安全的。网络安全服务提供这些功能。
本节概述了数据湖仓库架构的七个层次。第3到第7章将详细介绍这些层次。这些章节将详细阐述每个层次，并说明在实践中使用的常见模式。
现在，让我们转到需要应用的架构原则。
制定架构原则
如前面的部分所示，许多组件构成了数据湖仓库架构。数据湖仓库架构需要遵循一组架构原则，以确保数据湖仓库能够实现其成为灵活的AI和BI平台的目标，并能够灵活应对不断变化的需求。
架构原则管理任何架构构造，并定义了其基本的一般规则和使用指南。我们可以根据组织的需求定制这些原则。然而，有五个原则是神圣不可侵犯的。这些原则在以下图表中表示：
核心要有纪律，边缘要有弹性
创建新的架构范式的目的是保持灵活性和创新性，但它需要以实际的方式进行治理。这种平衡是一条微妙的线路。第一个神圣不可侵犯的原则体现了这种平衡。在核心保持纪律意味着存储数据的层面在其对数据管理的方法上需要有结构。这些层面需要有详细的治理政策，不留任何模糊的余地。然而，数据湖仓库的边缘，即数据被转换、锻造并变得有助于洞察的层面，需要具有灵活性。灵活性并不意味着在方法上一团乱。这些层面仍在数据湖仓库的政策范围内受到管理。然而，它们在根据需求创建新特性方面表现出一定的灵活性。在边缘保持灵活的一个例子是从数据湖层和数据仓库到数据服务层混合原始数据以创建机器学习模型。这些数据集具有不同的质量分数和属性。然而，这种灵活性是可以接受的，因为它促使快速洞察的产生。
解耦计算和存储
数据湖仓库存储了大量数据，以结构化和非结构化格式存储在数据湖层和服务层。数据需要使用不同类型的计算引擎进行处理，可以是基于批处理的计算或基于流的计算。计算与存储层紧密耦合会剥夺数据湖仓库所需的灵活性。解耦计算和存储还涉及成本问题——存储便宜而持久，而计算昂贵而短暂。这为您提供了根据需要启动计算服务并按需扩展的灵活性，还提供更好的成本控制和成本可预测性。
企业数据仓库（EDW）和数据湖模式中的一个关键挑战是计算和存储的紧密耦合。计算需要提前规划，无论是否被使用。随着存储的增加，计算也需要相应地进行扩展。云计算平台提供了解耦计算和存储的灵活性。
