
Meta推出F3 Lightning,让广告ML特征独立发布上线
来源标题:F3 Lightning: How Meta Accelerates Ads ML Features to Production at Scale
Meta 推出 F3 Lightning 基础设施层,将广告排序模型的特征发布与共享执行解耦,使每个特征可独立编译、验证、部署和回滚。此前 F3 把全部特征合并为单一图,任一特征定义出错都会阻塞整个发布流程。通过四项优化,F3 Lightning 在保留原有效率提升的同时,让同类特征约 3 倍更快到达生产环境。
以下正文由 AI 翻译自 Meta Engineering(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
- Facebook Feature Framework(F3)是 Meta 用于编写、编译和 serving 广告 ranking 模型所依赖的机器学习特征的框架,其中单次请求可能需要超过 20,000 个特征。我们最初在 AI @ Scale 2020 上介绍了 F3。
- F3 通过将所有特征编译成一个单一的合并图,降低了执行计算成本,但该图同时也是发布单元,因此单个失败或无效定义会阻塞整个发布流水线。
- 本文介绍 F3 Lightning,这是构建在 F3 之上的基础设施层,通过将特征发布与共享执行解耦来解决这一挑战,使每个特征都能独立编译、验证、部署和回滚。
- 最难解决的部分是保留 F3 的效率提升。早期按特征发布的原型增加了 CPU 使用率,因为独立特征不再共享计算。我们旨在通过四项优化来弥补这一差距:稳定的计算标识符、单一共享执行计划、所有特征共享一个内存缓冲区,以及用于直接数组访问的密集索引映射。
- 借助 F3 Lightning,同类提取特征现在进入生产环境的速度比之前的 F3 快约 3.6 倍,且基础设施计算成本没有增加。更短的发布周期也使得在同一时期内可以进行更多模型迭代。
F3 共享执行架构入门
生产机器学习系统很少直接消费原始数据。在模型能够做出预测之前,其特征 serving 系统可能需要读取存储的信号、将事件过滤到某个时间窗口、对值进行计数或求和、对其进行归一化,并组合中间结果。 完成这项工作的最简单设计是将每个特征视为一个独立函数。这很容易理解,但在规模化时会变得浪费,因为特征在计算上并不独立。七日点击数和七日曝光数可能读取相同的事件源并应用相同的时间窗口过滤器。点击率特征随后可能复用这两个结果。单独运行每个特征会在每次请求时重复该过滤器以及所有其他共享步骤。 F3 采用了不同的方法,将特征提取表示为有向无环图(DAG)。每个节点执行一个工作单元,例如读取输入、应用过滤器或计算聚合。一条边表示一个计算依赖于另一个计算的结果。图的输出是模型消费的特征值。 工程师使用高层语言独立编写每个特征。F3 编译器将每个定义转换为一个小图,然后将服务使用的每个特征对应的图合并为一个合并图(图 1)。当特征共享某个操作时,例如上面的七日过滤器,编译器会将重复项折叠为单个节点。这样,共享工作每次请求只运行一次,而不是为每个需要它的特征运行一次。在运行时,特征提取就是对该合并图的遍历。 图 1:F3 将所有特征整合到一个合并图中。
共享图让每次发布都变成全有或全无
F3 的合并图高效地共享了计算,但它也带来一个主要问题:该图同时也是发布单元,一个格式错误的定义可能会拖住合并图中的所有其他特征。 图 2 说明了这一挑战。它展示了七个独立编写的特征 A 到 G,其中五个定义有效,但 D 和 G 包含不相关的错误。“Attempt 1”构建在 D 上失败,因此七个特征一个都不会发布。D 修正后,“Attempt 2”构建到达 G 并再次失败。只有在“Attempt 3”中两个定义都修复后,完整的合并图才成功进入生产环境。 图 2:一个失败的特征阻塞整个发布。 随着 F3 规模扩大,失败变得更加频繁。F3 最初只服务几百个特征,在那个规模下合并能够成功,发布基本顺利。如今这个数字已超过 20,000,而且不同特征类型需要根据其计算方式进行各自的检查,因此新特征和修改过的特征要满足不同的测试标准。模型已经消费的特征在发布前需要经过与模型相关的测试。这些测试的计算成本足够高,因此只在较晚的发布阶段运行,而且由于合并图作为一个单元发布,其中的所有其他特征也要等待它们。
F3 Lightning:让每个特征独立发布并共享计算
F3 发布后,我们对合并图进行了多轮改进。每一轮都暂时恢复了发布速度,但随着更多特征落地,收益逐渐被侵蚀,因为所有特征仍然在合并图中一起发布。因此,我们构建了 F3 Lightning,使每个特征都能独立发布,同时保留 F3 的效率。 如图 3 所示,F3 Lightning 引入了两项变更来实现这一点:
- 部署粒度:每个特征都是一个可独立发布的配置。它的验证、发布和回滚不会影响任何其他特征。
- 效率对等:F3 的效率来自合并图,因此让每个特征独立发布就移除了效率的来源。在保持按特征发布的同时匹配这种效率,需要在 F3 Lightning 的执行方式上进行多项关键优化。 图 3:F3 Lightning 将发布边界与执行边界分离。
部署粒度:F3 Lightning 如何隔离特征发布
隔离从编译器开始,每个特征被单独编译为单个配置。该特征配置携带提取该特征所需的一切——它需要的每个节点,按顺序排列,不从邻近特征借用任何内容。如果特征 C 有问题,特征 A 仍然会发布,因为这两个配置彼此没有关系。 图 4:坏特征不再阻塞好特征。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。