译文:PaletteMeta商店之旅

以云看科技 2024-09-14 02:41:27

介绍

Uber 的机器学习 (ML) 团队正在不断开发新的创新组件来增强我们的 ML 平台 (Michelangelo)。

在机器学习中,特征是用于进行模型计算和预测结果的数据。您可以将其视为学习模型的输入或数据中与预测建模问题相关的属性。

在 Uber 的数据存储中查询特征数据时,可能很难:

找出 Uber 特有的优秀功能构建管道以生成特征实时计算特征保证训练时使用的数据与用于评分预测的数据相同监控功能

Uber Michelangelo 特征库 Palette 是一个专门为 Uber 策划的内部众包特征数据库,可轻松用于机器学习项目。它旨在解决上述所有挑战。管道是自动生成的,用于特征生成和特征分散。Palette 支持各种特征计算用例,例如批量和近实时,并包括与城市、司机和乘客相关的预计算特征,以及为 EAT、欺诈和通信团队生成的自定义特征。在我们正常的数据访问限制的约束下,Uber 用户可以使用其他 Uber 团队维护的许多精简特征,甚至可以创建自己的特征,并可以直接将这些特征纳入他们的机器学习模型中。

图 1:特征生成图显示作业计算特征。特征提取图显示将数据提取到 Hive 和 Cassandra。特征服务图显示特征如何离线/在线提供。特征元数据和数据质量图显示特征存储元数据如何在离线和在线存储之间流动。

Palette Metastore 背景

Palette 在其 Metastore 中提供功能管理基础设施,包括功能发现、创建、弃用、离线和在线服务设置。

Palette Metastore 是功能的元数据存储,Palette 的用户可以在其中创建、弃用、添加有关功能生成管道的所有权/回填/调度、离线训练和 HDFS 位置的详细信息。用户可以指定他们想要复制数据用于在线服务的 Cassandra 数据库以及 Spark 配置、连接键、功能列表以及功能元数据。用户还可以包含有关应复制哪些功能进行在线服务的信息、用于从上游依赖项生成功能的 SQL 查询以及维护更改审核。

图 2:功能组更新从调色板元数据存储库流向离线服务系统,最终传播到在线服务缓存,并被各种系统用于 ETL/培训。

进一步了解:问题与动机

2021 年发生了一起重大事故,原因是对 Palette Metadata 的架构验证不充分,推送了错误的元数据更改,导致 OnlineServing 在主要的 Tier1 用例中中断,因为它无法在启动期间加载 Palette Metadata。

模式验证逻辑曾经是客户端的,并存在于 FeatureSpec 存储库中的脚本中,该存储库是 Palette 客户进行元数据相关更改的元数据存储库。更新验证很有挑战性,因为客户元数据更新不会始终采用最新的验证,因为它们没有根据最新的代码更改进行重新定基。这导致错误的元数据被合并到主存储库中。

由于将错误的元数据更改合并到主版本中,元数据差异导致客户根据主版本进行重新定基时构建失败。

由于存在多个问题,事件解决花费了几个小时。

更新 OnlineServing 堆栈中的 Palette Metadata。由于缺乏增量更新系统,更改 Palette Metadata 存储库中的单个功能组会导致更新所有数百个功能组,从而延长回滚时间。缺乏模式验证。Feature Engine 值班人员必须投入大量时间来处理每个客户差异。大部分值班时间都花在协助 FeatureSpec repo 中的元数据更改上。在合并之前缺乏构建作业来验证实际的 Hive 表模式,导致训练时失败。客户在创建 Palette 表时出错,缺少必需的列。离线元数据更新。在 FeatureSpec repo 中完成更改后,元数据更新需要一个多小时,因为即使对其中一个功能组只做了微小的更改,整个元数据存储库也会更新。

这些问题凸显了架构验证不足所带来的挑战,导致数据丢失、帮助台负担加重、构建失败以及管道更新混乱。更新元数据的复杂过程和缺乏自动化架构验证进一步加剧了团队面临的问题。

深入探究:Meta Store特征存储对象模型

图 3:FeatureGroup 有 OnlineSpec、OfflineSpec、ComputeSpec。OnlineSpec 有 Snapshot Backing,其底层由 Cassandra 或 Hive Backing 支持。OnlineFeatureServingGroup 由在线商店和在线缓存组成。推理服务器/调色板服务引用 OnlineFeatureServingGroup 并间接引用 FeatureGroup。

以下是我们在由 protos 支持的新 Palette Metadata 系统中正式定义的新对象:

FeatureGroup:一个逻辑表,其中包含流式和批处理特征的集合,并由 Hive 表或在线商店的 Cassandra 中的每日特征快照支持。

特征 (Feature ) :与逻辑特征组 (FeatureGroup)(表)内的一列对应的单个特征。

数据集:数据集表示在数据库/存储中为给定功能组创建表所需的元数据。 例如,键空间、分区键和集群键将是为给定 C* 集群创建表所需的元数据。这些将是数据集规范的一部分。

存储:存储是数据集、在线要素服务组所引用的底层存储技术。

FeatureServingGroup:在线商店中服务的逻辑单元,可保证一定的 SLA(吞吐量、延迟)。它是支持 Feature Group 的存储(Cassandra/Redis 集群)的集合,以及 FeatureGroup 到底层数据集的路由映射。请注意(在非常大的用例的情况下,FeatureServingGroup 包含多个 Cassandra 集群是很常见的)。

推理服务器/调色板服务:推理服务器是逻辑对象,用于保存 Michelangelo 项目中给定模型的推理服务元数据。调色板服务(用户无需设置模型即可获取特征值的服务)同样将保存通过调色板服务提供服务的元数据。

元数据组织

我们打破了 Palette 元数据存储库中的元数据设置,其中设置了以下文件以简化客户交互和 Michelangelo 值班与元数据的交互,其中客户管理离线相关元数据文件,Michelangelo 值班管理在线服务相关元数据文件。

Description.json:此文件包含与离线服务相关的所有元数据,以及由上面定义的 OfflineSpec 支持的所有权和警报设置

Features.json:此文件将涵盖与功能相关的元数据,其架构由 Feature CRD 支持

OnlineServing.json:此文件包含与在线服务相关的所有元数据

HQL:此文件包含用于生成特征的 Hive 查询

元数据注册

图 4:Palette Metadata 存储库更新经过服务器端验证,在离线服务系统中注册,并推送到 OnlineServing Cache 和 OnlineServing 堆栈。

为了加快离线和在线元数据更新,我们将处理客户所做的调色板元数据更新的系统移至增量计算更新的增量,并在 OfflineServing 系统中注册这些更新。

一旦更新到达 UAPI,我们将使用基于 Kubernetes 的控制器将这些更新处理到我们高可用性缓存在线服务缓存(称为 ObjectConfig)中。

现在,对离线和在线系统的 E2E 更新仅需 15 分钟,而以前则需要一个多小时,因为只推送增量更新而不是整个元数据存储库。

在线服务重构

图 5:新旧 Schema 的更新从元数据服务传播到只读缓存,并通过 Wrapper 引用的 Loader 加载到 OnlineServing。

元数据统一

在旧架构中,在线服务的元数据分散在各个服务中。我们决定将所有在线服务的元数据整合到一个地方,即 Palette 元数据存储库。

界面重新设计

我们进行了界面更改,以弃用不再满足 Palette 在线系统不断变化的需求的旧模式。

元数据包装器

我们在迁移过程中引入了一个包装器,主要有两个目的:接口适配和快速回滚。在迁移过程中,我们为 Palette Online Serving 提供了两个版本的元数据。这使我们能够比较内存中的元数据。由于元加载器会将元数据转换为更适合服务需求的格式,因此内存中的元数据与我们在元数据服务中看到的元数据不同。比较内存中的元数据让我们对安全迁移更有信心。但由于接口重新设计,我们需要服务逻辑来支持这两个接口。因此,包装器是将旧元数据转换为新接口格式的工具。我们还引入了一个终止开关来告诉包装器应该向服务逻辑提供哪个版本的元数据。然后,当迁移期间发生任何元数据问题时,我们可以快速回滚。

迁移挑战在迁移期间保持流畅的用户体验:我们维护了脚本以自动同步新旧系统之间的功能元数据。这可以避免切换到新系统时出现数据缺口。提供了良好且清晰的文档来帮助用户了解如何将功能加入到新的元数据存储中。跟踪迁移的正确性:在特征生成管道系统和离线服务系统之间创建了比较指标和日志,以清楚地阐明新旧系统之间的差异。它们作为迁移正确性的证据证明。检查了流量指标,以确保完全迁移后没有流量通过旧系统。确保向后兼容性:更新后的元数据对数据格式和 API 进行了重大更改。为了保持向后兼容性,必须创建一个强大的通用 API 包装器。此包装器可以无缝弥合旧代码和新代码库之间的差距。随后,我们可以逐步过渡通用 API 包装器的底层实现,从而促进无缝迁移过程。测试:代码修改融入了 Michelangelo 团队的离线训练、再训练、评估和预测工作流程。为了保证这些集成在迁移后继续发挥作用,必须对所有现有系统进行全面的集成测试。回滚计划:为了防止迁移过程中遇到意外问题或未达到预期结果,我们还制定了全面的回滚计划,以最大限度地减少停机时间并降低风险。结果

元数据迁移的结果是 Palette Onboarding 部署时间大幅减少了 95% 以上。此外,由于所有在线服务配置都井然有序,因此迁移 Cassandra 集群的时间减少了 90%,这意味着值班人员不再需要费力地弄清楚哪个功能组在哪个 Cassandra 中提供服务。由于重新设计了离线元数据更新系统,以便逐步处理更新,离线元数据更新的时间从几小时缩短到了几分钟。此外,我们还引入了增强的 FeatureStore CRD 服务器验证和跨 CRD 验证

结论

总体而言,正式模式的引入、元数据的合并、增强的验证以及非常精心策划的迁移,使得我们的新元数据系统易于客户和 Michelangelo 值班人员使用,从而减少了部署和客户入职时间,以及维护和运营成本。

致谢

如果没有众多团队的贡献,Uber 机器学习的这一重大进步是不可能实现的。非常感谢 Uber Michelangelo 团队中的 Feature Engine 小组,他们花了一年多时间重新设计了 Meta Store 系统。

我们还要特别感谢米开朗基罗团队的合作伙伴将这个想法变成现实,以及帮助发起这个想法的前同事。

标题图片归属:“旅程从这里开始”图片受CC BY 2.0 许可保护,版权归Johnragai-Moment Catcher所有。图片未做任何修改。

作者:

Paarth Chothani

Paarth Chothani is a Staff Software Engineer at Uber AI’s Feature Store in the San Francisco Bay area. He specializes in building distributed systems at scale. Previously worked on building large scale systems on Amazon.com, AWS Chatbot, Microsoft Teams.

Nicholas Marcott

Nicholas Brett Marcott is a Staff Software Engineer, TLM on Uber AI’s Feature Store team in the San Francisco Bay area. He specializes in serving data for ML models at high scale. Previously worked on performance of Siri at Apple.

Dehua Lai

Dehua Lai is a Senior Software Engineer on Uber AI's Feature Store team based in Seattle. His primary focus is on building ML Platforms on large-scale distributed systems.

Xiyuan Feng

Xiyuan Feng is a Software Engineer at Uber AI’s Feature Store in the San Francisco Bay area. He majorly contributes to building ML Platforms on large-scale distributed systems including but not limited to ETL pipelines, feature registry etc.

Chunhao Zhang

Chunhao Zhang is a Senior Software Engineer at Uber AI’s Feature Store tead based in Sunnyvale. He specializes in building large scale distributed systems. Previous work on Google search indexing and display ads serving.

Victoria Wu

Victoria Wu is a Senior Software Engineer on the Uber AI’s Feature Store team based in the San Francisco Bay Area. She specializes in building large-scale distributed systems. Previously worked on building Kafka infrastructure at PayPal.

出处:https://www.uber.com/en-JP/blog/palette-meta-store-journey/

0 阅读:0

以云看科技

简介:感谢大家的关注