騰訊百億級(jí)大規(guī)模內(nèi)容處理系統(tǒng)探究

作者 | 騰訊內(nèi)容處理中臺(tái)技術(shù)團(tuán)隊(duì)

　　1. 背景介紹

　　騰訊內(nèi)容處理中臺(tái)是打通騰訊內(nèi)容生產(chǎn)、內(nèi)容處理、內(nèi)容分發(fā)、內(nèi)容變現(xiàn)等內(nèi)容生態(tài)閉環(huán)的核心基礎(chǔ)服務(wù)。作為銜接內(nèi)容生產(chǎn)端和內(nèi)容消費(fèi)端的關(guān)鍵路徑，旨在通過智能化、規(guī)模化的人機(jī)協(xié)同內(nèi)容處理和內(nèi)容審核等關(guān)鍵技術(shù)方案，對(duì)內(nèi)容供給端產(chǎn)生的各種形態(tài)內(nèi)容如視頻、圖文、商品、評(píng)論等，進(jìn)行安全化、標(biāo)準(zhǔn)化、算法化等流水線工業(yè)化處理，并將處理后的內(nèi)容統(tǒng)一分發(fā)到騰訊視頻、QQ 瀏覽器、騰訊新聞等多端渠道，為不同的用戶群體提供更好、更高效的內(nèi)容服務(wù)體驗(yàn)。

圖 1-1 內(nèi)容生態(tài)概覽圖

　　2. 問題和挑戰(zhàn)

　　騰訊內(nèi)容處理中臺(tái)作為工業(yè)化內(nèi)容處理技術(shù)基座，面對(duì)多元化的業(yè)務(wù)渠道以及海量復(fù)雜多樣的內(nèi)容處理訴求，需要不斷抽象業(yè)務(wù)模型，構(gòu)建高效穩(wěn)定的場(chǎng)景化內(nèi)容處理審核服務(wù)拓?fù)滏溌?，來滿足內(nèi)容生態(tài)各種內(nèi)容處理場(chǎng)景。因此，我們需要重點(diǎn)解決解決以下幾個(gè)關(guān)鍵核心問題。

圖 2-1 內(nèi)容處理中臺(tái)關(guān)鍵問題

　　問題 1：百億級(jí)的異構(gòu)元數(shù)據(jù)內(nèi)容物料接入

　　由于騰訊每個(gè)渠道產(chǎn)品都有自身產(chǎn)品的內(nèi)容類型及內(nèi)容調(diào)性需求，比如視頻、圖文、音頻、直播、商品、評(píng)論、賬號(hào)、標(biāo)簽等，面對(duì)這樣多態(tài)性的內(nèi)容，需要進(jìn)行標(biāo)準(zhǔn)模板化處理，并提供業(yè)務(wù)場(chǎng)景化的內(nèi)容預(yù)處理機(jī)制，同時(shí)為了能夠唯一識(shí)別內(nèi)容，從中臺(tái)視角，需要提供內(nèi)容中臺(tái)的統(tǒng)一內(nèi)容 ID 以及和各業(yè)務(wù)渠道映射關(guān)聯(lián)的 ID-Mapping 服務(wù)。

　　問題 2：?jiǎn)捂溌窋?shù)百個(gè)算子微服務(wù)低代碼樂高式編排

　　由于騰訊各個(gè)渠道業(yè)務(wù)既有通用公共內(nèi)容處理邏輯訴求，又有各自個(gè)性化的內(nèi)容處理邏輯訴求，且內(nèi)容處理服務(wù)鏈路通常涉及到 AI 能力和審核等多個(gè)服務(wù)提供方和多種協(xié)同模式的編排。因此，如何支持快速集成到端到端處理流程，提高研發(fā)效率，降低搭建內(nèi)容處理流程成本，成為內(nèi)容中臺(tái)架構(gòu)的核心關(guān)鍵之一。內(nèi)容中臺(tái)需要對(duì)系統(tǒng)進(jìn)行高度的抽象化處理，通過可插拔的插件模式進(jìn)行標(biāo)準(zhǔn)化，并提供高度靈活的低代碼形態(tài)多元化內(nèi)容處理服務(wù)編排能力。

　　問題 3：每日數(shù)十億次任務(wù)毫秒級(jí)優(yōu)先級(jí)可靠調(diào)度執(zhí)行

　　面對(duì)每天數(shù)千萬(wàn)的各類圖文、視頻等海量?jī)?nèi)容處理需求，需要在數(shù)千個(gè)內(nèi)容編排任務(wù)鏈路上在線流式運(yùn)行，保障數(shù)十億次任務(wù)調(diào)度毫秒級(jí)的延遲，并保障存儲(chǔ)資源的低成本訴求，對(duì)我們構(gòu)建消息隊(duì)列系統(tǒng)、調(diào)度系統(tǒng)、運(yùn)行系統(tǒng)、存儲(chǔ)系統(tǒng)等都形成了較大挑戰(zhàn)。同時(shí)，在面對(duì)復(fù)雜內(nèi)容處理系統(tǒng)，如何構(gòu)建全鏈路運(yùn)行優(yōu)化機(jī)制也十分重要，只有這樣才能為騰訊內(nèi)部各個(gè)渠道業(yè)務(wù)方提供高效穩(wěn)定的定制化內(nèi)容分發(fā)服務(wù)。

　　問題 4：端到端的可觀測(cè)性和服務(wù)穩(wěn)定性

　　系統(tǒng)中每一條內(nèi)容處理流程接入數(shù)百個(gè)處理能力，每一個(gè)能力的處理容量，可用性，服務(wù)方式都不一樣，如何保障系統(tǒng)在各種協(xié)同系統(tǒng)故障時(shí)能夠快速發(fā)現(xiàn)、定位、解決問題，以及如何應(yīng)對(duì)突發(fā)流量，提升系統(tǒng)穩(wěn)定性等問題都對(duì)系統(tǒng)提出了更高的要求。

　　3. 系統(tǒng)詳解

　　3.1 整體架構(gòu)

　　為了更好地理解內(nèi)容處理中臺(tái)工作的交互流程，下面將從業(yè)務(wù)架構(gòu)圖和技術(shù)架構(gòu)圖對(duì)內(nèi)容生態(tài)領(lǐng)域工業(yè)化處理中臺(tái)進(jìn)行簡(jiǎn)要的介紹。

　　 3.1.1 業(yè)務(wù)架構(gòu)圖

圖 3-1 內(nèi)容處理中臺(tái)業(yè)務(wù)架構(gòu)圖

　　內(nèi)容處理工業(yè)化業(yè)務(wù)架構(gòu)和我們熟悉的傳統(tǒng)工廠流水線生產(chǎn)模式極為相似。我們從端到端將整個(gè)內(nèi)容工業(yè)流水線生命周期分為了 7 大子系統(tǒng)：接入系統(tǒng)、消息系統(tǒng)、存儲(chǔ)系統(tǒng)、組件系統(tǒng)、編排系統(tǒng)、調(diào)度系統(tǒng)、運(yùn)行系統(tǒng)等。同時(shí)對(duì)關(guān)鍵核心功能進(jìn)行了關(guān)鍵解耦，以滿足騰訊內(nèi)部各渠道對(duì)內(nèi)容原料的復(fù)雜多變的私有化處理需求，支持多渠道高效分發(fā)。

　　 3.1.2 技術(shù)架構(gòu)圖

圖 3-2 內(nèi)容處理中臺(tái)技術(shù)概覽圖

　　接入系統(tǒng)：針對(duì)問題 1，主要解決騰訊內(nèi)部各渠道多形態(tài)內(nèi)容物料的自動(dòng)化接入適配問題，支持對(duì)內(nèi)容進(jìn)行預(yù)處理，比如篩選、合并等。同時(shí)，為了保障內(nèi)容物料在內(nèi)容處理中臺(tái)的唯一性，中臺(tái)對(duì)內(nèi)容進(jìn)行唯一識(shí)別碼賦值?；诮y(tǒng)一的內(nèi)容 ID 體系，內(nèi)容作為最基本的數(shù)據(jù)單元在各系統(tǒng)間流轉(zhuǎn)和調(diào)度，中臺(tái)也以內(nèi)容為核心視角來構(gòu)建業(yè)務(wù)。

　　插件系統(tǒng)：針對(duì)問題 2，主要解決內(nèi)容處理服務(wù)能力原子化和標(biāo)準(zhǔn)化的問題，使用戶能夠在全鏈路復(fù)用、共享、擴(kuò)展內(nèi)容處理能力，同時(shí)大幅降低業(yè)務(wù)使用方的開發(fā)成本。通過對(duì)服務(wù)處理能力的協(xié)議抽象，有效地避免了對(duì)基礎(chǔ)內(nèi)容處理功能的重復(fù)建設(shè)，比如常見的內(nèi)容算法服務(wù)、內(nèi)容工具服務(wù)等；同時(shí)，也對(duì)內(nèi)容處理服務(wù)提出了標(biāo)準(zhǔn)化的服務(wù)范式，提供零開發(fā)組件導(dǎo)入，組件同步執(zhí)行、異步執(zhí)行的能力。

　　編排系統(tǒng)：針對(duì)問題 2，主要解決用戶構(gòu)建內(nèi)容處理鏈路的易用性、高效性問題，低代碼 + 代碼化多元化模式構(gòu)建內(nèi)容處理工業(yè)化流水線工作。

• 　　Pipeline 模式：適合更低的熟悉成本、更快的開發(fā)，基于算子插件組成 stage，stage 內(nèi)部的多個(gè)插件并行執(zhí)行，多個(gè) stage 之間串行流轉(zhuǎn)構(gòu)成內(nèi)容處理鏈路。同時(shí)，我們提供基于 YAML 構(gòu)建任務(wù)拓?fù)?、更好的編碼體驗(yàn)、代碼式多版本管理。
• 　　DAG 模式：適合較低的開發(fā)成本、較好的業(yè)務(wù)理解，基于有向無環(huán)圖，構(gòu)建業(yè)務(wù)場(chǎng)景化內(nèi)容處理服務(wù)分支鏈路，讓開發(fā)同學(xué)可以有更清晰的業(yè)務(wù)認(rèn)知。

　　調(diào)度系統(tǒng)：針對(duì)問題 3，主要解決日均數(shù)十億次任務(wù)調(diào)度的低延遲、優(yōu)先級(jí)隊(duì)列等問題，并建設(shè)智能反壓機(jī)制。

　　運(yùn)行系統(tǒng)：針對(duì)問題 3，主要解決全鏈路端到端，涵蓋請(qǐng)求智能路由、彈性執(zhí)行、代理執(zhí)行、執(zhí)行流控、狀態(tài)微批持久化、結(jié)果共享等核心運(yùn)行優(yōu)化機(jī)制。

　　存儲(chǔ)系統(tǒng)：主要解決內(nèi)容處理的列更新場(chǎng)景以及寬表存儲(chǔ)問題，同時(shí)，在降本提效的基礎(chǔ)上，基于多租戶機(jī)制，建設(shè)私有和共有的存儲(chǔ)服務(wù)。

　　觀測(cè)系統(tǒng)：針對(duì)問題 4，主要解決多系統(tǒng)融合后的可觀測(cè)性，包括對(duì)內(nèi)容粒度和工程質(zhì)量的核心指標(biāo)秒級(jí)觀測(cè)洞察等。

　　相關(guān)術(shù)語(yǔ)

　　3.2 接入系統(tǒng)

　　為了應(yīng)對(duì)百億級(jí)的異構(gòu)元數(shù)據(jù)內(nèi)容物料接入的挑戰(zhàn)，針對(duì)多元化的騰訊各業(yè)務(wù)渠道的內(nèi)容數(shù)據(jù)，接入系統(tǒng)主要需要解決的是數(shù)據(jù)標(biāo)準(zhǔn)化處理與自動(dòng)化接入的問題，并把業(yè)務(wù)內(nèi)容及其原始屬性轉(zhuǎn)化為星航系統(tǒng)能夠標(biāo)記、識(shí)別和處理的元素。

圖 3-3 接入系統(tǒng)流程

　　為更好的支撐復(fù)雜業(yè)務(wù)場(chǎng)景以及敏捷接入需求，接入系統(tǒng)在設(shè)計(jì)實(shí)現(xiàn)上具備了以下能力要素：

• 　　標(biāo)準(zhǔn)化：針對(duì)常用的內(nèi)容形式制定了不同內(nèi)容類型的標(biāo)準(zhǔn)化協(xié)議，最大程度提高星航管線間的能力復(fù)用以及降低數(shù)據(jù)理解成本；
• 　　可擴(kuò)展：在標(biāo)準(zhǔn)化協(xié)議之上保留了可擴(kuò)展性，業(yè)務(wù)可以通過追加附加協(xié)議定制個(gè)性化的數(shù)據(jù)字段，滿足標(biāo)準(zhǔn)字段外的業(yè)務(wù)個(gè)性化需求；
• 　　低代碼：JSON 協(xié)議定義的高度可擴(kuò)展性以及 JsonPath 解析的靈活性以及完備的數(shù)據(jù) schema 和校驗(yàn)，實(shí)現(xiàn)業(yè)務(wù)接入特征的配置化解析；
• 　　自動(dòng)化：提供管理端，業(yè)務(wù)方按照約定的方式自助錄入內(nèi)容接入以及特征定義，節(jié)約對(duì)接運(yùn)營(yíng)成本；

　　 3.2.1 內(nèi)容類型

　　由于騰訊內(nèi)部不同渠道業(yè)務(wù)的調(diào)性定位不同，接入系統(tǒng)需要高度抽象，統(tǒng)一處理不同類型的內(nèi)容信息。

圖 3-4 各業(yè)務(wù)的內(nèi)容類型

　　 3.2.2 內(nèi)容 ID 體系

　　由于歷史發(fā)展原因，各渠道業(yè)務(wù)線的內(nèi)容 ID 體系不一，ID 存在生成方案不統(tǒng)一、長(zhǎng)短不一、ID 可能沖突的問題。內(nèi)容中臺(tái)作為內(nèi)容的橋梁，需要對(duì)各渠道的 ID 進(jìn)行標(biāo)準(zhǔn)化映射到星航平臺(tái)內(nèi)容統(tǒng)一 ID，并進(jìn)行統(tǒng)一管理。

圖 3-5 內(nèi)容中臺(tái) ID 和各渠道業(yè)務(wù) ID 映射體系

　　為便于騰訊各業(yè)務(wù)層面的內(nèi)容運(yùn)營(yíng)管理，內(nèi)容處理中臺(tái)的內(nèi)容 ID 中，希望能夠日期信息方便數(shù)據(jù)管理和定位；同時(shí)，系統(tǒng)層面上，需滿足以下要求：

• 　　開發(fā)部署；
  • 　　熟悉 RPC 開發(fā)框架，了解星航插件協(xié)議；
  • 　　代碼開發(fā)、同步 git 倉(cāng)庫(kù)；
  • 　　服務(wù)創(chuàng)建、審批、編譯、發(fā)布、測(cè)試；
  • 　　加工存儲(chǔ)模塊，記錄每條任務(wù)的狀態(tài)和執(zhí)行結(jié)果，在收到新增和更新的請(qǐng)求后，會(huì)將需要調(diào)度的任務(wù)發(fā)送到 kakfa 任務(wù)隊(duì)列。這種方式比起常規(guī)的輪詢?nèi)蝿?wù)的方式，時(shí)效性更高，并且能減少重復(fù)的任務(wù)發(fā)送。
  • 　　為了增加系統(tǒng)可靠性，當(dāng)任務(wù)隊(duì)列集群不穩(wěn)定或故障時(shí)，會(huì)將任務(wù)發(fā)送到補(bǔ)償隊(duì)列，保障任務(wù)不丟失。
  • 　　調(diào)度隊(duì)列服務(wù)，不斷地從任務(wù)隊(duì)列和補(bǔ)償隊(duì)列中消費(fèi)任務(wù)，計(jì)算每個(gè)任務(wù)的動(dòng)態(tài)優(yōu)先級(jí)，然后送入 redis 優(yōu)先級(jí)隊(duì)列。動(dòng)態(tài)優(yōu)先級(jí)的計(jì)算，結(jié)合了業(yè)務(wù)指定優(yōu)先級(jí)和調(diào)度因素（如狀態(tài)變更時(shí)間和失敗次數(shù)等），保證高優(yōu)內(nèi)容及時(shí)處理的同時(shí)，避免長(zhǎng)時(shí)間失敗導(dǎo)致影響低優(yōu)任務(wù)的處理。
  • 　　優(yōu)先級(jí)隊(duì)列為每個(gè)執(zhí)行器模塊的 worker 建一個(gè)子隊(duì)列，一個(gè)管線配置多個(gè) worker，每個(gè) worker 只從對(duì)應(yīng)的子隊(duì)列獲取任務(wù)。任務(wù)入隊(duì)服務(wù)使用一致性哈希算法，計(jì)算每個(gè)任務(wù)哈希到對(duì)應(yīng)管線的某個(gè)子隊(duì)列，當(dāng) worker 動(dòng)態(tài)調(diào)整數(shù)量時(shí)，會(huì)重新計(jì)算，動(dòng)態(tài)均衡。子隊(duì)列方案比起常規(guī)的高低級(jí)雙隊(duì)列方案，優(yōu)先級(jí)粒度更小，減少爭(zhēng)搶，調(diào)度效率更高。
  • 　　延時(shí)隊(duì)列，對(duì)失敗任務(wù)進(jìn)行延時(shí)調(diào)度，減少無效調(diào)度，降低對(duì)插件計(jì)算服務(wù)的壓力。
  • 　　任務(wù)分配服務(wù)，接收?qǐng)?zhí)行器模塊的請(qǐng)求，從對(duì)應(yīng)的優(yōu)先級(jí)隊(duì)列中返回任務(wù)，可以控制分配速率。
  • 　　對(duì)故障插件減少平均 60+% 的無效調(diào)度，利于插件服務(wù)恢復(fù)。對(duì)插件的調(diào)用峰值減少 60%，避免發(fā)生雪崩。
  • 　　故障恢復(fù)后，10 分鐘內(nèi)整體調(diào)度速度恢復(fù)正常。
  • 　　狀態(tài)的回寫時(shí)機(jī)包括：
  • 　　流程進(jìn)行到分發(fā)點(diǎn)
  • 　　流程執(zhí)行結(jié)束
  • 　　插件執(zhí)行失敗
  • 　　連續(xù)執(zhí)行超過 N 個(gè)狀態(tài)
  • 　　特定內(nèi)容信號(hào)觸發(fā)器
  • 　　大規(guī)模數(shù)據(jù)回溯處理
  • 　　管理端干預(yù)能力
  • 　　內(nèi)容屬性寬表 schema 需要靈活擴(kuò)展，同時(shí)需要對(duì)字段進(jìn)行規(guī)范管理；
  • 　　需要提供單個(gè)內(nèi)容的詳細(xì)處理流水供業(yè)務(wù)查詢追溯；
  • 　　需要支持 PB 級(jí)的數(shù)據(jù)存儲(chǔ)，以及對(duì)內(nèi)容萬(wàn)級(jí) qps 的在線讀寫能力，以及較高的可用性；
  • 　　需要支持不同業(yè)務(wù)個(gè)性化的關(guān)鍵字段的檢索需求；
  • 　　需要有離線 + 實(shí)時(shí)數(shù)倉(cāng)提供給業(yè)務(wù)進(jìn)行各種查詢分析；
  • 　　在降本的背景下還需要平衡好資源成本。
  • 　　以內(nèi)容 id 為主鍵的屬性數(shù)據(jù)，既包括業(yè)務(wù)原料庫(kù)中的數(shù)據(jù)（比如標(biāo)題 / 封面等），也包括內(nèi)容加工的產(chǎn)出特征（比如機(jī)器分類標(biāo)簽 / 人審結(jié)果等）；
  • 　　內(nèi)容每個(gè)步驟的變更流水，時(shí)序數(shù)據(jù)。
  • 　　HBase 屬性寬表。需要同時(shí)支持較高隨機(jī)讀寫，故而該集群使用了高性能 SSD 硬盤，開啟自帶的內(nèi)存緩存；同時(shí)利用 rs group 來區(qū)分核心 / 非核心業(yè)務(wù)，做到互不影響 ;
  • 　　HBase 事件流水表。寫量極大，存儲(chǔ)量大，但是讀量極少，主要用于運(yùn)營(yíng)展示頁(yè)面流水查詢，故而選擇廉價(jià)磁盤型機(jī)器搭建集群，能夠很好的滿足寫多讀少低成本的需求；
  • 　　盡量只存儲(chǔ)需要檢索的字段，以便減少存儲(chǔ)量，降低 ES 成本
  • 　　根據(jù)不同業(yè)務(wù)規(guī)模，按季 / 月 / 天分索引，同時(shí)采用冷熱分離的設(shè)置，有定時(shí)任務(wù)定期將熱索引落冷，減少集群整體成本
  • 　　根據(jù)需要預(yù)先配置好索引模板（比如讓字段名形如 *_ik 的字段值自動(dòng)分詞），針對(duì)實(shí)際業(yè)務(wù)數(shù)據(jù)特點(diǎn)設(shè)置的配置肯定會(huì)優(yōu)于 ES 自動(dòng)生成的配置
  • 　　不同業(yè)務(wù)可配置 Jsonpath 規(guī)則，定義 HBase 到 ES 字段的解析映射邏輯，以滿足不同業(yè)務(wù)可配置化的檢索需求
  • 　　接入效率：強(qiáng)大的接入能力，累計(jì)處理百億級(jí)內(nèi)容數(shù)據(jù)，支持自定義和模板化的近 10 種異構(gòu)內(nèi)容接入，管線創(chuàng)建實(shí)現(xiàn)自舉，接入周期從 1 周降低至 2 個(gè)小時(shí)。
  • 　　研發(fā)效率：端到端的效率優(yōu)化，提供三種不同的高效插件開發(fā)模式和在線調(diào)試模式，支持 30 多個(gè)團(tuán)隊(duì)的自定義協(xié)議和代理協(xié)議進(jìn)行高效封裝算法、業(yè)務(wù)邏輯等數(shù)千個(gè)算子插件的微服務(wù)；算法能力引入從天級(jí)別降低至 1 小時(shí)，引入百余個(gè)算法插件算子；鏈路編排，提供低代碼樂高式自助化編排，支持任意復(fù)雜的內(nèi)容處理鏈路拓?fù)渚幣?、調(diào)試與上線，整體鏈路迭代的交付周期從月級(jí)別降低到天級(jí)別。
  • 　　運(yùn)行效率：每天數(shù)十億的消息信號(hào)，高效的延遲隊(duì)列補(bǔ)償保障，水平擴(kuò)展優(yōu)先級(jí)隊(duì)列處理機(jī)制；融合統(tǒng)一 Pipeline 和 DAG 的調(diào)度架構(gòu)，輔以智能反壓穩(wěn)定性保障；插件共享，每天緩存命中數(shù)億次，為業(yè)務(wù)節(jié)省萬(wàn)余核 CPU、千余張 GPU。基于插件的共享機(jī)制和執(zhí)行狀態(tài)微批持久化等多種執(zhí)行優(yōu)化方案，和列式低成本存儲(chǔ)機(jī)制，支撐起每日千萬(wàn)級(jí)的高效內(nèi)容處理加工。
  • 　　維護(hù)效率：全鏈路秒級(jí)業(yè)務(wù)內(nèi)容視角和平臺(tái)工程視角健康性和追蹤性可觀測(cè)能力。管線的故障恢復(fù)、資源伸縮、流量調(diào)控通過自動(dòng)駕駛模塊統(tǒng)一管理。目前故障自動(dòng)處理率 75%+，自愈率 75%+，平均故障恢復(fù)時(shí)間 2.4 分鐘。