簡介： 優酷視頻內容數據天然呈現巨大的網絡結構，各類數據實體連接形成了數十億頂點和百億條邊的數據量，面對巨大的數據量，傳統關系型數據庫往往難以處理和管理，圖數據結構更加貼合優酷的業務場景，圖組織使用包括頂點和邊及豐富屬性圖來展現，隨著年輕化互動數據和內容數據結合，在更新場景形成單類型頂點達到日更新上億的消息量。本文將分享阿里文娛開發專家遨翔、玄甫在視頻內容實時更新上的實踐，從圖譜化的全新視角，重新組織內容數據的更新，詮釋圖譜化在業務更新場景的應用。

一背景

搜索推薦系統作為在線服務，為滿足在線查詢性能要求，需要將預查詢的數據構建為索引數據，推送到異構儲存介質中提供在線查詢。這個階段主要通過 Offline/Nearline 把實時實體、離線預處理、算法加工數據進行處理更新。這里包含了算法對這些數據離線和在線的處理，不同業務域之間最終數據合并(召回、排序、相關性等)。在平臺能力方面采用傳統的數倉模式即圍繞有共性資源、有共性能力方面建設，形成分層策略，將面向業務上層的數據獨立出來，而這種模式在實現業務敏捷迭代、知識化、服務化特征方面已不能很好滿足需求。

知識圖譜作為對數據進行結構化組織與體系化管理的核心技術，實際面向業務側應用過程中能很好的滿足知識化、業務化、服務化方面的訴求，基于內容圖譜體系的特征平臺建設，以內容(視頻、節目、用戶、人物、元素等)為中心，構建一個實時知識融合數據更新平臺。

二設計概要

基于搜索推薦系統數據處理鏈路一般包括以下幾個步驟：從內容生產端(媒資、互動、內容智能、包羅、糧倉、琳瑯等)接收 dump 出來的全量數據和業務側增量數據，然后業務側拿到這些數據按業務域進行一層一層加工，最終通過 build 構建索引進入到引擎端。

不同于其它業務場景，在優酷場景中我們接收的內容生產端并不是源頭生產端，中間摻雜了很多半加工的異源異構數據，數據的一致性(邏輯一致性、功能一致性)是擺在用戶側實際性面臨問題，特別實時和全量產出的數據需要保持結構一致，同時搜索引擎的字段結構保持一致。我們從數據結構化組織與業務體系化管理方面進行索引平臺更新設計。

1 數據結構化組織

設計文娛大腦面向應用側的中間層，將知識圖譜引入中間層，實現了面向業務領域的數據組織方式。將知識圖譜融入在中間層數據模型這一層，用包含實體、關系、事件、標簽、指標的知識圖譜統一視圖來定義面向領域的數據模型。將視頻領域知識圖譜作為中間層數據組織的基礎，實現面向業務領域數據組織方式的轉變。

2 業務體系化管理

將算法的邏輯以組件化的模式進行封裝，實現了業務方只需要維護一套邏輯，實時和全量一套代碼，采用統一 UDF 來實現。利用 Blink 的流批一體化的架構，實現全增量架構模式，如在數據清洗訂正邏輯時進行全量(實時引擎中做到了消息不丟的機制保證，不需要每天實現全量)，讓全量數據走一遍邏輯。

三關鍵模塊

1 特征庫

特征庫包含兩層：第一層是全增量一級特征計算，對接不同的數據源(包括實時和離線)，在特征域計算中不存在離線全量，對于冷數據或修正數據采用存量的全集重新走一次流處理。數據組織儲存在頂點和邊關系表中。實時更新過程中為了減少對上游反查導致的性能壓力，不同實體屬性變更直接走內部圖查詢，統一封裝 DataAPI 對這些數據進行操作，不同類型頂點采用獨立 blinkjob 進行計算。

離線數據組織方面，由于搜索引擎在線服務的機器并不持久化數據。當新的在線機器加入集群時需要從某個地方拉取全量索引文件進行數據裝載，我們組裝一個和索引模型一樣全量文件。全量文件只是某一個時間戳的快照，全量文件時間戳越早需要追的實時消息就越多，故障的恢復速度就越慢，需要有一個機制盡量及時產出最新全量文件，減少實時增量消息帶來的性能壓力。

二級特征計算，面向算法的接入，包含了搜索的相關性、排序、召回這層直接面向業務域，它直接消費一級特征庫中的數據，業務主要邏輯集中到這層進行計算，此時實時離線邏輯主要通過組件庫來完成。

2 組件庫

不同業務線算法按各自業務從同一份數據中獲取自身需要的數據進行處理加工，無形中就導致代碼的重復。組件庫建立主要開放適配接口，讓相同功能代碼得以復用，減少重復開發。

組件庫將業務邏輯抽象成簡單的基于 UDF 的算術表達式來組織，簡單、簡潔，并且更易維護，特征使用方，只需關注特征粒度，不需要關注整體。

3 Trace&Debug 模塊

每一個消息有唯一簽名(uuid)，源頭數據會在各個計算流程中流轉，處理過程中為了便于業務更好追蹤處理流程問題，將不同系統數據按 uuid 和實體 id 進行聚合，通過 Trace&Debug 服務能較好理解業務處理過程信息和系統處理信息。

四技術細節

整體計算框架采用新一代的實時計算引擎 Blink，主要優勢在于流批一體化，業務模塊通過 job 切分，不同的計算模塊可以隨意組合；消費位點自動保存，消息不丟失，進程 failover 自動恢復機制；分布式的計算可消除單點消費源和寫入性能瓶頸問題。儲存引擎采用 Lindorm 進行實體數據儲存，主要利用 Lindorm 二級索引來儲存 KV 和 KKV 數據結構，用于構建知識圖譜的底層數據。

1 知識圖譜儲存和組織

采用標簽屬性圖(Labeled Property Graph，LPG)建模，Lindorm 作為主儲存，實體表(視頻、節目、人物等)作為頂點表，實體間關系利用 lindorm 的二級索引能力作為邊表。

數據訪問方面，實現數據驅動層，提供給外部使用接口 API，開發人員通過本地 API 來操縱 Lindorm。接口層一接收到調用請求就會調用數據處理層來完成具體的數據處理，屏蔽了 java 代碼屬性和 Lindorm 列值的轉換以及結果查詢的取值映射，使用注解用于配置和原始映射，解決 java 對象直接序列化到 Lindorm 的行列儲存問題。

2 計算和更新策略

采用 Blink 計算平臺實現特征計算和索引更新，由于采用了全增量架構，在全量更新過程減少上游服務反查的壓力，采用列更新策略。在不同實體屬性或邊表屬性(邊表屬性為了減少圖查詢過程中頂點查詢的壓力開銷)更新采用級聯更新策略，即屬性更新后生成新的消息推送到總線鏈路端，不同實體或關系訂閱消息后按需進行自身屬性更新。

更新一個業務核心訴求就是一致性，其本質就是不丟消息和保序，我們采用 MetaQ 作為主消息管道，本身具備不丟消息，更多是在外部服務、儲存、處理鏈路層面上失敗情況。

對于一個實體數據或關系數據(通常一個 job)，采用原子操作，內部有一定的重試機制，如訪問外部服務，自身會有重試機制，這種重試為了不影響整體的鏈路性能我們稱作 Fast try，一般應對網絡抖動如超時等情況，如果失敗會保留一定現場，將數據寫入重試隊列中，拋出異常由最外層捕獲異常，丟棄本次更新接受下一個消息，失敗的消息會在 5 分鐘、10 分鐘，20 分鐘去重試 3 次如果依然失敗則發出通知人為干預。