Home 技術文章 如何通過擴展清單操作來獲得與數百萬人的個人化
Applications

如何通過擴展清單操作來獲得與數百萬人的個人化

About The Author

Outline

個人化的1:1觀看體驗正在改變電視體驗。 觀衆不只是一刀切,而是根據觀衆的設備類型,位置,歷史記錄,人口統計數據和其他數據,獲得有針對性且高度相關的廣告,定製內容,新節目推薦以及精確的DRM/中斷管理。

但是,將個性化影片流擴展到數百萬觀衆,特別是體育等現場節目,幾乎與棒球比賽中的循環一樣具有挑戰性。 觀衆數量可能會大幅波動,在開場,加班和近場比賽等必看時刻激增數十萬人。 假設您的支援個性化的基礎架構沒有足夠的適應性和可擴展性。 在這種情況下,您的個性化體驗將結束,您的整個業務可能在OTT世界面臨風險。

清單伺服器在個性化中的中心作用

OTT個性化 取決於清單伺服器的性能,以生成內容,廣告和播放說明的唯一播放列表。 清單伺服器必須與以下依賴性進行競爭:

  • AD伺服器延遲 —與AD伺服器的通信可以增加必須考慮到工作流的延遲,特別是涉及多個躍點時。
  • 貨幣化/報告 —播放廣告後,必須將信標發送回AD伺服器,以測量廣告曝光量並實現貨幣化。
  • 網際網路的無狀態層面 —爲了使個性化清單大規模工作,必須在每個查看者的多個請求中保持狀態。
  • DRM/驗證 —清單伺服器必須保留數字權限管理(DRM),會話級加密和驗證的選項卡。
  • 中斷/內容權限和限制 —根據用戶的位置,流式內容可能受到各種禁止規則的約束,所有這些規則都必須得到精確管理。
  • 內容建議 —線上觀衆希望您瞭解這些建議並對其進行個性化設定,以幫助他們完成搜尋和發現過程。
  • 內容本地化 —對於重大事件,向用戶提供適當的區域變化,包括音訊曲目,隱藏式字幕和字幕,這一點至關重要。

實時個性化流

如本部落格系列第1部分所述,我們的Slicer軟體應用程式正在攝取,編碼和打包直播或VOD源。 您可以插入廣告邊界,讓內容擁有者自訂檢視者的體驗。 當廣告被攝入時,它們也會通過在雲中執行的切片器進行處理,以獲得更具廣播效果的播放體驗。

當切片器開始嵌入實時或VOD流時,它會持續與我們的後端基礎設施進行通信,使數據庫保持最新狀態,瞭解可用的數據段數量。 清單伺服器使用該數據爲每個查看器個性化體驗。 當播放器請求流時,清單伺服器確定應在清單文件中列出哪些影片和音訊段,該文件用作播放列表。 能夠在每個用戶級別動態更改或自定義清單,因此可以定製查看體驗。 對於實時影片,每隔幾秒鐘就會請求一個新的清單,允許清單伺服器在查看條件發生變化時動態應用調整。

清單伺服器在個性化影片流方面的中心作用

如上文所示,體現個性化的核心是溝通。 對於大多數OTT業務要求,這意味着與AD伺服器通信,以實時提供有針對性的個性化廣告。 個人數據,包括查看者的IP地址,位置和設備類型——基本上我們可以捕獲的所有資訊,同時仍遵循嚴格的PII規則和法規——都會提供給廣告決策系統。 由此產生的解決方案十分強大,足以瞭解在直播流媒體期間提供廣告時與觀衆相關的內容。 該系統也足夠強大,能夠應對各種挑戰,例如管理每個用戶的中斷限制和內容權限,同時支援重要的個性化功能,如內容建議和其他本地化。

構建可擴展的清單基礎架構

在我們的影片平臺中,清單伺服器負責爲每個查看器生成自定義流清單。 它還需要了解上述其他要求,如內容限制和建議。 在此模型中,我們發送了一個集成流,這意味着客戶端在流中間等待廣告載入時不會出現”緩衝輪”問題。

爲了構建彈性的清單交付系統,我們在雲中維護着分散在全球不同地理區域的清單生成伺服器羣集。 例如,在美國,這些伺服器分爲全國五個地區。 當來自美國的玩家的新流請求進入時,該請求將被隨機分配到美國的一個區域。

“雷鳴般的牛羣”挑戰‘

這可能看起來與直覺相反,但它是爲了防止級聯故障模式。 大多數美國觀衆都位於該國東部。 如果我們要將他們全部路由到離他們最近的區域,並且我們的雲提供商在該區域遇到了故障,我們的大多數觀衆都會遇到這種故障。 如果所有觀衆都刷新了流媒體,而我們現在將觀衆引導到下一個最接近的健康區域,我們將會遇到一個”雷鳴般的羣體”問題,即所有來自失敗區域的觀衆現在都會在最接近的區域內徘徊。 由此產生的意外流量峯值可能會導致二次故障,直到新區域中的系統可以擴展以滿足額外需求。

相反,隨機分配我們的美國觀衆有助於減輕任何初始故障的影響,並使我們能夠將故障轉移流量平均分配到其他健康區域。

在我們的流式傳輸平臺中,我們將清單伺服器負載分佈到各個區域。 這可以防止在觀衆羣湧動期間任何特定區域超載,尤其是在故障轉移期間,查看器突然轉移到相鄰區域時。

我們的每個區域都有一個單獨的數據存儲區,專用於存儲關聯的會話數據。 將查看器路由到某個區域後,我們會爲該查看器創建一個會話,並將其保存在區域的會話羣集中。 會話是一堆有關查看器的數據,以及客戶提供的關於如何爲該查看器自定義會話的參數。 爲了克服網際網路無狀態特性帶來的挑戰,清單伺服器會爲返回給玩家的清單中包含的每個會話構建URL。 來自播放器的後續請求將直接路由到創建和存儲查看器會話的區域(而不是隨機路由到其他區域之一)。

如下圖所示,根據受衆的規模以及受衆是在本地還是在地理上分散,不同的活動可能有許多不同的要求。 請看這三個例子,其中說明了廣播公司在支援直播活動時所面臨的基礎設施挑戰。

在第一個場景中,我們舉辦了一場喫飯競賽(是的,我們已經直播其中一個),因爲它展示了一個分佈式但較小的觀衆規模。 也許美食競賽將成爲主流的一天到來,但目前,他們仍然是一個特殊的活動,吸引了廣大地區的少數觀衆。 清單伺服器負載可以輕鬆分佈在多個區域和清單伺服器羣集之間。 在這裏,您可以輕鬆地插入適合每個地區的廣告,同時也可以管理權限和中斷,從而使個性化的價值變得顯而易見。

德克嚴重急性呼吸道症候羣州足球錦標賽的情況發生了很大變化,因爲在同一地理區域,觀衆人數衆多。 我們以幾種方式處理這一問題。 如上所述,我們發現我們可以將查看者分配到位於直接地理區域之外區域的清單伺服器,而不會影響查看者的體驗。 除此之外,我們還擁有一個系統,可監控每個區域中的觀衆級別,並可根據需要自動啓動每個區域的清單生成伺服器。

我們可能會根據NBA總決賽等大型活動的預期收視率進行預縮放。 儘管如此,我們仍有多項活動,我們的自動調整系統可處理近100萬觀衆,而無需進行任何預熱。 除了提高可擴展性之外,能夠以區域無關的方式在清單伺服器之間即時分佈負載,大大提高了整個網路的可靠性和冗餘性。

玩家請求和廣告星標

業界的許多變化和趨勢使得雲擴展比以往任何時候都更重要。 主要驅動因素是播放器請求之間的間隔縮短。 我們的標準實時線性8秒“下一步要做什麼”播放器請求被驅動到5秒,對於低延遲至關重要的流,每2秒的時間可以縮短一次。 這會嚴重影響CPU利用率,因爲伺服器必須響應4倍的請求(每2秒響應一次,而每隔8秒響應一次)。 此外,現在還必須比以往更頻繁地檢查中斷和內容建議,以避免錯誤。

同樣地,廣告技術世界變得越來越複雜和要求更高。 對於每個插入到流中的AD,一個AD伺服器將至少有五個用於報告目的的信標。 需要使用 伺服器端廣告插入(SSAI)解決方案 來確保它發送這些信標,以便客戶得到廣告商的付款。 儘管最少5個信標,但可能還有更多信標。 事實上,我們已經看到一個廣告有30到100個信標需要報告的情況。

此外,複雜的AD伺服器網路在客戶的活動中越來越常見。 多個AD網路躍點可能會導致延遲問題。 例如,網路#1可能會說:”這是此中斷中的廣告列表”,只是爲了發現該中斷中的廣告#2需要向另一個網路發出請求。 廣告#3又增加了兩個躍點,依此類推。

在上例中,AD中斷可以使CPU利用率翻倍或翻倍。 實時影片播放器請求可以將此係數複合10–30%。

‍Looking領先—微服務和可擴展性

隨着複雜性的增加,我們採取的步驟之一是將以前由清單伺服器處理的不同工作負載分成更小的微服務。 我們所做的第一步是將AD伺服器通信和信標遷移到其自己的服務中,幫助解決AD伺服器延遲的挑戰。 此廣告代理服務提供了幾種高級功能,我們將在即將發佈的部落格文章中詳細討論這些功能。

今後,我們將繼續開發其他微服務,以消除清單伺服器的更多工作,並提供更有針對性的可擴展性方法。 很快,我們將從多個雲提供商添加區域,以適應任何單個雲提供商的故障。

通過將可擴展的SSAI與微服務相結合 ,我們可以優化伺服器成本,代碼庫結構以及AD流量特有的其他特徵。 此外,我們還可以克服幾個關鍵挑戰,包括AD伺服器延遲,中斷限制和貨幣化。 同時,通過將處理負擔分散在多個區域,我們的實時影片流服務可以廣泛擴展並克服關鍵挑戰,使我們能夠可靠地同時交付數百萬個個性化流,而不會對我們的交付網路造成壓力。