Get best of the week

为什么在ML数据领域需要DevOps



在生产环境中部署机器学习（ML）并非易事，但实际上，这比部署常规软件要困难一个数量级。结果，由于大多数组织都放弃并放弃了尝试使用ML来推广其产品并服务于客户的机会，因此大多数ML项目都将一无所获。

据我们所知，大多数团队无法按预期规模在生产中创建和部署ML的基本障碍是我们仍然无法引入DevOps实践在机器学习中。已经发布的MLOps解决方案部分公开了创建和部署ML模型的过程，但是它们缺乏ML最困难的方面之一的支持：数据。

在本文中，我们讨论了为什么行业需要ML数据的DevOps解决方案，以及ML数据的独特困难如何阻碍将ML付诸实践并将其部署到生产中的努力。本文介绍了当前ML基础架构生态系统中的真空，并建议使用Tecton（一种用于机器学习的集中式数据平台）填充真空。单击此处，阅读我的联合创始人Mike的文章，以获取有关启动Tecton的更多详细信息。

Tecton是由一组工程师创建的，这些工程师为Uber，Google，Facebook，Twitter，Airbnb，AdRoll和Quora等公司创建了内部ML平台。这些公司在ML上的大量投资使他们能够开发流程和工具，以在其组织和产品中广泛使用ML。本文介绍的课程以及Tecton平台本身，很大程度上是基于我们ML部署团队在过去几年中的生产经验。

还记得软件发布漫长而痛苦的时候吗？


二十年前的软件开发和部署过程与当今的ML应用程序开发过程有很多共同点：反馈系统变得非常长，而到产品发布时，您的最初要求和设计已经过时了。然后，在上世纪90年代末，出现了一组以DevOps形式出现的软件开发最佳实践，它们提供了管理开发生命周期的方法，并使我们能够持续快速地进行改进。

DevOps方法使工程师可以在定义明确的通用代码库中工作。一旦分阶段的变更准备好部署，工程师便可以通过版本控制系统对其进行验证。持续集成和交付过程（CD / CI）进行最新更改，执行单元测试，创建文档，执行集成测试，结果，以受控方式将更改发布到生产中或准备发布发布。


图。1：典型的DevOps流程DevOps的

主要功能：

  • 程序员自始至终拥有自己的代码。他们有权对生产中的每一行代码负责。这种主人翁意识通常会提高代码的质量以及程序的可用性和可靠性。
  • 团队能够快速重复流程，而不受级联模型长达数月的周期的约束。取而代之的是，他们几乎可以立即与真实用户一起测试新功能。
  • 快速检测和分析性能和可靠性问题。如果性能指标在上次部署后立即下降，则会触发自动回滚，并且导致代码中的部署发生的更改很可能导致指标下降。

如今，许多开发团队已将这种集成方法作为基础。

...总的来说，机器学习的部署仍然漫长而痛苦


与软件开发相反，没有用于快速生产数据分析的明确定义的全自动过程。创建ML应用程序并将其部署到产品的过程包括几个步骤：


图 2：数据分析专家必须在不同领域的多个团队之间协调工作

  • 发现和访问源数据。大多数公司的数据科学专家最多花费80％的时间来搜索用于建模问题的源数据。这通常需要与数据工程师和监管团队进行跨职能的协调。
  • . , . , , .
  • . . ( ).
  • 模型的部署和集成。此步骤通常涉及与使用该模型进行预测的服务进行集成。例如，在线零售商的移动应用程序使用推荐模型来预测产品报价。
  • 监控设置。再一次，要确保ML模型和数据处理正常工作，需要程序员的帮助。

结果，机器学习团队面临着程序员二十年前面临的同样问题：

  • 数据科学专家并不完全拥有模型和功能的生命周期。要部署他们的编辑并在生产中提供支持，他们必须依靠其他人。
  • data science . . . , , data science, , , , , .


. 3: ,

  • . data science, . , , , .

DevOps ML . DevOps ML data


诸如Sagemaker Kubeflow之类的MLOps平台朝着正确的方向发展，以帮助公司简化ML的生产，因此我们可以观察到MLOps如何在ML中引入原理和DevOps工具。首先，他们需要相当可观的前期投资，但在正确整合之后，他们能够扩展ML模型的训练，管理和生产领域的数据科学专家的能力。

不幸的是，大多数MLOps工具倾向于将重点放在围绕模型本身的工作流上（培训，实施，管理），这给现有ML带来了许多困难。 ML应用程序由代码，模型和数据定义。。它们的成功取决于创建高质量ML数据并将其快速稳定地交付生产的能力……否则，这就是另一种“垃圾进，垃圾出”的方式。下图是从Google关于ML中的技术债务的工作中特别选择和改编而成的，它说明了ML系统中的“以数据为中心”和“以模型为中心”的元素。今天，MLOps平台与许多“模型为中心的”元素的帮助，但只有少数“以数据为中心”的人或根本不影响他们：


图。 4：机器学习系统的模型和等轴心要素。如今，以模型为中心的元素已被MLOps系统广泛覆盖。

下一部分演示了我们在简化ML生产中遇到的一些最困难的测试。它们不是全面的示例，但是它们旨在显示我们在ML数据生命周期的管理（功能和标签）管理过程中遇到的问题：

  • 访问正确的源数据源
  • 从源数据创建功能和标签
  • 合并训练数据中的功能
  • 生产功能的计算和发布
  • 生产追踪

在进一步深入之前，有一个小提示：ML函数是作为模型决策输入的数据。例如，食品配送服务希望在其应用程序中显示预期的配送时间。为此，必须预测在特定时间，在特定餐厅中特定菜肴的准备时间。创建此类预测的便捷信号之一-代表餐厅的繁忙程度-将是最近30分钟内收到的订单的“最终帐户”。所述函数是基于所述顺序次序的最初的数据流计算：


图 5：通过函数转换将初始数据更改为函数值

测试日期1：访问正确的源数据


要创建任何功能或模型，数据科学专家首先需要找到正确的数据源并对其进行访问。一路上有几个障碍：

  • 数据发现：专业人士需要知道源数据在哪里。数据分类系统（例如Lyft的Amundsen）是一个很好的解决方案，但尚未得到普遍使用。通常，必要的数据通常根本不存在，因此必须首先创建或分类。
  • 批准访问：经常在授权机构之间四处奔波以获得获取将解决问题的数据的权限，这是数据科学专家必经之路。
  • : , , . , .

- #2:


源数据可以来自许多源，每个源都有其自己的重要属性，这些属性会影响从中提取的功能的类型。这些性质包括对数据源支持转换类型，数据相关性，以及金额数据的归档可用：


图6：不同的数据源有不同的方法来进行不同类型的数据转换，并根据相关性提供对不同数量数据的访问。

将这些属性考虑在内非常重要，因为数据源的类型决定了数据科学专家可以从源数据获取的功能类型：

  • ( Snowflake Redshift) ( ). , , « ».
  • ( MongoDB MySQL) . , 24 .
  • ( Kafka) ( ). . , « 30 ».
  • 预测查询数据是在进行ML预测之前实时发生的事件的初始数据，例如，用户刚在搜索栏中输入的查询。即使此类数据有限，它也通常尽可能“新鲜”，并包含易于预测的信号。这样的数据带有预测请求，并且可以用于实时计算，例如在用户的搜索查询和搜索数组中的文档之间搜索相似性估计。

展望未来，我们提请您注意：将来自不同来源的数据与互补特征相结合，可以创建出真正出色的功能。这种方法需要实施和管理更高级的功能转换。

测试日期3：将功能结合到训练数据中


训练或测试数据集的形成需要组合相应功能的数据。在这种情况下，有必要跟踪许多可能对模型产生关键影响的细节。最阴险的两个是：

  • 数据泄漏：数据科学专家需要确保他们的模型被训练在正确的信息，并没有允许的无用信息“泄露”到训练数据。这样的数据可能是：来自测试套件的数据，来自真实情况的数据，来自未来的数据或违反重要准备过程（例如匿名）的信息。
  • : — . ( ). , data science , .

- #4:


模型实时投入运行后，为了创建正确且相关的预测，它需要不断提供新的功能数据-通常是大规模的且等待时间最少。

我们应该如何将这些数据传递给模型？直接从源头？从存储接收和传输数据可能需要几分钟，几天，几小时甚至几天的时间，这对于实时输出数据来说太长了，因此在大多数情况下是不可能的。



在这种情况下，必须取消功能的计算和功能的使用。用于初步计算（预计算）功能及其将它们运送到为交付而优化的生产数据仓库中，有必要使用ETL流程。这些过程带来了更多的困难，并需要新的维护成本：



在关联性和盈利能力之间寻求最佳折衷方案：畅通无阻的计算和使用功能将关联性放在首位。通常，由于成本的增加，功能的流程可以更频繁地运行，因此产生更多的相关数据。正确的折衷方案因功能和用例而异。例如，如果更新30分钟的最终发票窗口的汇总功能比更新2周的最终发票窗口的类似功能更频繁，则该汇总功能将很有意义。



功能流程整合：加快功能的产生需要从几个不同的源获取数据，因此，解决与此相关的问题比仅使用一个数据源时要复杂得多，我们之前已经讨论过。此类过程的协调以及将其结果集成到单个功能向量中，要求数据工程界采用严肃的方法。



防止训练失真（训练/发球偏斜）：学习结果与工作过程之间的差异会导致学习失真。训练期间的失真很难检测到，并且它们的存在会使模型预测无法使用。当基于与生成的数据不同的数据得出结论时，该模型可能会表现混乱。就其本身而言，失真问题以及与它们一起工作的问题值得单独撰写一系列文章。但是，值得强调两个典型的风险：

  • : ( ) , . Null? ? . .


. 7 ,

  • ́ : - ( ). , , , . , , . — , , , .


图。8：该图显示了订单的最终帐户：在（1）上显示了为预测发布并每10分钟更新一次的函数的值; 关于（2）的训练数据显示，与为生产发布的功能相比，错误地更清楚地显示了真实值

测试日期5：生产中的跟踪功能


尽管进行了所有尝试来正确解决上述问题，但是某些事情还是会破裂。当ML系统崩溃时，它几乎总是由于“数据完整性违规”而发生。该术语可以表示许多不同的原因，每个原因都需要跟踪。违反数据完整性的示例：

  • : , , . , , . , .
  • : , . , , (, ), .
  • : . , (, , ) .
  • 对数据质量的责任不明确：如果功能可以从多个不同的分发源接收源数据，那么谁最终对功能的质量负责？创建该功能的数据科学专家？训练过模型的数据科学专家？数据馈送通道的所有者？将模型集成到生产中的程序员是谁？如果职责不明确，问题将长期无法解决。

这样的测试甚至为数据科学和ML工程领域的最高级团队创造了几乎无法克服的障碍。解决这些问题所需的条件要比大多数公司不变的现状要好得多，因为个体定制的解决方案仍然是解决这些问题的唯一方法。

Tecton简介：日期机器学习平台


在Tecron，我们正在创建一个用于机器学习的约会平台，以为数据科学领域中最常见和最困难的问题提供帮助。

在较高级别，Tecron平台具有：

  1. 功能流程可将您的源数据转换为功能和标签
  2. 功能库，用于存储存档的功能和标签数据
  3. 功能服务器向生产发布最新功能值
  4. SDK，用于训练数据和操作功能流程
  5. Web UI，用于监视和跟踪功能，标签和数据集
  6. 监视引擎，用于确定数据质量或漂移问题以及警报



图。9：作为ML的中央数据平台，Tecton在开发环境和生产中提供功能，

该平台允许ML团队将DevOps实践引入ML数据：



  • 规划： Tecron功能部件存储在中央存储库中。这使数据科学专家可以共享，查找和使用彼此的工作。
  • 代码： Tecton允许用户设置简单而灵活的功能转换过程。
  • 构建： Tecton将功能编译为高性能数据处理任务。
  • 测试： Tecton支持功能和功能的集成测试。
  • 发布： Tecton与git紧密集成。所有功能描述均具有版本控制，并且易于复制。
  • : Tecton ( Spark). Tecron.
  • : Tecton data science , .
  • : Tecton .

当然，没有ML模型的ML数据不会为您提供ML的实际实现。因此，Tecton提供了灵活的API并与现有的ML平台集成。我们从Databricks，SageMaker和Kuberflow开始，并继续与互补的生态系统组件集成。

More articles:


All Articles