杀手特性存储:为生产编排Spark ML管道和MLflow

视频记录

你好，火花峰会，我叫Nate。我是一名数据架构顾问，专注于工业化机器学习领域。所以这只是我的雇主用来指我们在机器学习方面所做的工作的术语，它不仅关注于数据科学，而且还关注于将数据科学的研究成果投入生产。因此，有机会在数据架构和机器学习的交集工作，我对功能存储这个新兴概念有了很多了解。这就是我今天要讲的内容。

我想概述一下这个领域的特色商店，它们正变得越来越受欢迎，我想描述一种实现特色商店的方法，我在日常生活中使用，我觉得它可能有点代表性不足，然后在最后我会提供一个演示，展示你如何能够将这些概念中的一些应用到自己的生产中。在我们深入研究这些特写故事的不同之处之前，我们先来看看它们的相同之处所有这些方法的统一之处是我们试图解决的一个共同问题。这是我在工作过的每个数据科学团队中都必须解决的挑战。我们所做工作的科学性质，工作的实验性质，以及我们必须为每个人创造商业价值这一事实合理化之间存在着根本的紧张关系。因此，我们需要的是能够更完整地讲述我们在每一次迭代中为数据科学创造的业务价值。我们可以这样做的一种方法是在每个实验的每次迭代开始时，我们可以非常清楚这是我在这个实验中要验证或否定的商业假设。当我们验证我们的假设时，我们在生产中创造了提升，我们提高了一些KPI，我们用这种方式创造了价值。

但无论如何，即使我们使我们的商业假设无效，我们仍然从我们学到的东西中创造了一些商业洞察力，关键的是，我不是作为个人学习，而是在一个存储库中捕获这种洞察力，以加速未来的研究，我们可以用来捕获这些洞察力的存储库之一是功能存储库。换句话说，特征库当我们使用特征库时我们所做的每一个实验都在加速未来的研究。我做这次演讲的初衷之一是，对关于这个话题的很多材料做一个调查。在做研究的过程中，我确定了这些资源这是一个相对较新的资源它为我们做了很多跑腿的工作。非常感谢featurestore。org这意味着今天我们可以不关注所有已经发布的东西但我们可以谈谈这些方法是如何不同的我们可以深入研究其中的一种方法。所以你要自己做研究你不可能在这个网站上找到所有的商业产品但这是一个很好的资源，谢谢你在featurestore.org上的朋友们有很多方法来分解这些不同的方法我选择的是，作为一个工程师，找出每一种方法中被自动化的东西。当我部署机器学习应用程序时，我不再需要做什么目前最常见的方法最常见的特征存储实现是我们将数据自动交付给科学家或生产应用程序。这种方法最常见的问题是，它与现有的数据管理和数据治理框架有什么不同?我们已经有了一个数据目录，我已经有了管理ETL运行时的策略。这里有什么新鲜事吗? And the way that I answer that is that when we’re working with these machine learning applications we wanna extend that framework we wanna extend that governance framework to capture some of the nuances and edge cases of our machine learning applications. So here’s an example of some of the semantics who might need to extend our data governance framework with. If you’re not doing machine learning you’re probably not dealing with training and test data, but here’s why you might want your governance framework to be aware of these concepts in the context of machine learning. Here’s a typical example of what we might be doing when we’re deploying machine learning application. Say some sales data, one of the first things I might wanna do with that sales data might want create some customer segments, depending on the model I’m creating what probably I gonna do is I’m gonna break my data down into a train set it’s a set. I do some machine learning I create that produces a model the model makes predictions and then crucially here the output those predictions are themselves feature themselves features that can be used to accelerate future research. So this seems like the ideal scenario for a feature store I’m creating a business insight, I’m using that to accelerate future research in this case, that future research might involve building a model next best action. Clearly something that could benefit from a customer segmentation So similarly I’m gonna join the customer segmentation to some other feature data from my source data I’m going to do a train test split this seems like the ideal scenario for a feature store, but what has gone wrong here? So if we were to build this model, what we’ll probably find is that the model performs really well on our test data and so we would continue to we would continue to tune our model and we would continue to perform really well on our test data and then when we go to deploy on our model, we would find that our test data is our performance on our test data is not a good signal of how our model is gonna generalize to unseen data, right? The fundamental reason we wanna create these training and test sets is to give us that signal so that we know for over fitting our model what we might find in this system here, is that our test data is no longer providing that signal. And the reason for that is that information about our test data has snuck into our training process through the segmentation feature. So this is an example of why you might want to extend your data governance framework to be aware of these training and test semantics or other machine learning semantics. In theory we want to deliver our data to our scientists or to our production applications in a way that helps us avoid this situation.

第二种管理特性的方法有很多方法，它们描述了我们如何自动化，而不是我们交付数据的方式，而是我们如何进行特性工程中涉及的ETL。所以很多科学家已经观察到我们在特征工程中做的很多ETL都是重复的感觉就像是可以自动化的东西你知道，基于这些维度打开我的数据，基于这些维度旋转我的数据，创建一大堆特征把它们输入到特征选择算法中这可能是一种更自动化的特征工程方法。这是另一类特性管理的方法。在接下来的演讲中，我想更深入地探讨我们如何构建机器学习管道的自动化。因此，自动化和构建我们的机器学习管道的一个例子是，自动机器学习率背后的方法，这些是针对公民数据科学家的方法。有些科学家可能在算法设计方面没有深入的知识，但仍然可以从机器学习中受益。今天我想分享的是一种自动化构建ML管道的方法。在某种程度上，针对那些做算法设计的人，让我们向他们公开API，这不是为他们做算法设计，而是隔离连接管道和部署管道的操作的关注点，这样他们就可以专注于算法设计。

对于外行来说，我们在谈论什么?

我说ML管道是什么意思?我们中的一些人可能对机器学习的工作方式有一个看法你知道，机器学习有一个常见的观点，它集中在机器学习的最后一步，我们有一个估计器，它取一些有特征的数据，我们最终的有特征的数据集，然后做一些类似逻辑回归或决策树的事情来做出预测。实际上，在工业化环境中，这通常是整个估计器管道的最后阶段。每个估计器创建特性，以向下游输送到管道中。这方面的一个例子就是之前提供的例子，我把它作为创建下一个最佳行动模型的第一步，我可能会在客户细分中使用。好的，那么这些多个估计器如果，组装成一个管道，完整的管道是适合数据的，当我们把这些类型的应用程序投入生产时，我们发现这是至关重要的，我们不仅要管理管道中产生的模型，当我们使它适合我们的数据时，还要管理管道本身的整个工件。我们需要对管道的洞察和控制，就像我们需要对模型的洞察一样。这就是代码的样子。这来自Spark文档，它只是快速入门文档，这就是管道的样子。我们定义了管道的一些阶段在这种情况下，我们有一个哈希我们使用哈希估计器虚拟化我们的输入，然后它适合逻辑回归，所有这些都连接到管道管道适合我们的训练数据，然后输出一个模型，该模型做出预测，我们评估模型质量。 And the basic insight behind the approach I’m going to describe in the last few minutes here is it comes down to this question, why does this line of code exist?

ML管道审核

这里仅仅是为了语法目的，还是我今天想说服你们的是，事实上，在这一点上，我们有所有的信息来隐式地构建一个管道，而不必显式地将这些阶段连接在一起，通过这样做，它为我们创造了优化管道的结构和在其之上的层治理的机会。让我们来谈谈这个算法，首先作为对比，我们来谈谈这些管道通常是如何部署的。这是一个管道和我们在代码中看到的很像我们对文本进行标记化或者对文本进行向量化然后在上面建立一个NOP模型。我们的第一个场景，是创建一个情感模型。现在通常会发生的是，部署这个情感模型，我将进入下一个实验迭代现在我想部署一种新的模型也许我想尝试做出一些关于文本毒性而不是文本情感的推断。通常情况下，情感管道会存在于笔记本电脑中，我会复制粘贴笔记本电脑的大部分，然后复制粘贴管道的大部分不仅在代码中而且在计算中会有很多冗余这些特征化步骤在计算上非常昂贵。现在，如果我试图在这个管道之上建立任何治理，或者在这些管道之上建立自动化，那也会到处粘贴副本。所以我想要的另一种选择是能够声明我的管道的阶段并给出关于我的管道的当前元数据，特别是我需要从我的管道中得到什么在这种情况下，我需要一个情绪预测一个毒性预测。我可以评价一个相对简单的算法，它可以反向构建一个管道，它可能更优一点。我不仅删除了一行代码我还通过推断，通过隐式地从我声明的阶段和声明的元数据构造管道。 I’ve already seen some early optimizations that I can do when I construct this pipeline. But so far this is a pretty simple algorithm, we can take a look at a more interesting case in this case we want to experiment with two different strategies for vectorizing our text. So maybe my sentiment model will perform better if I use a different strategy for turning my text into a vector.

如果我用同样的方法构造这个图，我将发现，我实际上可以将这个图输入spark，原因是我有多条入边指向一个节点，对吧?Spark不能确切地知道它从哪里得到数据不能有这种程度的模糊性它需要知道我的情感估计器需要知道从哪里得到这些向量。所以这个问题的一个解决方法就是重建这个图，通过对原始图的遍历来重建它，对吧?它看起来就像这样。这里有一些有趣的应用程序，我有一些用于AB测试的应用程序，我可以比较我的管道在使用Word2vec作为向量化器时的表现，而不是为什么使用TFIDF作为向量化器。这已经从这种隐式构建管道的算法方法中出现了，但这里出现的另一件事是一些非常有趣的元数据。因此，我自然有一个关于数据谱系的元数据，我知道我的情感模型从哪里得到它的预测，我知道这些数据是如何依次构建的。这是机会更好的管理我们的操作任务,如元数据管理和运行时优化和他们仅仅来自于算法本身,而是真正的价值这是我们的机会,创建新的类型的API是基于该算法和我得到真正的方式加速从操作的角度看这是因为它是事实,我现在可以构建的API,更好的隔离问题的算法设计操作我的担忧构建我的管道，我如何构建我的DevOps，我如何部署那个管道，围绕运行时管理的自动化。

将算法设计与操作分离

元数据管理和发现，以及如何在管道之上进行层或治理。因此，我将提供一个类似API的演示以及API的部署示例，它表明了我们可以在管道之上与元数据和层治理交互的一些新方法。

演示结束后，我会把事情交给未来的Nate来回答你们的任何问题，我希望你们能留下来回答这些问题，并在演讲结束时提供反馈。特性流ML管道编排算法为编写分离关注点的API创造了新的机会

如何从我们的操作上考虑韵律设计。关注诸如沉思式管理、运行时管理和治理。这是另一个API实现的例子，

作为ADO部署管道的一部分。

所以，在这里，我们只是在做一些典型的算法设计，定义我们的ML管道的一些阶段，在这种情况下，我们定义了一些NLP标记化策略，并在此基础上构建一个情感模型。

回想一下，我们并没有明确地将这个管道的各个阶段连接起来我们依赖于特征流算法来做到这一点但我们确实在我们的管道周围定义了一些元数据具体地说，我们告诉算法这里是我期望的输出。

通过某种方式，我期待一个情绪预测，我希望它能加入到作为管道输入提供的文本中。

所以，很明显，

从这些

这些算法问题是与我们的操作工具(如ML流模型管理工具或数据块运行时管理工具)的集成。这些关注点被处理了，隐藏在这个API后面，对吧?特别是对于所有的管道阶段，我们已经定义了我们现在有这个API方法可以用来部署这些阶段。

因此，所有这些操作方面的关注，包括如何评估管道的治理以及如何配置集群的棘手细节，所有这些都以可重用的方式被捕获

作为这个API的一部分。

为了更具体地说明，这里有一个这样的部署可能导致的结果的例子。这里，API为我们管理三个作业。我们正在管理一个作业，使我们的管道与数据相匹配

这是提供的

然后因为这个管道的输出是一个模型我们把它存储在模型目录中模型目录作为分段模型和生产模型的概念，我们有两个任务用于使用模型目录中的模型进行预测一个任务用于使用已升级到分段的模型进行预测另一个任务用于使用已升级到生产的模型。

因此，与ML流模型管理集成的所有细节都被封装到这些工作中，我们可以期望我们周围有控制和保证，收集了哪些指标?在ML流和模型目录中使用什么标准来收集所有这些数据?

那么元数据管理呢?当我们进行此部署时，我们捕获了关于管道的各种元数据，这些元数据最终在哪里呢?

你可以把它放在我们演示的UI的任何地方

这有助于

说明除了管理特性数据本身之外，还可以通过管理我们的管道阶段和特性化阶段来创建一些额外的见解。举个例子，

除了搜索文本向量等特征外，我还可以识别消耗文本向量的相关阶段，或者我有什么创建文本向量的策略，就像科学家一样，

制定这些策略并与他人分享。

还因为我不仅要管理特色数据，还要管理

我可以将这些管道与埃森哲阶段的特性联系起来。这里我们可以看到这是一个管道的一些信息这个特性化阶段正在被使用。我对这些管道是如何连接在一起的有一个简单的可视化，所以我对管道有深入的了解，但也因为我在管理运行时，我有深入的了解

进入运行时。这里我们用的是一种流行的可视化方法叫做facet可视化。