摘要：本文整理自 Disney 廣告智慧執行總監郝又超、Disney 廣告智慧實時計算負責人李丁哲，在 FFA 的分享。本篇內容主要分為四個部分：
- Disney 流媒體廣告與實時應用
- 業務場景實現
- 實時平臺構建
- 未來展望
一、Disney 流媒體廣告與實時應用
說到 Disney 流媒體業務包括 Hulu，大家可能並不熟悉，因為我們在國內的業務並沒有落地。Hulu 是在 15 年前由 Disney、福克斯和 NBC 共同發起成立的，現在已經在美國本土是一家頭部的流媒體平臺了。
2019 年，Disney 收購了福克斯從而得到的 Hulu 的運營控制權，因此也得到了 Hulu 上的廣告平臺這樣一個優質資源。因為作為傳統的流媒體公司，Disney 原來並沒有自己的技術廣告平臺，而在 2019 年之後，Disney 也陸續的發力線上流媒體，推出了 Disney+，ESPN+，Star+等多個流媒體品牌。下面來具體看一下 Disney 和 Hulu 的流媒體以及廣告業務的資料。
2.35 億，是截止到今年十月份，Disney 流媒體包括 Disney+，Hulu，ESPN+，Star+在全球的訂閱使用者。這是一個什麼概念呢？Netflix 已經在全球運營了超過十年，我們在今年 7 月份就已經超過了它全球的訂閱使用者數，且我們的訂閱使用者數是以家庭為單位的，所以實際觸達的個人使用者可能有 7 -10 億。
Hulu 是當前 Disney 流媒體廣告業務的主要來源，每天投放數億 15 秒、30 秒長的影片廣告，而每選擇一個廣告都會產生幾十甚至上百個事件，對資料平臺有著極高的挑戰，隨著 Disney+上 12 月份即將上線廣告，這種挑戰預期將數倍增長。
接下來給大家稍微介紹一下 Disney 的流媒體廣告資料平臺。大概分為兩層，一層是底層的資料和演算法，另一層是應用和服務。
資料和演算法主要包括三部分：
- 使用者資料。主要透過以使用者和使用者身份為主要維度來匯聚使用者的行為資料，從而對資料交換以及廣告所需要的定向進行人群圈選的核心能力。
運營資料。主要包括兩部分：
- 一部分是透過以廣告的曝光為核心，匯聚所有的廣告曝光、投放、轉化以及使用者互動的資料，形成 Event Store。
- 另一方面是透過對 Event Store 在廣告的訂單維度上進行進一步聚合，提供各種的 KPI。這些聚合通常是實時的，這就是 Flink 在我們廣告平臺上主要的應用場景。
- 機器學習平臺。主要透過我們豐富的資料，從使用者、廣告商以及 Disney 的核心的業務指標進行最佳化。
可以說資料和演算法提供的應用和服務，驅動著我們整個廣告生命週期的各個環節。比如:
- 售賣和規劃階段，我們提供庫存預測，使用者洞察；
- 投放和交易階段，我們提供實時的定向、實時的決策、實時的監控和故障定位；
- 報告分析階段，我們有商務智慧、廣告的歸因和麵向廣告商的各種報表。
從具體實時應用的角度，我們目前使用 Flink 主要嘗試了三個場景，分別是廣告決策漏斗、廣告曝光監控、廣告系統大屏，這三個環節將在後面做具體闡述。
二、業務場景實現
大概在兩年前，我們對流計算框架做了一個統一的選型，之前有用到多種的流計算框架，為了實現上面提到的業務需求，最終選擇了 Flink。原因有以下幾點：
- 使用 Flink，可以比較靈活的使用它的 vp 的處理或者流式的處理，從而達到我們對於時效性的多種需求。
- Flink 它有流批統一的 API，我們可以用 Datastream 對有限流做 Batch 處理，或者對無限流做流式的處理。而且它可以讓我們使用同一套程式碼，大大減少了我們維護程式碼的壓力。
- Flink 支援 Exactly Once 語義，結合我們的上下游，可以達到一個從端到端的 Exactly Once 的保證。
- Flink 有很多非常好用的程式設計的介面，比如 Window Functions。
從整個大資料平臺上來看，Flink 的定位主要如下圖所示。首先從系統及使用者側去把資料收集到多個訊息佇列中，然後在上面這條 Flink 統一做一個流式計算，計算出業務所需的一些指標，透過資料介面暴露給實時的業務平臺、實時的運維平臺，以及其他一些系統如廣告伺服器。在批處理的這一條鏈路上，除了會用 Spark 生成一些離線的業務報表、離線的對外資料輸出，還會用 Flink Batch 做一些指標回填的操作。
下面分享下第一部分最後提到的三個場景。第一個場景是廣告決策漏斗，主要面向的是維護人員和開發者。對於廣告的決策系統來講，廣告決策是一個相對比較複雜的過程。當使用者登入到流媒體平臺的時候，我們需要從一個龐大的廣告池子裡，透過粗排、精排等多個過濾條件，最終給使用者選擇出一個最適合他的廣告。
因此在這麼複雜的業務場景中，就萌生出了運維同學、開發同學對錯誤排查能力的需求。我們把廣告決策的整個流程，抽象成了一個廣告決策漏斗。我們希望透過前端給運維人員、開發人員展示一些具體的資訊，比如在漏斗裡是否有投放的機會、廣告是否定向成功、是否被過濾掉、最終有沒有投放給使用者，如果沒有投放給使用者，失敗原因是什麼等等。對於這個業務場景我們主要有三個非常需要關注的點。
- 資料質量。作為一個需要供大家去做 debug 的平臺，我們希望我們的資料質量能夠得以保證，要不然這個平臺將毫無意義，甚至會誤導運維人員、 開發人員，使他們做出一些錯誤的判斷。
- 系統時效。我們不僅希望廣告系統在出現問題時，可以及時發現，希望在運維人員更改配置後，或者開發人員修復一些程式碼 bug 後，可以及時在廣告平臺上看到變化，來判斷是否成功修復了問題。
- 開銷代價。決策漏斗是一個監控平臺，我們不希望它消耗太多的計算資源。那麼在整體的架構中，首先需要我們的廣告伺服器將一些決策資訊進行一些動態的編碼壓縮，然後傳送到訊息佇列當中。Flink 從訊息佇列中統一做拉取，在視窗框架中將它們 Join 起來，還原出決策漏斗。在這之前也做了一些解碼的工作，最終將決策漏斗放在前端進行展示。
這一條實時鏈路在實現的時候，我們使用了 Exactly Once 語義。上下游都是使用的 Kafka，利用 Kafka 的能力獲得 Exactly Once 的保證。OLAP 這一套插入資料的系統也是保證了 Exactly Once 從 Kafka 讀取到資料庫中，最終成功的實現了從端到端的 Exactly Once。
下面這一條離線的批處理鏈路，只把它當作一個糾錯的鏈路，當我們實時鏈路有一些 bug ，造成部分資料質量問題時候的一個資料重填以及糾錯。在這個離線鏈路上，我們也是嘗試使用了流批一體，使用同一套程式碼去做這個資料的回填。
總結一下，剛才提到的三點我們最關心的核心問題；
- 在資料質量方面，我們從業務角度上看，實現了髒資料收集旁路。一旦發現上游傳輸的資料不對，運維人員就可以及時得到通知，去進行問題排查。然後這一條鏈路從底層是用 Exactly Once 做的資料質量的保證，保證都是可以信賴的資料。
- 在開銷代價方面，Exactly Once+流批一體也實現了一個 Kappa 的架構。傳統 lambda 架構需要做一個常駐的回填糾錯。在 Kappa 的架構下，這一部分的計算資源可以被節省下來。
- 在系統時效方面，我們也做了一些最佳化，比如最佳化了 Flink 本身任務的一些效能。像決策資訊是由壓縮、動態的編碼來傳送到我們後端的，這裡就涉及了一些比較複雜的資料模型，因為它的原生正反序列化比較緩慢，所以我們進行了一個針對性的最佳化，提高了整體鏈路的吞吐率。
可能比較熟悉的同學知道，如果使用 Exactly Once，訊息的 Transaction Commit 和 Checkpoint 的生成是息息相關的。只有當 Checkpoint 生成的時候，才會把訊息 Transaction Commit 到 Kafka 上，所以時效性也跟 Checkpoint 的速度或者 Checkpoint 間隔的大小緊密相關，我們也對此進行了一些針對性的最佳化。
不同於一般情況下的 Hadoop 生態系統，Hadoop 在 HDFS 做 Checkpoint。在我們這個應用場景下，我們使用的是 AWS 的 S3 儲存。Flink on S3 的 Checkpoint，我們是對於這個場景進行一些深度的最佳化。
除了時效性以外，我們在穩定性方面也解決了一些問題。比如在比較大的被壓場景下，可能會有 Checkpoint 過於緩慢，甚至 Kafka Transaction 失效的問題；在 Flink 1.14 版本，Kafka 的 Producer 可能有 Transaction ID 重用的問題；在同時使用 Transaction，也就是 Exactly Once 和流批一體的時候，面臨了這兩者不是百分百相容的問題；比如 Checkpoint 和 Transaction Commit 緊密的關係，在 Batch 的情況下我們沒有 Transaction 的概念，需要對運算元的內部情況和整體的 Flush 做一些特殊的處理。
在這套系統上線後，我們成功的支援了 20 億/秒的指標生成，2 分鐘左右的端到端延遲，資料取用方面毫秒級響應。
第二個場景是廣告曝光監控，主要面向的是使用者方和廣告主。廣告主在簽訂廣告合同的時候，通常會有一些定向投放的限制，比如我是一個母嬰用品的廣告，那就希望投放的人群是媽媽或者女性，還會有一些動態的規則，比如在投放次數上，不希望在同一時間內投放給同一個使用者超過多少次；或在同一個使用者的會話視窗下，不希望跟競品廣告出現在一起等等需求。
因此我們研發了廣告曝光的監控平臺，廣告主可以在我們的廣告曝光監控平臺上看到自己廣告投放的一些資訊。比如廣告的投放區域、面向人群、或者當更改了一些定向規則後，廣告伺服器有沒有反映出這些變化等等需求。
那麼廣告監控具體是如何實現的呢？首先從我們的系統和客戶端收集到一些廣告選擇的上下文資訊、使用者和廣告的一些互動資訊到訊息佇列中。然後使用 Flink 進行流和流的 join，再加上維度表做維度的增強，從而生成了一系列的事實指標。這些事實指標可以包括廣告的曝光、獨立訪客的數量、使用者觀看頻率等等。
基於這些基礎的事實指標和一些特定的廣告業務規則，我們計算出一些衍生指標，比如廣告投遞的狀況。在離線我們也生成了一些，可能實時比較不容易生成的指標，比如特別多維度的 UV 指標等等。我們把這一系列的指標，統一透過我們的資料介面向外暴露。這個資料呢，一方面給前端使用，另一個方面也會被廣告系統使用。
我們現在的廣告系統，更多的是由基礎和簡單的廣告曝光計數器和演算法，來控制廣告投放的速率。如果我們使用有更加豐富維度的曝光資訊，可以支援 AB 測試、更加細膩的廣告曝光速率控制等場景。所以在整個資料鏈路中，我們最關心的就是資料的可用性。
對於資料可用性我們主要做了兩點。
- 嘗試讓 Flink 和我們正在使用的一個元資訊系統進行打通，然後我們的其他應用，比如 Spark，Hive 等應用就可以直接使用 Flink 生成的資料了。
- 我們提供了一個統一的指標介面。那麼不同的下游、前端、後端就可以靈活取用我們的指標了。
第三個場景是廣告系統大屏。前兩個場景更多的是關注某一個廣告投放的一個區域性，而廣告系統大屏更多的是面向管理層，需要對廣告系統和廣告投放有一個全域性的洞察力。
我們使用 Flink 對一些資料來源進行處理，然後透過指標介面暴露出來，再基於不同的業務規則，每 5 分鐘、每小時、每天的批式處理，最終投放給前端做廣告實時大屏展示。
三、實時平臺構建
我們的 Flink 實時平臺是基於雲上開發的，使用 K8s 作為容器的管理系統，Flink Operator 管理 Flink 叢集。我們自己研發了 Job submitter 的角色去幫助使用者，讓他們以自己熟悉的姿勢去提交 Flink 任務。
對於在計算平臺出現的一些經典問題，我們也都一一解決了。比如當叢集資源有限的情況下，有很多大任務，且每個任務都需要大量的資源，我們同時提交每個任務都能拿到一定的資源，但都沒能拿到應該拿到資源的時候，會造成任務和任務之間的互鎖，這個時候我們使用了 Gang scheduler 就可以將其解決。
除此之外我們還進行了流批作業混部，這樣可以最最佳化資源的利用率。
為了利用雲上彈性縮擴容的能力，我們主要建立了三種型別的佇列。
- 常駐任務佇列，它主要面向 Flink Streaming 這樣的任務，這樣的任務通常它的資源使用更加趨於穩定。所以我們為它主要選擇了 Reserved 節點，以一個更長的租期去租用這些裝置，然後達到更低的使用費率。
- 批處理任務佇列，它主要面向 Flink Batch，Spark Batch 這樣的任務。我們主要使用 On demand 節點，以保證我們對 SLA 的要求。
- 臨時任務佇列，它主要面向一些低優先順序的任務。我們主要使用 Spot 計算節點，這個節點有比較低 SLA 保證。比如在任務執行的過程中，Spot 節點可能會隨時撤出，在每次取用 Spot 節點時，也不能完全滿足即取即用的需求，因此我們用 SLA 換取了一個更低的費率。
總體來說，這個計算平臺也是根據我們不同佇列的一個負載去進行一個彈性的一個擴/縮容。
對於使用者側，我們也有相應的平臺，比如任務管理、任務詳情，可以讓使用者看到提交到實時平臺上的任務狀況。
除此之外還提供了日誌的管理系統，包括日誌蒐集、日誌查詢，滿足使用者 debug 的需求。
當然我們也有給運維同學的一些平臺，比如叢集總體指標檢視平臺以及對每一個任務執行情況、任務指標查詢的視窗。
四、未來展望
我們非常關注 Flink 社群的一些技術發展。Flink 未來在我們產品上的一些實用場景，可以歸納為以下幾個方面。
- 全流批一體。目前 Flink 在我們產品上的使用只在區域性環節，主要是一些實時 KPI 的生成，這造成了在儲存和計算上的資源浪費。因為我們不得不借助 Lambda 的結構來保證流批之間資料的一致性。如果能借助流批一體，希望可以降低我們在儲存和計算上的雙重成本。
- OLAP。目前我們的實時 KPI 返回還是有單獨的 OLAP 引擎，未來希望可以透過統一引擎來提高我們開發的效率。
- 實時歸因。對於廣告來說，歸因是非常重要的一個環節。目前我們所有的歸因都還是離線來實現的，但從業務需求上，我們希望能夠更快的知道使用者轉化的原因，所以利用 Flink 在實時歸因上對我們也非常重要。
- 流式機器學習。在資料平臺和計算引擎全部遷到實時計算上後，我們也很想嘗試流式機器學習。包括線上特徵提取、線上模型訓練等等。
更多內容
活動推薦
阿里雲基於 Apache Flink 構建的企業級產品-實時計算Flink版現開啟活動：
99 元試用 實時計算Flink版（包年包月、10CU）即有機會獲得 Flink 獨家定製衛衣；另包 3 個月及以上還有 85 折優惠！
瞭解活動詳情：https://www.aliyun.com/produc...
