Gatekeeper是Netflix的視頻內容評估管理平臺，可以展示視頻劇集的metadata，如合同信息、字幕、標題、內容分級等。但此前，運營人員無法通過Gatekeeper實時更新劇集信息，本文將介紹新的gatekeeper架構，以及因此獲得的收益。

?

文 / ?Drew Koszewnik

譯 / John

原文 https://medium.com/netflix-techblog/re-architecting-the-video-gatekeeper-f7b0ac2f6b00

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

上下文

?

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

●?視頻內容遵守合同或協議 - 視頻擁有正確的日期范圍與可被公開的合理標題。

●?視頻帶有字幕，字幕與配音正確無誤且能夠為世界各地的觀眾帶來高質量觀看體驗。

●?標題名稱與概要可供使用和翻譯。

●?針對不同國家/地區都有符合當地法律法規的內容分級策略。

?

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

?

Gatekeeper通過聚合來自多個上游系統的數據并結合應用一些業務邏輯，針對不同國家/地區背景，為每個視頻內容生成詳細說明，從而幫助內容生產者針對不同地區生產最符合當地用戶觀看習慣的視頻內容作品。

?

技術原理

?

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

●?一體化：整個數據集緩存在每個節點上，不存在驅逐策略且沒有處于空閑狀態的緩存。

●?高密度：采用編碼、位打包（bit-packing）和復制數據刪除（deduplication techniques）技術來優化數據集的內存占用率。

●?就近存儲：緩存存在于需要訪問數據集的任何RAM中。

?

?

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

?

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

?

亟待解決的現狀

?

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

?

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

?

舊版本的Gatekeeper架構

?

我們需要明確與此模型相關的幾個問題：

●?此過程完全受I / O限制，同時會對上游系統施加大量負載。

●?因此，這會導致這些隊列中的事件將一直處于排隊狀態并出現處理過程的延遲，繼而導致標題可能無法按時正常上線。

●?更糟糕的是，個別事件有時會被遺漏。這意味著在標題運營團隊的某位成員意識到這些問題之前，標題可能根本不會生效。

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

?

建設性想法

?

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

?

新的Gatekeeper架構

?

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

?

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

?

●?Gatekeeper可生成一套針對上游系統超額負載的明確解決方案

●?事件處理延遲會被完全消除，內容生產者不用擔心標題錯過上線日期。

●?有效減少內容運營工程團隊在處理與性能相關的問題上所花費的時間。

●?改進了可調試性和活躍度處理的可見性。

?

隨之而來的問題

?

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

?

Hollow就像一臺時間機器

?

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

?

生成數據狀態的傳統方法是維護運行一個重復“循環”的單個生產者。在一個“循環周期”中，內容生產端會迭代所有源自真實來源的記錄。當迭代進行時，系統將每個記錄添加到Hollow庫中。隨后Hollow計算在此周期中添加的數據與上一個周期中添加的數據之間的差異，并將狀態發布到消費者已知的位置。

?

傳統的Hollow用法

?

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

?

改進策略

?

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

?

增量Hollow就像一臺更快的時間機器

?

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

?

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

?

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

?

Hollow增量生產服務

?

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

?

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

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

?

觸手可及的成果

?

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

?

顯著減少上游系統的負載

?

除了以上性能參數上的優勢之外，我們還獲得了彈性優勢。在先前的Gatekeeper系統中，如果其中一個上游服務出現故障，由于無法從該系統檢索到任何數據，我們根本無法評估活躍性情況；而新Gatekeeper系統下，如果其中一個上游系統出現故障，盡管該系統會影響數據的實時發布，但我們仍能夠為相應的數據集提供舊數據，同時其他所有數據集不會受到影響。例如在電影片場，如果故事大綱的翻譯系統出現故障，那么在緊急上載正確的數據之后，我們仍然可以在當前片場繼續拍攝電影。

?

無形的成果

?

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

?

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

?

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

?

instancePREPROD Gatekeeper實際案例：“跟隨”PROD實例

?

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

Hollow產生的差異與確切的變化可以被直觀看到

?

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

?

結論

?

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

?

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

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。同時，也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

LiveVideoStackCon 2019北京 音視頻技術大會 終版日程現已上線，掃描圖中二維碼或點擊【閱讀原文】了解大會最新日程。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的Netflix如何通过重构视频Gatekeeper提升内容运营效率？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。