Netflix如何通過重構(gòu)視頻Gatekeeper提升內(nèi)容運營效率？

此文將與您分享我們的內(nèi)容設(shè)置工程團隊如何使用基于Netflix OSS技術(shù)的，被稱為“Hollow”的Java庫與工具包，簡化并重新構(gòu)建內(nèi)容傳輸基本組件的歷程———這段經(jīng)歷帶給我們產(chǎn)業(yè)價值方面的收獲，令我們受益匪淺。

上下文

Netflix平臺上的每部電影與電視節(jié)目都經(jīng)過精心策劃以確保觀眾可以收獲最佳觀看體驗，負責此策劃展示的團隊是“Title Operations”（標題運營）團隊。此團隊負責運營并確保以下事項無誤：

• 視頻內(nèi)容遵守合同或協(xié)議 – 視頻擁有正確的日期范圍與可被公開的合理標題。
• 視頻帶有字幕，字幕與配音正確無誤且能夠為世界各地的觀眾帶來高質(zhì)量觀看體驗。
• 標題名稱與概要可供使用和翻譯。
• 針對不同國家/地區(qū)都有符合當?shù)胤煞ㄒ?guī)的內(nèi)容分級策略。?

當標題滿足上述所有內(nèi)容的最低要求時，我們則允許其在該服務(wù)上生效。而Gatekeeper則是Netflix上一套負責評估網(wǎng)站上視頻等資產(chǎn)“活躍度”的工具，在得到Gatekeeper的批準之前，此視頻的標題不會對任何成員可見———如果此標題無法通過驗證，那么系統(tǒng)將會通過指出其相對于基準用戶體驗缺少的內(nèi)容，協(xié)助內(nèi)容生產(chǎn)者重新考慮更加合適的標題。

Gatekeeper通過聚合來自多個上游系統(tǒng)的數(shù)據(jù)并結(jié)合應用一些業(yè)務(wù)邏輯，針對不同國家/地區(qū)背景，為每個視頻內(nèi)容生成詳細說明，從而幫助內(nèi)容生產(chǎn)者針對不同地區(qū)生產(chǎn)最符合當?shù)赜脩粲^看習慣的視頻內(nèi)容作品。

技術(shù)原理

 Hollow 是我們幾年前 發(fā)布 的一套基于 OSS 的技術(shù)，準確地來說這是一個完整的高密度近緩存（high-density near cache），其具備以下三個特性：

• 一體化：整個數(shù)據(jù)集緩存在每個節(jié)點上，不存在驅(qū)逐策略且沒有處于空閑狀態(tài)的緩存。
• 高密度：采用編碼、位打包（bit-packing）和復制數(shù)據(jù)刪除（deduplication techniques）技術(shù)來優(yōu)化數(shù)據(jù)集的內(nèi)存占用率。
• 就近存儲：緩存存在于需要訪問數(shù)據(jù)集的任何RAM中。?

這里我想強調(diào)一下此技術(shù)的重要特性之一——“一體化”。“一體化”意味著我們不必擔心交換內(nèi)存中的記錄，同時可以進行諸如假設(shè)和預計算數(shù)據(jù)集的內(nèi)存表示等，脫離“一體化”就不可能實現(xiàn)的功能，我們期待的最終結(jié)果是這些數(shù)據(jù)集能更有效地使用RAM。然而，對于傳統(tǒng)的局部緩存解決方案，我們需要知道此方案是否可以只緩存數(shù)據(jù)集的5%，或者緩存是否需要為數(shù)據(jù)集10%預留足夠的空間，從而確保命中/未命中率符合相應要求——如果內(nèi)存量相同，則可以緩存100%的數(shù)據(jù)，命中率也可被設(shè)置并達到100%。

顯然，如果想要獲得100％的命中率，我們需要消除訪問數(shù)據(jù)所需的所有I / O ，同時盡可能實現(xiàn)更高效的數(shù)據(jù)訪問，這無疑為我們帶來了許多可能性。

亟待解決的現(xiàn)狀

直到最近，Gatekeeper才成為一個完全的事件驅(qū)動系統(tǒng)。當視頻在其任何一個上游系統(tǒng)中被更改時，該系統(tǒng)將向Gatekeeper發(fā)送此事件。

Gatekeeper對于此事件的響應是訪問其每個上游服務(wù)并收集必要的輸入數(shù)據(jù)以評估視頻及其相關(guān)資產(chǎn)的活躍度；隨后Gatekeeper將產(chǎn)生一個單記錄輸出用以詳細說明該單個視頻的狀態(tài)。

我們需要明確與此模型相關(guān)的幾個問題：

• 此過程完全受I / O限制，同時會對上游系統(tǒng)施加大量負載。
• 因此，這會導致這些隊列中的事件將一直處于排隊狀態(tài)并出現(xiàn)處理過程的延遲，繼而導致標題可能無法按時正常上線。
• 更糟糕的是，個別事件有時會被遺漏。這意味著在標題運營團隊的某位成員意識到這些問題之前，標題可能根本不會生效。

解決這些問題的方法是“掃描”目錄，以便將符合特定標準的視頻事件（例如：計劃下周發(fā)布）自動加入處理隊列。不幸的是，此方法會將更多的事件添加到隊列當中，這無疑加劇了問題的嚴重。

建設(shè)性想法

我們決定采用全高密度近緩存（即Hollow）來消除這一I / O方面的瓶頸。對于每個上游系統(tǒng)，我們將創(chuàng)建一個Hollow數(shù)據(jù)集，其中包含Gatekeeper執(zhí)行對其評估所需的所有數(shù)據(jù)。這樣，每個上游系統(tǒng)都能負責更新其緩存。

利用該模型，我們可以從概念上將活躍性評估與上游系統(tǒng)的數(shù)據(jù)檢索兩大過程分離開來。Gatekeeper不會直接對事件作出反應，而是在一個重復的周期內(nèi)，連續(xù)地評估所有國家所有視頻中所有資產(chǎn)的活躍性。此循環(huán)迭代將涉及Netflix上的每個可用視頻，同時系統(tǒng)也將計算每個視頻的活躍度細節(jié)。在每個周期結(jié)束時，Gatekeeper會生成一個完整的輸出（也是一個空數(shù)據(jù)集）用以表示所有國家所有視頻的活躍狀態(tài)細節(jié)。

我們期待實現(xiàn)這樣一個“連續(xù)處理”模型，因為完全消除I/O瓶頸意味著我們能夠更有效地控制數(shù)量級。我們認為，這種模式能為我們帶來更多產(chǎn)業(yè)價值方面的收獲：

• ?Gatekeeper可生成一套針對上游系統(tǒng)超額負載的明確解決方案
• 事件處理延遲會被完全消除，內(nèi)容生產(chǎn)者不用擔心標題錯過上線日期。
• 有效減少內(nèi)容運營工程團隊在處理與性能相關(guān)的問題上所花費的時間。
• 改進了可調(diào)試性和活躍度處理的可見性。?

隨之而來的問題

Hollow更像是一臺“時間機器”。在數(shù)據(jù)集隨時間變化的同時，Hollow會通過將時間線分解為一系列（離散數(shù)據(jù)狀態(tài)），以便于將這些更改傳遞給消費者。每個（數(shù)據(jù)狀態(tài)）表示特定時刻整個數(shù)據(jù)集的快照。

通常情況下，Hollow數(shù)據(jù)集的使用者會加載最新的數(shù)據(jù)狀態(tài)，并在生成新狀態(tài)時保持其緩存更新。但是，使用者可能會指向先前狀態(tài)，并將整個數(shù)據(jù)集的視圖恢復至過去某個時間點。

生成數(shù)據(jù)狀態(tài)的傳統(tǒng)方法是維護運行一個重復“循環(huán)”的單個生產(chǎn)者。在一個“循環(huán)周期”中，內(nèi)容生產(chǎn)端會迭代所有源自真實來源的記錄。當?shù)M行時，系統(tǒng)將每個記錄添加到Hollow庫中。隨后Hollow計算在此周期中添加的數(shù)據(jù)與上一個周期中添加的數(shù)據(jù)之間的差異，并將狀態(tài)發(fā)布到消費者已知的位置。

這種全真實迭代模型的問題在于其所花費的時間十分漫長。對于一些上游系統(tǒng)來說可能需要數(shù)小時。如此夸張的數(shù)據(jù)傳播延遲是不可被接受的——例如，如果標題運營者需要為即刻上線的電影添加評級，那么他們則需要為正在進行的實時處理耗費數(shù)小時的等待時間。

改進策略

我們需要的是一臺更快的時間機器——一臺具備更高處理效率的機器，只有這樣消費者才能切身體驗到技術(shù)帶來的直觀優(yōu)化感受。

為了實現(xiàn)這一目標，我們首先創(chuàng)造了必要的增量Hollow基礎(chǔ)組件以充分利用早期Hollow的庫與工具包，并將其作為一個公共的非測試API，率先用于流媒體平臺團隊。

使用此基礎(chǔ)組件，每當系統(tǒng)在源應用程序中檢測到更改時，更新的記錄都會被編碼并發(fā)送到Kafka的Topic。而那些不屬于源應用程序的新組件“Hollow 增量生產(chǎn)者”服務(wù)則會以預先定義好的節(jié)奏執(zhí)行重復循環(huán)。在每個循環(huán)期間，此組件會讀取來自上一個循環(huán)并已添加到主題的所有消息，同時改變Hollow狀態(tài)引擎以反映更新記錄的新狀態(tài)。

如果來自Kafka Topic的消息中包含與Hollow數(shù)據(jù)集中已反映的部分完全相同的數(shù)據(jù)，則不執(zhí)行任何操作。

為了解決事件錯過引起的一系列問題，我們實現(xiàn)了一個可周期性迭代的針對整個源數(shù)據(jù)集的掃描機制。在迭代時，系統(tǒng)將記錄下的每條內(nèi)容發(fā)送到Kafka Topic。這就使得任何可能遺漏的更新最終都會反映在Hollow數(shù)據(jù)集中。此外，由于這不是將更新傳遞至Hollow數(shù)據(jù)集的主要機制，其也不必如上文提到的用于傳統(tǒng)Hollow的迭代源那樣，快速或頻繁地進行循環(huán)過程。

Hollow增量生成器能夠從Kafka Topic中讀取大量消息并在內(nèi)部快速改變其Hollow狀態(tài)，這也就是為什么我們可以將其循環(huán)的時間配置得非常短（我們目前將此默認為30秒）。

這就是我們構(gòu)建更快時間機器的整個過程。現(xiàn)在，如果標題運營人員需要在即將上線的電影中快速添加電影等級，那么在30秒內(nèi)該數(shù)據(jù)即可實現(xiàn)在相應的Hollow數(shù)據(jù)集中可用。

觸手可及的成果

隨著數(shù)據(jù)傳播延遲問題得到了妥善解決，我們能夠基于全新的Gatekeeper系統(tǒng)消除所有I / O邊界。通過Gatekeeper的預判和決策，我們得以重新評估所有國家/地區(qū)中所有視頻的所有資產(chǎn)，而這一切在此之前都是不可想象的——以往條件下這些工作會占用整個內(nèi)容傳輸通道超過一周的時間，而現(xiàn)在只需大約30秒即可完成；與此同時，事件被錯過或評估被延遲也成為了歷史，而先前Gatekeeper系統(tǒng)被禁用也減少了我們上游系統(tǒng)的負載，在某些情況下甚至降低了80％。

除了以上性能參數(shù)上的優(yōu)勢之外，我們還獲得了彈性優(yōu)勢。在先前的Gatekeeper系統(tǒng)中，如果其中一個上游服務(wù)出現(xiàn)故障，由于無法從該系統(tǒng)檢索到任何數(shù)據(jù)，我們根本無法評估活躍性情況；而新Gatekeeper系統(tǒng)下，如果其中一個上游系統(tǒng)出現(xiàn)故障，盡管該系統(tǒng)會影響數(shù)據(jù)的實時發(fā)布，但我們?nèi)阅軌驗橄鄳臄?shù)據(jù)集提供舊數(shù)據(jù)，同時其他所有數(shù)據(jù)集不會受到影響。例如在電影片場，如果故事大綱的翻譯系統(tǒng)出現(xiàn)故障，那么在緊急上載正確的數(shù)據(jù)之后，我們?nèi)匀豢梢栽诋斍捌瑘隼^續(xù)拍攝電影。

無形的成果

比性能提升更有益的是，我們在該系統(tǒng)中的開發(fā)速度得到了顯著的提高。以前動輒幾天的開發(fā)工程現(xiàn)在僅需幾分鐘即可完成；而在原先的工作流程中，驗證與發(fā)布可能需要幾天或幾周的時間，現(xiàn)在我們則利用相同的時間顯著提升了發(fā)布的質(zhì)量。

Hollow這一“時間機器”意味著每次使用Hollow作為輸入數(shù)據(jù)的可靠途徑，整個過程是100％可重復的。對于Gatekeeper來說，這意味著可以通過將所有輸入狀態(tài)恢復為時間X隨后再次重新評估所有內(nèi)容，從而完成對在時間X時所發(fā)生事件的精確重放。

我們利用這些特性，通過快速迭代以實現(xiàn)對Gatekeeper業(yè)務(wù)邏輯的更改。下圖展示了我們維護一個PREPROD Gatekeeper的實際案例，PREPROD不斷評估整個目錄的活動性，同時其輸出將會被發(fā)布到不同的Hollow數(shù)據(jù)集。在每個循環(huán)開始時，PREPROD環(huán)境將從PROD收集最新生成的狀態(tài)，并將其每個輸入數(shù)據(jù)集設(shè)置為與用于生成PROD所輸出的完全相同的版本。

當我們想要對Gatekeeper業(yè)務(wù)邏輯進行更改時，我們會依據(jù)上述內(nèi)容進行調(diào)整，然后將其發(fā)布到PREPROD集群。而PREPROD之后的輸出狀態(tài)可以與其之前所對應的輸出狀態(tài)區(qū)別開，開發(fā)者可通過訪問PROD精準查看到邏輯改變所導致的精確效果，一目了然。以上工具幫助我們驗證多項優(yōu)化帶來的改變精準符合預期，同時不會造成其他任何意想不到的不良影響。

與部署過程的一些迭代相結(jié)合，上述一系列改進使我們的團隊能夠在幾分鐘內(nèi)實現(xiàn)對Gatekeeper編碼的關(guān)鍵性調(diào)整，同時完成驗證、部署等一系列關(guān)鍵步驟，其不僅帶來了一個數(shù)量級的速度提升，還讓架構(gòu)的整體安全性達到了前所未有過的高度。

結(jié)論

Gatekeeper系統(tǒng)的上述一系列改進措施，為我們收獲額外的業(yè)務(wù)價值提供了機會，我們計劃在未來幾個季度實現(xiàn)這一目標。此外，這種模式可以被復制到內(nèi)容工程領(lǐng)域等Netflix其他系統(tǒng)，我們也已經(jīng)啟動了多個后續(xù)項目從而正式化充分利用n-hollow-input架構(gòu)的優(yōu)勢。

內(nèi)容運營工程現(xiàn)在進入了一個嶄新的發(fā)展階段，特別是當我們擴展了我們的工作流程之后，我們得以借同樣的時間生產(chǎn)出比以往單位時間內(nèi)所能產(chǎn)出的更多內(nèi)容。這也讓我們有更多機會解決實際問題并發(fā)掘業(yè)務(wù)背后隱藏的巨大價值：借計算機科學的力量，開拓技術(shù)無限可能。

文：Drew Koszewnik @ LiveVideoStack

ps：內(nèi)容運營的多種玩法，期待與您的溝通，歡迎投稿至增長黑客；

微信溝通：18500351878

首席增長官CGO薦讀內(nèi)容運營：

• 《?小紅書：如何掌握其內(nèi)容運營策略?》
• 《產(chǎn)品運營：解構(gòu)丁香醫(yī)生內(nèi)容運營邏輯》
• 《存量運營時代，產(chǎn)品經(jīng)理如何理解用戶畫像》

更多精彩，關(guān)注：增長黑客（GrowthHK.cn）

增長黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來達成各種營銷目標的新型團隊角色。從單線思維者時常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實現(xiàn)低成本甚至零成本帶來的有效增長…