《Data Lakehouse in Action》学习笔记--第2章 Data LakeHouse架构概述

深思熟虑的架构是任何健壮的信息技术(IT)系统的基石，data lakehouse也不例外。 上一章阐述了现代数据分析平台的必要性。 还讨论了data lakehouse的演变。 本章将重点讨论data lakehouse的关键元素。

本章将从描述data lakehouse的系统上下文开始。 然后，研究与data lakehouse交互的参与者和系统。

我们将讨论由7层组成的data lakehouse的逻辑架构。 然后，本章将深入研究data lakehouse架构的各个组件，并对每个组件进行详细阐述。 本章的最后一节将重点讨论为实现data lakehouse提供框架的五个神圣的架构原则。

总而言之，本章涵盖以下主题:

• data lakehouse系统上下文

• data lakehouse逻辑架构

• 架构原则

Data LakeHouse系统上下文

系统上下文关系图显示了与系统交互的不同实体。在下图中是一个data lakehouse的系统上下文：

图2.1 data lakehouse系统上下文图

上图显示了与Data LakeHouse交互的关键实体(系统或参与者)。与Data LakeHouse的交互有两个部分，如下所示:

• 数据提供者：向Data LakeHouse提供数据的系统或参与者

• 数据使用者：使用来自Data LakeHouse的数据的系统或参与者

让我们详细检查这些实体。

数据提供者

数据提供者是将数据接入到Data LakeHouse的任何系统或参与者。任何生成数据的系统都是潜在的数据提供者。这里列出了一些典型的数据提供者:

• 软件操作系统：任何生成数据的系统都是潜在的数据提供者。 通常，在线事务处理(OLTP)系统生成和存储事务性数据。 这些系统中的数据以高度规范化的方式存储在关系数据库中。 由于数据是高度规范化的，因此该设计被优化以有效地捕获和更新事务。 这样的系统不适合分析。 OLTP系统在所有组织中都很普遍，并构成了大多数结构化数据存储。 然而，并不是所有的操作数据都是关系型的。 另一种形式的操作性数据存储包括Not-Only SQL (NoSQL)数据库。 NoSQL数据库中的数据不是表格式的。 它的设计目的是将数据存储在一个灵活的模式中，其结构可以根据输入数据类型快速调整。 这些数据库以各种格式存储数据，包括键值对、图和JSON。

• 文本数据：对于非结构化数据/文档，文本数据是最主要的非结构化数据类型。 这类数据包括文档和纯文本，比如手写的笔记。 自然语言处理(NLP)是人工智能(AI)的一个已建立的分支，我们可以从文本数据中提取宝贵的见解。 人工智能算法分析文本的能力正变得越来越复杂。

• 流数据：数据不只是静止的。有一类处于运动中的数据。流数据是指在固定时间内从系统中不断传输的数据。流数据包括来自物联网(IoT)设备的遥测数据，来自社交媒体平台(Twitter、Facebook (Meta)、YouTube、点击流、游戏等)的持续反馈，来自金融交易平台的连续数据，以及传输位置信息的地理空间服务。如果进行实时分析，这类数据将满足一系列用例，如复杂事件处理(CEP)、情感分析、关键字检测等。

• 媒体数据：媒体数据包括与语音、视频和图像相关的各种数据结构。我们可以使用音频数据来实现语音识别、语音到文本翻译和实时语音翻译等用例。媒体数据还包括视频和图片，我们可以使用它们来执行广泛的用例。卷积神经网络(CNN)等人工智能算法已经发展到比人类更能识别图像中的物体。随着大量视频和图像数据的出现，人工智能技术正被用于实现从目标检测到自动驾驶汽车的高级用例。

我们已经看到了典型的数据提供者和这些类型的数据可以实现的用例场景。现在，让我们关注谁是使用来自Data LakeHouse的数据的利益相关者。

下表总结了关键的数据提供者、数据类型和被实现的典型用例:

图2.2 典型的数据提供者和用例

接下来，让我们看看谁将使用这些数据。

数据使用者

一旦数据被接入到Data LakeHouse，各种利益相关方将以原始或转换后的形式使用它。 这些利益相关者将从Data LakeHouse中提取用于特定目的的数据。 每个消费者都有使用Data LakeHouse的个人动机。 一个架构良好的Data LakeHouse应该能够满足每一个涉众的需求。 让我们看看一些典型的用户和系统，他们使用来自Data LakeHouse的数据，如下所示:

• 数据科学家：我们看到使用Data LakeHouse的第一类人是数据科学家，他们从Data LakeHouse中提取数据，以测试他们可能想要证明或反对的各种假设。 数据科学家研究各种类型的数据：结构化的、非结构化的、原始的和处理过的。 Data LakeHouse需要能够确保数据对于特定用途是容易识别的，用户必须精通许多编程语言和技术，包括Python、R和结构化查询语言(SQL)， 架构需要为这个用户提供正确的平台来创建和测试他们的模型。

• 数据分析师：使用Data LakeHouse的第二类人是分析师。 他们主要是业务驱动的，寻求业务问题的答案，并且精通报表工具或基于SQL的语言。 他们主要处理处理过的数据，他们的日常工作包括执行业务分析。 通过查询、聚合和切片数据(主要是清理和处理的数据)来完成这项任务。 Data LakeHouse应该迎合这样的用户，为他们提供一个平台，进行有效和无缝的数据分析。

• 管理人员：第三类大量使用Data LakeHouse的人是管理人员，他们需要定期的报表以进行业务决策。 他们深入研究那些按特定业务需求处理过数据。 他们可能是半技术通，可能需要一个使用商业智能(BI)工具创建报表或分析的地方。 这些人通常通过报表系统获取他们所需的报表。

• 报表系统：Data LakeHouse的其他关键用户是报表系统。 报表系统间接地迎合了希望订阅预定的、临时的或自助报表的人员。 此外，可能还有其他类型的报表系统是为了监管报表。 这些系统定期从Data LakeHouse中提取数据，然后存储报表以便交付。

• 下游应用系统：当数据从上游应用程序接入到Data LakeHouse时，下游应用程序也会使用处理过的信息。 这些应用程序可能是OLTP系统，也可能是另一个数据仓库或数据湖，其任务与企业Data LakeHouse(EDL)不同。 通常，用于下游消费的数据要么定期从Data LakeHouse中提取，要么使用一种可行的机制将数据推送到目的地。

• 基于应用程序编程接口(API)的系统：Data LakeHouse还需要能够以API的形式公开数据。 Data LakeHouse处理各种类型的数据，需要服务于多个内部和外部系统。 虽然紧密耦合的交付机制可能适用于特定的使用者，但基于API的数据使用是一种可伸缩且实用的选择。 此外，基于API的系统还可以公开不属于组织的外部涉众所使用的数据。

• 数据共享系统：数据共享系统代表了一种新型的数据消费机制。 当数据作为数据市场的一部分被消费或共享时，就会使用这种机制。 当需要就数据使用的特定条款达成一致时，也可以使用数据共享机制。

下表总结了数据使用者的主要动机和典型需求:

图2.3 典型的数据使用者和用例

所以，现在我们知道谁可能在使用我们的lakehouse，让我们开始考虑如何建造它。

Data LakeHouse逻辑架构

我们讨论了Data LakeHouse系统上下文。 现在让我们开始开发Data LakeHouse逻辑架构。 逻辑架构关注集成以满足特定功能需求(FR)和非功能需求(NFR)的组件。 它被抽象到一个与技术无关的级别，并专注于组件功能。 逻辑架构主要关注以下两种需求:

• FR是实现特定业务或领域驱动的行为的需求。 这些类型的需求是由任务和特定业务功能的需求驱动的。

• NFR是一种需求，它指定了需要满足的标准，以便系统在特定的环境中发挥作用。 例如，典型的NFR包括预期完成特定查询的时间、数据加密的需求，等等。

一个架构良好的系统可以确保它的架构能够满足NFR，而不会有太多的权衡。 下图描述了Data LakeHouse的逻辑架构:

图2.4 Data LakeHouse逻辑架构

如上图所示，Data LakeHouse架构有七个层，它们交织在一起形成了一个架构良好的Data LakeHouse。现在让我们详细研究每一层。

数据接入层

要详细说明的第一层是数据接入层，也叫数据摄取/摄入层。这一层是Data LakeHouse的外部数据提供者之间的集成点。有两种类型的数据接入服务，如下图所示:

图2.5 数据接入服务的类型(译者注：这就需要一个流批一体的ETL工具 译者当前使用的是Streamsets流批一体ETL工具)

这里有更详细的解释:

• 批量数据接入服务：批量接入指的是定期将数据接入到Data LakeHouse。 接入的频率从几分钟到几天不等。 周期频率取决于许多因素，包括NFR、数据源生成数据的能力，以及数据源推送数据或允许服务拉取数据的能力。 典型的软件操作系统需要将数据推入或拉入Data LakeHouse。 在分批地接入数据时，需要考虑的一个关键问题是接入数据的源系统的可用性以及接入批次数据的大小。 这两个因素都将影响数据如何被接入到Data LakeHouse。

• 实时数据接入服务：实时数据接入服务允许数据在生成时被拉入(pull)Data LakeHouse。 实时数据是一种恒定的数据流，因此必须识别感兴趣的数据并将其拉入Data LakeHouse进行存储或实时处理。 实时接收通常由队列服务(如Kafka)组成，它可以将实时流分组并临时存储为接收队列。 流服务还用于通过更改数据捕获(CDC)持续捕获数据库中的数据更改。 在接收流数据时，与流数据吞吐量相关的考虑和与延迟相关的需求变得很重要。

数据湖层

一旦数据接入层接入数据，就需要将其送到存储中，并且需要对其执行各种转换，以供使用。最后，将数据落在数据湖中。可以在这里看到这一层的可视化表示:

图2.6 数据湖层的数据存储类型

数据湖层有四种重要的存储类型，如下所示:

• 原始数据：原始数据存储是存储从数据提供者获取的数据。 顾名思义，数据以其自然形式存储在原始数据存储中。 因此，数据与源格式、结构和内容是一致的。 原始数据存储可以将数据生成位置与Data LakeHouse解耦。

• 中间数据：当数据经过Data LakeHouse并进行转换时，中间数据集被创建。 这些中间数据集可以是暂时的，也可以是持久的。 这些数据集可以存储在数据湖层，可以加速数据处理。 中间数据还使数据处理管道不受完全重启的影响。

• 处理数据：一旦数据被转换，我们就可以将结果数据集存储在数据湖中。 然后可以将该数据集用于服务或分析目的。 经过处理的数据适用于下游消费。 然而，在数据湖层中处理的数据提供了相对便宜的存储成本。 它还允许数据科学家和分析人员使用处理过的数据进行实验或分析，而不会给服务层带来额外的开销。

• 存档数据：用于洞察的数据通常都很热门。 热数据是指用于存储数据的存储技术可以保证更好的吞吐量和可访问性。 然而，并不是所有的数据都需要是热的。 不用于分析但需要存储的数据可以转移到更便宜的存储技术。 这种数据称为归档数据。

数据处理层

需要对数据进行转换或处理，以便对其进行消费。 数据处理服务执行将接收到的数据转换为可以提供给涉众的形式的工作。 可以在这里看到这一层的可视化表示:

图2.7 数据处理服务的类型

有两种类型的数据处理服务，如下所述:

• 批量数据处理服务：批量数据处理服务周期性地处理数据，无需终端用户交互。 数据首先落在原始数据区。 一旦数据进入原始数据区，批处理服务将获取原始数据并执行所需的转换。 批量数据处理服务需要随需应变，并且可以根据需要进行扩展。

• 流数据处理服务：另一种处理是流数据处理。 捕获实时流数据并对其进行处理，而不需要将数据落盘或存储在磁盘上。 所有的流处理都在内存中进行，数据几乎是实时转换的。 典型的流数据处理服务还具有消息队列层，该层捕获数据流，并将它们排队以供进一步处理。 当数据流被接收和处理时，原始数据作为一条路径被发送到数据湖存储器进行存储。 另一条路径进行实时处理，并将输出发送给下游消费。 最后，转换后的数据也被推入数据湖层进行持久存储。

接下来，让我们讨论一下数据服务层。

数据服务层

一旦数据被处理，就可以用于下游的消费。 这些信息可以提供给不同的涉众，他们都有适合自己需要的需求。 可以在下图中看到组成这一层的服务:

 图2.8 数据服务服务的类型

一般来说，有四种类型的数据服务，概述如下:

• 数据仓库服务：第一种类型的数据服务是数据仓库服务。 数据仓库服务提供经过清理和转换的数据，这些数据可以用于多种用途。 首先，它用作报表和BI层。 其次，它是一个用于业务或数据分析的数据查询平台。 第三，它作为一个存储库来存储需要在线可用的历史数据。 最后，它还充当其他下游数据集市转换数据的来源，这些数据集市可能满足特定的部门需求。

• 实时数据服务：第二种服务是提供实时数据。 实时数据服务用于为各种下游应用程序提供服务。 这类应用的几个例子是移动系统，实时数据提供给下游应用，如客户关系管理(CRM)系统，网站或移动应用的推荐引擎，以及实时异常值检测系统，如欺诈检测。 实时数据服务以多种技术格式显示，如果服务正确，会增加巨大的业务价值。

• 基于API的数据服务：用于共享数据的第三种服务是基于API的数据服务。 API是一种接口，它允许应用程序使用一组简单的命令与外部服务进行交互。 数据也可以作为API交互的一部分。 由于数据公开给多个外部服务，因此基于API的方法可以扩展到与外部服务安全地共享数据。 通过API提供的数据是JSON格式的，因此使用API提供数据的技术应该能够支持JSON格式。 例如，NoSQL数据库可以存储这样的数据。

• 数据共享服务：第四种服务是数据共享服务。 数据共享数据服务共享来自组织或其他组织中的多个数据源的数据，数据格式和大小不限。 这种类型的服务提供共享数据所需的控制，并允许创建数据共享策略。 它还支持以结构化的方式共享数据，并对如何共享数据和如何使用数据提供了完整的可见性。 数据共享系统使用API进行数据共享。

数据分析层

数据分析层包括从数据中提取洞察力的服务。 它们是分析师、数据科学家和BI用户创建报表、执行分析和试验AI/ML模型的游乐场。 你可以在下面的图中看到这一层的服务:

 图2.9 数据分析服务的类型

在数据分析层有三种类型的服务，概述如下:

• 分析沙盒服务：分析沙盒是一个数据科学家和分析师可以部署他们的工具进行数据实验的游乐场。 沙盒应该为基于SQL的分析和开发ML模型提供不同种类的工具。 该层还应该与数据湖层和数据服务层无缝集成。 这一层应该按需启动和关闭工具集，以促进快速实验。

• 人工智能和机器学习(AI-ML)服务：AI和机器学习服务是现代数据分析平台的重要组成部分。 AI-ML服务允许数据科学家构建、训练和部署可用于生产的AI-ML模型。 这一层还提供了维护和监控此类模型的框架。 此外，它还提供了团队在构建这些模型时进行协作的能力。 该服务应该能够根据需要向上或向下扩展，并且应该能够促进自动模型部署和操作。

• 商业智能(BI)服务：BI服务从企业数据仓库(EDW)时代就已经出现了。 在Data LakeHouse架构中，它们实现了相同的功能。 该服务需要用于创建报表、执行数据可视化和促进自助BI的工具和技术。主要侧重于创建不同的表格或可视化视图，以显示当前和历史操作视图。

数据治理层

垃圾输入、垃圾输出 的原则也适用于Data LakeHouse。 Data LakeHouse中的数据需要得到适当的管理，这一层负责管理。 你可以在这里看到它的可视化表示:

图2.10 数据治理服务的类型

四个组件有助于确保Data LakeHouse不会变成数据沼泽。 这些措施概述如下:

• 数据策略管理：第一个组件不是技术组件——它是一组数据策略和标准。 数据策略是一组描述控制Data LakeHouse中数据的标准、安全性、完整性、质量和使用的规则的语句。

• 数据编目和管理服务：数据编目和管理是组织数据目录以便易于识别的过程。 该服务确保所有源系统数据、数据湖和数据仓库中的数据、数据处理管道以及从Data LakeHouse提取的输出都被适当地编目。 把数据编目服务看作是数据领域的Facebook----一个获取所有data lakehouse内容的可视化信息的地方，包括关于数据之间关系的信息，以及数据经过的一系列转换的血缘关系。

• 数据质量服务：在Data LakeHouse中存储或接入的任何数据都必须有一个数据质量评分，以确定数据的可靠性和可用性。 有许多参数决定了数据的质量。 其中一些参数包括数据的完整性、数据的一致性和数据的准确性。 数据质量服务确保数据是完整、一致和准确的。

数据安全层

Data LakeHouse架构的最后一层是数据安全层。 数据安全性本身就很重要，其重要性再怎么强调也不为过。 你可以在下图中看到组成这一层的服务:

图2.11 数据安全服务的类型

数据安全层有四个关键组成部分，如下:

• IAM (Identity and Access Management 身份和访问管理)服务：对Data LakeHouse的访问必须是安全的，并根据需要进行。 IAM服务充当访问Data LakeHouse的大门。 IAM服务可以保证访问Data LakeHouse的授权和鉴权的安全性和可靠性。 它提供了对恶意登录尝试的防御，并通过基于风险的访问控制、身份保护工具和健壮的身份验证选项保护凭证——而不会影响生产效率。

• 数据加密服务：数据加密是一种对信息进行编码的安全方法，只有用户使用正确的加密密钥才能访问或解密。 当数据存储在云中时，数据加密是必不可少的。 有许多不同的算法可用于加密数据。 加密为静态存储的数据提供数据保护。 它可以防止各种类型的网络攻击，并保护敏感数据。 组织对数据治理和遵从性工作的需求也可能需要数据加密。 因此，数据安全层需要有根据需要对数据进行加密和解密的工具。

• 数据屏蔽(Masking)服务：许多数据子集需要被屏蔽，以保护个人的身份或隐私。 这种类型的数据包括电子邮件、社会识别号码、信用卡号码等。 数据屏蔽是一种创建隐藏的但可读的数据版本的方法。 其目标是保护敏感数据，同时在不需要实际数据时提供功能性替代方案。 数据安全层需要一些工具来屏蔽这些敏感数据，并根据需要将其解除屏蔽。

• 网络安全服务：Data LakeHouse中的数据需要随时进行安全保护。 应该控制对数据的访问，以拒绝任何未经授权的访问。 还需要确保外部网络和Data LakeHouse之间的数据流动是安全的。 网络安全服务提供这些功能。

本节概述了Data LakeHouse架构的七个层。 第3章到第7章将详细介绍这些层。 本章将详细阐述每一层，并列出在实践中使用的常见模式。

现在让我们继续讨论我们需要应用的架构原则。

完整版PDF格式，请到知识星球下载：

《Data Lakehouse in Action》学习笔记--前言(文章末尾有福利)