文 / 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架構的優勢。
内容營運工程現在進入了一個嶄新的發展階段，特别是當我們擴充了我們的工作流程之後，我們得以借同樣的時間生産出比以往機關時間内所能産出的更多内容。這也讓我們有更多機會解決實際問題并發掘業務背後隐藏的巨大價值：借計算機科學的力量，開拓技術無限可能。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/100017578「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。