腾讯百亿级大规模内容处理系统探究

作者 | 腾讯内容处理中台技术团队

　　1. 背景介绍

　　腾讯内容处理中台是打通腾讯内容生产、内容处理、内容分发、内容变现等内容生态闭环的核心基础服务。作为衔接内容生产端和内容消费端的关键路径，旨在通过智能化、规模化的人机协同内容处理和内容审核等关键技术方案，对内容供给端产生的各种形态内容如视频、图文、商品、评论等，进行安全化、标准化、算法化等流水线工业化处理，并将处理后的内容统一分发到腾讯视频、QQ 浏览器、腾讯新闻等多端渠道，为不同的用户群体提供更好、更高效的内容服务体验。

图 1-1 内容生态概览图

　　2. 问题和挑战

　　腾讯内容处理中台作为工业化内容处理技术基座，面对多元化的业务渠道以及海量复杂多样的内容处理诉求，需要不断抽象业务模型，构建高效稳定的场景化内容处理审核服务拓扑链路，来满足内容生态各种内容处理场景。因此，我们需要重点解决解决以下几个关键核心问题。

图 2-1 内容处理中台关键问题

　　问题 1：百亿级的异构元数据内容物料接入

　　由于腾讯每个渠道产品都有自身产品的内容类型及内容调性需求，比如视频、图文、音频、直播、商品、评论、账号、标签等，面对这样多态性的内容，需要进行标准模板化处理，并提供业务场景化的内容预处理机制，同时为了能够唯一识别内容，从中台视角，需要提供内容中台的统一内容 ID 以及和各业务渠道映射关联的 ID-Mapping 服务。

　　问题 2：单链路数百个算子微服务低代码乐高式编排

　　由于腾讯各个渠道业务既有通用公共内容处理逻辑诉求，又有各自个性化的内容处理逻辑诉求，且内容处理服务链路通常涉及到 AI 能力和审核等多个服务提供方和多种协同模式的编排。因此，如何支持快速集成到端到端处理流程，提高研发效率，降低搭建内容处理流程成本，成为内容中台架构的核心关键之一。内容中台需要对系统进行高度的抽象化处理，通过可插拔的插件模式进行标准化，并提供高度灵活的低代码形态多元化内容处理服务编排能力。

　　问题 3：每日数十亿次任务毫秒级优先级可靠调度执行

　　面对每天数千万的各类图文、视频等海量内容处理需求，需要在数千个内容编排任务链路上在线流式运行，保障数十亿次任务调度毫秒级的延迟，并保障存储资源的低成本诉求，对我们构建消息队列系统、调度系统、运行系统、存储系统等都形成了较大挑战。同时，在面对复杂内容处理系统，如何构建全链路运行优化机制也十分重要，只有这样才能为腾讯内部各个渠道业务方提供高效稳定的定制化内容分发服务。

　　问题 4：端到端的可观测性和服务稳定性

　　系统中每一条内容处理流程接入数百个处理能力，每一个能力的处理容量，可用性，服务方式都不一样，如何保障系统在各种协同系统故障时能够快速发现、定位、解决问题，以及如何应对突发流量，提升系统稳定性等问题都对系统提出了更高的要求。

　　3. 系统详解

　　3.1 整体架构

　　为了更好地理解内容处理中台工作的交互流程，下面将从业务架构图和技术架构图对内容生态领域工业化处理中台进行简要的介绍。

　　 3.1.1 业务架构图

图 3-1 内容处理中台业务架构图

　　内容处理工业化业务架构和我们熟悉的传统工厂流水线生产模式极为相似。我们从端到端将整个内容工业流水线生命周期分为了 7 大子系统：接入系统、消息系统、存储系统、组件系统、编排系统、调度系统、运行系统等。同时对关键核心功能进行了关键解耦，以满足腾讯内部各渠道对内容原料的复杂多变的私有化处理需求，支持多渠道高效分发。

　　 3.1.2 技术架构图

图 3-2 内容处理中台技术概览图

　　接入系统：针对问题 1，主要解决腾讯内部各渠道多形态内容物料的自动化接入适配问题，支持对内容进行预处理，比如筛选、合并等。同时，为了保障内容物料在内容处理中台的唯一性，中台对内容进行唯一识别码赋值。基于统一的内容 ID 体系，内容作为最基本的数据单元在各系统间流转和调度，中台也以内容为核心视角来构建业务。

　　插件系统：针对问题 2，主要解决内容处理服务能力原子化和标准化的问题，使用户能够在全链路复用、共享、扩展内容处理能力，同时大幅降低业务使用方的开发成本。通过对服务处理能力的协议抽象，有效地避免了对基础内容处理功能的重复建设，比如常见的内容算法服务、内容工具服务等；同时，也对内容处理服务提出了标准化的服务范式，提供零开发组件导入，组件同步执行、异步执行的能力。

　　编排系统：针对问题 2，主要解决用户构建内容处理链路的易用性、高效性问题，低代码 + 代码化多元化模式构建内容处理工业化流水线工作。

• 　　Pipeline 模式：适合更低的熟悉成本、更快的开发，基于算子插件组成 stage，stage 内部的多个插件并行执行，多个 stage 之间串行流转构成内容处理链路。同时，我们提供基于 YAML 构建任务拓扑、更好的编码体验、代码式多版本管理。
• 　　DAG 模式：适合较低的开发成本、较好的业务理解，基于有向无环图，构建业务场景化内容处理服务分支链路，让开发同学可以有更清晰的业务认知。

　　调度系统：针对问题 3，主要解决日均数十亿次任务调度的低延迟、优先级队列等问题，并建设智能反压机制。

　　运行系统：针对问题 3，主要解决全链路端到端，涵盖请求智能路由、弹性执行、代理执行、执行流控、状态微批持久化、结果共享等核心运行优化机制。

　　存储系统：主要解决内容处理的列更新场景以及宽表存储问题，同时，在降本提效的基础上，基于多租户机制，建设私有和共有的存储服务。

　　观测系统：针对问题 4，主要解决多系统融合后的可观测性，包括对内容粒度和工程质量的核心指标秒级观测洞察等。

　　相关术语

　　3.2 接入系统

　　为了应对百亿级的异构元数据内容物料接入的挑战，针对多元化的腾讯各业务渠道的内容数据，接入系统主要需要解决的是数据标准化处理与自动化接入的问题，并把业务内容及其原始属性转化为星航系统能够标记、识别和处理的元素。

图 3-3 接入系统流程

　　为更好的支撑复杂业务场景以及敏捷接入需求，接入系统在设计实现上具备了以下能力要素：

• 　　标准化：针对常用的内容形式制定了不同内容类型的标准化协议，最大程度提高星航管线间的能力复用以及降低数据理解成本；
• 　　可扩展：在标准化协议之上保留了可扩展性，业务可以通过追加附加协议定制个性化的数据字段，满足标准字段外的业务个性化需求；
• 　　低代码：JSON 协议定义的高度可扩展性以及 JsonPath 解析的灵活性以及完备的数据 schema 和校验，实现业务接入特征的配置化解析；
• 　　自动化：提供管理端，业务方按照约定的方式自助录入内容接入以及特征定义，节约对接运营成本；

　　 3.2.1 内容类型

　　由于腾讯内部不同渠道业务的调性定位不同，接入系统需要高度抽象，统一处理不同类型的内容信息。

图 3-4 各业务的内容类型

　　 3.2.2 内容 ID 体系

　　由于历史发展原因，各渠道业务线的内容 ID 体系不一，ID 存在生成方案不统一、长短不一、ID 可能冲突的问题。内容中台作为内容的桥梁，需要对各渠道的 ID 进行标准化映射到星航平台内容统一 ID，并进行统一管理。

图 3-5 内容中台 ID 和各渠道业务 ID 映射体系

　　为便于腾讯各业务层面的内容运营管理，内容处理中台的内容 ID 中，希望能够日期信息方便数据管理和定位；同时，系统层面上，需满足以下要求：

• 　　开发部署；
  • 　　熟悉 RPC 开发框架，了解星航插件协议；
  • 　　代码开发、同步 git 仓库；
  • 　　服务创建、审批、编译、发布、测试；
  • 　　加工存储模块，记录每条任务的状态和执行结果，在收到新增和更新的请求后，会将需要调度的任务发送到 kakfa 任务队列。这种方式比起常规的轮询任务的方式，时效性更高，并且能减少重复的任务发送。
  • 　　为了增加系统可靠性，当任务队列集群不稳定或故障时，会将任务发送到补偿队列，保障任务不丢失。
  • 　　调度队列服务，不断地从任务队列和补偿队列中消费任务，计算每个任务的动态优先级，然后送入 redis 优先级队列。动态优先级的计算，结合了业务指定优先级和调度因素（如状态变更时间和失败次数等），保证高优内容及时处理的同时，避免长时间失败导致影响低优任务的处理。
  • 　　优先级队列为每个执行器模块的 worker 建一个子队列，一个管线配置多个 worker，每个 worker 只从对应的子队列获取任务。任务入队服务使用一致性哈希算法，计算每个任务哈希到对应管线的某个子队列，当 worker 动态调整数量时，会重新计算，动态均衡。子队列方案比起常规的高低级双队列方案，优先级粒度更小，减少争抢，调度效率更高。
  • 　　延时队列，对失败任务进行延时调度，减少无效调度，降低对插件计算服务的压力。
  • 　　任务分配服务，接收执行器模块的请求，从对应的优先级队列中返回任务，可以控制分配速率。
  • 　　对故障插件减少平均 60+% 的无效调度，利于插件服务恢复。对插件的调用峰值减少 60%，避免发生雪崩。
  • 　　故障恢复后，10 分钟内整体调度速度恢复正常。
  • 　　状态的回写时机包括：
  • 　　流程进行到分发点
  • 　　流程执行结束
  • 　　插件执行失败
  • 　　连续执行超过 N 个状态
  • 　　特定内容信号触发器
  • 　　大规模数据回溯处理
  • 　　管理端干预能力
  • 　　内容属性宽表 schema 需要灵活扩展，同时需要对字段进行规范管理；
  • 　　需要提供单个内容的详细处理流水供业务查询追溯；
  • 　　需要支持 PB 级的数据存储，以及对内容万级 qps 的在线读写能力，以及较高的可用性；
  • 　　需要支持不同业务个性化的关键字段的检索需求；
  • 　　需要有离线 + 实时数仓提供给业务进行各种查询分析；
  • 　　在降本的背景下还需要平衡好资源成本。
  • 　　以内容 id 为主键的属性数据，既包括业务原料库中的数据（比如标题 / 封面等），也包括内容加工的产出特征（比如机器分类标签 / 人审结果等）；
  • 　　内容每个步骤的变更流水，时序数据。
  • 　　HBase 属性宽表。需要同时支持较高随机读写，故而该集群使用了高性能 SSD 硬盘，开启自带的内存缓存；同时利用 rs group 来区分核心 / 非核心业务，做到互不影响 ;
  • 　　HBase 事件流水表。写量极大，存储量大，但是读量极少，主要用于运营展示页面流水查询，故而选择廉价磁盘型机器搭建集群，能够很好的满足写多读少低成本的需求；
  • 　　尽量只存储需要检索的字段，以便减少存储量，降低 ES 成本
  • 　　根据不同业务规模，按季 / 月 / 天分索引，同时采用冷热分离的设置，有定时任务定期将热索引落冷，减少集群整体成本
  • 　　根据需要预先配置好索引模板（比如让字段名形如 *_ik 的字段值自动分词），针对实际业务数据特点设置的配置肯定会优于 ES 自动生成的配置
  • 　　不同业务可配置 Jsonpath 规则，定义 HBase 到 ES 字段的解析映射逻辑，以满足不同业务可配置化的检索需求
  • 　　接入效率：强大的接入能力，累计处理百亿级内容数据，支持自定义和模板化的近 10 种异构内容接入，管线创建实现自举，接入周期从 1 周降低至 2 个小时。
  • 　　研发效率：端到端的效率优化，提供三种不同的高效插件开发模式和在线调试模式，支持 30 多个团队的自定义协议和代理协议进行高效封装算法、业务逻辑等数千个算子插件的微服务；算法能力引入从天级别降低至 1 小时，引入百余个算法插件算子；链路编排，提供低代码乐高式自助化编排，支持任意复杂的内容处理链路拓扑编排、调试与上线，整体链路迭代的交付周期从月级别降低到天级别。
  • 　　运行效率：每天数十亿的消息信号，高效的延迟队列补偿保障，水平扩展优先级队列处理机制；融合统一 Pipeline 和 DAG 的调度架构，辅以智能反压稳定性保障；插件共享，每天缓存命中数亿次，为业务节省万余核 CPU、千余张 GPU。基于插件的共享机制和执行状态微批持久化等多种执行优化方案，和列式低成本存储机制，支撑起每日千万级的高效内容处理加工。
  • 　　维护效率：全链路秒级业务内容视角和平台工程视角健康性和追踪性可观测能力。管线的故障恢复、资源伸缩、流量调控通过自动驾驶模块统一管理。目前故障自动处理率 75%+，自愈率 75%+，平均故障恢复时间 2.4 分钟。