深入了解 Facebook 的视频分发系统

本文将解释 Facebook 应用用于向用户分发相关内容的端到端系统。
了解 Facebook 的视频统一工作如何简化了产品体验和基础设施，深入了解移动端分发，以及我们正在视频内容分发栈中开发的新功能。

分发高度相关、个性化、及时且响应迅速的内容面临着复杂的挑战。在 Facebook 的规模下，为支持和克服这些挑战而构建的系统需要进行广泛的权衡分析、针对性优化，并构建允许工程师推动相同用户和业务成果的架构。

1、Facebook 的视频统一

如果不提及我们两年的视频统一工作，就很难谈论 Facebook 的视频分发。我们将在下面引用的许多功能和技术如果没有简化和统一 Facebook 视频产品和技术栈的努力是不可能实现的。

简单来说，我们有三个系统来支持 Facebook 的视频分发：排序（RecSys）、服务器和移动端：

1.1、排序（RecSys）

推荐满足用户兴趣（即短期、长期和实时兴趣）的内容，同时允许新内容和发现用户历史互动之外的内容。该架构支持各种优化函数和价值建模的灵活性，并建立在允许严格延迟预算、快速模型部署和偏向新鲜内容的交付系统之上。（我们将新鲜度定义为排序生成此视频候选的时间距今多久。我们通常认为更新鲜的内容更好，因为它基于更近期和相关的信号。）

1.2、服务器（WWW）

作为移动端/网页端与 RecSys 之间的中介，它是驱动 Facebook 视频所有功能集的核心业务逻辑，并通过 RecSys 将适当的内容推荐消费到移动客户端。它控制关键的分发特性，如内容分页、去重和排序信号收集。它还管理关键系统权衡，如通过缓存和限流实现的容量控制。

1.3、移动端 – Android 版 Facebook（FB4A）和 iOS 版 Facebook（FBiOS）

Facebook 的移动应用针对超越像素的用户体验进行了高度优化。移动端构建了诸如客户端排序（CSR）等框架，允许在消费点精确分发对用户最优的内容，有时无需往返服务器。

2、为什么要统一？

让我们深入了解我们的视频统一工作。以前，我们为 Watch 和 Reels 提供了各种用户体验、移动客户端层、服务器层和排序层。在过去几年中，我们一直在将应用的视频体验和基础设施整合为单一实体。

原因很简单。维护多个视频产品和服务会导致用户和开发者体验碎片化。碎片化导致开发时间变慢、用户体验复杂且不一致，以及积极的应用推荐减少。Facebook Watch 和 Facebook Reels——两个类似的产品——运作得相当独立，这意味着我们无法在它们之间共享改进，导致整体体验更差。

这种分离也给创作者带来了很多开销。以前，如果创作者想要在某个界面获得分发，他们需要创建两种类型的内容，例如用于沉浸式 Reels 界面的 Reel 和用于 Watch 标签的点播视频（VOD）。对于广告商来说，这意味着为不同的广告格式创建不同的广告。

3、移动端和服务器技术栈统一

统一的第一步是将我们的两个客户端和服务器数据模型以及两个架构统一为一个，同时不改变用户界面（UI）。这里的复杂性是巨大的，这项服务器、iOS 和 Android 的技术栈统一花了一年时间，但这是为后续步骤铺平道路的必要步骤。

有几个变量增加了复杂性，包括：

产品拥有数十亿用户。日志记录、UI 或性能方面的任何微小意外变化都会立即在核心指标中显现。
每个层在 Android、iOS 和服务器上都有数万行代码。
合并 Reels 和 Watch 同时保留两个系统的最佳功能需要大量审计和调试。（我们需要审计数百个功能和数千行代码，以确保保留所有关键体验。）
各层之间的交互也需要在底层代码变更时得到维护。日志记录在确保这一点方面发挥了关键作用。
产品工程师继续在旧的 Reels 和 Watch 系统上工作，改进用户的产品体验并改进 Facebook 应用的关键视频指标。这给新的统一系统创造了”移动目标”效应，因为我们必须匹配这些新发布的功能。我们必须快速行动并选择正确的”截止”点，以便尽早将所有视频工程师转移到新栈上工作。
- 如果我们过早转移工程师，大约 50 名产品工程师将无法达成他们的目标，同时还会导致核心基础设施的变动。
- 如果我们过晚转移，将需要在新统一基础设施上做更多工作来移植旧功能。
维护新栈核心指标的日志记录。日志记录非常敏感，在不同界面上的实现方式也不同。我们有时不得不以新的方式重新实现日志记录以服务两个产品。我们还必须确保维护数百个关键日志参数。
我们必须在做所有这些的同时保持互动和性能指标，以确保新架构达到我们的性能标准。

4、将 Watch 用户迁移到 Reels 界面

下一步是将我们所有的点播视频信息流串联体验迁移到使用沉浸式 Reels UI。由于沉浸式 Reels UI 针对观看短视频进行了优化，而点播视频信息流串联 UI 针对观看长视频进行了优化，因此需要多次产品迭代来确保统一界面能够在不妥协的情况下满足所有用户的需求。我们进行了数百次测试来识别和优化最优的视频功能集。这个项目又花了一年时间完成。

5、统一 Reels 和 Watch 的排序层

下一步于 2024 年 8 月交付，是统一我们的排序层。这必须在前面的层完成之后进行，因为排序依赖于从各界面 UI 派生的信号保持一致。例如，点赞按钮在 Reels UI 的垂直侧边栏顶部且相当突出。但在 Watch UI 上，它在底部最左侧。它们是相同的信号，但具有不同的上下文，如果排序将它们等同对待，你会看到视频推荐的降级。

除了 UI 统一之外，另一个重大挑战是构建一个能够推荐 Reels 和点播视频混合库存的排序系统，同时满足偏重短视频和偏重长视频的用户。排序团队在这方面取得了巨大进展，首先从统一 Reels 和 Watch 栈的数据、基础设施和算法基础开始。随后创建了一个包含短视频和长视频的统一内容池，实现了更大的内容流动性。然后团队优化了推荐机器学习（ML）模型，以展示最相关的内容而不受视频长度偏见的影响，确保为具有不同产品偏好的用户（例如偏重 Reels 与偏重 Watch）无缝过渡到统一的内容推荐体验。

6、统一的视频标签页

最后一步是交付新的视频标签页。此标签页使用 Reels 沉浸式 UI，在所有层上具有统一的排序和产品基础设施，提供从 Reels、长格式点播视频到直播视频的推荐。它使我们能够从 UI、性能和推荐的角度提供最佳的全方位体验。

随着视频统一接近完成，我们能够跨栈实现更深入的集成和端到端的复杂功能。

7、视频统一的前奏

在 Facebook 应用进行任何正式的视频统一之前，我们在视频组织内部做了一个较小的努力来现代化 Watch UI。当你点击视频时，Watch 标签页会打开一个新的视频信息流模态屏幕。这导致了界面中的界面，可能是一种令人困惑的体验。Watch 标签页也更接近动态消息 UI，与行业中现代沉浸式视频产品不匹配。

这个项目致力于使 Watch 标签页 UI 变得沉浸式和现代化，同时将信息流中的信息流扁平化为单一信息流。问题是我们没有跨移动端、服务器和排序层整合基础设施层。这在尝试实施现代推荐功能时导致了放缓。我们还意识到排序将在这个项目中发挥关键作用，但我们在项目生命周期后期才进行排序更改。

这些关键经验让视频组织能够采取上述正确的步骤和操作顺序。如果没有从这个项目中获得的经验，我们可能不会看到成功的视频统一结果。

在向 Facebook 用户分发内容时，我们遵循五个关键原则：

优先新鲜内容。
让排序决定内容顺序。
仅在需要时才提供内容（将其从内存移动到 UI 层），并尽可能少地提供。
确保获取行为是确定性的。
当有明确信号表明用户想要内容时，才提供内容。

7.1、视频信息流网络请求的生命周期

7.1.1、移动客户端发送请求

移动客户端通常有几种机制可以触发网络请求。每种请求类型都有自己的触发器。预取请求（在界面可见之前发出的请求）在应用启动后短时间触发。预取仅适用于我们的标签页界面。

首屏加载（初始网络请求）在用户导航到界面时触发。尾部加载请求（包括所有后续请求）在用户每次滚动时触发，但有一些注意事项。

预取和首屏加载可以同时进行中。我们将为 whichever 先返回的那个提供内容。或者如果它们都耗时太长，我们将提供缓存内容。

每次用户滚动时都会尝试尾部加载，但我们仅在内存池（准备好观看的视频故事的内存存储）中有三个或更少的来自网络的视频故事时才会发出请求。因此，如果我们有四个来自网络的故事，我们不会发出请求。如果我们有四个来自缓存的故事，我们将发出网络请求。与尾部加载请求一起，我们会向排序发送用户信号，以帮助为该请求生成良好的视频候选。

7.1.2、服务器接收请求

当客户端请求到达服务器时，它会通过几个关键层。由于它是 GraphQL 请求，第一层是 GraphQL 框架和我们对视频数据模型的 GraphQL 模式定义。接下来是视频交付栈，这是一种通用架构，能够为 Facebook 中的任何产品体验提供视频服务。这种架构在支持各种后端数据源方面具有灵活性：信息流、诸如 TAO 之类的数据库、缓存或其他后端系统。因此，无论你是查看个人资料的视频标签页、浏览使用特定配乐或话题标签的视频列表，还是访问新的视频标签页，视频交付栈都能满足所有这些需求。

对于视频标签页，下一步是信息流栈。在 Facebook，我们有很多信息流，因此我们构建了通用基础设施来构建、定义和配置各种类型的信息流：主要的动态消息、Marketplace、群组——应有尽有。视频标签页的信息流实现然后调用排序后端服务。

在这些层之间，服务器处理大量的业务逻辑。这包括响应数据中心容量紧张或灾难恢复场景而限流请求、缓存来自排序后端的结果、从各种数据存储收集模型输入数据以发送到排序，以及延迟追踪以记录系统性能，还有传递需要传递给排序的客户端输入参数。

7.1.3、排序接收请求

本质上，我们的排序栈是一个基于图的执行服务，它协调整个服务工作流，最终生成一定数量的视频故事并将其返回给 Web 服务器。

推荐服务工作流通常包括多个阶段，例如从多种类型的检索 ML 模型中进行候选检索、各种过滤、逐点排序、列表排序和启发式多样性控制。候选必须经过所有这些阶段才能存活下来并被分发。

此外，我们的排序栈还提供更高级的功能以最大化用户价值。例如，我们使用根视频来情境化顶部视频故事以实现愉悦的用户体验。我们还有一个称为弹性排序的框架，允许基于系统负载和容量可用性运行动态变体的排序查询。

7.1.4、服务器接收来自排序的响应

在最基本的层面上，排序给服务器一个视频 ID 列表和每个视频的排序元数据。然后服务器需要从我们的 TAO 数据库加载视频实体并执行隐私检查，以确保观看者可以看到这些视频。这些隐私检查的逻辑在服务器上定义，因此排序无法执行这些隐私检查，尽管排序有一些启发式方法来减少推荐观看者无法看到的视频的频率。然后视频被传递回 GraphQL 框架，该框架实例化客户端查询最初请求的字段。这两个步骤——隐私检查和实例化——合计构成了我们数据中心全球 CPU 使用量的相当大一部分，因此在这里进行优化是缓解数据中心需求和功耗的重要重点领域。

7.1.5、移动客户端接收来自服务器的响应

当客户端收到网络响应时，视频故事被添加到内存池中。我们根据服务器排序键（由排序层提供）以及用户是否已查看来对故事进行优先级排序。通过这种方式，我们将内容优先级排序推迟到排序层，与客户端相比，排序层拥有更复杂的内容推荐机制。

通过在客户端遵循服务器排序键，我们实现了将内容优先级排序推迟给排序以及优先新鲜内容的关键原则。

移动客户端的平衡在于内容新鲜度与性能/效率之间。如果我们等待网络请求完成的时间太长，用户将离开界面。如果我们每次用户进入界面时都立即提供缓存，他们看到的第一批内容可能是陈旧的，因此不相关或无趣。

如果我们获取太频繁，我们的容量成本会增加。如果我们获取不够，相关的网络内容将不可用，我们将提供陈旧内容。

当故事从内存池中添加时，我们还执行媒体预取；这确保从一个视频滑动到另一个视频是无缝的体验。

这是我们在内容分发领域代表移动客户端必须进行的持续平衡。

7.2、动态分页：视频信息流分发的新方法

在典型的分发场景中，Facebook 上的每个人都从排序到客户端接收固定大小的视频页面。然而，对于需要按需优化容量成本的大型用户群，这种方法可能有限制。用户特征差异很大，从那些在视频上从不向下滑动的人到那些在一次会话中消费许多视频的人。某人可能是我们视频体验的完全新手，也可能是每天多次访问 Facebook 应用的人。为了适应用户消费频谱的两端，我们开发了一个新的动态分页框架。

在这种方法下，排序层完全控制应该为特定用户排序并提供多大的视频页面大小。服务器的角色是为服务器和客户端设备之间的确定性页面大小契约提供护栏。总之，排序和服务器之间的契约是动态页面大小，而服务器和客户端之间的契约是固定页面大小，取尽可能小的值。这种设置有助于确保如果排序视频的数量太大，用户的设备不会最终接收所有这些视频。同时，它通过确保客户端和服务器之间有确定性的页面大小行为来简化客户端分发基础设施。

通过上述设置，排序可以提供不同程度的个性化。如果排序对用户的消费需求有把握，它可以输出更大的排序内容集。相反，如果排序不太有把握，它可以输出更小的排序内容集。通过整合这种个性化程度，我们可以为相对较新的平台用户精心策划内容，同时为常规用户提供更大的推荐批次。这种方法使我们能够节省容量并为我们极其庞大的用户群提供最佳内容。