《Architecting Data and Machine Learning Platforms》第五章：架构设计数据湖

数据湖是数据平台的一部分，从组织中捕获未经管理的原始数据，并支持Apache生态系统中的计算工具。在本章中，我们将更详细地讨论这一概念，这在设计现代数据平台时非常重要。正如您将在整章中了解到的那样，云计算可以提供对其上可以实施的不同用例的支持。

我们将从回顾为什么要存储仅支持基本计算的原始未经管理的数据开始。然后，我们将讨论在云中的架构设计和实施细节。尽管最初数据湖仅用于基本数据处理，但现在通过API和连接器与其他解决方案的集成，可以使数据湖内的数据更适合特定目的，从而实现了对数据的民主访问和报告。最后，我们将以鸟瞰的视角看待通过利用数据科学笔记本在组织内加速数据分析和实验的一种非常常见的方式。

数据湖与云计算------完美的结合

数据帮助组织更快做出更好的决策。数据是从应用到安全等一切的中心，而更多的数据意味着对处理能力的更多需求，而云解决方案可以提供这种处理能力。

在本地数据湖面临的挑战

组织需要一个存储各种类型数据的地方，包括非结构化数据（图像、视频、文本、日志、二进制文件、网页内容）。这是企业采用数据湖的主要原因。最初，企业认为数据湖只是纯粹的原始存储。

业务部门希望从IT部门存储的数据中提取洞察和价值，而不仅仅是存储数据。由于Hadoop生态系统的演进，数据湖使能够进行大数据分析的组织能够超越存储卸载的简单概念。数据湖为组织提供了先进的分析和机器学习能力。在2010年代，Hadoop及其相关技术推动了数据湖的大规模采用。

然而，由于总拥有成本（TCO）、可扩展性、治理和敏捷性方面的缺点，企业一直难以从数据湖项目中获得足够的投资回报。本地数据湖的资源利用和管理总成本可能变得难以管理。资源密集型的数据和分析处理通常导致未能达到服务水平协议（SLA）。数据治理和安全性问题可能导致合规性问题。由于需要配置资源而导致的分析实验速度较慢。

根据预测，到2025年，80%的组织数据将是非结构化的，本地环境已无法以合理的价格提供足够的环境。云解决方案，正如您在第2章中看到的那样，使组织能够首先降低TCO，然后构建创新平台，因为公司内部的人员可以专注于业务价值而不是硬件管理。

云数据湖的好处

云范式对数据湖的巨大好处在于：

1. 不需要将所有数据存储在昂贵、始终运行的Hadoop分布式文件系统（HDFS）集群中。对象存储解决方案（例如AWS S3、Azure Blob Storage或Google Cloud Storage）是完全托管、无限可扩展且成本较低的选择。
2. Hadoop集群不仅提供存储功能，甚至还提供处理计算能力。这些集群可以按需在短时间内创建（几分钟或几秒钟），由于它们不需要始终运行，因此可以立即节省成本。这些Hadoop集群可以直接从对象存储读取/写入数据，即使这种数据访问速度较慢，但通过使用短暂的集群可以实现整体权衡的成本节省。
3. 超大规模云服务提供商通常提供利用较便宜的虚拟机（称为Spot Instances或Preemptible Instances）的能力作为工作节点。这些虚拟机的缺点是它们可以随时被系统驱逐（通常提前30到60秒通知），但由于底层的Hadoop技术具有工作节点容错功能，因此可以很容易地用新的实例替代。通过这种方法，额外的成本可以得到节省。
4. 如今，在超大规模云服务提供商上提供的大多数Hadoop服务都是完全托管的，并以PaaS模式提供（尽管您可以使用纯IaaS服务构建自己的Hadoop集群）。PaaS意味着您无需自己管理所有主节点和工作节点所需的所有虚拟机，而可以专注于构建用于从数据中提取价值的处理。
5. 与在组织内部生成数据孤立的本地Hadoop集群相比，云中可以有效地将存储（即对象存储中的数据可以注入到任何HDFS集群中）和计算（即按需创建的虚拟机）有效地分离，使组织能够更灵活地应对数据治理方面的挑战。
6. 云是数据湖的理想环境，因为它解决了本地数据湖面临的所有挑战：总体成本、可扩展性、弹性和一致的数据治理。
7. 市场正在大力投资于数据湖，特别是基于云的数据湖。Amazon EMR、Azure Data Lake和Google Cloud Dataproc都可在超大规模云服务提供商上使用。Databricks（是开源Spark引擎的主要开发者，该引擎是所有主要Hadoop发行版的一部分）构建了一个完整的多云数据平台，不仅提供存储和计算，还提供处理整个数据生命周期所需的全部功能。

接下来，让我们深入了解云上数据湖的设计和实施细节。

设计与实现

数据湖的设计取决于您是否需要流式处理，您将如何进行数据治理，您使用哪些Hadoop功能以及您正在构建哪个超大规模云服务提供商的平台。让我们逐一来看这些。

批计算和流计算

在分析数据工作负载时，要回答的第一个问题是要处理的数据的年龄：这是已经存储了一段时间的数据，还是刚刚到达系统的数据？根据答案，选择两种主要的数据处理方法之一：批处理和流处理。批处理已经是主导方法已有20多年的历史，但近年来，特别是随着云计算的出现，流处理变得越来越受欢迎。流处理更适用于实时处理大量数据，而批处理更适用于离线处理大量数据。

无论是批处理还是流处理，数据湖中有四个存储区域：

1. Raw/Landing/Bronze（原始/着陆/青铜）

   • 在这里，原始数据直接从源系统收集和摄入。

2. Staging/Dev/Silver（暂存/开发/银）

   • 在这里，更高级的用户（如数据工程师、数据科学家）处理数据，为最终用户准备数据。

3. Production/Gold（生产/金）

   • 在这里，存储生产系统使用的最终数据。

4. Sensitive（敏感）（可选）

   • 敏感数据所在的地方。它连接到所有其他阶段，并促进数据访问治理，以确保符合公司和政府法规。

在2014年，提出了两种新的体系结构，以允许在规模上进行批处理和流处理：Lambda（由Nathan Marz提出）和Kappa（由Jay Kreps提出）。Lambda体系结构（如图5-1所示）使用独立的技术堆栈，批处理层跨越所有（历史）事实，速度层用于实时数据。

系统中摄取的新数据同时存储在持久数据集（批处理层）和易失性缓存（速度层）中。第一个数据集然后被索引，并可供批处理视图的服务层使用，而第二个则通过速度层通过实时视图公开。这两个数据集（持久和易失性）可以并行或分离地查询，以回答所需的问题。这种体系结构通常部署在Hadoop环境中，其中HDFS可以作为批处理层的基础，而诸如Spark、Storm或Beam等技术可以用于速度层。最后，Hive可以成为实施服务层的解决方案，例如。

在Kappa体系结构（如图5-2所示）中，您可以使用单一技术堆栈（例如Beam/Spark）执行实时和批处理处理。核心是流处理架构。首先，事件流平台存储传入的数据。然后，流处理引擎实时处理数据，使数据可用于实时视图。在这个阶段，数据可以持久化到数据库中，以在需要时执行批量分析并利用相同的技术堆栈。

数据目录

数据分布在多个站点，包括数据库、DWH（数据仓库）、文件系统和Blob存储。此外，数据可能存储在数据湖的不同区域：原始、分段、生产或敏感。这使得数据科学家难以找到他们需要的数据，企业用户难以访问最新的数据。我们需要一个解决方案，使所有这些数据源变得可发现和可访问。

数据目录是描述组织数据集的所有元数据的存储库，它将帮助数据科学家、数据工程师、业务分析师和其他用户找到通向所需数据集的路径。在图5-3中，您可以看到一个可能的高层次体系结构，描述了数据目录如何与数据湖和数据平台的其他解决方案连接。

如果数据存在于多个数据存储库中（其中之一是数据湖），但处理引擎和分析工作负载的Gold存储库位于数据湖内，请确保数据目录是全面的，并且数据没有重复。确保元数据包含有关数据集级别（例如主数据或副本）的信息。 在将主数据集引入数据湖并进行转换时，可能需要在计算后进行同步。在图5-3中，您可以看到这种与数据处理的数据目录的高级集成：

1. 元数据目录履行。
2. 搜索所需的数据资产。
3. 如果数据资产尚不存在于数据湖中，则将其复制到Bronze存储区。
4. 在复制的数据资产上执行所需的转换。
5. 根据需要更新原始数据资产。

数据目录有助于理清组织可能拥有的各种数据集，因为它可以帮助找到重复使用或相似的数据集，并根据需要删除、停用或合并它们。数据目录可以帮助组织专注于对它们最相关的数据，并避免使用资源来存储和处理无用的数据，这可能导致成本节省。 每当数据在组织内共享时，具有关联数据合同是有益的。数据合同通常是JSON/YAML文件，捕捉数据生产者和消费者之间关于数据架构、摄入/发布频率、所有权和数据访问级别的协议，包括匿名化和脱敏等方面的协议。

Hadoop生态

Hadoop仍然是数据湖在本地和云端的事实标准。数据湖的概念始于MapReduce和Hadoop技术（参见"反模式：数据集市和Hadoop"）。在过去的15年中，Hadoop的流行逐渐增长，形成了一个丰富的生态系统，用于数据摄取、存储、处理和可视化。这导致了IBM和Cloudera等公司开发商业发行版。Databricks提供了多云Hadoop功能。在表5-1中，我们列举了一些按用例划分的框架中的热门工具。

表5-1中列出的解决方案可以部署在本地环境中，但也可以通过IaaS方法轻松部署在云中。超大规模云服务提供商将这些热门产品转变为完全托管的解决方案，以减轻用户端的配置和基础设施管理负担，提高固有的可扩展性和弹性，并降低成本。表5-1还概述了云中最受欢迎的解决方案，以促进对最受欢迎的本地Hadoop技术的云迁移和采用。

请参考表格，我们将审查三个主要云提供商的数据湖参考架构。

云数据湖参考架构

在本节中，我们将审查在公共云中利用主要三家超大规模供应商的服务实施数据湖的一些参考架构。与任何云架构一样，不存在一种适用于所有情况的设计。总会有多种不同的选项可供选择，可以满足您的具体需求。

Amazon Web Services

在AWS上，托管的Hadoop服务是Amazon Elastic MapReduce (EMR)。然而，它仅提供分析数据处理。AWS建议我们更全面地思考数据湖，并考虑使用Amazon Athena或Amazon Redshift更好地进行结构化数据的分析。此外，原始数据可能尚不存在于云存储（Amazon S3）中，需要进行摄取。因此，在AWS上实现数据湖的推荐方式是利用AWS Lake Formation。它是一项完全托管的服务，使开发人员能够自动进行数据收集、数据清理/处理和数据移动，以使数据可用于分析和机器学习工作负载。它配备了一个权限服务，扩展了AWS IAM功能，实现更好的数据治理和安全性（例如，细粒度策略、列级和行级访问控制等）。查看图5-4中的架构，我们可以识别出以下主要组件：

• 数据源，在这种情况下是Amazon S3、关系型和NoSQL数据库
• 构建在Amazon S3存储桶之上的存储区
• 由AWS Lake Formation协调的数据目录、数据治理、安全性和流程引擎
• 提供对数据的访问的分析服务，如Amazon Athena、Amazon Redshift和Amazon EMR

这种架构适用于处理结构化、半结构化和非结构化数据的任何类型的用例。一旦数据经过准备和转换，由于AWS S3服务的普遍性，即使对于数据湖之外的解决方案（如Databricks或Snowflake），它也可以轻松地提供，潜在地可以连接到平台上的任何其他服务。

Microsoft Azure

在Azure平台上，有几种实现数据湖的方式，因为有不同的解决方案可以帮助设计可能的目标架构。通常，我们会看到图5-5中所示的架构，其中我们可以识别出以下主要组件：

• Azure Data Lake Storage Gen2（ADLSG2）：为大量数据优化的对象存储，与HDFS完全兼容，通常由用户实现数据湖的所有数据区域。
• Azure Data Factory：无服务器解决方案，用于摄取、转换和操作数据。
• Azure Purview：提供治理功能，用于查找、分类、定义和执行跨数据的政策和标准。
• Azure Synapse Analytics：用于针对存储在ADLSG2中的数据发出SQL查询的分析服务。
• Databricks：基于Spark处理引擎的完整分析和机器学习解决方案。
• Power BI：业务智能（BI）报告和可视化工具。

必须注意的是，Azure Databricks可以与Azure HDInsight互换使用。两者之间的主要区别在于，Databricks是一个基于Apache Spark的分析平台，经过优化以在Microsoft Azure云服务平台上运行，而HDInsight是一个托管的完整Apache Hadoop分发版（即不仅包括Spark工具，还包括其他不太适应Azure的工具）。如果您想使用标准的Hadoop生态系统解决方案，应该利用HDInsight；而如果您更愿意利用基于Spark的完整分析和机器学习解决方案，那就选择Databricks。

Google Cloud Platform

在Google Cloud Platform上（参见图5-6），不同的无服务器和完全托管的组件通过API进行通信。我们可以识别以下主要组件：

• Data Fusion：用于批量和流处理的数据摄取和转换解决方案
• Pub/Sub：用于集成来自Data Fusion的输入和由Dataproc提供的Hadoop集群的消息中间件
• Dataproc：按需提供HDFS、Spark和非Spark功能的Apache Hadoop集群
• Cloud Storage：对象存储解决方案，用于实现数据区域
• Bigtable和BigQuery：分析和实时数据处理引擎
• Looker/Looker Studio：BI和可视化解决方案
• Dataplex：处理数据治理、数据目录和安全性的单一视图
• Composer：基于Apache Airflow的数据工作流编排服务，使用户能够编写、调度和监视流水线

根据您的用例，Hadoop或HDFS集群可能并非总是最合适的选择。将数据存储在Cloud Storage中使您能够自由选择适合当前工作的正确工具，而不受限于HDFS集群上可用的工具和计算资源。例如，许多临时的Hive SQL查询可以轻松迁移到BigQuery，它可以使用其本地存储或直接读取/查询Cloud Storage。同样，流应用程序可能更适合于Apache Beam流水线，这些流水线可以在Dataflow上运行，Dataflow是一个完全托管的流分析服务，通过自动缩放和批处理最小化延迟、处理时间和成本。

既然您熟悉了云数据湖的参考架构，让我们深入了解如何通过第三方解决方案扩展数据湖。

集成数据湖：真正的超能力

数据湖技术因其能够处理任何类型的数据，从结构化的表格格式到文本或图像等非结构化文件，而变得流行。这使得许多之前不可能的用例成为可能，例如通过对发票进行文本分析来分析供应商，识别电影场景中的演员，或者实现实时仪表板以监控电子商务网站上的销售情况。数据湖的超能力在于它能够将数据与无限数量的处理引擎连接起来，以激活您心中可能的任何用例。

扩展湖的APIs

在数据湖中，数据摄取过程始于将原始数据导入到着陆区。在数据摄取后，必须对其进行处理（可能需要多次处理）才能进行可视化和激活。这些步骤中的每一个都可能涉及数据湖本身的各种引擎，或者是托管在云中的第三方产品，有时甚至是在本地。

为了使位于混合环境中的不同系统进行通信和数据交换，可以使用API。API是一种允许两个或多个系统通过共享的协议（如HTTPS和gRPC）进行通信的软件组件。大多数现代应用程序使用API来集成服务和交换数据。即使有临时连接器可用，它们通常也是基于API构建的。您可以将API视为数据可以从一个系统流向另一个系统的高速公路。用于保护数据流量的安全措施是收费站，速率限制是速度限制。通过这些高速公路，数据可以在多个系统之间流动，并且可以由任何类型的处理引擎处理，从标准ETL到现代ML框架如TensorFlow或PyTorch。

组织可以使用API将其数据湖演进到所需的外部服务。API还可以用于监视、配置、调整、自动化以及访问和查询湖本身。

Apache Iceberg，Apache Hudi和Delta Lake对数据湖的演进

将数据湖与其他技术集成的主要目标是扩展其功能，超出Hadoop框架提供的开箱即用功能。考虑到标准的Hadoop堆栈，通常有一个缺失的元素，通常使用其他技术（例如在线事务处理[OLTP]数据库）来处理：ACID事务管理。Apache Iceberg、Apache Hudi和Delta Lake是建立在HDFS之上的开源存储层，旨在解决这一关键方面。尽管它们各自具有一组不同的功能（例如，Apache Iceberg支持比Apache Hudi和Delta Lake更多的文件格式），但它们有一些共同的元素：

• ACID兼容性，确保用户查询的信息是一致的
• 克服HDFS在文件大小方面的固有限制------通过这种方法，即使是小文件也可以完美运作
• 记录对数据所做的每一次更改，保证在必要时进行完整的审计并启用时光旅行查询
• 在处理批量和流式插入和处理时没有差异
• 与Spark引擎的完全兼容
• 基于Parquet格式的存储，可实现高度的压缩
• 流处理支持
• 能够将对象存储视为数据库
• 在行和列级别应用治理

这些存储解决方案可以启用通常由其他技术处理的多个用例（例如DWH，我们将在第6章中更详细地研究），主要是因为它们能够防止数据损坏，以非常快的模式执行查询，并经常更新数据。在这些新启用的存储的交易功能（即更新/删除）在这方面发挥关键作用的特定场景非常明确，这些场景涉及GDPR和加利福尼亚消费者隐私法（CCPA）。根据这些法规，组织被迫具备根据特定请求清除与特定用户相关的个人信息的能力。在标准HDFS环境中执行此操作可能是耗时和资源密集的，因为必须识别与请求的个人数据相关的所有文件，然后将其摄取，过滤并写成新文件，最后删除原始文件。这些新的HDFS扩展简化了这些操作，使它们易于快速执行，并且更重要的是，可靠。 这些开源项目已被社区广泛采用，社区正在大力投资它们的开发。例如，Netflix广泛使用Apache Iceberg，而Uber的数据平台由Apache Hudi提供支持。尽管Delta Lake是一个Linux基金会项目，但主要贡献者是Databricks，这是Spark引擎背后的公司，该公司开发并商业化了一个完整的套件，用于处理基于Spark和Delta Lake的供应商专有版本的大数据工作负载。

除了ACID之外，还有两个功能正在改变用户在数据湖中处理数据的方式：

• 分区演进

这是在文件（即表）上更新分区定义的能力。分区是允许文件系统将文件内容拆分为多个块以避免在检索信息时完成全扫描的信息（例如，提取2022年第一季度的销售数据时，您应该能够仅查询属于年初的数据，而不是查询整个数据集，然后过滤掉不需要的数据）。考虑到文件中分区的定义可能因业务需求（例如，我们希望收集有关设备工作时间的见解）而发生变化，有一个能够以透明且快速的方式处理这些更改的文件系统是至关重要的。HDFS（通过Hive）可以从逻辑角度实现这一点，但实际上是不可实现的，因为需要大量计算工作。请注意，在撰写本文时，此功能仅由Apache Iceberg提供。

• 模式演进

与分区一样，模式可能需要随时间而更新。您可能想要添加、删除或更新表中的列，文件系统应该能够在不需要重新转换数据的情况下进行大规模的操作（即，无需ELT / ETL方法）。请注意，在撰写本文时，只有Apache Iceberg完全支持这一点，但在使用Apache Spark作为引擎时，所有解决方案都能够处理模式演进。

现在您已经了解了如何扩展数据湖的功能并丰富可以通过它解决的广泛用例，让我们看看如何实际与数据湖进行交互。

使用Notebooks进行交互式分析

在处理数据时，最重要的之一就是能够以交互方式轻松快速地访问数据并进行分析。在利用数据湖时，数据工程师、数据科学家和业务用户可以利用诸如Spark、Pig、Hive、Presto等众多服务来处理数据。在几个社区中，尤其是数据科学家社区中，一种备受欢迎的解决方案被认为是组织进行数据分析的瑞士军刀：Jupyter Notebook。

Jupyter Notebook是一个开源应用程序，可用于编写包含文本、要执行的代码、图表和图形混合的实时文档。它可以被看作是一个实时书，除了使用类似Markdown的标记语言编写的文本之外，还包含一些执行一些数据操作（例如查询、转换等）的代码，并最终生成一些结果，生成图表或表格。

从架构的角度来看，可以将在数据湖上运行的Jupyter Notebook视为三个不同的组件，如图5-7左侧所示。HDFS是存储，内核是处理引擎，而Jupyter是服务器，利用处理引擎来访问数据，并通过浏览器为用户提供编写和执行笔记本内容的用户界面。有几个内核可以利用（对于机器学习，通常会使用PyTorch），但对于数据工程而言，最常见的选择是Spark，可以通过用Python编写的代码使用PySpark访问（如图5-7右侧所示）。

一旦正确配置，您可以立即在笔记本中直接编写文本和代码，并与数据集进行交互，就像利用Spark命令行界面一样。您可以使用笔记本开发和与组织内的其他人共享代码，进行快速测试和分析，或快速可视化数据以获得额外的见解。重要的是要强调结果不是静态的，因为它们是实时文档：这意味着如果底层数据集发生变化或代码片段发生变化，与笔记本共享的人在重新执行笔记本时会得到不同的结果。完成分析后，通常有两种不同的路径可以选择：

1. 与其他数据科学家、数据工程师、开发人员或任何希望做出贡献的人共享笔记本的源代码（Jupyter Notebook生成.ipynb文件）。他们可以在其环境中加载文件并重新运行代码（当然需要对底层存储系统和通过API集成的任何其他解决方案具有正确的访问权限）。
2. 通过生成HTML页面或PDF文档将结果静态化，可以与更广泛的用户共享。

由于其极大的灵活性，无论是在可以利用的编程语言方面（多亏了众多可用的内核）还是在可以执行的活动方面，笔记本已成为交互式数据分析、测试和实验的事实标准解决方案（例如，您可以从数据湖中的数据生成图表，或者在将其移至生产环境之前在小数据子集上训练复杂的ML算法）。 我们在与几个组织合作时看到的情况是，笔记本方法是实现数据民主化征程的第一步（如我们将在下一节讨论的那样），因为它允许技术上更为熟悉的人立即获得对数据的标准化访问，促进协作。虽然数据科学家是笔记本使用的先驱，但数据工程师和分析工程师也在不断采用它们。我们甚至看到一些公司正在开发自定义库，以包含在笔记本模板中，以便促进与其他多个解决方案（现成或定制开发的）的集成，将标准化提高到另一个水平，并减少最终用户（甚至是痛苦）的学习曲线。这种标准化，借助容器技术，甚至已经在计算级别实现：公司内的用户每次启动笔记本时，背后都会启动一个带有足够计算资源和一组工具的容器，这些工具可以立即用于其数据分析。

云超大规模提供了一些托管版本的Jupyter Notebook解决方案，例如AWS SageMaker、Azure ML Studio和Google Cloud Vertex AI Workbench等，可以帮助摆脱与底层基础架构管理相关的麻烦，因为它们是完全托管的。 现在您对如何利用Jupyter Notebook扩展数据湖有了更好的理解，我们将把注意力转向帮助您了解组织内的人员如何处理数据摄取到数据可视化报告，从完全的IT模型过渡到更为民主的方法。

民主化数据处理和报告

数据为组织提供的最大价值是使决策者和一般用户能够做出明智的决策。为此，数据应该能够被任何授权的个人访问和使用，而无需专业的临时专业知识。即使从技术角度实现了公司内部数据访问的民主化，仅专注于技术是不够的。组织还需要实施数据编目和治理操作。拥有描述正确数据集的良好元数据将使用户能够找到他们需要的正确信息，并激活正确的数据处理和报告。在本节中，我们将探讨在构建云数据湖时，组织如何从完全由IT驱动的方法转向更具民主化的方法的关键技术。

建立对数据的信任

当本书的一位作者几年前为一家重要的零售客户担任顾问时，他致力于开发解决方案，自动从销售数据库提取数据以生成供业务用户利用的报告。他需要随时回答决策者的以下问题：

• 你从哪里获取这些数据？
• 你是如何转换那些数据的？
• 生成报告之前你进行了什么操作？

一旦他被分配到另一个客户，组织的IT团队接管了整个端到端的流程。虽然他们可以修复错误并监视报告生成，但他们无法说服决策者数据和报告是可信的，因为他们没有足够的知识来回答这些问题。 这种信任显然是一个障碍，通过使最终用户能够以自主方式深入挖掘他们的数据并从摄取到最终报告值进行审计，这个障碍将被消除。这种方法在过去可能是不切实际的，但现在人们在数字方面更有经验，这在转变这种方法方面起到了很大的帮助。

正如图5-8所示，在所有权和责任方面存在明显的过渡，从左边的旧世界到右边的新世界。虽然以前大部分工作是由IT部门完成的，但如今最终用户手中有了工具，使他们能够在数据目录化到数据可视化的大多数活动中具有很高的自主权。

Atlan、Collibra、Informatica、AWS Glue、Azure Purview 和 Google Dataplex等工具使元数据收集的过程变得更加简单和快速。一方面，已经构建了大量自动化工具，以实现自动化的数据爬取，特别是通过与多个数据库和存储引擎的集成（例如AWS Redshift 和 Athena、Azure Synapse、Google BigQuery、Snowflake等），另一方面，通过丰富且易于使用的用户界面简化数据输入活动，让业务人员能够完成大部分工作。

沿着这个链条往上走，我们发现即使是一直以来由专业用户（即数据工程师）负责的数据处理、准备、清理和整理步骤，现在也可以由最终用户直接处理。当然，仍然可能需要数据工程师/数据科学家利用先进的处理引擎（如Spark）完成数据处理的某些子集。对于需要专业人员（SMEs）参与的活动，例如探索、转换和过滤，已经开发并提供了一些工具，如Talend Data Preparation 或 Trifacta Dataprep，其明确目标是支持非数据工程/数据科学家用户：这些工具通过提供直观的界面，将处理委托给底层引擎（例如Beam），该引擎可以对大规模数据集应用所有变更。这种方法甚至强调了底层数据的访问，该数据存储在HDFS集群上或直接存储在AWS S3、Azure Data Lake或Google Cloud Storage等对象存储上，可以通过提供一系列功能和控制的多种不同工具实现。这意味着不同类型的用户可以利用不同类型的工具处理数据。例如，数据工程师可以利用Spark开发其数据转换流水线；数据科学家可以使用scikit-learn、TensorFlow或PyTorch实现ML算法；业务分析师可以使用Hive或PrestoSQL使用SQL查询执行假设分析。

最后一步是数据可视化/报告，这通常是业务用户自己可以轻松完成的。这里有很多可以利用的解决方案（例如Microsoft Power BI、Looker、Tableau 和 Qlik等），它们为用户提供所需的灵活性。在这个阶段，用户往往自然而然地具有自主性，因为这些工具在某种程度上与他们在Excel中所熟悉的方法相似，因此用户不需要经历陡峭的学习曲线以熟练使用。数据可视化、BI和假设分析是业务用户可以轻松进行的典型分析。

即使原始数据始终由IT部门管理，由于与第三方服务的集成，业务用户可能也可以以自主方式将数据导入数据湖。由于这一点，人们对于不同业务单元摄取的数据内容以及相关数据集的质量和正确性的信任需求正在增长。治理的概念正在获得推动以帮助处理这一问题。治理是指管理和监督组织数据资产的过程，以确保业务用户能够访问高质量、一致且易于获取的数据，可以看作是以下三个关键因素的组合：

1. 确定具有按时获取正确信息的关键利益相关方。
2. 保护数据免受任何内部和外部的滥用，重点关注人员。
3. 与公司内外的其他人合作，释放数据的价值。

在许多公司中，我们看到治理不一定是人们被分配的一个角色，而更多地是他们在实地通过与工具的交互以及他们向内部社区提供信息的质量而赢得的一个头衔。事实上，有一些工具（例如Informatica Data Catalog）允许用户对治理者进行评级，方式类似于购买者在亚马逊上对卖家进行评级。

既然您已经了解了将组织引向更现代和民主方法的各种选项，让我们讨论该过程的一个主要部分，仍然主要由IT团队掌握：数据摄取。

数据摄取仍然是IT事务

数据摄取仍然是IT事务中最关键且重要的步骤之一。如果规划不善，数据湖可能会变成一个"数据沼泽"，其中存在大量未使用的数据。这通常是因为组织倾向于将各种原始数据加载到数据湖中，即使他们并不完全了解为什么加载数据以及如何利用它。这种方法会导致大量未使用的数据堆积，这些数据在大多数时间内都不会被使用。但即使未使用的数据仍然留在湖中，并使用本应为其他活动空闲的空间。过时的数据还倾向于存在间断和不一致，当最终有人使用它时，可能导致难以排查的错误。因此，在摄取过程中遵循以下最佳实践非常重要：

文件格式 有几种文件格式可供选择，各有利弊。如果主要目标是可读性，那么CSV、JSON和XML是最常见的。如果性能是最重要的目标，则Avro、Parquet或Optimized Row Columnar (ORC) 是更适合的：

• Avro（基于行的格式）在需要强烈I/O和低延迟操作时效果更好（例如，基于事件的源、流式仪表板）。
• Parquet和ORC（基于列的格式）更适用于查询用例。

文件大小 通常在Hadoop世界中，文件越大越好。文件通常有数十吉字节大小，当处理非常小的文件（例如，物联网使用案例场景）时，建议使用流处理引擎（如Apache Beam或Spark Streaming）将数据 cons 许多小文件合并为几个大文件。

数据压缩 数据压缩对于节省空间非常重要，特别是在每天可能摄取PB级数据的数据湖中。此外，为了保证性能，选择一个足够快速以在需要时即时压缩/解压缩数据的压缩算法非常关键。标准的ZIP压缩算法通常不适用于这样的应用，我们看到组织倾向于使用由谷歌开发的Snappy，它提供了与数据湖需求相一致的性能。

目录结构 这是一个非常重要的主题，根据用例和要使用的处理引擎，目录结构可能会有很大变化。以物联网使用案例通过HBase处理为例：假设您正在全球范围内收集来自设备的数据，并且想要从特定位置的设备生成的消息中提取特定日期的信息。一个良好的目录结构示例可能是/country/city/device_id/year/month/day/hours/minute/second。如果用例是批处理操作，将输入数据放入名为IN的文件夹，将输出数据放入名为OUT的文件夹可能会很有用（当然，它必须用最佳前缀标识以避免误解和数据重复）。

根据数据的性质（批处理与流处理）和数据的目标（例如，AWS S3、Azure Data Lake Storage、Google Cloud Storage），可以利用多种解决方案：用户可以使用脚本（例如PowerShell或bash）加载数据，也可以直接使用API或本机连接器摄取数据。用户可以直接将数据流入平台（例如AWS Kinesis、Azure Event Hub或Google Pub/Sub），也可以将其作为原始文件上传到HDFS以供将来处理。通常由IT部门管理这些活动，因为它们可能涉及大量自动化以及同时需要专门技能的集成/数据处理。然而，有一些解决方案，如Fivetran，正在简化用户配置数据摄取到云中的方式。对于这样的解决方案，甚至较不熟练的人（例如业务用户）也有可能在湖中加载数据，扩展我们之前讨论的民主化概念。

数据湖中的ML

正如我们之前讨论的，可以以原始格式将任何类型的数据存储在数据湖中，这与数据仓库不同，数据需要是结构化或半结构化的。特别是，可以将非结构化数据（图像、视频、自然语言等）以它们的典型格式（JPEG、MPEG、PDF等）存储在其中。这使得将各种类型的数据纳入数据湖变得非常方便，然后可以用于开发、训练和预测ML算法，特别是基于深度学习的算法（参考"应用AI"）。

在原始数据上进行训练

对于结构化数据，您可以利用像Spark、XGBoost和LightGBM等库。这些框架可以直接读取和处理CSV文件，而这些文件可以原封不动地存储在数据湖中。对于非结构化数据，最常用的ML框架是TensorFlow和PyTorch。这些框架可以以其原生形式读取大多数图像和视频格式，而原始数据将以此形式存储。因此，在图5-9中，我们演示了训练ML模型的步骤，准备的数据可以与收集和存储的数据相同，并且标签可以是数据本身的一部分，无论是CSV文件中的一列还是基于图像/视频组织的方式（例如，所有螺丝的图像可以存储在名为screws的文件夹中）。这使得在数据湖上训练ML模型变得非常简单。

然而，有一些效率方面的考虑------直接读取JPEG或MPEG文件将导致ML训练程序受到I/O约束。因此，数据通常会以TensorFlow Records等格式从数据湖中提取和存储。由于这些格式在从云存储读取时优化了吞吐量，它们有助于最大程度地利用GPU。GPU制造商还提供了从云存储直接读取常见格式（例如Apache Arrow）到GPU内存的功能，从而加速ML过程。

在数据湖中进行预测

因为机器学习框架直接支持在原始格式中读取数据，因此在原始数据上调用模型也非常简单。例如，在图 5-10 中，我们向您展示了在 AWS 上的图像分类工作流程。请注意，图像以原样被摄入到云存储桶中，并且在上传的图像上调用了机器学习模型。类似的功能在 GCP 和 Azure 中也是可用的，我们将在第 11 章中更详细地介绍。

如果选择数据湖作为主要平台，还可以考虑使用 MLflow，这是一个开源项目，用于实现端到端的机器学习工作流程。数据存储在数据湖中，分布式训练通常使用 Spark 进行，尽管也存在与 TensorFlow 和 PyTorch 的集成。除了训练和部署外，MLflow 还支持高级功能，如模型注册表和特征存储。直接在机器学习框架中处理原始数据的这种能力是数据湖的引人注目的优势之一。

总结

在本章中，您更详细地了解了真正的数据湖是什么，面临的挑战以及可以采用的模式，使其成为组织数据平台的核心支柱。以下是关键要点：

1. 数据在每个组织中都起着关键作用，帮助在短时间内做出坚实决策，可能是实时的。
2. 数据湖比数据仓库提供更大的灵活性，因为它允许用户处理任何类型的数据（结构化、半结构化，甚至是非结构化），并利用来自开源生态系统的各种解决方案和工具。
3. 在旧的本地环境中管理数据湖对组织来说是一项挑战。云环境是组织存储数据、降低总体成本并专注于业务价值而不是硬件管理的好解决方案。
4. 云采用的主要优势包括：（1）通过在存储和计算方面节省费用降低总体成本；（2）通过利用超大规模提供的可伸缩性；（3）通过利用底层平台的弹性来采用快速失败的方法，加速实验；（4）在平台上采用一致的数据治理方法，以符合安全性和控制要求。
5. 在数据湖中，存在描述组织数据集的所有元数据的存储库，这将帮助数据科学家、数据工程师、业务分析师以及可能需要利用数据找到通往所需数据集的路径的任何用户。
6. 数据湖支持批处理和流处理操作，并促进Lambda/Kappa模式的实施。
7. 市场在数据湖方面的投资强劲，特别是在基于云的数据湖。因此，可以通过利用API或与第三方解决方案集成来扩展数据湖。
8. 一种常见的集成是在HDFS之上采用Iceberg或Delta Lake，使存储符合ACID标准并启用其他类型的用例（主要是那些对数据强一致性要求较高的用例）。
9. Jupyter Notebook是组织中实施数据分析、实验和基于测试的方法的最常见方式。
10. 数据湖促进了组织内部的数据民主化访问，因为大部分活动都可以进行自助服务。
11. 由于数据以数据湖中的原生格式存储，并且由于机器学习框架支持读取这些格式，因此数据湖在没有任何特殊钩子的情况下促进了机器学习。

在接下来的章节中，我们将探讨数据湖的替代方案，即数据仓库。