簡介：優酷視頻內容數據天然呈現巨大的網絡結構，各類數據實體連接形成了數十億頂點和百億條邊的數據量，面對巨大的數據量，傳統關係型數據庫往往難以處理和管理，圖數據結構更加貼合優酷的業務場景，圖組織使用包括頂點和邊及豐富屬性圖來展現，隨着年輕化互動數據和內容數據結合，在更新場景形成單類型頂點達到日更新上億的消息量。本文將分享阿里文娛開發專家遨翔、玄甫在視頻內容實時更新上的實踐，從圖譜化的全新視角，重新組織內容數據的更新，詮釋圖譜化在業務更新場景的應用。
一 背景
搜索推薦系統作爲在線服務，爲滿足在線查詢性能要求，需要將預查詢的數據構建爲索引數據，推送到異構儲存介質中提供在線查詢。這個階段主要通過 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 次如果依然失敗則發出通知人爲干預。
3 統一 UDF
採用核心解決 UDF 的業務邏輯，在各個系統之間的可移植，通過技術手段保證只維護一套業務邏輯，各個計算平臺（離線/實時）可複用，解決 UDF 業務邏輯的一致性和可移植性問題。
五 總結 & 展望
基於內容圖譜結構化特徵與索引更新平臺，在結構化方面打破傳統的數倉建模方式，以知識化、業務化、服務化爲視角進行數據平臺化建設，來沉澱內容、行爲、關係圖譜，目前在優酷搜索、票票、大麥等場景開始進行應用。
隨着圖神經網絡、表徵學習方面不斷的發展，進一步在圖存儲和圖計算在面向 OLTP 和 OLAP 進行着重深度優化，通過深度算法策略來補充實時融合和實時推理方面的建設。
在索引更新平臺建設方面，隨着多方業務的接入、搜推融合帶來的挑戰，索引更新朝向全增量化的進行推進，在業務自助方面，進一步探索抽象 DSL，提升業務整體接入效率。
版權聲明：