在这篇评论中，描述了当前的Feature Store格局，以及如何在MLOps管道中构建？
人工智能和机器学习已达到拐点。在2020年，各种规模的不同行业的组织开始将其ML项目从实验发展到工业规模的生产。这样做的时候，他们意识到他们在功能特征定义和提取上浪费了很多时间和精力。
Feature Store是ML堆栈和任何强大的数据基础结构的基本组成部分，因为它可以实现有效的功能工程和管理。它还允许简单地重复使用功能，整个公司范围内的功能标准化以及离线和在线模型之间的功能一致性。集中式，可扩展的Feature Store（功能存储）使组织可以更快地进行创新并大规模推动ML流程。
Provectus的团队 已建立了多个功能库，我们希望分享我们的经验和教训。在本文中，我们将探讨功能存储区如何帮助消除返工并增强团队之间从源到模型的数据可追溯性。我们将研究构建可扩展功能存储的细节，并讨论如何实现实时功能与训练功能之间的一致性，以及如何提高数据随时间传播的可重复性。
什么是Feature Store（功能存储）
功能存储是用于机器学习功能的数据管理层。机器学习功能是观察中的现象的可测量属性，例如原始单词，像素，传感器值，数据存储中的数据行，CSV文件中的字段，聚合（最小，最大，总和，均值）或派生表示（嵌入或簇）。
从业务角度来看，Feature Store具有两个主要优点：
- 通过降低每个模型的成本，从要素工程中获得更好的投资回报，从而促进要素的 协作，共享和重用
- ML工程师提高了生产率，从而加快了新模型的上市时间。这使组织能够将ML工程师的存储实现和服务API的功能分离开来，使他们可以在模型上工作，而不是在延迟问题上工作，以实现更有效的在线服务。
某些用例不需要集中的，可伸缩的功能存储。特征存储适用于需要模型有状态，不断变化的系统表示的项目。这种用例的例子包括需求预测，个性化和推荐引擎，动态定价优化，供应链优化，物流和运输优化，欺诈检测以及预测性维护。
Feature Store概念
标准化功能存储具有围绕它的某些关键概念。这些概念是：
- 在线功能存储。在线应用程序寻找特征向量，该特征向量被发送到ML模型进行预测。
- ML特定元数据。启用发现和重复使用功能。
- ML特定的API和SDK。用于获取培训功能集和在线访问的高级操作。
- 物化版本化数据集。维护用于训练ML模型的功能集的版本。
这四个概念得到多种产品的支持。市场的领导者是Feast，Tecton，Hopsworks和 AWS SageMaker Feature Store。
现代数据平台的挑战
在研究构建功能存储的细节之前，必须考虑现代数据平台的挑战。无法将要素存储与其余数据和ML基础结构隔离地进行检查 。
传统上，规范的数据湖架构如下所示：
图片由作者提供。
这种高级体系结构具有用于采购，提取，处理，持久化，查询和使用者组件的组件。尽管它对于大多数任务都可以正常工作，但并不理想。
- 数据访问和可发现性 可能是一个问题。数据分散在多个数据源和服务中。这曾经帮助保护数据，但现在只增加了一层新的复杂性并创建了数据孤岛。这种架构需要繁琐的过程来管理AWS IAM角色，Amazon S3策略，API网关和数据库权限。在多帐户设置中，这甚至变得更加复杂。结果，由于默认情况下无法发现元数据，工程师对存在哪些数据以及实际上可以访问哪些数据感到困惑。这将创建一个环境，其中由于数据访问问题而减少了对数据和机器学习的投资。
- 整体数据团队 是另一个要考虑的问题。由于数据和机器学习团队非常专业，因此它们通常必须在上下文之外进行操作。所有权和域上下文的缺乏在数据生产者和数据消费者之间造成了孤岛，使积压的数据团队很难满足业务需求。数据和ML Engineering成为复杂依赖关系的受害者，无法同步其操作。在这种情况下，不可能进行任何快速的端到端实验。
- 机器学习实验基础设施 是未知领域。传统架构缺少实验组件，这不仅导致数据发现和数据访问问题，而且使维护数据集，ML管道，ML环境和脱机实验的可重复性变得更加复杂。尽管Amazon SageMaker和Kubeflow在这里取得了一些进展，但可重复性还是有问题的。生产实验框架尚不成熟，不能完全依赖。结果，可能需要三到六个月的时间才能将一个端到端实验从数据推向生产ML。
- 在生产中扩展ML 很复杂，需要大量时间和精力。尽管机器学习主要被视为离线活动（例如，数据收集，处理，模型训练，评估结果等），但实际使用模型和在线服务模型的方式才是真正重要的。使用传统架构，您无法在模型服务期间以统一且一致的方式访问功能。您也不能在多个培训管道和ML应用程序之间重用功能。ML应用程序的监视和维护也更加复杂。结果，在生产中从1个模型扩展到100个模型所需的时间和成本成倍增长，这限制了组织以所需的步伐进行创新的能力。
为了应对这些挑战，出现了一些架构上的转变：
- 从Data Lake到Hudi / Delta湖泊。数据湖不仅仅是Amazon S3中的文件夹。它是功能丰富的，完全托管的层，用于数据摄取，增量处理以及与ACID事务和时间点查询一起使用。
- 从数据湖到数据网格。数据域，数据管道，元数据和API的所有权正在从集中式团队转移到产品团队。另一个有效的好处是将数据视为一个完整的产品并拥有，而不是没有人关心的副作用。
- 从数据湖到数据基础设施平台。如果数据所有权分散，则平台组件必须统一并打包到可重用的数据平台中。
- 从端点保护到全球数据治理。作为向集中式数据平台转变的一部分，组织正在从Endpoint Protection迁移到Global Data Governance，这是用于跨可用数据源管理安全性和数据访问策略的高级控制计划。
- 从元数据存储到全局数据目录。像Hive元存储这样的元数据存储不能聚合许多数据源。业界需要一个全球数据目录来支持有关数据发现，沿袭和版本控制的用户体验。
- 功能存储。功能存储是ML堆栈中新出现的组件，它通过为ML功能添加单独的数据管理层来实现ML实验和操作的扩展。
所有这些转换都是并行发生的，应该整体考虑。您无法开始设计功能存储并最终为功能和其他数据应用程序使用单独的数据目录。在构建功能部件存储时，您必须依靠数据版本控制功能，这些功能很容易成为其他并行项目的一部分。
现代数据基础架构
现在让我们看一下现代数据基础架构。
图片由作者提供。
我们对原始数据进行批处理，对事件数据进行流处理。我们将处理过的工件存储在用于业务报告的冷存储中，并在API中以近实时，增量更新的热索引存储。在两种情况下都可以使用相同的数据，为了使数据一致，我们使用不同的发布/子系统。
这是数据平台的传统架构。它的目标是提供冷存储和热存储之间的一致性，并允许通过其上的细粒度控制从数据目录，数据质量和全局安全性中发现数据。
如果我们看一下功能存储设计，我们将看到功能和基础架构组件几乎与数据平台中的功能和基础组件相同。在这种情况下，要素存储不是一个单独的筒仓，它带来了另一个摄取系统，存储，目录和质量门。它充当我们数据平台和ML工具之间的轻量级API。它可以很好地与您的数据基础架构中已经完成的一切集成在一起。它应该是可组合的，轻巧的，并且没有过分的设计。
在开始设计和构建数据基础结构时，请考虑以下“经验教训”：
- 首先设计一个一致的ACID Data Lake，然后再投资Feature Store。
- 现有开源产品的价值不能证明对集成及其带来的依赖性进行投资的合理性。
- 功能存储不是新的基础结构和数据存储解决方案，而是集成到现有数据基础结构中的轻量级API和SDK。
- 数据目录，数据治理和数据质量组件对于包括功能存储在内的整个数据基础架构都是水平的。
- 对于全球数据目录和数据质量监控，还没有成熟的开源或云解决方案。
参考架构
该图表描述了我们一直为客户使用的参考体系结构。它具有我们选择使用的服务，但您不应受到我们选择的限制。这里的想法是，您必须 根据数据工作负载和业务需求选择冷 存储和热存储。
对于热存储，您可以选择DynamoDB，Cassandra，Hbase或传统的RDBMS，例如Mysql，PostgreSQL甚至Redis。重要的是，热存储应可组合，可插入并与数据基础结构策略保持一致
对于冷藏，Apache Hudi和Delta湖是我们的最爱。它们提供诸如“时间旅行”，“增量摄取”和“物化视图”之类的功能。
图上有一些空白，我们希望尽快填充。例如，到目前为止，数据目录还没有现成的领导者。数据质量工具也处于早期阶段。目前，您可以从“ Great Expectations”或“ Apache Deequ”中选择，这是很棒的工具，但是它们并不能提供完整的解决方案。
详细点击标题见原文