MLOps工作流在Databricks上

为每个阶段创建单独的环境

执行环境是代码创建或使用模型和数据的地方。每个执行环境由计算实例、它们的运行时和库以及自动化作业组成。

Databricks建议为ML代码和模型开发的不同阶段创建单独的环境，并在各个阶段之间明确定义转换。本文中描述的工作流遵循这个过程，使用阶段的通用名称:

• 发展

• 暂存

• 生产

还可以使用其他配置来满足组织的特定需求。

访问控制和版本控制

访问控制和版本控制是任何软件操作过程的关键组成部分。Databricks的建议如下:

• 使用Git进行版本控制。管道和代码应该存储在Git中进行版本控制。在阶段之间移动ML逻辑可以解释为将代码从开发分支移动到登台分支，再移动到发布分支。使用砖回购与您的Git提供者集成，并与Databricks工作区同步笔记本和源代码。Databricks还为Git集成和版本控制提供了额外的工具;看到开发人员工具和指导．

• 使用Delta表在Lakehouse体系结构中存储数据。数据应该存储在Lakehouse架构在你的云帐户中。原始数据和特征表都应该存储为三角洲表通过访问控制来确定谁可以读取和修改它们。

• 使用MLflow管理模型和模型开发。你可以使用MLflow跟踪模型开发过程并保存代码快照、模型参数、度量和其他元数据。使用模型注册管理模型版本和部署状态。模型注册中心提供人则和一个API，所以你可以集成CD系统，也处理模型的访问控制．

部署代码，而不是模型

在大多数情况下，Databricks建议在ML开发过程中进行推广代码，而不是模型，从一个环境到另一个环境。以这种方式移动项目资产可以确保ML开发过程中的所有代码都经过相同的代码审查和集成测试过程。它还确保模型的生产版本在生产代码上得到训练。有关选项和权衡的更详细讨论，请参见模型部署模式．

1.数据源

在开发环境中工作的数据科学家通常对生产数据具有只读访问权。在某些情况下，为了满足数据治理需求，开发环境可能只能访问生产数据的镜像或编校版本。数据科学家还拥有对单独的开发存储环境的读写访问权，以开发和试验新功能和其他数据表。

2.探索性数据分析(EDA)

数据科学家在交互式的迭代过程中探索和分析数据，使用笔记本、可视化和砖的SQL．

这个特别流程通常不是将部署在其他执行环境中的管道的一部分。

3.代码

ML系统的所有代码都存储在代码库中。数据科学家在Git项目的开发分支中创建新的或更新的管道。代码可以在Databricks内部或外部开发，并使用Databricks与Databricks工作区同步砖回购．

4.更新特性表

模型开发管道从原始数据表和现有特性表中读取数据，并将数据写入特色商店．该管道包括2个任务:

• 数据准备。检查数据质量问题。

• 创建或更新特性表。数据科学家开发或更新代码来创建功能。这些管道可以从Feature Store和其他Lakehouse表中读取，也可以写入开发存储环境中的特性表。然后，数据科学家使用这些开发特性表来创建原型模型。当代码升级到生产环境时，这些更改将更新生产特性表。

  特性管道可以与其他ML管道分开管理，特别是当它们属于不同的团队时。

5.火车模型

数据科学家在只读生产数据或非生产数据上开发模型训练和其他管道。管道可以在开发环境或prod环境中使用特性表。

该管道包括2个任务:

• 训练和调优。模型训练过程从特征存储和银色或金色级别的Lakehouse表中读取特征，并将模型参数、度量标准和工件记录到MLflow跟踪服务器。

  当训练和超参数调优完成后，数据科学家将最终的模型工件保存到跟踪服务器。这记录了模型、输入数据和用于生成模型的代码之间的链接。

  当这个培训管道在登台或生产中运行时，ML工程师(或他们的CI/CD代码)可以通过使用模型URI(或路径)加载模型，然后将模型推到模型注册表进行管理和测试。

• 评估。通过测试保留数据来评估模型质量。这些测试的结果被记录到MLflow跟踪服务器。

  如果您的组织的治理需求包括关于模型的附加信息，您可以使用MLflow跟踪．典型的工件是纯文本描述和模型解释，就像由SHAP或LIME生成的那样。

6.提交代码

在为特性工程、训练、推理和其他管道开发代码之后，数据科学家或ML工程师将开发分支变更提交到源代码控制中。

1.合并请求

当ML工程师在源代码控制中向登台分支(通常是“主”分支)创建合并请求时，部署过程就开始了。合并请求触发持续集成(CI)流程。

2.单元测试

CI流程自动构建源代码并触发单元测试。如果测试失败，则拒绝合并请求。单元测试不与数据或其他服务交互。

3.集成测试(CI)

然后CI流程运行集成测试。集成测试运行所有管道(包括特性工程、模型训练、推断和监控)，以确保它们一起正确地工作。登台环境应该尽可能地与生产环境相匹配。

为了减少运行集成测试所需的时间，模型训练步骤可以在测试的保真度和速度之间进行权衡。例如，您可能使用数据的小子集或运行更少的训练迭代。根据模型的预期用途，您可以选择在此时进行全面的负载测试。

集成测试通过登台分支后，您可以将代码提升到生产环境。

4.合并到分段分支

如果测试通过，代码可以合并到登台分支。如果测试失败，CI/CD系统应该通知用户，并在合并(拉)请求上发布结果。

您可以在暂存分支上安排定期的集成测试。如果分支由不同的用户频繁更新，这是一个好主意。

5.创建一个发布分支

当代码准备好部署到生产环境时，ML工程师创建一个发布分支，该分支触发CI/CD系统更新生产作业。

1.更新特性表

当新的生产数据可用时，该管道将吸收这些数据并更新生产特性存储表。该管道可以作为批处理作业或流作业运行，并且可以调度、触发或连续运行。

2.火车模型

在完整的生产数据上训练模型的生产版本，并将其注册到MLflow模型注册中心。这个管道可以由代码更改或自动再培训作业触发。

该管道包括2个任务:

• 训练和调优。与开发阶段一样，自动记录将训练过程的记录保存到MLflow跟踪服务器。这包括模型指标、参数、标签和模型本身。

  在开发过程中，数据科学家可能会测试许多算法和超参数。在生产训练代码中，通常只考虑性能最好的选项。以这种方式限制调优可以节省时间，并可以减少自动再训练中调优的方差。

• 评估。模型质量是通过测试生产数据来评估的。这些测试的结果被记录到MLflow跟踪服务器。这一步使用数据科学家在开发阶段指定的评估指标。这些指标可能包括自定义代码。

模型训练完成后，将模型工件注册到MLflow模型注册表用于生产环境。初始的Model Registry阶段是“None”。

3.连续部署(CD)

CD流程获取新模型(在模型注册表“stage=None”中)，测试它们(通过“stage=Staging”过渡)，如果成功部署它们(将它们提升到“stage=Production”)。CD可以使用模型注册表网钩或者你自己的CD系统。

该管道包括3个任务:

• 合规检查。这些测试从model Registry加载模型，执行组织所需的任何遵从性检查(例如，标签或文档)，并根据测试结果批准或拒绝请求。如果遵从性检查需要人力专业知识，则此自动化步骤可以计算统计数据或可视化以进行手动检查。无论结果如何，使用标签中的元数据和描述中的注释将模型版本的结果记录到model Registry。

  您可以使用MLflow UI手动管理阶段转换和转换请求，也可以使用MLflow api和webhook自动化它们。如果模型通过了遵从性检查，那么转换请求将被批准，模型将被提升到“stage=Staging”。如果模型失败，转换请求将被拒绝，模型将被移动到模型注册表中的“stage=Archived”。

• 比较登台和生产。为了防止性能下降，您应该将升级到Staging的模型的性能与当前的生产版本进行比较。比较指标和方法取决于用例，可以包括金丝雀部署、A/B测试或其他方法。比较测试的结果应该保存到Lakehouse的度量表中。

  如果这是第一次部署，并且还没有生产版本，那么您可以将登台版本与业务启发式或其他阈值作为基线进行比较。

• 请求模型转换到生产。如果候选模型通过了比较测试，您可以在模型注册表中请求将其转换为“stage=Production”。您可以使用MLflow UI手动完成，也可以使用MLflow API和webhooks自动完成。在这一点上考虑需要人的批准也是一个好主意。这是将模型发布到生产环境并集成到现有业务流程之前的最后一步。您可以包括人工检查，以验证合规性检查、性能比较和任何其他难以自动化的检查。

4.在线服务(REST api)

对于低延迟用例，您可以使用MLflow部署用于在线服务的模型。选项包括Databricks模型服务、云提供商服务端点或自定义服务应用程序。

服务系统从模型注册中心加载生产模型版本。对于每个请求，它从在线特征存储中获取特征，对数据进行评分，并返回预测。您可以使用服务系统、数据传输层或模型记录请求和预测。

5.推理:批处理或流处理

对于批处理或流推理作业，管道从Feature Store读取最新数据，从model Registry装入生产模型版本，对数据进行评分，并返回预测。批处理或流推理通常是高吞吐量、高延迟用例中最具成本效益的选择。

批处理作业通常通过JDBC连接将预测发布到Lakehouse表或平面文件。流作业通常将预测发布到Lakehouse表或消息队列(如Apache Kafka)。

6.监控

您应该监视输入数据和模型预测的统计属性(例如数据漂移和模型性能)和计算性能(例如错误和吞吐量)。您可以根据这些指标创建警报，或者在仪表板中发布警报。

无论采用何种部署模式，您都可以将模型的输入查询和预测记录到Delta表中。您可以创建作业来监视数据和建模漂移，还可以使用Databricks SQL在仪表板上显示状态并发送警报。数据科学家可以访问开发环境中的日志和度量，以调查生产问题。

该管道包括3个任务:

• 数据摄取。该管道从批处理、流或在线推理中读取日志。

• 检查准确性和数据漂移。管道计算关于输入数据、模型预测和基础设施性能的度量。数据科学家在开发过程中指定数据和模型指标，而机器学习工程师指定基础设施指标。

• 发布标准。管道写入Lakehouse表进行分析和报告。您可以使用Databricks SQL创建监控仪表板来跟踪模型性能，并设置监控作业或仪表板工具，以便在指标超过指定阈值时发出通知。

7.触发模型再训练

您可以创建一个计划作业，用最新的数据重新训练模型，或者您可以设置一个监控器，在检测到数据或模型中的漂移时触发重新训练。如果模型监视指标表明存在性能问题，数据科学家可能需要返回开发环境并开发一个新的模型版本。

• 如果定期有新数据可用，则可以创建安排的工作在最新可用数据上运行模型训练代码。

• 如果监控管道可以识别模型性能问题并发送警报，则可以将其配置为自动触发再培训。如果管道可以检测到传入数据分布的变化或模型性能的下降等情况，那么自动再训练和重新部署可以在最小化人工干预的情况下提高模型性能。