在Databricks第一部分（Delta Lake）和第二部分（Delta Lake+ML）中尝试这个笔记本系列对于许多数据科学家来说，构建和调整机器学习模型的过程只是他们每天工作的一小部分。他们的绝大多数时间都花在执行ETL、构建数据管道和将模型投入生产等不那么迷人（但至关重要）的工作上。在本文中，我们将逐步介绍构建生产数据科学管道的过程。在此过程中，我们将展示Delta Lake是机器学习生命周期的理想平台，因为它提供了统一数据科学、数据工程和生产工作流的工具和功能，包括：能够连续处理来自历史和实时流式数据源的新数据流的表，大大简化了data science的生产流水线。模式强制，它确保表保持干净整洁，没有列污染，并且可以进行机器学习。Schema evolution，它允许将新的列添加到现有的数据表中，即使这些表是在生产中使用的，也不会引起破坏性的更改。时间旅行，也称为数据版本控制，允许对任何Delta Lake表的更改进行审核、复制，甚至在需要时回滚，以防由于用户错误而进行的意外更改。与MLflow集成，通过自动记录实验参数、结果、模型和曲线，可以跟踪和再现实验。Delta Lake的这些特性使数据工程师和科学家能够比以往更快地设计可靠、有弹性、自动化的数据管道和机器学习模型。利用Delta-Lake构建机器学习数据管道多跳体系结构通用体系结构使用与数据工程管道中不同质量级别相对应的表，逐步向数据添加结构：数据摄取（"青铜"表）、转换/功能工程（"银色"表）和机器学习培训或预测（"黄金"表）。综合起来，我们将这些表称为"多跳"体系结构。它允许数据工程师建立一个管道，从原始数据开始，作为"单一的真相来源"，所有的东西都从中流出。可以重新计算和验证后续的转换和聚合，以确保业务级聚合表仍然反映底层数据，即使下游用户优化数据并引入特定于上下文的结构。有必要深入研究数据与水的类比，以了解三角洲湖管道是如何工作的（如果您允许我们扩展示例的话）。Delta-Lake不需要调度一系列不同的批处理作业来分阶段地通过管道传输数据，而是允许数据像水一样流动：无缝、持续、实时。青铜桌是典型的湖泊，大量的水（数据）源源不断地流入湖中。当它到达时，它是脏的，因为它来自不同的来源，其中一些不是那么干净。从那里，数据源源不断地流入银表，就像与湖泊相连的溪流源头，快速流动，不断流动。当水（或数据，在我们的例子中）顺流而下，它被河流的曲折和曲折所净化和过滤，随着它的移动变得更加纯净。当它到达下游的水处理厂（我们的金表）时，它会接受一些最终的净化和严格的测试，以备饮用，因为消费者（在本例中是ML算法）非常挑剔，不能容忍受污染的水。最后，从净化厂，它被输送到每一个下游消费者的水龙头中（不管是ML算法，还是BI分析师），随时可以以最纯粹的形式消费。为机器学习准备数据的第一步是创建一个青铜表，在那里可以捕获数据并以最原始的形式保存。让我们看看如何做到这一点-但首先，让我们谈谈为什么三角洲湖是您的数据湖明显的选择。数据湖困境如今，我们看到的最常见的模式是公司使用Azure事件中心或AWS Kinesis收集实时流数据（如客户在网站上的点击行为），并将其保存到廉价、丰富的云存储中，如Blob存储或S3存储桶。公司通常希望用历史数据（如客户过去的购买历史）来补充这种实时流式数据，以全面了解过去和现在。因此，公司往往有大量原始的、非结构化的数据，它们从各种来源收集而来，这些数据都停滞在数据湖中。如果不能可靠地将历史数据与实时流数据结合起来，并为数据添加结构以便将其输入到机器学习模型中，这些数据湖很快就会变得错综复杂、杂乱无章，从而产生了"数据沼泽"一词在对单个数据点进行转换或分析之前，数据工程师已经遇到了第一个难题：如何将历史（"批处理"）数据和实时流数据的处理结合起来。传统上，人们可能会使用lambda体系结构来弥补这一差距，但这也带来了由lambda的复杂性引起的自身问题，以及它导致数据丢失或损坏的趋势。三角洲湖解决方案：在一张表格中结合过去和现在解决"数据湖困境"的方法是利用三角洲湖。DeltaLake是一个开源存储层，位于数据湖的顶部。它是为分布式计算而构建的，并且与Apache Spark 100%兼容，因此您可以轻松地将现有的数据表从当前存储的任何格式（CSV、Parquet等）转换为Delta-Lake格式的青铜表，如下所示。#阅读loanstats_2012_2017.parquet贷款统计=spark.read.拼花地板（拼花地板文件路径）#将表格另存为三角洲湖贷款统计_ce.write.format格式（"delta"）.mode（"overwrite"）.save（deltaRake_文件路径）#重新解读为三角洲湖贷款统计=spark.read.format（"delta"）.load（DELTALAKE_文件路径）一旦为原始数据构建了一个青铜表，并将现有的表转换为Delta-Lake格式，就已经解决了数据工程师的第一个难题：合并过去和现在的数据。怎样？Delta Lake表可以无缝地处理来自历史和实时流媒体源的连续数据流。因为它使用Spark，它几乎可以与不同的流数据输入格式和源系统兼容，不管是Kafka、Kinesis、Cassandra还是其他。要演示Delta-Lake表如何同时处理批处理和流式数据，请看下面的代码。在将我们的初始数据集从DELTALAKE_FILE_路径文件夹加载到Delta Lake表（如前面的代码块中所示）之后，我们可以在将新数据流式传输到表中之前，使用友好的SQL语法对当前数据运行批处理查询。%sql语言选择addr\u state，SUM（`count`）作为贷款由_state_delta贷款按地址状态分组正如你在上面看到的，最初，加州和德克萨斯州的贷款额最高。现在我们已经演示了Delta Lake运行批处理查询的能力，下一步是展示它同时对流数据运行查询的能力。我们将创建一个流式数据源，该数据源与之前绘制的现有批处理数据相结合，不断向Delta-Lake表添加新数据。注意loan_by_state_readStream是如何从同一个位置DELTALAKE_FILE_PATH读取的，就像在前面的代码块中批处理查询一样。按州贷款spark.readStream.format（"delta"）.load（DELTALAKE_文件路径）按州贷款_readStream.createOrReplaceTempView（"国家贷款"）实际上，批处理和流式数据可以在同一个位置（即DELTALAKE_FILE_PATH）着陆，而Delta Lake可以同时响应对这两种类型数据的查询，因此Delta-Lake表提供了"统一的批处理和流式源汇"当三角洲湖处理这条河流时，我们眼前的景象不断更新，我们开始看到一种不同的模式出现。 正如你所看到的，由于最近的数据流，爱荷华州（中西部的州越来越黑暗）拥有最多的贷款。loan_by_state_delta表在新数据同时使用loan_by_state_readStream流入表时也会更新。现在，我们已经了解了Delta Lake如何使我们能够同时可靠地分析批处理和流式数据源，下一步是做一些数据清理、转换和功能工程，为机器学习工作做好准备。用三角洲湖打造高品质特色商店数据清理和转换到目前为止，我们已经成功地将数据转换为Delta-Lake格式，并创建了一个青铜表，作为无缝处理历史和实时数据的着陆区。目前，数据的位置是正确的，但远没有以目前的形式有用：它需要大量的清理、转换和结构，才能用于机器学习模型。ML建模库没有提供太多（如果有的话！）数据类型、空值和丢失数据的灵活性，因此数据工程师的下一项工作是清理和处理原始数据。由于Delta Lake与ApacheSpark 100%兼容，我们可以使用Spark熟悉的API在Delta Lake表上执行数据咀嚼，如下所示。打印（"将多个级别映射到一个因素级别以验证状态…"）loan_stats=贷款_stats.with列（'verification_status'，修剪（regexp_replace（贷款_stats.verification_状态，'源验证'，'已验证'））打印（"计算每笔贷款的总收入或损失额…"）loan_stats=贷款_stats.with列（'net'，round（贷款_总PYMNU统计-贷款_贷款统计，2）在执行ETL之后，我们可以将经过清理、处理的数据保存到一个新的Delta-Lake-Silver表中，这样我们就可以在不修改origi的情况下将结果保存为新表