译者 | 陈峻
公司在选择他们的在线特征存储之前,通常会执行全面的基准测试,以比较哪一种架构是最高效且具有成本效益的。本文将和您讨论四种成功部署了实时 AI/ML 用例的开源与商业化的特征存储架构和基准。
如今,随着欺诈预防和个性化推荐等实际商业用例的广泛使用,特征存储(Feature Stores)在将AI/ML技术实时、成功地部署到生产环境的过程中,发挥着关键性的作用。
目前最流行的开源特征存储平台之一当属Feast。用户在其Slack社区(https://slack.feast.dev/)中提及最多的便是Feast的可扩展性与性能。毕竟,对于实时的AI/ML特征存储而言,最重要的指标便是被用于在线预测或评分的ML模型的特征服务速度。
通常,成功的特征存储应当满足如下严格的要求:
- 低延迟(以毫秒为单位)
- 一致性(以99%的情况结果来衡量)
- 成规模(每秒高达十万、甚至百万的查询量,以及千兆、甚至TB字节的数据集)
- 较低的总体拥有成本和高精确度
公司在选择他们的在线特征存储之前,通常会执行全面的基准测试,以比较哪一种架构是最高效且具有成本效益的。下面,我们将和您一起讨论四种成功部署了实时AI/ML用例的开源与商业化的特征存储架构和基准。
1.开源的Feast
我们先来看看Feast(https://feast.dev/)开源特征存储的基准数据、及其数据架构。在其最近的一个基准测试中,Feast比较了使用不同的在线存储(即Redis、Google Cloud DataStore和AWS DynamoDB)时特征服务的延迟,并比较了使用不同机制的提取特征(如Java gRPC服务器、Python HTTP服务器、以及lambda函数等)时的速度。您可以从链接—https://feast.dev/blog/feast-benchmarks/,了解完整的基准测试设置及其结果。其中,Feast发现在使用Java gRPC服务器与Redis组合作为在线存储时,性能最高。
来源:https://www.applyconf.com/agenda/using-feast-in-a-ranking-syst
在上图中,您可以看到知名的在线抵押贷款公司Better.com是如何使用开源的Feast特征存储,来构建对其潜在客户的评分排名系统。Better.com的高级软件工程师Vitaly Sergey介绍了从离线存储(S3、Snowflake和Redshift)到在线存储(Redis)的过程。同时,他们也将特征从流媒体源(Kafka的各个主题)摄取到了在线存储。Feast最近也添加了对于流式数据源(除了批处理数据源)的支持,不过目前仅支持Redis。
由于此类用例需要依赖实时数据,因此支持流式数据源对于实时的AI/ML用例是非常重要的。例如,在该评分用例中,新的潜在客户数据被实时地摄取到。只要有一个新的潜在客户被发现,它就会被模型摄取并予以评分,同时它会被摄取到在线存储中,以便我们在后续对其进行重新排名。同时,Better.com会让潜在客户在48小时后过期。这是在Redis在线存储中实现的。他们只需将TTL(生存时间,time to live)设置为48小时,那么实体(即潜在客户)与关联特征向量就会在48小时后过期。也就是说,特征存储会自动自行清理,以保证没有旧的实体或特征占用宝贵的在线存储空间。
Feast的另一个实现是Microsoft Azure的特征存储(https://techcommunity.microsoft.com/t5/ai-customer-engineering-team/bringing-feature-store-to-azure-from-microsoft-azure-redis-and/ba-p/2918917)。你可以通过链接--https://techcommunity.microsoft.com/t5/image/serverpage/image-id/323561i3F763F78F483587D/image-size/large?v=v2&px=999,来参考它的架构。它运行在针对低延迟实时AI/ML用例进行过优化的Azure云上,能够支持批处理和流式数据源,并集成到Azure数据和AI生态系统中。各种特征从批处理源(Azure Synapse Serverless SQL、Azure Storage/ADLS)和流式源(Azure Event Hub)被摄取到在线存储处。在线存储使用的是带有Enterprise Tiers of Azure Redis的Azure Cache,包括了通过主动异地复制,来创建具有高达99.999%可用性的全局分布式缓存。因此,如果您的应用已经部署在Azure上,或熟悉Azure生态系统,那么此类特征存储就比较适合。此外,通过使用Enterprise Flash层在分层内存架构上运行Redis,并使用内存(DRAM)和闪存(NVMe或SSD)来存储数据,还可以进一步降低成本。
2.Wix将DIY特征存储作为MLOps平台的基石
流行的网站建设平台Wix(https://www.wix.com/)将特征存储架构用于诸如推荐、生产、溢价、预测、排名、以及垃圾邮件分类器等MLOps平台应用中。虽然Wix能够为超过2亿的注册用户提供服务,但是在任何给定的时间内,通常只有少部分的活跃用户。因此,这对特征存储的实现方式提出了一定的影响。下图源自Wix的ML Engineering领导Ran Romano在TechTalk上的演示文稿(https://youtu.be/E8839ENL-WY?t=2061)。Wix的特征存储中存储着超过90%的点击流,ML模型可以按照网站或用户被触发。Ran解释说,对于生产环境中的实时用例而言,他们需要在几毫秒内提取特征向量,因此需要避免延迟。
来源:https://youtu.be/E8839ENL-WY?t=2061
如上图所示,原始数据被存储在AWS Parquet文件的S3存储桶中,并按业务单元(如“编辑”、“餐厅”、“预订”等)以及日期进行分区。在使用Spark SQL的日常构建批处理过程(需要几分钟到几小时)中,所有用户的历史记录特征都会从S3中提取,按用户进行转换和聚合,然后被提取到离线存储(Apache Hbase)中。这种“按用户”的方式,能够加快针对用户的历史查找。一旦系统检测到用户当前处于活动状态,“预热(Warmup)”流程就被触发,该用户的特征则会被加载到比离线存储小得多的、只用来保存活动用户历史记录的在线存储(Redis)中。该“预热”过程通常需要几秒钟。最后,在线特征存储中的特征,会使用来自用户的每个事件(使用Apache Storm)作为“实时”流数据,进行持续更新。
与Feast架构相比,Wix架构的读写速率较低。但是由于它只为在线存储中的活跃用户提供存储特征,而非所有用户,因此在具体化(materialization)和在线存储方面非常高效。而且,活跃用户在Wix中仅占所有注册用户的一小部分,因此也节省了不少空间。
不过,虽然我们从在线存储中检索特征只需几毫秒,但前提是在线存储中已经存在了这些特征。相反,由于预热过程需要几秒钟,那么对于某些变得活跃的用户而言,可能会由于加载相关特征的速度不够快,根据竞态条件(race conditions),用户会因评分过低而导致失败。可见,只要用例不是关键性的流程或任务(如:批准交易或防范欺诈),就可以使用此类架构。
3.商业化特征存储--Tecton
除了批量数据源和流式数据源,商业化的企业特征存储Tecton(https://www.tecton.ai/)架构还支持“开箱即用”的实时数据源(也称为“实时特性”或“实时转变”)。由于Tecton已经能够被特征存储原生支持,因此它更易于实现。
与Feast和Wix的特征存储一样,Tecton也在注册表中定义了各种特征,以便为离线和在线存储进行一次性的逻辑定义,以显著减少训练服务的偏差,进而确保ML模型在生产环境中的高精度。
来源:https://www.tecton.ai/blog/delivering-fast-ml-features-with-tecton-and-redis-enterprise-cloud/
下面我们来看看Tecton在离线存储、在线存储和基准测试等方面的特点:就离线特征存储而言,Tecton支持S3。就在线存储而言,Tecton为客户提供DynamoDB和Redis Enterprise Cloud之间的选择(https://www.tecton.ai/blog/delivering-fast-ml-features-with-tecton-and-redis-enterprise-cloud/)。而在最近的一次演示中,Tecton首席技术官Kevin Stumpf根据公司近期执行的基准测试,给出了有关如何选择在线特征存储的建议,请参见--https://youtu.be/osxzKxiznm4。除了对延迟和吞吐量进行基准测试,Tecton也对在线存储的成本进行了基准测试。其原因在于,对于高吞吐量或低延迟的用例而言,在线存储的成本可能占整个MLOps平台总拥有成本的大部分,因此任何成本的节省都是非常有益的。
Tecton在对用户的典型高吞吐量用例进行基准测试时发现,与DynamoDB相比,Redis Enterprise的速度提高了3倍,同时成本降低了14倍。详细的测试结果请参见--https://www.tecton.ai/blog/announcing-support-for-redis/。可见,除非您只有一个用例,而且它既没有高并发量,又没有严格的延迟要求,那么就可以使用DynamoDB。
4.Lightricks使用商业化特征存储——Qwak
Lightricks是一家专为视频和图像编辑开发移动应用程序的独角兽公司,Facetune就是其著名的自拍编辑APP。它也将特征存储用到了其推荐系统上。
来源:https://www.youtube.com/watch?v=CG2vUCcvnD8&t=1915s
如上图所示,Qwak的特征库也支持开箱即用的三种特征源——批处理、流式和实时特征。这与Tecton十分类似。不过,在使用Qwak特征存储时,他们是从离线存储(使用S3上的Parquet文件)和在线存储(使用Redis)的原始数据源处,将特征具体化到了特征存储中的。这与来自Wix、Feast或Tecton的特征存储示例有所不同。此举动的好处在于,不仅单个特征的转换逻辑,在训练和服务流之间是统一的(就像上面的Feast、Wix和Tecton的特征存储一样),而且实际的转换或特征计算也是统一完成的,这样就进一步减少了训练-服务的偏差。也就是说,拥有源于原始数据的统一离线与在线,可以在生产环境中确保更高的准确性。您可以通过链接--https://drive.google.com/file/d/1KfOMI9C-aitJNPdGB56L-6tA8BBp9gsl/view,了解Qwak的更多有关特征存储架构和组件的内容。
5.小结
通过对上述四种用于实时AI/ML特征存储的基准和架构的讨论,我们可以看到,由于架构、支持的特性类型和选择的组件的不同,它们所产生的特性存储的性能和成本会存在显著的差异。同时,我们也在文中比较了哪一种在线存储的性能最高、最具成本效益,以及该使用哪一种机制或特征服务器,从在线存储中提取特征。
原文链接:https://www.kdnuggets.com/2022/03/feature-stores-realtime-ai-machine-learning.html
译者介绍
陈峻 (Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式,分享前沿技术与新知;经常以线上、线下等方式,开展信息安全类培训与授课。