1、引言
- 在ML项目生命周期的更大背景下强调生产部署
2、CI/CD管道
2.1、概念
- CI
- 持续集成
- 工具:Jenkins
- 持续集成
- CD
- 持续交付
2.2、目的
- 以更频繁、更快速地发布应用程序,同时更好地控制质量和风险
2.3、目标
- 避免将工作合并的不必要努力
- 尽快发现错误或开发冲突
2.4、案例
- (1)构建模型
- 构建模型工件
- 将工件发送到长期储存库
- 运行基本检查
- 冒烟测试
- 健全性检查
- 生成公平性和可解释性报告(评估)
- (2)部署到测试环境
- 运行测试以验证机器学习性能、计算性能
- 手动验证
- (3)部署到生产环境
- 部署为金丝雀
- 完全部署模型
2.5、注意事项
- 没有通用的方法,可以从最简单的工作流开始,逐步引入自己企业个性化的更复杂的流程。
3、创建ML工件
3.1、使用集中的版本控制系统
- 常见的版本控制系统
- Git
- 数据版本化
- Git扩展
- 文件格式
- 数据库
3.2、ML工件
3.2.1、概念
- 构建一个可测试和可部署的项目包,在CI/CD中,这些包就是工件
3.2.2、包含元素
- 模型及其预处理的代码
- 超参数和配置
- 训练和验证数据
- 可运行形势的训练模型
- 环境
- 具有特定版本的库
- 环境变量
- ...
- 文档
- 测试场景的代码和数据
- ...
3.3、测试管道
3.3.1、作用
- 可以验证工件中模型的各种特性
- 验证是否符合要求
- 很容易在失败时诊断问题的源头
3.3.2、测试方案
- 命名测试
- 测试类型
- 近期情况确定
- 从近期时间提取数据集并测试,用时间命名例如23年3月22日数据测试等
- 特殊情况确定
- 缺失值测试、或者极值测试等
- 基本情况确定
- 在固定的数据集上执行测试
- 近期情况确定
- 测试要求
- 尽可能自动化
- 测试类型
4、部署策略
4.1、区分概念
- 集成
- 将一个贡献文件合并到一个中央存储库(通常将一个Git特征分支合并到主分支)并执行或多或少复杂测试的过程
- 交付
- 构建一个完全打包并经过验证的模型版本的过程,该版本可以部署到生产环境
- 部署
- 概念
- 在目标基础设施上运行新模型版本的过程
- 类别
- 批处理
- 实时处理
- 概念
- 发布
- 生产工作负载指向新版本
4.2、生产中的维护
- 维护开始时间
- 模型发布后
- 维护措施
- 资源监控
- 收集信息技术指标,例如中央处理器、内存、磁盘或网络使用等
- 健康检查
- 固定间隔1分钟左右,查询模型并记录结果
- ML指标监控
- 通常一周一次,对模型的准确性分析或者与另一版本进行比较。
- 资源监控
5、容器化
5.1、背景
- 一台机器运行多个模型,可能会争夺资源,一个行为不良的模型可能会损害多个协同模型的性能
5.2、目的
- 解决资源争夺的问题
5.3、用法
- 工具和应用程序与其配置文件、库、依赖项捆绑到一起
- 与虚拟机不同,多个容器共享同一个操作系统。资源效率更高
5.4、案例
- Docker
- 容器化的标准
- 允许一个应用程序被打包,发送到一个服务器(Docker主机),并在与其他应用程序隔离的情况下运行它的所有依赖项。
- 模型
- 构建一个环境,可以容纳许多模型,每个模型可以运行多个副本
- 可能需要多个Docker主机
- 框架的问题
- 那个主机应该接受容器?
- 一个模型部署多个副本,如何平衡工作负载?
- 托管机器故障,后果会怎么样?
- 如何检测故障并重新配置容器?
- 如何跨多台机器升级某模型?
- 如何确保新旧版本顺利切换?
- 如何保证负载平衡器仪正确的顺序进行更新?
负载平衡器:
(1)概念
负载平衡是在两台或更多的计算机之间分配计算工作负荷的做法。在互联网上,负载平衡经常被用来在几个服务器之间分配网络流量。这能够减少每台服务器的压力,使服务器更有效率,加快性能,减少延迟。负载平衡对于大多数互联网应用的正常运行是必不可少的。
(2)运作
负载平衡由称为负载平衡器的工具或应用程序处理。负载平衡器可以是基于硬件的,也可以是基于软件的。硬件负载平衡器需要安装专用的负载平衡设备;基于软件的负载平衡器可以在服务器、虚拟机或云中运行。内容交付网络 (CDN) 通常包括负载平衡功能。
当来自用户的请求到达时,负载平衡器将请求分配到给定的服务器,并对于每个请求重复此过程。负载平衡器根据多种不同的算法确定应由哪个服务器处理每个请求。这些算法分为两大类:静态和动态。
(3)用处
负载平衡通常用于 Web 应用程序。基于软件和基于云的负载平衡器有助于在托管应用程序的服务器之间平均分配互联网流量。一些云负载平衡产品可以在全球分布的服务器之间平衡互联网流量负载,这一过程称为全局服务器负载平衡 (GSLB)。
负载平衡也常用于大型本地化网络,例如数据中心或大型办公大楼内的网络。传统上,这需要使用硬件设备,例如应用程序交付控制器 (ADC) 或专用负载平衡设备。基于软件的负载平衡器也用于此目的。- Kubernetes正在成为容器编排的标准,极大简化了许多问题
- Docker与Kubernetes可以提供一个强大的基础设施来托管应用程序,包括ML模型。
6、扩展部署
6.1、背景挑战
- 在生产中使用具有大规模数据模型的能力
- 训练越来越多模型的能力
- 模型部署的几种情况
- 一个模型部署在一台服务器上
- 一个模型部署在多台服务器上
- 一个模型的多个版本部署在一台服务器上
- 一个模型的多个版本部署在多台服务器上
- 多个模型的多个版本部署在多个服务器上
6.2、平台要求
- 水平可扩展
- 一个计算系统能够逐步增加更多计算机来扩展处理能力
- 弹性系统
- 自适应添加和删除资源
- 集群使用指标高的时候,自动添加机器
- 集群使用指标低的时候,自动删除机器
- 自适应添加和删除资源
7、需求和挑战
7.1、需求:一个有效的记录日志系统能够生成数据集给模型使用
- 可以从多个服务器访问和检索
- 实时评分用例
- 批量评分用例
- 分布式批处理(批量评分)
- 概念
- 从字面来理解就是有大批量的业务数据需要应用程序去批量计算处理,而通过单机模式去执行会耗费很长的处理时间,也不能充分发挥业务集群中每个应用节点处理能力。
- 作用
- 可以有效地让业务集群中所有业务应用节点协同完成一个大批量数据处理的任务,从而提升整体的处理效率和处理可靠性。
- 挑战
- 数据量太大
- 策略
- 使用本地处理分布式计算的框架,特别是Spark。
- 对数据进行分区
- 一行一行的评分
- 某种分割方式,可以几台机器对相应行的子集进行评分
- 概念
- 分布式批处理(批量评分)
- 可以跨服务器处理所有任意版本的所有信息的映射和聚合
7.2、挑战
- 大规模的机器学习应用,没有预处理过滤聚合数据,则日志数量会很大
- 实时评分用例的流数据记录需要建立一套全新工具,需要大量维护工作