视频
在 Google Colab 上运行 Redis
了解更多
速度的未来即将在您所在的城市举办的活动中出现。
加入我们在 Redis 发布活动
分享
实时人工智能/机器学习 (AI/ML) 用例（如欺诈预防和推荐）正在兴起，并且特征存储在成功将其部署到生产环境中起着关键作用。根据流行的开源特征存储 Feast，用户在他们的社区Slack中问得最多的问题之一是：Feast 的可扩展性和性能如何？ 这是因为实时 AI/ML 的特征存储最重要的特征是特征从在线存储到 ML 模型的提供速度，用于在线预测或评分。成功的特征存储可以满足严格的延迟要求（以毫秒为单位），始终如一（考虑 p99）并且可以扩展（每秒数百万个查询，数据集大小为千兆字节到太字节），同时保持较低的总拥有成本和较高的准确性。
正如我们将在本文中看到的那样，在线特征存储的选择以及特征存储的架构在决定其性能和成本效益方面起着重要作用。难怪公司在选择在线特征存储之前，通常会进行彻底的基准测试，以查看哪种架构或在线特征存储选择最具性能和成本效益。在本文中，我们将回顾由成功部署实时 AI/ML 用例的公司构建的自建特征存储以及开源和商业特征存储的架构和基准测试。 让我们开始吧。
让我们首先看一下开源Feast特征存储的基准测试数据和数据架构。Feast 最近进行了一项基准测试，以比较在使用不同的在线存储（Redis 与 Google Cloud DataStore 与 AWS DynamoDB）时，其特征提供延迟。它还比较了使用不同机制提取特征的速度（例如 Java gRPC 服务器、Python HTTP 服务器、lambda 函数等）。您可以在此博文中找到完整的基准测试设置及其结果。底线：Feast 发现使用 Java gRPC 服务器和 Redis 作为在线存储，其性能远远领先。
在上图中，您可以看到在线抵押贷款公司Better.com如何使用开源 Feast 特征存储实现其潜在客户评分排名系统的示例。正如 Better.com 的高级软件工程师Vitaly Sergey所述，特征从离线存储（S3、Snowflake 和 Redshift）物化到在线存储（Redis）。除此之外，特征还从流式源（Kafka 主题）摄取到在线存储中。Feast 最近添加了对流式数据源的支持（除了批处理数据源之外），目前仅支持 Redis。支持流式数据源对于实时 AI/ML 用例非常重要，因为这些用例依赖于最新的实时数据。
例如，在 Better.com 的潜在客户评分用例中，新的潜在客户在全天持续摄取。特征来自许多不同的来源，并且用于评分的实体（潜在客户）和特征一直在更新，因此，潜在客户的排名会不断更新。一旦有新的潜在客户，它就会被摄取并由模型进行评分。在将其摄取到在线存储的同时，我们可能希望在不久之后重新对其进行排名。Better.com 的潜在客户在 48 小时后过期，这在 Redis 在线存储中通过简单地将生存时间 (TTL) 设置为 48 小时来实现，以便在 48 小时后使实体（潜在客户）和关联的特征向量过期。因此，特征存储会自动清理自身，并且没有陈旧的实体或特征占用宝贵的在线存储空间。
Feast 的另一个有趣的实现是Microsoft Azure 特征存储。您可以在此处查看其架构。它在针对低延迟实时 AI/ML 用例优化的 Azure 云上运行，支持批处理和流式源，以及与 Azure 数据和 AI 生态系统集成。特征从批处理源（Azure Synapse 无服务器 SQL、Azure 存储/ADLS）和流式源（Azure 事件中心）摄取到在线存储中。如果您已经部署在 Azure 上或熟悉 Azure 生态系统， 那么此特征存储可能是适合您的。对于在线存储，它使用 Azure 缓存 for Redis，并且使用 Azure Redis 的企业层，它包括主动-主动地理位置重复，以创建具有高达 99.999% 可用性的全球分布式缓存。此外，通过使用企业闪存层在使用内存 (DRAM) 和闪存 (NVMe 或 SSD) 存储数据的分层内存架构上运行 Redis，可以进一步降低成本。
下面是实现实时 AI/ML 用例的不同架构。它是流行的网站构建平台Wix的特征存储架构。它用于实时用例，例如推荐、流失和高级预测、排名和垃圾邮件分类器。Wix 为超过 2 亿个注册用户提供服务，其中只有一小部分在任何给定时间都是“活跃用户”。这对特征存储的实现方式产生了很大影响。让我们看一下它。
以下信息基于TechTalk 演示文稿，该演示文稿由 Ran Romano 在领导 Wix 的 ML 工程时发表。存储在 Wix 特征存储中的数据超过 90% 是点击流，并且 ML 模型按网站或按用户触发。Ran 解释说，对于实时用例，延迟是一个大问题。此外，对于他们的一些生产用例，他们需要在毫秒内提取特征向量。
原始数据存储在 AWS 的 S3 存储桶中的 Parquet 文件中，并按业务部门（例如“编辑”、“餐厅”、“预订”等）进行分区，然后按日期进行分区。它是 Wix 数据平台的一部分，该平台由其数据分析师使用，该平台比 Wix ML 平台早几年。在日常构建批处理过程中，使用 Spark、SQL（需要几分钟到几小时），所有用户的历史特征都从 S3 中提取出来，并按用户进行透视和聚合，然后摄取到离线存储（Apache Hbase）中。这为按“用户”更快速地查找其用户的历史记录提供了可能。一旦系统检测到用户当前处于活动状态，就会触发“预热”进程，并将该用户的特征加载到在线存储（Redis）中，该存储比离线存储小得多，因为它只保存活跃用户的用户历史记录。此“预热”进程可能需要几秒钟。最后，在线特征存储中的特征使用来自流式源的最新实时数据持续更新，每当来自用户的事件出现时（使用 Apache Storm）。
这种类型的架构与 Feast 架构相比，写入与读取的比率较低， 在物化和在线存储方面非常有效，因为它只存储在线存储中活跃用户的特征，而不是所有用户的特征。由于活跃用户仅占 Wix 所有注册用户的一小部分，因此这节省了大量的存储空间。然而，这样做也有一些代价。虽然从在线存储中检索特征非常快，在毫秒内就可以完成，但这仅适用于在线存储中已经存在的特征。由于竞争条件，由于预热进程需要几秒钟，因此它无法足够快地加载相关特征，因为用户正在变为活跃状态。因此，对该用户的评分或预测将简单地失败。只要用例不属于关键流程或关键任务用例（例如批准交易或防止欺诈），这都是可以接受的。这种类型的架构也非常特定于 Wix，其中只有一小部分用户在任何给定时间都是活跃用户。
现在让我们看看商业企业特征存储Tecton的架构。正如我们在下图中看到的，除了批处理数据源和流式数据源之外，Tecton 还支持“开箱即用”的实时数据源。这些也被称为“实时特征”或“实时”转换。实时特征只能在推理请求时计算。例如，怀疑交易的规模与上次交易规模之间的差异。因此，在上面使用开源 Feast 的 Better.com 案例中，Better.com 自己开发了对实时特征的支持。使用 Tecton 特征存储，这更容易实现，因为它已经被特征存储本身原生支持。与 Feast 和 Wix 特征存储一样，Tecton 也在注册表中定义特征，以便逻辑定义在离线存储和在线存储中只定义一次。这大大减少了训练-服务偏差，以确保 ML 模型在生产中的高准确性。
在离线特征存储方面，Tecton 支持 S3；在线存储方面，Tecton 目前为其客户提供了 DynamoDB 和 Redis Enterprise Cloud 之间的选择。在最近的一次演示中，Tecton CTO Kevin Stumpf 提供了如何选择在线特征存储的建议，这些建议基于公司最近进行的基准测试。除了基准测试延迟和吞吐量之外，Tecton 还对在线存储的成本进行了基准测试。为什么这很重要？对于高吞吐量或低延迟的用例，在线存储的成本可能是整个 MLOps 平台总拥有成本的重要组成部分，因此任何成本节约都可能非常可观。
Tecton 基准测试的底线是，对于 Tecton 用户典型的用例（高吞吐量），Redis Enterprise 的速度是 DynamoDB 的 3 倍，同时成本只有 DynamoDB 的 1/14。
那么，你可能会问，有什么问题吗？如果你只有一个用例，并且它没有高或一致的吞吐量，也没有任何严格的延迟要求，那么你可以选择 DynamoDB。你可以在此处找到完整的详细信息和 Tecton 基准测试的结果。
以下是另一个特征存储架构示例。该架构由 Lightricks 使用，它基于商业特征存储 Qwak。Lightricks 是一家独角兽公司，开发视频和图像编辑移动应用程序，特别是以其自拍编辑应用程序 Facetune 而闻名。它使用特征存储来构建其推荐系统。
如上图所示，与 Tecton 一样，Qwak 特征存储支持三种类型的特征源：批处理、流式和实时特征。
需要注意的是，使用 Qwak 特征存储，特征的物化直接从原始数据源进行，无论对于离线存储（使用 S3 上的 Parquet 文件）还是在线存储（使用 Redis）都是如此。这与 Wix、Feast 或 Tecton 的特征存储示例不同，在这些示例中，在线存储的物化是从离线存储到在线存储进行的，用于批处理源。这具有以下优势：不仅特征的转换逻辑在训练和服务流程中统一（如 Feast、Wix 和 Tecton 的特征存储），而且实际的转换或特征计算也是统一的，进一步减少了训练-服务偏差。拥有一个从原始数据直接进行离线和在线统一的数据管道，有可能确保生产过程中更高的准确性。你可以在此演示文稿中找到有关 Qwak 的 特征存储架构和组件的更多信息。
在本文中，我们回顾了几个用于实时 AI/ML 的特征存储的基准测试和架构的关键要点。第一个是开源 Feast，第二个是 DIY Wix 特征存储，第三个来自 Tecton，第四个来自 Qwak。我们还回顾了这些公司进行的一些基准测试的亮点，以查看哪种在线存储性能最佳，成本效益最高。我们还探讨了使用哪种机制或特征服务器从在线存储中提取特征。我们看到，特征存储的性能和成本存在很大差异，具体取决于架构、支持的特征类型以及选择的组件。
最初发布在 KDnuggets.
