22. ByteDance 亿级视频处理系统高可用架构实践
info
01 视频处理系统整体介绍
视频整体的生命周期大致可以分为四个阶段:
- 端侧生产: 视频的创作者用手机或者其他设备拍摄一个视频，可以对视频做一些增强和编辑，通过上传 SDK，即可把这个视频上传到云端。
- 云端生产: 在云端有两个比较核心的流程：视频处理和审核，这两个流程是在并行执行的。
- 云端下发: 当以上两个流程都执行完以后，一个视频也就可以给大家看了，接下来就进入云端下发的阶段。在这个阶段，点播服务负责下发视频的播放地址（包括相关的 meta 信息），然后视频的内容是通过 CDN 下发。
- 视频播放: 这个阶段由播放 SDK 进行端上视频的处理以及渲染。
在视频生命周期里，视频处理系统是云端生产的核心环节，这也是本文主要介绍的内容。
1.1 视频处理的当前挑战
- 大规模: 目前，字节跳动每天处理的视频量级在亿级，因为每一个视频都会产生不同档位、不同格式的视频，实际生产出的是接近十亿量级的视频。这对计算和存储都是非常大的消耗，这么大体量的业务对系统整体的稳定性和性能也有非常高的要求。
- 多业务: 字节跳动的视频业务非常多样，包括短视频、中视频、长视频，以及点播、直播、RTC 相关的一些业务，涉及教育、游戏等不同的垂直的行业。
- 资源复杂: 除了常规的 CPU 资源，还有很多弹性资源，以及 CPU/GPU/FPGA 等多种类型的资源，还有一些其他的硬件转码设备等。
- 业务高速增长以及大型活动的峰值: 到目前为止，每年处理的视频量级至少都是在翻倍地增长。每年又有很多大型的活动，给系统带来了非常巨大的考验。
1.2 视频处理系统的目标
面临以上这些挑战，视频处理系统要实现哪些目标呢？
大家可以看上图，这张图是一个更偏逻辑的关系。视频处理系统最终的目标总结起来只有三点：
- 满足业务需求
- 提升用户体验: 比如画质、流畅性等方面的体验。
- 降低成本: 字节跳动的体量带来的计算、存储以及 CDN 成本都非常巨大，所以降低成本也是一个很重要的目标。
为了实现这些目标，就需要对视频做不同类型的处理，包括转码、编辑、分析，也包括一些图片处理，每一项都是一种视频的应用。
总结起来就是，整个视频处理系统以底层的系统支撑为基础，构建各种各样的视频处理的能力，形成多种视频应用，从而满足业务场景的需要，提升体验，降低成本
02 视频处理系统架构
为了实现这些目标，视频处理系统的架构如上图所示，外层被划分为三个平面.
- 用户平面: 顾名思义，就是从用户的角度，如何去调用系统。
- 控制平面: 它面向的是开发人员、运维人员、支持人员，如何去控制这个系统，以及当系统出问题的时候，怎么样对系统做一些管理和应急处理的动作。
- 数据平面: 系统每天会产生海量的数据。这些数据一方面可以进行分析，来指导系统的优化。另一方面也用于计量、计费、监控等。
中间的这四层分别是.
- 服务层: 主要是处理鉴权、任务队列的管理、上层的模板管理、策略控制等等。
- 工作流系统: 主要是为了串联异步、分布式的媒体处理流程。
- Lambda: 高可用的函数计算平台，它最大的作用是管理底层海量的资源，并且对资源进行高效的调度，以及任务的执行。
- BMF: 它是一个动态多媒体处理框架，目标是把所有多媒体处理的原子能力进行插件化 管理，然后提高系统的可扩展性以及开发和运维的效率。
03 服务层和工作流系统
服务层有几个重要的组件。
- 服务网关: 它可以进行跨机房的流量调度以及一些接口的鉴权，包括接口层的限流。
- 管理服务:
- 元数据管理 (队列、任务模板、媒体工作流)
- 媒体工作流生命周期管理 (触发、执行、状态管理等)
- 弹性队列:
- 队列限流能力：QPS，MRT 最大并发任务的数量
- 队列管理：任务分发，状态维护
- 弹性资源管理：动态资源调整
3.1 媒体工作流介绍
服务层下方就是媒体工作流的引擎，工作流是以 DAG 的形式组织一系列视频处理的流程。比如说在西瓜视频上传一个视频后，需要去抽取它的封面，并对视频进行无水印转码，还需要进行各种档位的转码。这些都是处理视频的流程，每一个流程都是一个细粒度的任务。把这些单个的流程组织起来就形成了一个工作流。
工作流能解决什么问 题呢？
-
解决了复杂业务的调用流程
- 如果没有工作流，处理一个视频就要进行多次的调用。
-
比较好管理视频处理流程的依赖关系
- 在实际的处理过程中，前后的流程之间是会有依赖的，比如画质增强的流程，需要先对原片作增强，再进行普通转码，或者通过分片转码的功能对视频预先切片，再对每一个切片再做转码，最后再把它们拼接在一起。这些都可以通过工作流的方式实现。
-
提供任务超时、错误重试等高可用的能力
- 通过工作流，可以对每一个任务设置超时时间，并在任务失败时进行重试，从而提高系统的稳定性和可用性。
下面图示是工作流内部结构:
- Gate: 工作流入口
- 处理流量调度，包括鉴权的功能。
- Engine: 工作流状态管理
- 管理所有工作流的状态。
- Scheduler: 节点任务队列管理
- 一个工作流包含很多节点，Scheduler 可以对每一个节点进行细粒度的任务调度。
- VWorker: 工作流和函数计算平台粘合层
- 将上层一些偏业务属性的模板转换成一个底层，实际可以执行的函数任务的参数。
3.2 高可用性 - 任务执行
视频处理系统是一个离线处理系统，每一个任务都是 long-term running 任务。这时最重要是保证过来的每一个任务都能够最终被执行，而且最终保持一致。所以对系统来讲，需要有 at least once 的保证。
-
任务幂等
- 转码系统 -> 多媒体离线处理系统 -> 任务需要保证最终一致性 -> 任务幂等
- 同一个任务无论何时执行 执行多少次，最终的结果是一样的。业务方对此是无感知的。
-
任务合并/去重
- 在一定的时间内，如果同一个视频做同一个处理提交了非常多次，这时就需要有去重的机制，只执行一次。这在某些场景下能够比较好的提升系统的效率。业务方对此是无感知的。
- 判重逻辑 -> 转码模板的 Hash + 元信息的 Input
- 接口幂等 -> 当发现有重复转码任务时会返回 相同任务ID + 多次回调
3.3 高可用性 - 快速响应和恢复
视频处理系统的下游涉及到计算资源和存储资源。一旦计算资源和存储资源出问题，很难有一个完美的方案对上层业务做到无感知，要做的就是尽量避免损失，尽量减少对于业务的影响。
- 限流控制: 保证有限的资源内保证重要的任务优先被处理
- 多级限流: 接口/工作流队列/节点
- 例如. 假设底层计算资源现在突然变为正常的一半，如何减少对业务的影响？首先，在工作流层面，需要把一些对于任务延时不敏感的工作流任务进行 delay，这就需要一些策略的预设置。
- 预配置策略 & 动态调整
- 例如. 需要对不同的节点进行优先级的配置，比如视频要转出五个档位，可能其中有两个档位是大家消费概率最高的，就需要把这两个档位优先转出来，其他的档位进行延迟处理
- 多级限流: 接口/工作流队列/节点
- 重转重试 (快速恢复): 任务重试/快速筛选工具/批量重转工具
- 例如场景. 昨天有位同学上线了一个有问题的功能，但是今天才发现。这时要做的是把昨天这个功能上线这个功能以后所影响的视频全部筛选出来，快速进行重新转码，而且不能够影响目前正在运行的业务.
- 挑战1: 如何准确的从某任意一个时间点到另外一个时间点把这一批视频全部都挑出来
- 挑战2: 快速重传，而且不能影响线上的业务。所以这里需要有一个单独的子系统来负责整体的批量任务的查找和重转。
3.4 高可用性 - 系统维度
- 下游中间件冗余备份
- 数据库多级缓存
- 消息队列备份
- 完备的活动压测/预案
- 完备的报警/监控/Oncall 流程
04 函数计算平台
-
函数的定义
- 一个工作流内部的一个节点
- 一个具体的处理任务
- 一段可以运行的程序函数
-
函数计算平台所提供的能力
- 视频应用的水平扩展能力
- 提供多种资源的高效管理和调度能力
- 提供函数管理能力
- 提供函数部署、运行环境等
- 提供各种异常处理及容灾等高可用能力
- 提供日志、报警、监控等数据相关服务
- 图中左侧部分是一个控制平面，开发者可以开发自定义函数，通过管理 UI 注册到函数计算平台上。
- 图中右边是整个函数调用的流程。这个流程首先会经过该函数计算平台的 Gateway，到集群层面的调度，然后会到一个单集群里，单集群内部是我们自研的一个中心调度系统 Order。
- Order 有一个中心调度器，会把这个任务调度到一个具体的节点上去执行。
- 这个节点就会拉取整个函数的可执行的包，然后执行这个函数。
4.1 高可用 - 任务维度
- 点播转码、抽帧幂等任务 vs 直播、RTC 非幂等任务
4.2 高可用性 - 多集群
- 多机房/多集群容灾，一键切换
- 多集群流量自动调节，策略配置（根据任务堆积，资源使用量等）
4.3 高可用性 - 单集群
- 单集群调度层面
- 中心调度器多实例，平滑动态升级
- 节点状态检测，问题节点熔断/任务重试
- 控制面 - 服务治理
- 上下游异常实例检测 + 摘除
- 中间件熔断策略，DB/Redis
05 动态多媒体框架 BMF
tip
GitHub Link: 字节开源 - 跨平台可定制的多媒体/视频处理框架
BMF 全称是 ByteDance Media Framework。它是字节跳动自研的多媒体处理框架。之所以会去自研一个视频处理框架，是因为我们发现传统的一些视频处理框架会有一些限制。
- 传统框架一般使用 C/C++ 开发和扩展，扩展门槛比较高，并且扩展以后需要重新编译，在一个大型系统里面这是一件很麻烦的事情。如果这个框架有很多人在开发和维护，那么它的依赖越来越多，最后会大大降低开发和运维的效率。
- 传统的视频处理，比如视频转码，它的流程比较固定，一般处理框架都可以支持。但是对于一些更加复杂的场景，比如视频编辑，或者 AI 分析，传统框架本身在灵活性上会有一些限制。
- 传统的框架本身性能上也会有一些瓶颈。以 ffmpeg 为例.
- filter graph 是单线程执行的。如果在 filter graph 里面放一个 GPU 的 filter，它的执行效率就会下降得很厉害，而且 GPU 的占用率也不会很高。
为了解决上面这些问题，我们自研了 BMF 多媒体处理框架。它的目标包括.
- 减少视频应用开发的成本. 使应用开发标准化。
- 通过一套框架支持各种复杂的应用场景，从框架本身来讲，它具有比较高的灵活性。
- 通过这个框架把所有视频处理的原子能力模块化，并且做到动态管理和复用，以此解决大规模协同开发的问题；同时，也能使这些能力比较好地复用在不同的场景和业务上。
- 屏蔽底层的硬件差异。业务现在会越来越多地用到不同的异构硬件，比如说 GPU，我们希望这个框架能够 原生支持这些硬件。
- 最上层是应用层。应用层上的每一块是一个视频应用，比如前面提到的的视频转码、视频编辑、图片处理等等。
- 下层是模块层，每一个模块是视频处理的一个细粒度的原子能力。例如对视频进行编解码，或者是进行 ROI 检测等等。
- 应用层和模块层是通过中间的框架层串联起来的。这个框架层的中心是一个核心的引擎。
- 这个引擎对上提供一套比较通用、简洁的流式接口，使开发者能够比较容易地搭建出视频处理的应用。该接口支持多语言，包括 C++、Python、Go。
- 对下，它会提供一套比较完善的模块开发的 SDK，也支持 C++、Python、Go 这几种语言。
- 围绕着核心引擎，我们又做了一些相关的服务和工具集，这个服务主要用来管理模块的版本、依赖等。
- 在实际情况当中，算法开发人员研发了视频处理的算法。
- 首先这个算法会送到算法优化同学那里做优化。 优化完以后，整个算法就会形成一个模型。
- 接下来算法优化的同学会把这个模型注册到系统上 ，模块的开发同学会把这个模型封装成具体的模块，也是注册到系统里面去，这个模块就是一个具体的原子的能力。
- 再接下去，函数开发者，也就是业务开发同学，就可以把模块串联成一个具体的视频处理应用，做成一个函数注册到函数管理平台，然后灰度上线。
总结和展望
上图是视频转码的完整流程示例.
- 当用户上传一个视频以后，这个视频首先会进入服务端的存储，这时会触发一个转码的流程，也就是提交一个工作流任务。这个任务首先会经过转码的服务，然后被放到弹性队列里去.
- 下一步，任务从弹性队列出队，进入到工作流引擎里面去执行.
- 工作流引擎会把工作流拆解为一个个细粒度的任务，然后送到函数计算平台去执行，每一个函数，会采用前面介绍的 BMF 动态开发的方式去构建。
- 最终，当所有细粒度节点的任务都执行完，整个工作流也完成以后，转码或者视频处理的流程就完成，再一步步往上返回。