如何为ML构建您自己的要素存储

截至2020年5月，Logical Clock是唯一一家机器学习(ML)功能商店的供应商，也是唯一一家完全开源和云原生ML功能商店的制造商。因此，我们与正在决定是建立自己的功能商店还是购买功能商店的公司和组织进行了多次交谈。鉴于人们对建立功能商店的兴趣与日俱增，我们认为我们应该分享建立一个功能商店的经验，并激励我们做出(和没有做出)一些决定和选择，以帮助其他正在考虑追随我们的人走上同样的道路。

在这里，我们首先列出了想要一个ML特性存储的一些原因。

功能存储可以消除对功能的两种不同实现的需要：一种是在训练模型时，另一种是在为模型提供服务时。使用特征存储，您可以拥有计算特征并将其存储到离线和在线存储中的单个特征管道，以便分别在训练模型和服务模型中使用。离线要素存储需要支持大量数据用于模型训练，并供批处理(分析)应用程序用于模型评分。在线商店需要支持对生产中提供的型号的功能进行低延迟访问。

功能应该在不同的模型之间重用。在Twitter中，他们有一个“分享采用率”的指标来评估内部功能商店的成功。“共享采用”衡量在其他团队创建的生产模型功能中重用的团队数量。

运营模型通常需要低延迟访问可能计算复杂或根据历史数据生成的功能。这些类型的特征通常很难或不可能在应用程序本身内进行计算，这要么是因为缺乏可用的数据，要么是因为计算这些特征所需的时间过长。功能存储可以通过充当操作模型(由在线应用程序使用)的预计算功能的低延迟存储来解决此问题。

数据科学家可以发现可用的预计算特征、这些特征的类型(数值的、分类的)、它们的描述性统计数据以及特征值的分布。他们还可以查看特征值的小样本，以帮助快速识别在模型中使用给定特征时的任何潜在问题。

您希望使用时态逻辑来增强功能存储查询。也就是说，您希望在以下位置了解给定功能的值：

时间段：固定的时间段(例如，2012-2018年的培训数据，2019年的测试数据)。

在关系数据库中，用户定义的表通常支持时态查询，该表保留数据更改的完整历史记录，并允许进行简单的时间点分析，如SQL Server。在可伸缩的SQL系统中，支持时间查询的列式存储格式的示例有Apache Hudi和Delta Lake，以及Apache Flink中的流支持。这些系统需要增加存储空间(以存储更新和当前值)，以便能够在时间点、时间间隔或时间段查询要素的值。

功能存储是组织功能的中央存储库，使其能够进行访问控制、治理并跟踪其使用情况。要素存储还提供元数据的通用标准、一致的文档和要素编码标准。存储库可以维护功能的受欢迎程度计数，以显示哪些功能被广泛使用，哪些功能可能会被删除，从而能够更好地管理功能。

特征存储应该能够为给定的时间点重新创建训练数据集，以实现模型的重现性。重建训练数据集的另一种选择是将它们存档，但对于许多行业，如医疗保健和保险，出于监管原因，它们需要是可重现的。为模型重新创建训练数据集的功能对于调试模型也很有用，即使法律不要求您保留训练数据集。

特征存储可以计算和存储训练数据集上的统计数据，并通过API调用使这些统计数据可供模型服务平台使用。在操作模型中，然后可以将训练数据统计与发送到模型用于预测的实时数据(最后一分钟、小时、一天)的时间窗口计算的统计进行比较。简单(或复杂)的统计测试可以识别数据漂移-当实时特征值与模型的训练数据明显背离时。

下面的功能存储设计流程图显示了在决定滚动您自己的功能存储时需要做出的一些决定。这组决策显然不完整，我们省略了在任何可伸缩系统中常见的系统设计问题，例如模式设计、API设计、语言支持和平台支持(内部部署、云本地)。

第一个决策点是，您是否真的想构建一个数据平台来支持您的ML工作，因为您知道这将需要相当长的时间(至少6-12个月后才能投入生产)，以及维护和更新您的平台的未来成本。如果您认为创建一个功能商店太多，那么给我们一个呼喊-提到Jim给您发送的内容，并要求博客阅读器折扣：)。

如果您仍然决心构建一个，那么您需要做出您的第一个重大决定：您的特性存储是库还是存储(特性的实体化缓存)？如果您想要解决的唯一问题是培训和服务之间的特性一致，那么图书馆的方法可能是合适的。在库方法中，您可以在培训和服务管道中都包含的版本化库中编写功能编码函数。这样做的一个缺点是，培训和服务管道都需要使用相同(或兼容)的编程语言实现。另一个缺点是您可能需要等待很长时间才能回填培训数据，因为您需要运行作业来计算特性。Netflix的早期事实/功能存储引入了共享的、版本化的功能编码器，以确保一致的功能工程。

您的下一个决策是是否要跨不同模型重用功能。重用要素意味着您将需要将标准化要素连接在一起以创建训练数据集，并且在提供要素时也是如此。如果您决定不想重用功能，您仍然可以解决服务功能的一致功能工程和系统支持问题。有些功能商店，比如基于Cassandra的CondéNest，只有一个用于存储培训和服务功能的数据存储。

如果您只使用分析模型而不是在线(操作)模型，则下一个决策至关重要，您可能会决定只需要一个(可伸缩的)数据库来存储您的特性。假设您是一个典型用户，需要培训模型和服务模型的特征存储，那么您需要决定是否需要支持时间旅行查询。许多具有窗口功能的在线模型(用户在过去15分钟内做了多少次“X”)通常需要时间旅行支持，以确保功能服务和创建训练数据的功能一致。假设您决定添加时间旅行支持，您现在需要在具有时间查询的系统上构建，或者添加对时间查询的应用程序支持。

您的下一个决策还取决于您为离线(可伸缩SQL)和在线(低延迟功能服务)存储选择的数据存储。在Hopsworks中，独一无二的是，我们为文件系统提供了统一的元数据层HopsFS、功能服务层MySQL Cluster和可伸缩的SQL层Apache Have(-on-Hops)。我们可以很容易地将扩展的元数据添加到统一的元数据层，以描述功能、它们的统计数据，并对它们进行标记。统一元数据层的CDC(更改数据捕获)API使我们还能够在Elasticsearch中索引功能描述，它支持自由文本搜索，并且搜索不会影响统一元数据服务的性能。如果您的双数据库没有统一的元数据，那么坏消息是您需要设计和开发协议协议，以确保3个不同的系统保持同步，从而为您的功能提供一致的视图：您的离线、在线和功能元数据平台。这是一项艰巨的分布式系统工程挑战-祝您好运！

最后，您需要决定一个计算引擎(可能在您的平台内部或外部)，既用于连接特征以创建训练数据集，又用于计算您的特征。您可以选择特定于领域的语言(如Michelangelo或Zipline)或更通用的语言或框架，如Python(Feast)或Spark(Hopsworks)。

除了所有这些问题，您还需要决定是否需要UI来发现和管理功能(Hopsworks、Michelangelo、Twitter、Zipline)或不需要(Feast)。您还需要决定是否需要支持多个功能存储(如开发、生产和敏感功能存储)，以及对这些不同功能存储的访问控制(就像在Hopsworks中一样)。

哟！最后，您已经了解了根据您的需要定制您的功能商店平台所需做出的一些决策。虽然我们没有讨论到您的功能商店的API设计问题，但我们可以确信，大多数功能商店平台都经历了不止一代的API(我们也不能幸免于此)。所以，祝你好运，如果你决定购买而不是建造，请给我们打电话。‍