MLOps 体系结构模型(1)

对于解决方案架构师来说，设计过程从新体系结构需要解决的问题规范开始，例如：

• 手动数据收集速度慢，容易出错，并且需要大量工作
• 实时数据处理不是当前数据加载方法的一部分
• 没有数据版本控制，因此不支持随时间推移的可重复性
• 模型的代码在本地计算机上手动触发，并不断更新，无需版本控制
• 完全缺少通过通用平台共享数据和代码
• 预测过程不表示为业务流程，所有步骤都是分散的和不同步的，并且大多数步骤都需要手动操作
• 数据和模型的实验不可重现且不可审计
• 在内存消耗增加或占用大量 CPU 的操作的情况下，不支持可伸缩性
• 目前不支持对整个过程进行监控和审计

下图演示了新架构的四个主要组件：监视和审计平台、模型部署平台、模型开发平台和数据管理平台。

**图 1.**MLOps 体系结构图

平台设计决策

设计 MLOps 平台时要考虑的两个主要策略是：

1. 从头开始开发与选择平台
2. 在基于云的、本地或混合模型之间进行选择

从头开始开发与选择完全打包的 MLOps 平台

从头开始构建 MLOps 平台是最灵活的解决方案。它将提供解决公司未来任何需求的可能性，而无需依赖其他公司和服务提供商。如果公司已经拥有所需的专家和训练有素的团队来设计和构建 ML 平台，那将是一个不错的选择。

预打包解决方案是模拟不需要大量自定义的标准 ML 流程的不错选择。一种选择甚至是购买一个预训练的模型（例如，模型即服务），如果市场上有售，并只围绕它构建数据加载、监控和跟踪模块。这种解决方案的缺点是，如果需要添加新功能，可能很难按时完成这些添加。

将平台作为黑匣子购买通常需要围绕它构建额外的组件。选择平台时要考虑的一个重要标准是扩展或自定义它的可能性。

基于云的本地或混合部署模型

基于云的解决方案已经上市，AWS、Google 和 Azure 提供了流行的选项。在没有严格的数据隐私要求和法规的情况下，基于云的解决方案是一个不错的选择，因为模型训练和模型服务的基础设施资源是无限的。对于非常严格的安全要求，或者如果基础结构在公司内部已经可用，则本地解决方案是可以接受的。对于已经构建了部分系统但希望通过其他服务对其进行扩展的公司来说，混合解决方案是一种选择，例如，购买预训练模型并与本地存储的数据集成或合并到现有的业务流程模型中。

MLOps 架构实践

从我们的用例来看，金融机构没有足够的专家从头开始构建专业的 MLOps 平台，但由于法规和额外的财务限制，它也不想投资端到端托管的 MLOps 平台。该机构的架构委员会已决定采用开源方法，仅在需要时购买工具。架构概念是围绕开发简约组件和可组合系统的想法构建的。总体思路是围绕微服务构建的，这些微服务涵盖了可伸缩性和可用性等非功能性需求。为了最大限度地简化系统，对系统组件做出了以下决定。

数据管理平台

数据收集过程将完全自动化。由于外部数据提供程序的异构性，每个数据源都将有一个单独的数据加载组件。在写入实时数据和读取大量数据时，数据库选择至关重要。由于宏观经济数据的基于时间的性质以及该机构已有的关系数据库专家，他们选择使用开源数据库TimescaleDB。

使用标准关系数据库 GUI 客户端提供基于 SQL 的标准 API、执行数据分析和执行数据转换的可能性将减少交付平台第一个原型的时间。可以跟踪数据版本和转换并将其保存到单独的数据版本或表中。

模型开发平台

模型开发过程包括四个步骤：

1. 数据读取和转换
2. 模型训练
3. 模型序列化
4. 模型包装

训练模型后，参数化和训练的实例通常存储为打包工件。代码存储和版本控制最常见的解决方案是 Git。此外，该金融机构已经配备了像 GitHub 这样的解决方案，提供定义用于构建、打包和发布代码的管道的功能。基于 Git 的系统的体系结构通常依赖于一组执行管道的分布式工作器计算机。该选项将用作简约的 MLOps 架构原型的一部分，以训练模型。

训练模型后，下一步是将其作为已发布和版本控制的项目存储在模型存储库中。在该阶段，将模型作为二进制文件、共享文件系统甚至工件存储库存储在数据库中都是可以接受的选项。稍后，可以将模型注册表或 Blob 存储服务合并到管道中。模型的 API 微服务将公开模型的宏观经济预测功能。

模型部署平台

使 MLOps 原型尽可能简单的决定也适用于部署阶段。部署模型基于微服务体系结构。每个模型都可以使用 Docker 容器作为无状态服务进行部署，并按需扩展。该原则也适用于数据加载组件。一旦完成了第一个部署步骤，并明确了所有微服务的依赖关系，就可能需要一个工作流引擎来编排已建立的业务流程。

模型监控和审计平台

传统的微服务架构已经配备了用于收集、存储和监控日志数据的工具。Prometheus、Kibana 和 ElasticSearch 等工具足够灵活，可以生成特定的审计和性能报告。

开源 MLOps 平台

简约的 MLOps 架构是公司初始数字化转型的良好开端。但是，并行跟踪可用的 MLOps 工具对于下一个设计阶段至关重要。下表提供了一些最流行的开源工具的摘要。

**表 1.**用于初始数字化转型的开源 MLOps 工具

工具	描述	职能领域
Kubeflow	使 Kubernetes 上的 ML 工作流部署变得简单、可移植且可扩展	跟踪和版本控制、管道编排和模型部署
MLflow（机器学习流）	一个用于管理端到端 ML 生命周期的开源平台	跟踪和版本控制
BentoML系列	用于 AI 应用和推理管道的开放标准和 SDK;提供自动生成 API 服务器、REST API、gRPC 和长时间运行的推理作业等功能;并提供自动生成 Docker 容器映像的功能	跟踪和版本控制、管道编排、模型开发和模型部署
TensorFlow 扩展 （TFX）	一个生产就绪的平台;专为部署和管理 ML 管道而设计;包括用于数据验证、转换、模型分析和服务的组件	模型开发、管道编排和模型部署
Apache Airflow， Apache Beam	一个灵活的框架，用于定义和调度复杂的工作流，尤其是数据工作流，包括 ML	管道编排

总结