✏️ 編者按： 對於短視頻產品而言，提升視頻去重性能、降低誤殺率，是提升用戶體驗的必要環節。在此次 Milvus 社區發起的「Milvus 實戰系列直播」中，我們有幸邀請到了 vivo 互聯網服務器開發工程師馬運傑，與大家分享開源向量數據庫 Milvus 在 vivo 視頻中的實踐。
🌟 嘉賓簡介：
馬運傑，vivo 短視頻後端架構師，負責 vivo 短視頻服務端以及視頻處理平臺的系統架構設計，畢業於南京郵電大學，熱衷新技術預研與難點攻堅。
業務背景
爲什麼要視頻去重？
對於觀衆來說，良好的觀看體驗與視頻內容有着很大的關係。當前，全網範圍內主要精品視頻主要來自於 MCN 機構，一些公司爲了更快更好地去覆蓋全網內容，會選擇和內容代理合作，而代理手上會有很多重複的版權內容，導致重複內容出現。另外，搬運類視頻也會產生重複內容。如果將重複的內容直接分發給用戶，就會造成極差的用戶體驗，堪稱「勸退」。所以，內容進行去重處理是非常有必要的。
目前，視頻去重面臨哪些痛點？
目前，基礎樣本數據已達到大幾千萬，在不久的將來會過億。目前的難點是，在億級樣本數據的基礎上支持百萬級別的吞吐量，同時需要兼顧去重的精度以及高召回率。接下來，我將爲大家介紹我們是如何應對這幾個問題的。
算法流程設計
首先，進行視頻特徵提取，對視頻進行抽幀。視頻抽幀有多種策略，可以按照固定的時間間隔抽幀，或者抽取視頻所有的關鍵幀等。我們首先對視頻進行場景檢測，優先抽取出場景切換中具有代表性的一些關鍵幀，然後利用圖像算法提取關鍵幀的局部特徵，之後再把這些局部特徵去合併得到全局特徵。全局特徵是幾千維的浮點型的向量，最後我們還會再進行一層哈希壓縮，這層哈希壓縮其實壓縮了很多的數字量，但是也會給我們帶來一些問題，後續會提到。除了視頻特徵之外，我們還會提取視頻的音頻指紋，作爲比對的重要依據。 
特徵提取後，我們進行特徵匹配。將歷史提取的視頻特徵放在向量數據庫 Milvus 中，經過 Milvus 數據庫召回 topK 的向量，然後通過一定的策略進行過濾合併，得到相似的視頻的候選集，經過細緻的音頻指紋的比對，基本可以得到相似視頻的集合。最後，根據業務上的其他特徵，如時長、標題等等特徵的完整比對，最終形成相似視頻集合。
識別效果需要同時兼顧召回和精度這兩個方面。在視頻召回的時候，我們會適當放寬整個限制，儘可能多地召回相似視頻；而在音頻比對當中，我們會更嚴格地進行篩選。這種策略有一定缺陷，比如短視頻常用的“拍同款”功能中，拍出來的音頻十分相似，比對結果可能不是很好。整體來看的話，這樣的策略還是能達到 90% 以上的精度和召回率目標。 
去重系統設計
整體系統架構如上圖，分爲三個服務、四個步驟。第一個部分是特徵提取，主要是負責視音頻特徵的提取以及特徵文件的管理，其中還包括了視頻的鏡頭檢測以及抽幀。第二個部分是去重策略，主要包括了業務上的邏輯以及去重的策略控制。第三個部分是特徵召回部分，主要是作爲 Milvus 數據庫的客戶端代理工作，工作內容主要是負責創建集合以及索引。第四個部分則是基於 Milvus 數據庫搭建的檢索集羣，裏面分爲主集羣和備集羣。 
在進行系統的詳細介紹之前，我們先來看一組壓測結果。從結果中可以看到，第一列向量數量、第三列向量維度和最終的 TPS 呈負線性相關。向量數量、向量維度和索引參數，是影響 TPS 的主要因素，也是我們後面去提升這個性能的主要方向。 
我們所做的第一個工作是集羣化部署。
從壓測數據可以看出，單實例只能支持幾百萬的向量檢索，也就是幾十萬的視頻樣本。雖然這種單機部署也會有它的一些優勢，比如說部署起來非常簡單，使用方便等等。但是對於全局去重的業務不合適的。我們選擇使用 Mishards 插件來搭建分佈式集羣，通過不斷地加入 Milvus 實例，來分擔每個實例的查詢數量，提升整個集羣的吞吐量。Milvus 數據庫內部處理請求的時候其實都是單線程的，如果要提升整個系統的併發能力，可以考慮右邊這樣多集羣部署方式，提升我們整體的吞吐量。 
除了集羣化部署之外，創建索引也是提升性能的主要方式。上圖左邊表示精度，右邊表示性能。可以看到，在添加索引之後會導致一些召回率上的損失，nlist 越小，損失越大，所以我們自然想把 nlist 設置得大一些。然而，Milvus 對二值型向量的支持比較弱，在構建索引的時候沒有充分利用 CPU 資源，構建時間非常長。比如，nlist 等於 1024 的時候，索引構建時間已經達到一個小時左右。我們就只能妥協地降低 nlist 的大小，給我們帶來了召回率上的一些損失。 
此外，構建索引期間集羣裏面的數據無法正常寫入的，只有等待整個索引構建完成之後後，才能夠正常插入請求，這也是爲什麼我們需要 Milvus 備級羣。我們把向量的讀寫分爲三個狀態：正常狀態（對主集羣進行讀寫）、索引構建時的狀態（不能寫入主集羣，使用備集羣，然後同時查詢主集羣及備集羣）索引構建結束狀態（主集羣已經可以正常讀寫，需要把備用集羣的數據遷移回主集羣，遷移完成後，這個狀態也就重新變成了正常的狀態）。通過這樣主備切換，我們解決了索引構建期間無法正常寫數據的問題。 
整個集羣的樣本數據量越來越大，集羣的吞吐量會隨着時間的遷移而變小。爲了控制整個集羣的吞吐量，我們選擇通過業務上的一些規則進行了分支。比如，我們發現兩個相同或者相似的視頻，我們會是根據視頻的發佈時間以周爲單位去進行分區。在召回的時候，選擇該視頻所在分區相近的幾個分區進行查詢。通過這樣一種方式，我們對整個比對的數量進行了嚴格控制，從而保證了檢索效率。以上就是我們基於 Milvus 數據庫所做的系統設計和性能優化。
期待與總結
在識別效果方面，通過視音頻特徵的結合，採用寬視頻閾值、嚴音頻閾值的方式，目前我們去重識別的精度與召回都達到了 90% 以上；在系統性能方面，Milvus 集羣的吞吐量和每臺機器檢索的數據量強相關，我們通過集羣化部署、數據分區的方式，限制每臺機器檢索的向量數量，以此達到我們系統吞吐量 100 W/天的目標；在索引構建方面，我們遇到了比較多的問題，我們暫時以主備集羣的方式滿足系統可用性的條件，接下來我們會和社區持續溝通，解決二值索引的相關問題。
在未來，我們期待 Milvus 數據庫對以下方向進行優化：
匹配分級：對匹配結果進行分級，對於低於閾值之下的視頻通過視頻處理、採集更細緻的視頻特徵，進行二次匹配；
索引構建效率提升：與社區合作，針對二值索引的構建性能進行優化；
集羣自動擴縮容：通過 Milvus 服務的自動註冊與自動方向，解決集羣靜態擴縮容的問題；
系統高可用：通過多集羣部署等方式，解決 Mishards 以及 Milvus 數據庫寫節點單點問題。
Zilliz 以重新定義數據科學爲願景，致力於打造一家全球領先的開源技術創新公司，並通過開源和雲原生解決方案爲企業解鎖非結構化數據的隱藏價值。
Zilliz 構建了 Milvus 向量數據庫，以加快下一代數據平臺的發展。Milvus 數據庫是 LF AI & Data 基金會的畢業項目，能夠管理大量非結構化數據集，在新藥發現、推薦系統、聊天機器人等方面具有廣泛的應用。