一种新的以数据为中心的方法来构建强大的 MLOps 实践。
在 Databricks，我们已帮助成千上万的客户将机器学习 (ML) 投入生产。壳牌拥有超过160 个活跃的人工智能项目，节省了数百万美元；Comcast使用 MLflow 轻松管理100 多个机器学习模型；和许多其他人已经构建了成功的 ML 驱动的解决方案。
在与我们合作之前，许多客户都在努力将 ML 投入生产，这是有充分理由的：机器学习操作 (MLOps)具有挑战性。MLOps 涉及在生产过程中共同管理代码 (DevOps)、数据 (DataOps) 和模型 (ModelOps)。我们见过的最常见和最痛苦的挑战是数据和 ML 之间的差距，通常分裂在连接不良的工具和团队之间。
为了解决这一挑战，Databricks 机器学习建立在Lakehouse 架构的基础上，将其主要优势（简单性和开放性）扩展到 MLOps。
我们的平台通过定义以数据为中心的工作流程来简化机器学习，该工作流程统一了 DevOps、DataOps 和 ModelOps 的最佳实践。机器学习管道最终是数据管道，其中数据流经多个角色。数据工程师摄取和准备数据；数据科学家从数据中构建模型；ML 工程师监控模型指标；和业务分析师检查预测。Databricks 通过使这些数据团队能够在单个平台而不是孤岛上协作和管理大量数据，简化了生产机器学习。例如，我们的特色商店允许您联合生产模型和功能：数据科学家创建“了解”他们需要哪些功能的模型，以便 ML 工程师可以使用更简单的流程部署模型。
MLOps 的 Databricks 方法建立在开放的行业范围标准之上。对于 DevOps，我们与 Git 和 CI/CD 工具集成。对于 DataOps，我们以Delta Lake和 Lakehouse 为基础，这是事实上的开放和高性能数据处理架构。对于 ModelOps，我们以MLflow为基础，这是最流行的模型管理开源工具。这种开放格式和 API 的基础使我们的客户能够根据他们的不同需求调整我们的平台。例如，围绕我们的 MLflow 产品集中模型管理的客户可以根据他们的需要使用我们的内置模型服务或其他解决方案。
我们很高兴在这篇博文中分享我们的 MLOps 架构。我们讨论联合 DevOps + DataOps + ModelOps 的挑战，概述我们的解决方案，并描述我们的参考架构。如需深入了解，请下载The Big Book of MLOps并参加即将举行的2022 年 Data+AI 峰会上的MLOps 讲座。
在 Lakehouse 平台之上构建 MLOps 有助于简化代码、数据和模型的联合管理。
共同管理代码、数据和模型
MLOps 是一组用于管理代码、数据和模型的流程和自动化，以满足ML 系统中稳定的性能和长期效率的两个目标。简而言之，MLOps = DevOps + DataOps + ModelOps。
开发、分期和生产
在他们开发面向业务或面向客户的应用程序的过程中，ML 资产（代码、数据和模型）经历了一系列阶段。它们需要被开发（“开发”阶段）、测试（“暂存”阶段）和部署（“生产”阶段）。这项工作在 Databricks 工作空间等执行环境中完成。
以上所有——执行环境、代码、数据和模型——都分为开发、登台和生产。这些划分可以从质量保证和访问控制的角度来理解。开发中的资产可能更容易获得，但没有质量保证。生产中的资产通常对业务至关重要，具有最高的测试和质量保证，但严格控制谁可以修改它们。
MLOps 需要共同管理执行环境、代码、数据和模型。所有四个都分为开发、登台和生产阶段。
主要挑战
上述要求的复杂性很容易爆炸：一个人应该如何管理代码、数据和模型，跨开发、测试和生产，跨多个团队，同时处理访问控制和多种技术等复杂问题？我们观察到这种复杂性导致了一些关键挑战。
运营流程
DevOps 的想法不会直接转化为 MLOps。在 DevOps 中，执行环境、代码和数据之间有着密切的对应关系；例如，生产环境只运行生产级代码，它只产生生产级数据。ML 模型使故事复杂化，因为模型和代码生命周期阶段通常是异步操作的。您可能希望在推送代码更改之前推送新的模型版本，反之亦然。考虑以下场景：
- 为了检测欺诈交易，您开发了一个每周重新训练模型的 ML 管道。您每季度更新一次代码，但每周都会自动训练、测试一个新模型并投入生产。在这种情况下，模型生命周期比代码生命周期快。
- 要使用大型神经网络对文档进行分类，由于成本原因，训练和部署模型通常是一次性的过程。但是随着下游系统的周期性变化，您需要更新服务和监控代码以匹配。在这种情况下，代码生命周期比模型生命周期快。
协作和管理
MLOps 必须平衡数据科学家对开发和维护模型的灵活性和可见性的需求与 ML 工程师控制生产系统的冲突需求。数据科学家需要在生产数据上运行他们的代码，并查看生产系统的日志、模型和其他结果。ML 工程师需要限制对生产系统的访问以保持稳定性，有时还需要保护数据隐私。当平台由不共享单一访问控制模型的多种不相交技术拼接在一起时，解决这些需求变得更具挑战性。
集成和定制
许多机器学习工具并非设计为开放的；例如，一些 ML 工具仅以 JAR 文件等黑盒格式导出模型。许多数据工具不是为 ML 设计的；例如，数据仓库需要将数据导出到 ML 工具，这增加了存储成本和治理难题。当这些组件工具不基于开放格式和 API 时，就不可能将它们集成到一个统一的平台中。
使用 Lakehouse 简化 MLOps
为了满足 MLOps 的要求，Databricks 在Lakehouse 架构之上构建了它的方法。Lakehouses 将数据湖和数据仓库的功能统一在一个架构下，通过使用支持这两种类型的数据工作负载的开放格式和 API，可以实现这种简化。类似地，对于 MLOps，我们给予了一个更简单的架构，因为我们围绕开放数据标准构建 MLOps。
在深入了解我们的架构方法的细节之前，我们先对其进行高层次的解释并强调其主要优势。
运营流程
我们的方法将 DevOps 理念扩展到 ML，为代码、数据和模型的“迁移到生产”意味着什么定义了清晰的语义。可以重用现有的 DevOps 工具和 CI/CD 流程来管理 ML 管道的代码。特征计算、推理和其他数据管道遵循与模型训练代码相同的部署过程，从而简化了操作。指定的服务——MLflow 模型注册表——允许独立更新代码和模型，解决了使 DevOps 方法适应 ML 的关键挑战。
协作和管理
我们的方法基于支持数据工程、探索性数据科学、生产机器学习和业务分析的统一平台，所有这些都以共享的 Lakehouse 数据层为基础。ML 数据在用于其他数据管道的相同湖屋架构下进行管理，从而简化了交接。对执行环境、代码、数据和模型的访问控制允许正确的团队获得正确的访问级别，从而简化管理。
集成和定制
我们的方法基于开放格式和 API：Git 和相关 CI/CD 工具、Delta Lake 和 Lakehouse 架构以及 MLflow。代码、数据和模型以开放格式存储在您的云帐户（订阅）中，并由具有开放 API 的服务给予支持。虽然下面描述的参考架构可以在 Databricks 中完全实现，但每个模块都可以与您现有的基础架构集成并进行定制。例如，模型再训练可以是完全自动化的、部分自动化的或手动的。
MLOps 的参考架构
我们现在准备回顾在 Databricks Lakehouse 平台上实现 MLOps 的参考架构。这种架构——以及一般的 Databricks——与云无关，可在一个或多个云上使用。因此，这是一个旨在适应您的特定需求的参考架构。有关架构和潜在定制的更多讨论，请参阅The Big Book of MLOps。
概述
该架构从高层次上解释了我们的 MLOps 流程。下面，我们将描述架构的关键组件以及将 ML 管道转移到生产环境的分步工作流程。
此图说明了跨开发、暂存和生产环境的高级 MLOps 架构。
成分
我们根据管理一些关键资产来定义我们的方法：执行环境、代码、数据和模型。
执行环境是代码创建或使用模型和数据的地方。环境被定义为用于开发、登台和生产的 Databricks 工作区（AWS、Azure、GCP），具有用于强制分离角色的工作区访问控制。
在架构图中，蓝色、红色和绿色区域代表三种环境。
在环境中，每个 ML 管道（图中的小方框）都运行在由我们的集群服务（AWS、Azure、GCP）管理的计算实例上。这些步骤可以手动运行，也可以通过工作流和作业（AWS、Azure、GCP）自动运行。默认情况下，每个步骤都应使用带有预设置库（AWS、Azure、GCP）的 Databricks Runtime for ML，但它也可以使用自定义库（AWS、Azure、GCP）。
定义 ML 管道的代码存储在 Git 中以进行版本控制。ML 管道可以包括特征化、模型训练和调整、推理和监控。在高层次上，“将 ML 迁移到生产环境”意味着从开发分支通过 staging 分支（通常是“main”）提升代码，并发布分支以供生产使用。这种与 DevOps 的一致性允许用户集成现有的 CI/CD 工具。在上面的架构图中，这个提升代码的过程显示在顶部。
在开发 ML 管道时，数据科学家可以从笔记本开始，并根据需要过渡到模块化代码，在 Databricks 或 IDE 中工作。Databricks Repos与您的 git 给予商集成，以将笔记本和源代码与 Databricks 工作区（AWS、Azure、GCP）同步。Databricks 开发人员工具可让您从 IDE 和现有 CI/CD 系统（AWS、Azure、GCP）进行连接。
数据存储在Lakehouse 架构中，全部在您的云帐户中。用于特征化、推理和监控的管道都可以被视为数据管道。例如，模型监控应该遵循从原始查询事件到仪表板聚合表的渐进式数据细化的奖章架构。在上面的架构图中，数据在底部显示为一般的“Lakehouse”数据，隐藏了开发、暂存和生产级别数据的划分。
默认情况下，原始数据和特征表都应该存储为 Delta 表，以保证性能和一致性。Delta Lake为结构化和非结构化数据给予了一个开放、高效的存储层，在 Databricks（AWS、Azure、GCP）中具有优化的 Delta Engine。Feature Store表只是带有附加元数据的 Delta 表，例如沿袭（AWS、Azure、GCP）。原始文件和表处于可以根据需要授予或限制的访问控制之下。
模型由MLflow管理，它允许对来自任何 ML 库的模型进行统一管理，适用于任何部署模式，包括 Databricks 内部和外部。Databricks 给予 MLflow 的托管版本，具有访问控制、数百万模型的可扩展性以及开源 MLflow API 的超集。
在开发过程中，MLflow 跟踪服务器跟踪原型模型以及代码快照、参数、指标和其他元数据（AWS、Azure、GCP）。在生产中，相同的过程保存了可重复性和治理的记录。
对于持续部署 (CD)，MLflow 模型注册表跟踪模型部署状态，并通过 webhook（AWS、Azure、GCP）和 API（AWS、Azure、GCP）与 CD 系统集成。模型注册服务与代码生命周期分开跟踪模型生命周期。这种模型和代码的松散耦合给予了在不更改代码的情况下更新生产模型的灵活性，反之亦然。例如，自动再训练管道可以在生产环境中训练更新的模型（“开发”模型）、测试它（“暂存”模型）和部署它（“生产”模型）。
下表总结了代码、数据和模型的“开发”、“暂存”和“生产”的语义。
工作流程
通过上面解释的架构的主要组件，我们现在可以了解将 ML 管道从开发带到生产的工作流程。
开发环境：数据科学家主要在开发环境中操作，为 ML 管道构建代码，其中可能包括特征计算、模型训练、推理、监控等。
1.创建开发分支：新的或更新的管道在 Git 项目的开发分支上进行原型设计，并通过 Repos 与 Databricks 工作区同步。
2.探索性数据分析 (EDA)：数据科学家使用笔记本、可视化和 Databricks SQL 在交互式迭代过程中探索和分析数据。
3.特征表刷新：特征化逻辑被封装为一个管道，可以从特征存储和其他 Lakehouse 表中读取，并写入特征存储。功能管道可以与其他 ML 管道分开管理，尤其是当它们由不同的团队拥有时。
4.模型训练和其他管道：数据科学家在只读生产数据或编辑或合成数据上开发这些管道。在这个参考架构中，管道（而不是模型）被提升为生产；有关在需要时推广模型的讨论，请参阅完整的白皮书。
5.提交代码：新的或更新的 ML 管道提交到源代码控制。更新可能会影响单个 ML 管道或同时影响多个。
暂存环境：ML 工程师拥有测试 ML 管道的暂存环境。
6.合并（拉取）请求：对暂存分支（通常是“主”分支）的合并请求会触发持续集成 (CI) 流程。
7.单元测试 (CI)： CI 流程首先运行不与数据或其他服务交互的单元测试。
8.集成测试 (CI)： CI 流程然后运行更长的集成测试，共同测试 ML 管道。训练模型的集成测试可能会使用小数据或少量迭代来提高速度。
9.合并：如果测试通过，代码可以合并到暂存分支。
10.剪切发布分支：准备好后，可以通过剪切代码发布并触发 CI/CD 系统更新生产作业来将代码部署到生产中。
生产环境： ML 工程师拥有部署 ML 管道的生产环境。
11.功能表刷新：此管道摄取新的生产数据并刷新生产功能存储表。它可以是计划、触发或连续运行的批处理或流式作业。
12.模型训练：模型在完整的生产数据上进行训练，并推送到 MLflow 模型注册表。培训可以由代码更改或自动再培训作业触发。
13.持续部署 (CD)： CD 流程采用新模型（在模型注册表中“stage=None”），测试它们（通过“stage=Staging”过渡），如果成功部署它们（将它们提升到“stage=Production”） . CD 可以使用Model Registry webhook和/或您自己的 CD 系统来实现。
14.推理和服务：模型注册表的生产模型可以以多种模式部署：用于高吞吐量用例的批处理和流式作业以及用于低延迟 (REST API) 用例的在线服务。
15.监控：对于任何部署模式，模型的输入查询和预测都会记录到 Delta 表中。从那里，作业可以监控数据和模型偏差，Databricks SQL仪表板可以显示状态并发送警报。在开发环境中，可以授予数据科学家访问日志和指标的权限以调查生产问题。
16.再培训：可以通过简单的时间表对模型进行最新数据的再培训，或者监控作业可以触发再培训。
原文标题：Architecting MLOps on the Lakehouse
原文作者：Joseph Bradley, Rafi Kurlansik, Matthew Thomson and Niall Turbitt
原文地址：https://www.databricks.com/blog/2022/06/22/architecting-mlops-on-the-lakehouse.html
