视频

了解更多
欺诈预防欺诈预防和推荐等实时人工智能/机器学习 (AI/ML) 用例正在兴起,而特征商店在成功将其部署到生产环境中发挥着关键作用。根据流行的开源特征商店 Feast 的说法,用户在其社区 Slack 中最常问的问题之一是:Feast 的可扩展性/性能如何? 这是因为实时 AI/ML 特征商店最重要的特性是特征从在线商店提供给 ML 模型以进行在线预测或评分的速度。成功的特征商店能够持续(想想 p99)在大规模(每秒数百万次查询,数据集大小从 GB 到 TB)满足严格的延迟要求(以毫秒计),同时保持较低的总拥有成本和高准确性。
正如我们将在本文中看到的,在线特征商店的选择以及特征商店的架构对于确定其性能和成本效益起着重要作用。毫不奇怪,公司在选择在线特征商店之前,通常会进行彻底的基准测试,以了解哪种架构选择或在线特征商店的性能和成本效益最高。在本文中,我们将回顾成功部署实时 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 topics)注入到在线商店。Feast 最近添加了对流式数据源(除了批处理数据源)的支持,目前仅支持 Redis。支持流式数据源对于实时 AI/ML 用例非常重要,因为这些用例依赖于新鲜的实时数据。
举例来说,在 Better.com 的潜在客户评分用例中,新的潜在客户全天持续注入。特征来自许多不同的来源,并且用于评分的实体(潜在客户)和特征都不断更新,因此潜在客户会被排名和重新排名。一旦出现新的潜在客户,就会被注入并由模型评分。在将其注入在线商店的同时,我们可能希望很快对其进行重新排名。Better.com 的潜在客户在 48 小时后过期,这在 Redis 在线商店中通过简单地设置生存时间 (TTL) 为 48 小时来实现,以便在 48 小时后使实体(潜在客户)和关联的特征向量过期。因此,特征商店会自动清理自身,不会有陈旧的实体或特征占用宝贵的在线存储空间。
Feast 的另一个有趣的实现是 Microsoft Azure 特征商店。您可以在这里查看其架构。它运行在 Azure 云上,针对低延迟实时 AI/ML 用例进行了优化,支持批处理和流式源,并集成了 Azure Data & AI 生态系统。特征从批处理源(Azure Synapse Serverless SQL、Azure Storage / ADLS)和流式源(Azure Event Hub)注入到在线商店。如果您已经部署在 Azure 或熟悉 Azure 生态系统,那么此特征商店可能适合您。对于在线商店,它使用 Azure Cache for Redis,而 Azure Redis 企业级层包含 Active-Active Geo-Duplication 功能,可以创建具有高达 99.999% 可用性的全球分布式缓存。此外,通过使用企业闪存层在分层内存架构上运行 Redis(该架构同时使用内存(DRAM)和闪存(NVMe 或 SSD)来存储数据),可以进一步降低成本。
下面是另一种实现实时 AI/ML 用例的架构。这是流行的网站构建平台 Wix 的特征商店架构。它用于实时用例,例如推荐、流失和高级用户预测、排名和垃圾邮件分类器。Wix 拥有超过 2 亿注册用户,其中只有一小部分在任何给定时间是“活跃用户”。这对特征商店的实现方式产生了重大影响。我们来看看。
以下信息基于 Ran Romano 在领导 Wix ML Engineering 时所作的 TechTalk 演示文稿。Wix 特征商店中存储的数据超过 90% 是点击流数据,ML 模型按网站或用户触发。Ran 解释说,对于实时用例,延迟是一个大问题。此外,对于他们的一些生产用例,他们需要在几毫秒内提取特征向量。
原始数据存储在 AWS S3 存储桶中的 Parquet 文件中,并按业务单元(例如“editors”、“restaurants”、“bookings”等)和日期分区。它是 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 用户典型的高吞吐量用例,与 DynamoDB 相比,Redis Enterprise 快了 3 倍,同时成本降低了 14 倍。
您可能会问,这有什么问题吗?如果您只有一个用例,并且它没有高或稳定的吞吐量,并且没有任何严格的延迟要求,那么您可以选择 DynamoDB。您可以在此处找到详细信息和 Tecton 基准测试结果。
下面是另一个特征商店架构示例。这个由 Lightricks 使用,基于商业特征商店 Qwak。Lightricks 是一家独角兽公司,开发视频和图像编辑移动应用,尤以其自拍编辑应用 Facetune 而闻名。它将其特征商店用于推荐系统。
如上图所示,与 Tecton 一样,Qwak 特征商店支持三种类型的特征源——批处理、流式处理和实时特征。
值得注意的是,使用 Qwak 特征商店,特征到特征商店的物化是直接从原始数据源进行的,同时针对离线商店(使用 S3 上的 Parquet 文件)和在线商店(使用 Redis)。这与 Wix、Feast 或 Tecton 的特征商店示例不同,后者的在线商店物化是针对批处理源从离线商店到在线商店进行的。这样做的好处是,特征的转换逻辑在训练和提供流程中是统一的(与上面的 Feast、Wix 和 Tecton 特征商店一样),而且实际的转换或特征计算也是统一进行的,进一步减少了训练服务偏差。直接从原始数据实现离线和在线的统一数据管道有可能确保生产环境中更高的准确性。您可以在此演示文稿中找到有关 Qwak 特征商店架构和组件的更多信息。
在本文中,我们回顾了几种用于实时 AI/ML 特征商店的基准测试和架构的关键亮点。第一个是开源 Feast,第二个是自建的 Wix 特征商店,第三个来自 Tecton,第四个来自 Qwak。我们还回顾了这些公司进行的一些基准测试的关键亮点,以了解哪种在线商店的性能和成本效益最高。我们还探讨了从在线商店提取特征应使用哪种机制或特征服务器。我们看到,特征商店的性能和成本存在显著差异,具体取决于架构、支持的特征类型和所选组件。
最初发表于 KDnuggets。