Gatekeeper是Netflix的視頻內(nèi)容評(píng)估管理平臺(tái)，可以展示視頻劇集的metadata，如合同信息、字幕、標(biāo)題、內(nèi)容分級(jí)等。但此前，運(yùn)營(yíng)人員無(wú)法通過(guò)Gatekeeper實(shí)時(shí)更新劇集信息，本文將介紹新的gatekeeper架構(gòu)，以及因此獲得的收益。

?

文 / ?Drew Koszewnik

譯 / John

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

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

上下文

?

Netflix平臺(tái)上的每部電影與電視節(jié)目都經(jīng)過(guò)精心策劃以確保觀眾可以收獲最佳觀看體驗(yàn)，負(fù)責(zé)此策劃展示的團(tuán)隊(duì)是“Title Operations”（標(biāo)題運(yùn)營(yíng)）團(tuán)隊(duì)。此團(tuán)隊(duì)負(fù)責(zé)運(yùn)營(yíng)并確保以下事項(xiàng)無(wú)誤：

●?視頻內(nèi)容遵守合同或協(xié)議 - 視頻擁有正確的日期范圍與可被公開(kāi)的合理標(biāo)題。

●?視頻帶有字幕，字幕與配音正確無(wú)誤且能夠?yàn)槭澜绺鞯氐挠^眾帶來(lái)高質(zhì)量觀看體驗(yàn)。

●?標(biāo)題名稱與概要可供使用和翻譯。

●?針對(duì)不同國(guó)家/地區(qū)都有符合當(dāng)?shù)胤煞ㄒ?guī)的內(nèi)容分級(jí)策略。

?

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

?

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

?

技術(shù)原理

?

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

●?一體化：整個(gè)數(shù)據(jù)集緩存在每個(gè)節(jié)點(diǎn)上，不存在驅(qū)逐策略且沒(méi)有處于空閑狀態(tài)的緩存。

●?高密度：采用編碼、位打包（bit-packing）和復(fù)制數(shù)據(jù)刪除（deduplication techniques）技術(shù)來(lái)優(yōu)化數(shù)據(jù)集的內(nèi)存占用率。

●?就近存儲(chǔ)：緩存存在于需要訪問(wèn)數(shù)據(jù)集的任何RAM中。

?

?

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

?

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

?

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

?

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

?

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

?

舊版本的Gatekeeper架構(gòu)

?

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

●?此過(guò)程完全受I / O限制，同時(shí)會(huì)對(duì)上游系統(tǒng)施加大量負(fù)載。

●?因此，這會(huì)導(dǎo)致這些隊(duì)列中的事件將一直處于排隊(duì)狀態(tài)并出現(xiàn)處理過(guò)程的延遲，繼而導(dǎo)致標(biāo)題可能無(wú)法按時(shí)正常上線。

●?更糟糕的是，個(gè)別事件有時(shí)會(huì)被遺漏。這意味著在標(biāo)題運(yùn)營(yíng)團(tuán)隊(duì)的某位成員意識(shí)到這些問(wèn)題之前，標(biāo)題可能根本不會(huì)生效。

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

?

建設(shè)性想法

?

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

?

新的Gatekeeper架構(gòu)

?

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

?

我們期待實(shí)現(xiàn)這樣一個(gè)“連續(xù)處理”模型，因?yàn)橥耆齀/O瓶頸意味著我們能夠更有效地控制數(shù)量級(jí)。我們認(rèn)為，這種模式能為我們帶來(lái)更多產(chǎn)業(yè)價(jià)值方面的收獲：

?

●?Gatekeeper可生成一套針對(duì)上游系統(tǒng)超額負(fù)載的明確解決方案

●?事件處理延遲會(huì)被完全消除，內(nèi)容生產(chǎn)者不用擔(dān)心標(biāo)題錯(cuò)過(guò)上線日期。

●?有效減少內(nèi)容運(yùn)營(yíng)工程團(tuán)隊(duì)在處理與性能相關(guān)的問(wèn)題上所花費(fèi)的時(shí)間。

●?改進(jìn)了可調(diào)試性和活躍度處理的可見(jiàn)性。

?

隨之而來(lái)的問(wèn)題

?

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

?

Hollow就像一臺(tái)時(shí)間機(jī)器

?

通常情況下，Hollow數(shù)據(jù)集的使用者會(huì)加載最新的數(shù)據(jù)狀態(tài)，并在生成新?tīng)顟B(tài)時(shí)保持其緩存更新。但是，使用者可能會(huì)指向先前狀態(tài)，并將整個(gè)數(shù)據(jù)集的視圖恢復(fù)至過(guò)去某個(gè)時(shí)間點(diǎn)。

?

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

?

傳統(tǒng)的Hollow用法

?

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

?

改進(jìn)策略

?

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

?

增量Hollow就像一臺(tái)更快的時(shí)間機(jī)器

?

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

?

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

?

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

?

Hollow增量生產(chǎn)服務(wù)

?

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

?

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

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

?

觸手可及的成果

?

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

?

顯著減少上游系統(tǒng)的負(fù)載

?

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

?

無(wú)形的成果

?

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

?

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

?

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

?

instancePREPROD Gatekeeper實(shí)際案例：“跟隨”PROD實(shí)例

?

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

Hollow產(chǎn)生的差異與確切的變化可以被直觀看到

?

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

?

結(jié)論

?

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

?

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

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運(yùn)營(yíng)，與全球頂尖多媒體技術(shù)專家和LiveVideoStack年輕的伙伴一起，推動(dòng)多媒體技術(shù)生態(tài)發(fā)展。同時(shí)，也歡迎你利用業(yè)余時(shí)間、遠(yuǎn)程參與內(nèi)容生產(chǎn)。了解崗位信息請(qǐng)?jiān)贐OSS直聘上搜索“LiveVideoStack”，或通過(guò)微信“Tony_Bao_”與主編包研交流。

LiveVideoStackCon 2019北京 音視頻技術(shù)大會(huì) 終版日程現(xiàn)已上線，掃描圖中二維碼或點(diǎn)擊【閱讀原文】了解大會(huì)最新日程。

超強(qiáng)干貨來(lái)襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。