簡介：5 月 22 日北京站 Flink Meetup 分享的議題。

本文整理自愛奇藝技術經理韓紅根在 5 月 22 日北京站 Flink Meetup 分享的議題《Flink 在愛奇藝廣告業務的實踐》，內容包括：

業務場景

業務實踐

Flink 使用過程中的問題及解決

未來規劃

GitHub 地址
https://github.com/apache/flink
歡迎大家給 Flink 點贊送 star~

一、業務場景

實時數據在廣告業務的使用場景主要可以分為四個方面：

• 數據大屏：包括曝光、點擊、收入等核心指標的展示，以及故障率等監控指標；
• 異常監測：因為廣告投放的鏈路比較?，所以如果鏈路上發生任何波動的話，都會對整體的投放效果產生影響。除此之外，各個團隊在上線過程中是否會對整體投放產生影響，都是通過異常監測系統能夠觀測到的。我們還能夠觀測業務指標走勢是否合理，比如在庫存正常的情況下，曝光是否有不同的波動情況，這可以用來實 時發現問題;
• 數據分析：主要用于數據賦能業務發展。我們可以實時分析廣告投放過程中的一些異常問題，或者基于當前的投放效果去研究怎樣優化，從而達到更好的效果;
• 特征工程：廣告算法團隊主要是做一些模型訓練，用于支持線上投放。技術特征最初大部分是離線，隨著實時的發展，開始把一些工程轉到實時。

二、業務實踐

業務實踐主要分為兩類，第一個是實時數倉，第二個是特征工程。

1. 實時數倉

1.1 實時數倉 - 目標

實時數倉的目標包括數據完整性、服務穩定性和查詢能力。

• 數據完整性：在廣告業務里，實時數據主要是用于指導決策，比如廣告主需要根據當前投放的實時數據，指導后面的出價或調整預算。另外，故障率的監控需要數據本身是穩定的。如果數據是波動的，指導意義就非常差，甚至沒有什么指導意義。因此完整性本身是對時效性和完整性之間做了一個權衡；
• 服務穩定性：生產鏈包括數據接入、計算（多層）、數據寫入、進度服務和查詢服務。除此之外還有數據質量，包括數據的準確性以及數據趨勢是否符合預期；
• 查詢能力：在廣告業務有多種使用場景，在不同場景里可能使用了不同的 OLAP 引擎，所以查詢方式和性能的要求不一致。另外，在做數據分析的時候，除了最新最穩定的實時數據之外，同時也會實時 + 離線做分析查詢，此外還包括數據跨源和查詢性能等要求。

1.2 實時數倉 - 挑戰

• 數據進度服務：需要在時效性和完整性之間做一個權衡。
• 數據穩定性：由于生產鏈路比較長，中間可能會用到多種功能組件，所以端到端的服務穩定性對整體數據準確性的影響是比較關鍵的。
• 查詢性能：主要包括 OLAP 分析能力。在實際場景中，數據表包含了離線和實時，單表規模達上百列，行數也是非常大的。

1.3 廣告數據平臺架構

上圖為廣告數據平臺基礎架構圖，從下往上看：

• 底部是數據采集層，這里與大部分公司基本一致。業務數據庫主要包含了廣告主的下單數據以及投放的策略；埋點日志和計費日志是廣告投放鏈路過程中產生的日志；

• 中間是數據生產的部分，數據生產的底層是大數據的基礎設施，這部分由公司的一個云平臺團隊提供，其中包含 Spark / Flink 計算引擎，Babel 統一的管理平臺。Talos 是實時數倉服務，RAP 和 OLAP 對應不同的實時分析以及 OLAP 存儲和查詢服務。

  數據生產的中間層是廣告團隊包含的一些服務，例如在生產里比較典型的離線計算和實時計算。

  • 離線是比較常見的一個分層模型，調度系統是對生產出的離線任務做有效的管理和調度。
  • 實時計算這邊使用的引擎也比較多，我們的實時化是從 2016 年開始，當時選的是 Spark Streaming，后面隨著大數據技術發展以及公司業務需求產生了不同場景，又引入了計算引擎 Flink。
  • 實時計算底層調度依賴于云計算的 Babel 系統，除了計算之外還會伴隨數據治理，包括進度管理，就是指實時計算里一個數據報表當前已經穩定的進度到哪個時間點。離線里其實就對應一個表，有哪些分區。
  • 血緣管理包括兩方面，離線包括表級別的血緣以及字段血緣。實時主要還是在任務層面的血緣。
  • 至于生命周期管理，在離線的一個數倉里，它的計算是持續迭代的。但是數據保留時間非常長的話，數據量對于底層的存儲壓力就會比較大。
  • 數據生命周期管理主要是根據業務需求和存儲成本之間做一個權衡。
  • 質量管理主要包括兩方面，一部分在數據接入層，判斷數據本身是否合理；另外一部分在數據出口，就是結果指標這一層。因為我們的數據會供給其他很多團隊使用，因此在數據出口這一層要保證數據計算沒有問題。

• 再上層是統一查詢服務，我們會封裝很多接口進行查詢。

  • 因為數據化包括離線和實時，另外還有跨集群，所以在智能路由這里會進行一些選集群、選表以及復雜查詢、拆分等核心功能。
  • 查詢服務會對歷史查詢進行熱度的統一管理。這樣一方面可以更應進一步服務生命周期管理，另一方面可以去看哪些數據對于業務的意義非常大。
  • 除了生命周期管理之外，它還可以指導我們的調度系統，比如哪些報表比較關鍵，在資源緊張的時候就可以優先調度這些任務。
• 再往上是數據應用，包括報表系統、Add - hoc 查詢、數據可視化、異常監控和下游團隊。

1.4 實時數倉 - 生產鏈路

數據生產鏈路是從時間粒度來講的，我們最開始是離線數倉鏈路，在最底層的這一行，隨著實時化需求推進，就產生了一個實時鏈路，整理來說，是一個典型的 Lambda 架構。

另外，我們的一些核心指標，比如計費指標，因為它的穩定性對下游比較關鍵，所以我們這邊采用異路多活。異路多活是源端日志產生之后，在計算層和下游存儲層做了完全的冗余，在后面的查詢里做統一處理。

1.5 實時數倉 - 進度服務

上文介紹了我們要求提供出去的實時數據的指標是穩定不變的，進度服務實現的核心點包括時間窗口里指標的變化趨勢，同時結合了實時計算任務本身的狀態，因為在實時數倉里，很多指標是基于時間窗口做聚合計算。

比如一個實時指標，我們輸出的指標是 3 分鐘，也就是說 4：00 這個時間點的指標的就包括了 4：00～4：03 的數據，4：03 包括了 4：03～4：06 的數據，其實就是指一個時間窗口的數據，什么時候是對外可見的。因為在實時計算里，數據不斷進來， 4：00 的時間窗口的數據從 4：00 開始，指標就已經開始產生了。隨著時間疊加，指標不斷上升，最后趨于穩定。我們基于時間窗口指標的變化率，來判斷它是否趨于穩定。

但如果只是基于這個點來看，那么它還存在一定的弊端。

因為這個結果表的計算鏈會依賴很多個計算任務，如果這個鏈路上面哪個任務出現問題，可能會導致當前的指標雖然走勢已經趨于正常，但是最終并不完整。所以在這基礎之上，我們又引入了實時計算任務狀態，在指標趨于穩定的時候，同時去看生產鏈路上這些計算任務是否正常，如果是正常的話，表示任務本身時間點的指標已經穩定，可以對外提供服務。

如果計算有卡頓、堆積，或者已經有異常在重啟過程中，就需要繼續等待迭代處理。

1.6 實時數倉 - 查詢服務

上圖為查詢服務架構圖。

最下方是數據，里面有實時存儲引擎，包括 Druid 等。在離線中，數據在 Hive 里邊，但是在做查詢的時候，會把它們進行 OLAP 的同步，在這邊使用的是兩種引擎。為了和 Kudu 做 union 查詢，會把它同步到 OLAP 引擎，然后上面去統一使用 Impala 做查詢。另外，對于使用場景里比較固定的方式，可以導到 Kylin 里，然后在上面做數據分析。

基于這些數據，會有多個查詢節點，再上面是一個智能路由層。從最上面查詢網關，當有一個查詢請求進來，首先判斷它是不是一個復雜場景。比如在一個查詢里，如果它的時長同時跨越了離線和實時，這里就會同時使用到離線表和實時表。

另外，離線表里還有更復雜的選表邏輯，比如小時級別，天級別。經過復雜場景分析之后，就會把最終選擇的表大概確定下來。其實在做智能路由的時候，才會去參考左邊的一些基礎服務，比如元數據管理，當前這些表的進度到哪個點了。

對于查詢性能的優化，在數據里，底層掃描的數據量對最終性能的影響是非常大的。所以會有一個報表降維，根據歷史的查詢去做分析。比如在一個降維表包含哪些維度，可以覆蓋到百分之多少的查詢。

1.7 數據生產 - 規劃

之前在實時數據報表生產里提到，它主要是基于 API 的方式實現的。Lambda 架構本身有一個問題就是實時跟離線是兩個計算團隊，對于同一個需求，需要兩個團隊同時去開發，這樣會帶來幾個問題。

• 一方面是他們的邏輯可能會發生差異，最終導致結果表不一致；
• 另一方面是人力成本，同時需要兩個團隊進行開發。

因此我們的訴求是流批一體，思考在計算層是否可以使用一個邏輯來表示同一個業務需求，比如可以同時使用流或者批的計算引擎來達到計算的效果。

在這個鏈路里邊，原始數據通過 Kafka 的方式接入進來，經過統一的 ETL 邏輯，接著把數據放在數據湖里。因為數據湖本身可以同時支持流和批的方式進行讀寫，而且數據湖本身可以實時消費，所以它既可以做實時計算，也可以做離線計算，然后統一把數據再寫回數據湖。

前文提到在做查詢的時候，會使用離線跟實時做統一整合，所以在數據湖里寫同一個表，在存儲層面可以省去很多工作，另外也可以節省存儲空間。

1.8 數據生產 - SQL 化

SQL 化是 Talos 實時數倉平臺提供的能力。

從頁面上來看，它包括了幾個功能，左邊是項目管理，右邊包括 Source、Transform 和 Sink。

• 有一些業務團隊本身對于計算引擎算子非常熟，那么他們便可以做一些代碼開發；
• 但是很多業務團隊可能對引擎并不是那么了解，或者沒有強烈的意愿去了解，他們就可以通過這種可視化的方式，拼接出一個作業。

例如，可以拖一個 Kafka 的數據源進來，在上面做數據過濾，然后就可以拖一個 Filter 算子達到過濾邏輯，后面可以再去做一些 Project，Union 的計算，最后輸出到某個地方就可以了。

對于能力稍微高一些的同學，可以去做一些更高層面的計算。這里也可以實現到實時數倉的目的，在里面創建一些數據源，然后通過 SQL 的方式，把邏輯表示出來，最終把這個數據輸出到某種存儲。

上面是從開發層面來講，在系統層面上，它其實還提供了一些其他的功能，比如規則校驗，還有開發/測試/上線，在這里可以統一管理。此外還有監控，對線上跑的實時任務有很多實時指標，可以通過查看這些指標來判斷當前的任務是不是正常的狀態。

2. 特征工程

特征工程有兩方面的需求：

• 第一個需求是實時化，因為數據價值隨著時間的遞增會越來越低。比如某用戶表現出來的觀影行為是喜歡看兒童內容，平臺就會推薦兒童相關的廣告。另外，用戶在看廣告過程中，會有一些正/負反饋的行為，如果把這些數據實時迭代到特征里，就可以有效提升后續的轉化效果。

  實時化的另一個重點是準確性，之前很多特征工程是離線的，在生產環節里面存在計算時的數據跟投放過程中的特征有偏差，基礎特征數據不是很準確，因此我們要求數據要更實時、更準確。

• 特征工程的第二個需求是服務穩定性。

  • 首先是作業容錯，比如作業在異常的時候能否正?；謴?#xff1b;
  • 另外是數據質量，在實時數據里追求端到端精確一次。

2.1 點擊率預估

下面是在特征實時化里的實踐，首先是點擊率預估的需求。

點擊率預估案例的背景如上所示，從投放鏈路上來說，在廣告前端用戶產生觀影行為，前端會向廣告引擎請求廣告，然后廣告引擎在做廣告召回粗排/精排的時候會拿到用戶特征和廣告特征。把廣告返回給前端之后，后續用戶行為可能產生曝光、點擊等行為事件，在做點擊率預估的時候，需要把前面請求階段的特征跟后續用戶行為流里的曝光和點擊關聯起來，形成一個 Session 數據，這就是我們的數據需求。

落實到具體實踐的話包括兩方面：

• 一方面是 Tracking 流里曝光、點擊事件的關聯；
• 另一方面是特征流跟用戶行為的關聯。

在實踐過程中有哪些挑戰？

• 第一個挑戰是數據量；
• 第二個挑戰是實時數據亂序和延遲；
• 第三個挑戰是精確性要求高。

在時序上來說，特征肯定是早于 Tracking，但是兩個流成功關聯率在 99% 以上的時候，這個特征需要保留多久？因為在廣告業務中，用戶可以離線下載一個內容，在下載的時候就已經完成了廣告請求和返回了。但是后續如果用戶在沒有網的情況下觀看，這個事件并不會立馬返回，只有當狀態恢復的時候，才會有后續曝光和點擊事件回傳。

所以這個時候，其實特征流和 Tracking 的時間概括是非常長的。我們經過離線的數據分析，如果兩個流的關聯率達 99% 以上，那么特征數據就需要保留比較長的時間，目前是保留 7 天，這個量級還是比較大的。

上圖為點擊率預測的整體架構，剛才我們提到關聯包括兩部分：

• 第一個部分是用戶行為流里曝光跟點擊事件的關聯，這里通過 CEP 實現。
• 第二個部分是兩個流的關聯，前面介紹特征需要保留 7 天，它的狀態較大，已經是上百 TB。這個量級在內存里做管理，對數據穩定性有比較大的影響，所以我們把特征數據放在一個外部存儲 (Hbase) 里，然后和 HBase 特征做一個實時數據查詢，就可以達到這樣一個效果。

但是因為兩個流的時序本身可能是錯開的，就是說，當曝光、點擊出現的時候，可能這個特征還沒有到，那么就拿不到這個特征。所以我們做了一個多級重試隊列，保證最終兩個流關聯的完整性。

2.2 點擊率預估 - 流內事件關聯

上圖右邊是更細的講解，闡述了流內事件關聯為什么選擇 CEP 方案。業務需求是把用戶行為流里屬于同一次廣告請求，并且是同一個廣告的曝光跟點擊關聯起來。曝光之后，比如 5 分鐘之內產生點擊，作為一個正樣本，5 分鐘之后出現的點擊則拋棄不要了。

可以想象一下，當遇到這樣的場景，通過什么樣的方案可以實現這樣的效果。其實在一個流里多個事件的處理，可以用窗口來實現。但窗口的問題是：

• 如果事件序列本身都在同一個窗口之內，數據沒有問題；
• 但是當事件序列跨窗口的時候，是達不到正常關聯效果的。

所以當時經過很多技術調研后，發現 Flink 里的 CEP 可以實現這樣的效果，用類似政策匹配的方式，描述這些序列需要滿足哪些匹配方式。另外它可以指定一個時間窗口，比如曝光和點擊間隔 15 分鐘。

上圖左邊是匹配規則的描述，begin 里定義一個曝光，實現曝光之后 5 分鐘之內的點擊，后面是描述一個可以出現多次的點擊，within 表示關聯窗口是多長時間。

在生產實踐過程中，這個方案大部分情況下可以關聯上，但是在做數據對比的時候，才發現存在某些曝光點擊沒有正常關聯到。

經過數據分析，發現這些數據本身的特點是曝光跟點擊的時間戳都是毫秒級別，當它們有相同毫秒時間戳的時候，這個事件就不能正常匹配。于是我們采用一個方案，人為地對于點擊事件加一毫秒，進行人工錯位，這樣就保證曝光跟點擊能夠成功關聯上。

2.3 點擊率預估-雙流關聯

前文提到特征數據需要保留 7 天，所以狀態是上百 TB。需要把數據放在一個外部存儲里，因此在做技術選型時對外部存儲有一定的要求：

• 首先支持比較高的讀寫并發能力；
• 另外它的時效性需要非常低；
• 同時因為數據要保留 7 天，所以它最好具備生命周期管理能力。

基于以上幾個點，最終選擇了 HBase，形成上圖的解決方案。

上面一行表示通過 CEP 之后把曝光點擊序列關聯在一起，最下面是把特征流通過 Flink 寫到 HBase 里，去做外部狀態存儲，中間核心模塊是用于達到兩個流的關聯。拿到曝光點擊關聯之后去查 HBase 數據，如果能夠正常查到，就會把它輸出到一個正常結果流里。而對于那些不能構成關聯的數據，做了一個多級重試隊列，在多次重試的時候會產生隊列降級，并且在重試的時候為了減輕對 HBase 的掃描壓力，重試 Gap 會逐級增加。

另外還有一個退出機制，因為重試不是無限進行的。退出機制的存在原因主要包括兩個點：

• 第一點是特征數據保留了 7 天，如果對應特征是在 7 天之前，那么它本身是關聯不到的。
• 另外在廣告業務里，存在一些外部的刷量行為，比如刷曝光或刷點擊，但它本身并沒有真實存在的廣告請求，所以這種場景也拿不到對應特征。

因此，退出機制意味著在重試多次之后就會過期，然后會到重試過期的數據里。

2.4 有效點擊

在有效點擊場景里，其實也是兩個流的關聯，但是兩個場景里的技術選型是完全不一樣的。

首先看一下項目背景，在網大場景里，影片本身就是一個廣告。用戶在點擊之后，就會進入到一個播放頁面。在播放頁面里，用戶可以免費觀看 6 分鐘，6 分鐘之后想要繼續觀看，需要是會員或者購買才行，在這里需要統計的數據是有效點擊，定義是在點擊之后觀影時長超過 6 分鐘即可。

這種場景落實到技術上是兩個流的關聯，包括了點擊流和播放心跳流。

• 點擊流比較好理解，包括用戶的曝光和點擊等行為，從里面篩選點擊事件即可。
• 播放行為流是在用戶觀看的過程，會定時地把心跳信息回傳，比如三秒鐘回傳一個心跳，表明用戶在持續觀看。在定義時長超過 6 分鐘的時候，需要把這個狀態本身做一些處理，才能滿足 6 分鐘的條件。

在這個場景里，兩個流動 Gap 相對比較小，而在電影里時長一般是兩個多小時，所以點擊之后的行為，Gap 基本是在三個小時以內才能完成，因此這里本身的狀態是相對比較小的，使用 Flink 的狀態管理可以達到這樣的效果。

接下來我們看一個具體的方案。

從流上來看，綠色部分是點擊流，藍色部分是播放心跳流。

• 在左邊的狀態里面，一個點擊事件進來之后，會對這個點擊做一個狀態記錄，同時會注冊一個定時器做定期清理，定時器是三個小時。因為大部分影片的時長在三小時以內，如果這個時候對應的播放事件還沒有一個目標狀態，點擊事件基本就可以過期了。

• 在右邊的播放心跳流里，這個狀態是對時長做累計，它本身是一個心跳流，比如每三秒傳一個心跳過來。我們需要在這里做一個計算，看它累計播放時長是不是達到 6 分鐘了，另外也看當前記錄是不是到了 6 分鐘。對應 Flink 里的一個實現就是把兩個流通過 Connect 算子關系在一起，然后可以制定一個 CoProcessFunction，在這里面有兩個核心算子。

  • 第一個算子是拿到狀態 1 的流事件之后，需要做一些什么樣的處理；
  • 第二個算子是拿到第 2 個流事件之后，可以自定義哪些功能。

  算子給用戶提供了很多靈活性，用戶可以在里面做很多邏輯控制。相比很多的 Input Join，用戶可發揮的空間比較大。

2.5 特征工程 - 小結

針對以上案例做一個小結。現在雙流管理已經非常普遍，有許多方案可以選擇，比如 Window join，Interval join，還有我們使用的 Connect + CoProcessFunction。除此之外，還有一些用戶自定義的方案。

在選型的時候，建議從業務出發，去做對應的技術選型。首先要思考多個流之間的事件關系，然后判斷出狀態是什么規模，一定程度上可以從上面很多方案里排除不可行的方案。

三、Flink 使用過程中的問題及解決

1. 容錯

在 Flink 內部主要是通過 Checkpoint 做容錯，Checkpoint 本身是對于 Job 內部的 Task 級別的容錯，但是當 Job 主動或異常重啟時，狀態無法從歷史狀態恢復。

因此我們這邊做了一個小的改進，就是一個作業在啟動的時候，它也會去 Checkpoint 里把最后一次成功的歷史狀態拿到，然后做初始化管理，這樣就達到狀態恢復的效果。

2. 數據質量

Flink 本身實現端到端精確一次，首先需要開啟 Checkpoint 功能，并且在 Checkpoint 里指定精確一次的語義。另外，如果在下游比如 Sink 端，它本身支持事務，就可以結合兩階段提交與 Checkpoint 以及下游的事務做聯動，達到端到端精確一次。

在上圖右邊就是描述了這個過程。這是一個預提交的過程，就是 Checkpoint 協調器在做 Checkpoint 的時候，會往 Source 端注入一些 Barrier 數據，每個 Source 拿到 Barrier 之后會做狀態存儲，然后把完成狀態反饋給協調器。這樣每個算子拿到 Barrier，其實是做相同的一個功能。

到 Sink 端之后，它會在 Kafka 里提交一個預提交標記，后面主要是 Kafka 本身事務機制來保證的。在所有的算子都完成 Checkpoint 之后，協調器會給所有的算子發一個 ACK，發送一個確認狀態，這時候 Sink 端做一個提交動作就可以了。

3. Sink Kafka

在之前的實踐中我們發現，下游 Kafka 增加分區數時，新增分區無數據寫入。

原理是 FlinkKafkaProducer 默認使用 FlinkFixedPartitioner，每個 Task 只會發送到下游對應的一個 Partition 中，如果下游 Kafka 的 Topic 的 Partition 大于當前任務的并行度，就會出現該問題。

解決辦法有兩個：

• 第一個辦法是用戶自定義一個 FlinkKafkaPartitioner；
• 另一個辦法是默認不配置，默認輪詢寫入各個 Partition。

4. 監控加強

對于運行中的 Flink 作業，我們需要查看它本身的一些狀態。比如在 Flink UI 里面，它的很多指標都是在 Task 粒度，沒有整體的效果。

平臺這邊對這些指標做了進一步的聚合，統一在一個頁面里面展示。

從上圖可以看到，展示信息包括反壓狀態，時延情況以及運行過程中 JobManager 和 TaskManage 的 CPU / 內存的利用率。另外還有 Checkpoint 的監控，比如它是否超時，最近是否有 Checkpoint 已經失敗了，后面我們會針對這些監控指標做一些報警通知。

5. 監控報警

當實時任務運營異常的時候，用戶是需要及時知道這個狀態的，如上圖所示，有一些報警項，包括報警訂閱人、報警級別，下面還有一些指標，根據前面設置的指標值，如果滿足這些報警策略規則，就會給報警訂閱人推送報警，報警方式包括郵件、電話以及內部通訊工具，從而實現任務異常狀態通知。

通過這種方式，當任務異常的時候，用戶可以及時知曉這個狀態，然后進行人為干預。

6. 實時數據生產

最后總結一下愛奇藝廣告業務在實時鏈路生產上面的關鍵節點。

• 我們的實時是從 2016 年開始起步，當時主要功能點是做一些指標實時化，使用的是 SparkStreaming；
• 2018 年上線了點擊率實時特征；
• 2019 年上線了 Flink 的端到端精確到一次和監控強化。
• 2020 年上線了有效點擊實時特征；
• 同年10月，逐步推進實時數倉的改進，把 API 生產方式逐漸 SQL 化；
• 2021 年 4 月，進行流批一體的探索，目前先把流批一體放在 ETL 實現。

之前我們的 ETL 實時跟離線是分別做的，通過批處理的方式，然后換到 Hive 表里邊，后面跟的是離線數倉。在實時里，經過實時 ETL，放到 Kafka 里邊，然后去做后續的實時數倉。

先在 ETL 做流批一體的第一個好處是離線數倉時效性提升，因為數據需要做反作弊，所以我們給廣告算法提供基礎特征的時候，反作弊之后的時效性對于后續整體效果的提升是比較大的，所以如果把 ETL 做成統一實時化之后，對于后續的指導意義非常大。

ETL 做到流批一體之后，我們會把數據放在數據湖里面，后續離線數倉和實時數倉都可以基于數據湖實現。流批一體可以分為兩個階段，第一階段是先把 ETL 做到一體，另外報表端也可以放在數據湖里邊，這樣我們的查詢服務可以做到一個更新的量級。因為之前需要離線表跟實時表做一個 Union 的計算，在數據湖里面，我們通過離線和實時寫一個表就可以實現了。

四、未來規劃

關于未來規劃：

• 首先是流批一體，這里包括兩個方面：

  • 第一個是 ETL 一體，目前已經是基本達到可線上的狀態。
  • 第二個是實時報表 SQL 化和數據湖的結合。
• 另外，現在的反作弊主要是通過離線的方式實現，后面可能會把一些線上的反作弊模型轉成實時化，把風險降到最低。

原文鏈接：https://developer.aliyun.com/article/786120?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的Flink 在爱奇艺广告业务的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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