机器学习模型部署的三种方法

“企业机器学习需要从数据工程和数据平台的角度看待大局[...]，”贾斯汀·诺曼（Justin Norman）在今年巴塞罗那的DataWorks峰会上关于机器学习模型的部署的演讲中说。

实际上，工业机器学习系统是庞大数据基础架构的一部分，这使得端到端ML工作流变得特别复杂。当我们追求最好的机器学习算法时，与现实世界机器学习系统的开发，部署和维护相关的挑战不容忽视。

 

机器学习并不一定要取代人类的决策，它主要是关于帮助人们做出复杂的基于判断的决策。

我参加的演讲是Cloudera的专家Justin Norman和Sagar Kewalramani进行的“ 机器学习模型部署：实施战略”。他们就端到端ML工作流遇到的挑战作了演讲，重点介绍了将机器学习交付到生产环境。

需求的AI金字塔

越来越多的企业使用机器学习和AI来改善他们的服务并在竞争中领先。不幸的是，许多企业在没有适当的数据平台的情况下进行了AI转换，也没有对部署ML模型的理解。首先应满足几个大数据和数据科学技术需求：

• 大数据基础架构，用于在通常由数据工程师处理的系统的不同部分之间收集，提取，存储，清理和移动数据
• 分析策略，用于探索，可视化，转换和预处理数据为有用的ML输入变量
• 一个框架，用于试验算法，对其进行协作并在跟踪所有模型的参数，准确性和性能的同时进行部署
• 用最简单的数据科学算法建立基准

除此之外，您还需要牢记ML平台的一些重要特征：

• 与业务流程的深度集成
• 连续交付（CI / CD像任何经典代码一样
• 闭环反馈

在演示中，这些需求用金字塔表示，类似于马斯洛的需求层次结构。上面列表中的点被视为金字塔的级别，从金字塔的第一个点开始。这个概念，也称为“需求的AI层次结构”，有助于理解以下要点：

没有用于计算（食物，水，温暖）的基本基础设施，就没有人工智能（与自我实现相对应）。在成功使用机器学习算法之前，您必须能够对过去进行推理并对未来有基本的了解。如果所使用的数据集被误解且未准备好，您将无法期望神经网络会产生出色的结果。

通常，将精力放在基本系统方面可以比调整当前的预测算法更多地提高预测的准确性。例如，与调整ML模型相比，处理输入数据的表示形式可以产生更好的结果。当满足了所有基本工程需求并且准确性不足时，则应该将精力放在更复杂的算法上。

机器学习系统中隐藏的技术债务

考虑到Google题为“机器学习系统中的隐藏技术债务”（pdf）的论文，企业ML系统中软件工程工作的重要性显而易见。作者在其中辩称，现实世界中的ML系统中只有一小部分由ML代码组成。ML代码可能甚至不到整个ML系统的10％。

 

尽管ML代码决定了所有决策，但从整个软件系统的角度来看，这几乎是无关紧要的，而整个软件系统必须为解决最终用户的问题而开发。提供决策的微小ML部分很重要，但是系统中还有许多其他重要组件。花时间在系统架构的设计，模型强化，部署，监视等上至少与花在ML上一样有价值。

端到端ML工作流程的挑战

ML工作流应解决金字塔所有层次的问题，以确保它不会招致潜在的技术债务。为了总结演讲的前半部分，可以确定端到端ML工作流中的三个主要挑战：复杂性，规模和试验。挑战不是排他的，它们都是相互关联的。

复杂

企业机器学习工作流程要求：

• 数据基础架构和大量数据处理为ML模型提供了准备好的数据
• 通过多次实验构建ML模型
• 将ML模型部署到生产中并进行监视的大量工作

上面列出的点可以与三个不同的专业相关：数据工程师，数据科学家和DevOps工程师。他们对项目有不同的看法，对输出有不同的期望，并使用不同的工具。ML系统中存在的示例技术是Hadoop，Kafka，Spark，Tensorflow，xgboost，Docker和Kubernetes。这些工具必须集成，并且必须实现在它们之间安全移动数据的机制。

人们的推理和工具集之间的差异可能导致可能破坏整个项目的问题。例如，数据科学家倾向于使用无法并行化且不能在生产环境中使用的笔记本和软件包来生成代码，因为它们无法部署在分布式系统上。笔记本就像是所需输出模型（蛋糕）的规格（配方））。由于数据工程师和DevOps并不是数据科学领域的专家，因此他们可能会误解该食谱，并烤出另一块蛋糕。仅仅由于团队之间的错误解释，生产中的ML模型可能会导致与预期产品不匹配，并且无法满足用例。由于每个用例需要不同的特定ML模型，不同的数据准备以及部署的特殊考虑因素，因此增加了复杂性。

规模

大规模是工业机器学习的重要特征。机器学习解决方案可能需要扩展才能为数百万个客户提供服务，这意味着需要庞大的数据集。预处理这些大数据集并将其用于训练ML模型需要大量的计算能力。大数据技术通常用于在安全集群环境中通过并行计算来提供该计算能力。将训练有素的机器学习模型大规模部署到生产中也意味着需要DevOps策略和工具。

实验性

创建ML模型是一个涉及许多实验的渐进过程。ML面临的一个独特挑战是跟踪这些实验。必须向数据科学家提供一种手段，用于预订模型每次训练的信息：模型参数，使用的库，版本等。

CI工具和系统必须足够健壮，才能为不同的ML模型（每个都有特定的依赖性）提供灵活性，并具有兼容性，以在生产中快速扩展，升级和降级ML模型。然后，必须监视和管理许多ML模型。

端到端ML工作流程的策略和生命周期

具有ML功能的产品必须将ML管道视为数据基础结构的一部分。同样，机器学习输出必须视为在较大系统中获得的结果的子集。如果没有集成，将ML模型投入生产将需要很长时间才能保持竞争力。

ML工作流的三个部分将得到解决：

• 版本化和可复制的ML模型训练
• ML模型部署
• 生产中的ML模型管理

重要的一点是，无论使用什么工具来开发ML模型，最好避免移动数据。处理数据所在的位置。无需跨多个平台发送数据，而是选择单个可扩展的分布式解决方案，例如在内部部署环境或云环境中。

最好避免移动数据，例如在数据驻留的内部部署环境或云环境内部。

版本化和可复制的ML模型训练

机器学习模型是在迭代过程中创建的。通过许多实验获得了最终投入生产的ML模型，其中以反复试验的方式逐步调整模型的参数和超参数。

不幸的是，跟踪这些实验并不是一种常见的做法，导致最终模型的中间版本往往会迷失方向。ML工作流应提供一种轻松跟踪和管理新兴ML模型的方法。

最终模型之前应有一系列先前模型元信息的快照，例如创建模型的人员和时间，模型的代码，依赖项配置，参数，注释等。

专门解决版本化，可再现的ML模型训练的项目的两个示例是：

• DVC-机器学习项目的开源版本控制系统
• 彗星 -专有解决方案

ML模型部署

部署应快速并适应业务需求。部署的模型应该受到监控并且易于管理。根据业务用例，可以采用三种主要的部署模式：

• 批处理部署-ML模型以脱机方式使用。例如，生成带有预测的每日报告，以帮助管理人员做出决策
• 实时部署-ML模型用于自动执行对时间敏感的决策。例如，在推荐系统和欺诈检测系统中
• 边缘部署-ML模型用于对时间要求严格的系统中，需要立即做出决策。先前的两种部署类型都有一个运行ML模型的中央单元，而边缘部署的模型则直接在外部系统上执行。例如，在自主无人机中

ML模型可以部署为例如Java / C ++ / Python应用程序，Spark应用程序或REST API。与基于API的模型部署相比，将模型作为应用程序进行部署的成本更高且速度较慢，但​​可提供更高的可靠性，更高的速度和更好的安全性。部署格式仍然是很大程度上取决于用例的决定。

用例确定哪种模式部署适用，这又决定了部署格式和使用的工具。例如，在批处理部署方案中，可以选择在Hadoop集群上运行的Scala Spark作业。在实时场景中，需要一种流处理引擎，例如Flink或Kafka Stream。最后，在边缘部署可能需要重写为C / C ++和特定的处理器体系结构。

生产中的ML模型管理

与在训练阶段跟踪实验类似，应在生产ML中跟踪ML模型。

• 在部署时，应收集所有元数据：模型的部署者和部署时间，模型是什么，模型的版本，参数等。
• 必须监视已部署模型的性能，并收集各种度量标准，例如准确性，F1分数（用于衡量测试的准确性），业务KPI，资源使用，响应时间等。需要确定降级模型并分析其性能度量标准。哪个指标发生了漂移，出现了多少，何时出现等情况。

在生产中对ML模型的跟踪使数据科学家可以重新评估模型并重新考虑所选的学习算法。同样，可以部署模型的一些变体并进行比较。应该根据用例的性能，统计意义和实际意义进行比较。

有一些工具专门针对ML模型管理（例如Datmo），但是更常见的是这是整个机器学习平台的功能。

货柜化

如前所述，每种模型部署格式都对应于特定的用例，并具有许多特定的要求：语言，框架，库，包。通常，这些依赖项必须具有特定版本。这创建了许多不同的软件先决条件，通常是相互冲突的。由于依赖性和其他软件冲突之间的版本不匹配，因此在群集的节点上安装不同的软件可能是一个障碍。容器化可以是一种解决方案。我们可以利用容器化在已打包所有必需软件的隔离Docker环境中托管ML模型。可以将不同版本的项目代码打包到具有不同Docker映像的多个Docker容器中。

Kubernetes是部署和管理可伸缩容器化应用程序的绝佳工具。它通常用于编排Docker容器。或者，Hadoop 3可以编排Docker容器。

机器学习平台

仅仅几年前，还没有大规模构建ML系统的工具。大公司必须创建自己的平台，例如Uber的机器学习平台Michelangelo。在某种程度上，这种专有平台为ML工作流创建了标准，然后在开源生态系统中采用了这些标准。

如今，有几种机器学习平台/工具包可用于帮助ML工作流。演讲中提出的最引人注目的选择是Cloudera Data Science Workbench（CDSW），它与常用的数据平台CDH和HDP集成在一起。

Hadoop集群上的ML项目的一个有趣选项是Apache的Hadoop Submarine，我在另一个演讲中发现了Hadoop {Submarine}项目： Sunil Govindan和Zhankun Tang给出的在YARN上运行深度学习工作负载。潜艇允许在Hadoop集群上计算未修改的Tensorflow应用程序。Submarine利用Hadoop YARN编排ML工作负载，并利用Hadoop HDFS收集和存储系统中的数据。由于Hadoop 3支持YARN以及Docker容器上的GPU调度和隔离，因此该解决方案成为可能。

MLflow平台似乎是一个有前途的选择。还有两个替代方案是Polyaxon和Kubeflow，它们适用于Kubernetes。

结论

人工智能和机器学习正在进入工业化阶段。训练ML模型的大规模，复杂性和实验性是企业ML工作流程中的主要挑战。正在创建新的工具和平台，以在行业中开发，训练和部署ML模型。

原文：https://www.adaltas.com/en/2019/09/30/machine-learning-model-deployment/