Flink Forward Asia 2022 主論壇概覽

2022 年 11 月 26-27 日，Flink Forward Asia(FFA)峰會成功舉行。Flink Forward Asia 是由 Apache 軟體基金會官方授權、由阿里雲承辦的技術峰會，是目前國內最大的 Apache 專案會議之一，也是 Flink 開發者和使用者的年度盛會。由於疫情原因，本屆峰會仍採用線上形式。此外，本次峰會上還舉行了第四屆天池實時計算 Flink 挑戰賽的頒獎儀式，4346 支參賽隊伍中共有 11 支隊伍經過層層角逐脫穎而出，最終收穫了獎項。

FFA 大會照例總結了 Apache Flink 過去一年的發展情況。2022 年，Apache Flink 社群繼續保持快速發展：Github Star 數突破 2 萬;程式碼貢獻者總人數超過 1,600 人;單月下載量突破 1,400 萬次。其中，Apache Flink 中文社群的發展尤為蓬勃：據 ossinsight.io 統計截至目前 Apache Flink 專案所有 PR 中有 45% 來自中國開發者;由 Apache 軟體基金會授權、Apache Flink PMC 管理的官方微信公眾號，2022年 共釋出了 130+ 篇技術分享文章，累計訂閱使用者數突破 6 萬;新開通的微信影片號釋出了36 篇影片，目前已有近 4,000 訂閱使用者。

我們欣喜地看到，Apache Flink 已成為實時流計算全球範圍事實標準。Flink 憑藉強大的實時化大資料計算能力，與眾多開源社群生態專案的強強聯合，形成了實時大屏展示、實時資料整合、實時湖倉分析、實時個性化推薦、實時風控監控等一系列實時化大資料場景的解決方案，成為了推動各行各業資料分析實時化升級的核心推動力。

本文接下來將對本次 FFA 峰會主論壇幾個 Keynotes 議題進行簡單的歸納總結，感興趣的小夥伴可以到官網 觀看大會全部議題的影片回放。

雲與開源，共植數字世界的根

在 Keynotes 議題開始之前，阿里巴巴集團副總裁、阿里巴巴開源技術委員會負責人、阿里雲智慧計算平臺負責人賈揚清老師作為開場嘉賓，分享了他對雲與開源關係的理解。

在產業數字化、數字產業化的今天，雲和開源已經共生、共長、共築了一個數字世界的根。開源與商業化如何更好地結合，我們認為雲是其中最重要的一環。云為開源軟體的部署和獲取提供了更好的環境，在雲提供的彈性環境中，使用者可以一鍵獲得開源軟體與平臺的能力。雲和開源軟體的共生，也使得使用者能有更加廣闊和靈活的選擇，每個人都能夠尋找到最適合的開源軟體組合來解決自身業務問題。在這個發展的過程中，逐漸形成了雲原生的概念。

在過去的十幾年中，阿里巴巴一直是開源軟體和社群的堅定擁護者和實踐者，形成了“三位一體”的策略：開源社群的技術、阿里巴巴內部應用的技術以及在阿里雲上透過商業化形式提供給客戶的技術是統一的。開源提供了非常好的使用者體驗，在阿里巴巴這樣的大規模場景中能夠產生很多個性化或系統化的需求，二者的關注點形成互補。阿里巴巴將自己的實踐貢獻回開源社群，使得社群的易用性與大規模企業所使用的穩定性、彈效能夠很好地結合。

以 Apache Flink 為例，阿里巴巴在 2016 年開始採用 Flink 作為內部實時計算的一條技術路線，並基於 Flink 建設了 Blink 這樣一個內部體系。從 16 年開始，我們逐漸將 Blink 貢獻回社群，至 18 年已成為 Flink 社群最大的貢獻者。今天我們欣喜地看到，Apache Flink 專案管理委員會中有 1/4 的成員來自阿里巴巴，透過阿里巴巴的推動以及整個社群的合作，Flink 已經被中國絕大多數的網際網路企業作為流計算的事實標準來採用，Flink 也連續兩年蟬聯 Apache 社群最活躍專案。

今天雲與開源的迭代，也使得人們在開源軟體的方向上有了新的探索。以 Flink 為例，最初是一個以 Java API 實現流計算的平臺，在阿里巴巴內部及阿里雲上的應用中逐漸生長出了像 SQL 這樣的能力。近幾年，阿里巴巴也在根據自身使用 Flink 的需求不斷探索新的方向，例如在資料整合方向發展非常快的 Flink CDC 專案、和機器學習結合的 Flink ML 專案、與傳統數倉相結合的流式數倉概念以及在此概念下推出的 Flink Table Store 專案等。此外，在整個大資料領域也有很多共性的技術，例如大規模分散式計算在存算分離環境中的 Remote Shuffle Service，在 Flink、Spark、Hive 等引擎中都有類似的需求。我們也很高興地向大家宣佈，阿里雲已經將自身雲場景中孕育的 Remote Shuffle Service 專案捐獻給了 Apache 軟體基金會，命名為 Apache Celeborn。

阿里巴巴不僅是開源軟體的受益者，同時也是貢獻者。開源已經成為阿里巴巴工程師文化中不可或缺的一部分，越來越多的工程師在開源社群汲取知識，在積極地參與開源軟體和社群建設，同時也在適當的時候將我們自己建設的專案貢獻給開源社群。我相信在未來我們會繼續和開源社群一起，基於雲這樣一個底座，給使用者提供更加容易觸達和使用軟體的平臺和方式，同時以我們和社群的技術實力共同建設更加繁榮的開源社群。

Flink Towards

Streaming Data Warehouse

主論壇 Keynotes 議題照例由 Apache Flink 中文社群發起人、阿里雲開源大資料平臺負責人王峰老師開啟，介紹了 Apache Flink 社群在 2022 年取得的主要技術創新與成果，以及未來的發展方向。

Apache Flink 2022 - 資料實時化技術創新不止

2022 年，Apache Flink 釋出了兩個大版本。在 Flink 1.15 版本中，社群集中解決了許多長期存在的歷史難題，包括 SQL 作業的跨版本升級、狀態快照的所屬權語義與生命週期管理、跨資料來源的 Watermark 進度同步、批作業自適應運算元併發設定等。在 Flink 1.16 版本中，社群進行了更多新的創新與嘗試，包括分散式一致性快照架構升級、創新流批自適應融合 Shuffle、基於非同步與快取技術的流式 SQL 維表 Join 改進、完整相容 Hive 生態、PyFlink 功能及效能全面生產可用等。

■ 分散式一致性快照架構全新升級

Apache Flink 作為一款有狀態的流式計算引擎，分散式一致性快照是其非常核心的一項技術。Flink 在流計算過程中，定期對狀態做快照並持久化，當作業出現異常時可以從最近一次快照進行恢復，以保證業務連續性。因此，能夠以更高的頻次、更低的成本進行快照，讓業務更加流暢，是 Flink 使用者的共同訴求。然而在真實生產環境中，特別大規模複雜生產環境中，分散式一致性快照面臨著諸多挑戰：一方面在反壓狀態下，網路緩衝擁塞，用於做分散式快照的 Barrier 無法沿資料流向下傳輸，無法及時觸發快照;另一方面，即使能觸發快照，需要持久化到遠端儲存系統的本地狀態資料的資料量和上傳時間均不可控。上述原因導致使用者時常遇到無法在規定時間內生成分散式快照的情況，嚴重影響業務的穩定性。

針對上述問題，Flink 在最近幾個版本中對整個分散式一致性快照架構進行了全方面的升級，主要內容包括：

Unaligned Checkpoint：當 Barrier 對齊時間達到一定閾值後，自動轉化為 Unaligned Checkpoint，兼顧 Checkpoint 的資料量與 Barrier 對齊時間。

Buffer Debloating：只快取下游運算元 1s 內可以處理的資料量，在避免網路傳輸影響運算元效能的前提下，最大限度降低運算元間快取的資料量。

Log-based Checkpoint：狀態表與增量日誌解耦，非同步上傳，大幅降低生成快照的成本。

隨著上述技術在 Flink 1.16 落地，Flink 形成了新一代的分散式一致性快照架構。

■ 面向雲原生的新一代狀態儲存管理體系

雲原生時代已經到來，各個基礎軟體專案都需要考慮如何去適應這樣一個時代，Apache Flink 也不例外。對於 Flink 而言，雲原生時代帶來的最顯著的變化是對於資源彈性擴縮容的訴求，這要求 Flink 作業的併發度能夠隨著業務量和資源不斷改變。在併發度改變時，Flink 的狀態儲存也需要快速地重新分配，即狀態儲存的分裂與合併。因此，Flink 狀態儲存的分裂、合併效能，直接關係到 Flink 彈性擴縮容的體驗。

在 Flink 1.16 版本中，社群對 RocksDB State Backend 的狀態重建演算法進行了大量最佳化，取得了 2-10 倍的效能提升，使得 Flink 的彈性擴縮容更加平滑、更加適應雲原生時代。

此外，社群還計劃將 Flink 狀態儲存管理體系進一步升級為徹底的存算分離架構，以適應雲原生環境。目前 Flink 的狀態儲存管理體系並非真正的存算分離架構，所有狀態資料依然儲存在本地 RocksDB 例項中，只有在分散式快照時將增量資料複製到遠端儲存，保證遠端儲存中存有全量的狀態資料。未來，Flink 的狀態資料將全部原生於遠端儲存之上，本地磁碟與記憶體只用作快取加速，形成分層儲存體系，我們稱之為分層狀態儲存(Tired State Backend)架構。

■ 流批融合的 Hybrid Shuffle 創新技術

流批一體、流批融合是 Apache Flink 非常有特色的一個技術理念，而 Shuffle 則是分散式計算系統中一項非常核心的、與效能高度相關的技術。Flink 1.16 創新推出了流批融合的 Hybrid Shuffle 技術。

在此之前，Apache Flink 在流模式和批模式下分別採取了兩種不同的 Shuffle 技術：

流式 Pipelined Shuffle：上下游任務透過網路直接連線，資料透過記憶體和網路進行傳輸，無需磁碟 IO，效能更好。

批式 Blocking Shuffle：上游任務先將中間資料寫到磁碟或其他儲存服務，下游再從磁碟或儲存服務讀取中間資料，需要磁碟 IO，效能稍差。

那麼能否將流式 Shuffle 也應用在批執行模式下，加速批的 Shuffle 呢?從技術本身來說是可以的，但在生產環境下會面臨比較大的約束。流式 Shuffle 要求所有彼此聯通的任務同時拉起，這就需要更多的資源，而在生產環境下是否能有這麼多資源是無法保證的，甚至可能會有死鎖的情況發生。如果能只在資源充足的情況下將彼此聯通的任務同時拉起進行流式 Shuffle 加速，同時在資源不足的情況下退化為批式 Shuffle，就可以更加合理地利用資源來進行 Shuffle 的加速。這也就是 Hybrid Shuffle 的背景和思路。

Flink 1.16 中完成了第一版 Hybrid Shuffle，初步評測相比傳統的 Blocking Shuffle 取得了不錯的效能提升。在後續版本中，社群也會對這項技術做進一步的完善與最佳化。

■ Flink CDC 全增量一體化資料同步

Flink CDC，即基於 Apache Flink 的全增量一體化資料同步技術，是近兩年提出的一個新概念。

為什麼要基於 Flink 打造一款全增量一體化資料同步引擎?Flink 本質上是一款流式分散式計算引擎，事實上已經成為連線不同儲存的資料管道。Flink 擁有豐富的 Connector 生態能夠連線各種主流儲存系統，具有優秀的分散式架構支援分散式快照、流批融合等機制，這些都是一款全增量一體資料整合引擎所需要的特性。因此，基於 Flink 打造全增量一體化資料同步引擎是非常適合的，這也就是 Flink CDC 專案的由來。

去年我們推出了 Flink CDC 1.0，得到了來自開發者生態非常好的反饋。因此今年我們加大投入，推出了更加成熟完善的 Flink CDC 2.0。Flink CDC 2.0 的主要特性包括：

通用的增量快照框架抽象，降低了新資料來源的接入成本，使 Flink CDC 能夠快速接入更多的資料來源。

支援高效能的並行讀取。

基於 Flink 的分散式快照機制，實現資料同步的斷點續傳，提高可靠性。

對資料來源全程無鎖，資料同步對線上業務無任何影響。

Flink CDC 創新專案成長非常迅速，正在成為新一代資料整合引擎。目前 Flink CDC 已支援了包括 MySQL 家族、PolarDB、Oracle、MongoDB 等主流資料庫且接入了增量快照框架，另外還支援了像 DB2、SQLServer、PostgreSQL、TiDB、OceanBase 等耳熟能詳的資料庫，相信今後也會有更多的資料來源接入 Flink CDC 框架。該專案也獲得了開源生態中開發者們的一致好評，Github Star 數已經超過 3,000。

■ 新一代迭代計算框架助力 Flink ML-2.0

在老版本的 Flink 中有一個 Flink ML 模組，是一套基於 DataSet API 實現的機器學習演算法庫。隨著 Flink 基礎 API 層全部統一到流批一體的 DataStream API，原本的 Flink ML 模組也和 DataSet API 一同被廢棄了。今年，Flink 社群基於 DataStream API 重新建設 Flink ML 成為一個新的子專案，目前已經發布了兩個版本。

眾所周知，機器學習演算法庫運算的核心是迭代計算框架。Flink ML 2.0 基於 Flink DataStream API 重建了一套流批一體的迭代計算框架，能夠支援無限流上的線上訓練、訓練中斷恢復以及高效能的非同步訓練。Flink ML 2.0 仍處於起步階段，第一批數十種演算法已經由阿里雲實時計算和機器學習團隊完成了貢獻，能夠覆蓋常見的特徵工程場景，支援低延遲的近線推理計算。期待未來有更多公司和開發者能夠參與進來，為 Flink ML 貢獻更多經典的機器學習演算法，讓 Flink 優秀的計算能力在機器學習場景中發揮更大的作用。

Apache Flink Next - Streaming Data Warehouse

在去年的 FFA 峰會上，我們提出了 Apache Flink 社群下一步技術演進的方向——Streaming Data Warehouse。

我們首先來回顧一下 Flink 歷史上核心技術理念演進的過程，這有助於理解為什麼我們認為 Streaming Data Warehouse 是 Flink 下一步的演進方向。

Stateful Streaming：Flink 在誕生之初，能夠受到開發者的青睞，取代上一代流式計算引擎 Storm，成為新一代流式計算引擎，關鍵在於其有狀態的流計算這一定位。透過將流計算與狀態儲存有機融合，Flink 可以在保持高吞吐低延遲的同時，在框架層支援有狀態流計算的精準資料一致性。

Streaming SQL：早期 Flink 開發必須寫 Java 程式，使得 Flink 專案在快速發展幾年之後遇到了推廣門檻過高的瓶頸。在資料分析師的世界裡，事實標準的語言是 SQL。於是在 2019 年，阿里雲將內部積累的 Blink SQL 貢獻給了 Flink 社群，大幅降低了 Flink 的開發門檻，使得 Flink 在各行各業的應用得到了爆炸式的增長。

Streaming Data Warehouse：Flink 的流批一體 SQL 能夠實現計算層全量增量開發一體化的體驗，但無法解決儲存層割裂的問題。流式儲存中的資料很難對其進行查詢分析，而批式儲存中資料的時效性又比較差。因此，我們認為下一階段 Flink 社群新的機會點就在於繼續提升一體化體驗，透過流批一體 SQL + 流批一體儲存構建一體化體驗的流式數倉。

Flink 社群推出的全新子專案 Flink Table Store，其定位就是實現流批一體的儲存能力，能夠實現高效能的流讀、流寫、批讀、批寫。Flink Table Store 的設計遵循存算分離理念，資料存放在主流的雲端儲存之上，其核心儲存格式由 LakeStore 和 LogStore 兩部分組成。LakeStore 應用了經典的 LSM、ORC 及其他索引技術，適合大規模、高效能的資料更新與讀取。LogStore 提供了完整 CDC 語義的 ChangeLog，配合 Flink Streaming SQL 可以增量訂閱 Table Store 進行流式資料分析。此外，Flink Table Store 採用開放的資料格式體系，除了預設對接 Flink 之外，也可以對接 Spark、 Hive、Trino 等主流開源計算引擎。

Flink Table Store 誕生一年來，共推出了兩個版本，完成了從 0 到 1 的孵化落地。目前除了阿里雲之外，也有來自位元組跳動等公司的開發者在參與共建和試用。我們對 Flink Table Store 和目前主流的資料湖儲存 Hudi 進行了效能對比，結果顯示 Flink Table Store 的更新效能明顯領先 Hudi，查詢效能明顯領先 Hudi MOR 模式、接近 Hudi COW 模式，綜合表現更佳。

Apache Flink 實時計算在美的多業務場景下的應用與實踐

第二場 Keynotes 議題是由美的集團實時資料負責人、資深資料架構師董奇老師帶來的，她從家電行業的視角分享了 Apache Flink 實時計算在美的傳統及新興業務場景的應用與實踐。

董奇老師首先介紹了實時生態體系在美的的發展和建設現狀。美的的實時數倉體系建設主要圍繞時效性、穩定性、靈活性三個要素。時效性方面，設計了以 Flink 為核心的時效性保障架構;穩定性方面，包括開發階段針對資料來源連通性、後設資料引數格式等的一系列校驗和執行階段的叢集資源、任務狀態等監控告警;靈活性方面，包括統一的後設資料、UDF、Connector 等資源管理和對任務模板、公用邏輯等任務管理功能的支援。

Flink 在美的核心傳統業務場景的數字化轉型中發揮了重要的作用，董奇老師分享了其中三個場景。

B 端長週期場景：具體業務場景包括美雲銷 App 看板和全鏈路訂單可視。傳統行業的採購、營銷、庫存分析以及長週期訂單的跟蹤，都需要對過去很長一段時間的資料進行回溯，這對實時計算的挑戰是比較大的。在我們的架構中，歷史全量資料是透過 Flink 自動載入 Hive 分割槽表來引入的，與 Kafka 增量資料相結合，做進一步計算加工。

工廠生產進度：工廠的管理人員和員工可以透過實時大屏看到每個小時的生產進度，對於更好地完成每天的生產任務具有很大的實用價值。

搶單活動大屏：面向代理商、運營商、零售商的搶單活動，涉及到價格、供貨、新品首發等方面的權益，是非常關鍵的。活動現場的實時大屏對於指導運營人員調整運營策略、代理商和零售商開展零售和搶單活動具有重要意義。

在美的新興業務場景中，同樣有許多基於 Flink 的實時數字化應用實踐，在這方面董奇老師也分享了三個場景。

家居裝置實時智慧調控：冰箱雲管家、洗地機雲管家、電熱雲管家等產品都具有分析使用者行為、調整控制智慧家電行為以達到節能節水目的的功能。Flink 消費 Kafka 中的裝置資料，與 Redis / HBase 使用者、產品、第三方資料以及演算法模型、規則相關聯，將結果再寫出到 Kafka 中，最終透過 IoT 雲完成裝置指令的下發。此外，在這套鏈路中 Flink 還承擔了實時監控的職能。

HI 服務實時訊息推送：智慧家居產品除了自動調控功能之外，還有許多需要透過人機互動、人為操控完成的功能，例如故障提醒、完成提醒、耗材提醒等。這套鏈路與家居裝置實時智慧調控很像，只是最終的資料會寫出到第三方的推送平臺。

電商活動監控大屏：業務資料化，將運營人員手工收集錄入的業務資料落入資料庫，透過 CDC 技術捕捉增量變化資料，再由 Flink 進行加工，透過 StarRocks + QuibkBI 搭建實時大屏，以供快速直觀的運營決策。

董奇老師指出，美的集團接下來的實時生態體系建設將重點圍繞降本提效與工具賦能，包括雲原生部署、熱點均衡、任務報錯根因與修復提示等基礎運維能力，以及平臺與業務側的視覺化配置整合工具、細粒度資源配置、流批一體實踐等。

Apache Flink 在米哈遊的應用實踐

接下來是來自米哈遊大資料實時計算團隊負責人張劍老師的分享。

張劍老師首先介紹了 Flink 在米哈遊的發展歷程和平臺建設情況。米哈遊實時計算平臺建立之初就選擇了 Apache Flink，這是基於 Flink 毫秒延遲、視窗計算、狀態儲存、容錯恢復等優異特性以及背後蓬勃發展的社群。最初的實時計算平臺是完全基於 Flink DataStream API 的，初步具備任務的管理與運維能力。隨著業務的增長，米哈遊實時計算平臺在 2020 年開始邁入高速發展階段，著手打造以 SQL 為主的一站式開發平臺，推進了多雲跨區域的任務管理、SQL 及聯結器、指標和日誌體系、後設資料和血緣等能力的建設，大大提高了研發效率。今年，米哈遊實時計算平臺開始朝著新的目標邁進，著手推進一站式開發平臺的功能深化與場景覆蓋，包括靜態和動態調優、自動擴縮容、資源彈性、近實時數倉等能力的建設。

在應用方面，張劍老師分享了米哈遊內部四個重要的應用場景。

全球遊戲日誌標準化採集加工：Flink 承擔著米哈遊全遊戲業務每天近百億的日誌處理，峰值流量過千萬。透過 Filebeat 採集和日誌上報服務接收到的日誌傳輸到 Kafka 實時資料匯流排，經過 Flink SQL 處理加工，寫入下游 Clickhouse、Doris、Iceberg 等儲存，提供給客服查詢系統、運營實時分析、離線數倉等應用場景。

實時報表及實時大屏：我們會根據業務需求，對重要的指標提供實時大屏服務，同時針對運營基於 BI 報表提供實時指標的應用檢視。在社群帖子排序的場景中，資料來源一是客戶端埋點上報到 Kafka，二是透過 Flink CDC 抓取業務庫的增量資料。為了不引入額外的 KV 儲存，同時解決維表更新不及時導致關聯失敗的問題，我們將 Flink 流式消費 Kafka 的任務和 Flink CDC 抓取業務庫的任務合併成了同一個任務，採用 RegularJoin 進行關聯。這裡我們對 Flink SQL 進行了擴充，能夠控制底層狀態細化的生存週期，避免維表狀態過期。關聯後的資料再經過指標計算，提供給帖子排序服務。

近實時數倉：我們透過 Flink SQL 實時寫入 Iceberg 的方式，實現了日誌離線入倉近實時化，資料入倉時效從小時級縮短到了分鐘級，離線儲存 IO 的波動性也平穩了很多。透過 Flink CDC 對 MySQL 資料庫進行全量、增量的同步，結合平臺的一鍵任務生成、自動調優擴縮容、自動提交執行等能力，實現了資料庫一鍵入湖，大幅提高了開發效率、降低了對資料庫的壓力。近實時數倉的一個典型應用場景是玩家戰績查詢。

實時風控：在米哈遊，風控團隊和實時計算團隊聯絡密切。風控團隊提供了良好的風控引擎，實時計算團隊基於風控引擎構建了一套相對自動化的 API 及任務管理方式，讓實時計算平臺服務化。具體的應用場景包括登入校驗、遊戲反作弊、人機校驗等。

張劍老師介紹，米哈遊在實時計算領域未來的工作主要包括三個方面：一是平臺能力建設，包括 Flink SQL、資源調優、自動化運維、資源彈性等;二是使用場景的探索，比如延遲訊息服務、基於 Flink CDC 的 Binlog 服務、應用級別指標服務等;三是資料湖和 TableStore 的不斷實踐，包括流批一體與近實時數倉的實踐與探索。

Disney 流媒體廣告 Flink 的應用實踐

最後一場 Keynotes 議題是由 Disney 廣告智慧執行總監郝又超老師和 Disney 廣告智慧實時計算負責人李丁哲老師聯合帶來的。

郝又超老師首先介紹了 Disney 流媒體廣告業務。Hulu 作為美國本土頭部的流媒體平臺，最早是由 Disney、Fox、NBC 共同發起成立的。隨著 2019 年對 Fox 的收購，Disney 得到了 Hulu 的運營控制權與廣告平臺的優質資源，開始發力線上流媒體，陸續推出 Disney+、ESPN+、Star+ 等品牌。目前，Disney 流媒體在全球有 2.35 億訂閱使用者(以家庭為單位)，已超過 Netflix。Hulu是當前 Disney 流媒體廣告業務的主要來源，每天投放數億15秒、30秒長的影片廣告，而每選擇一個廣告都會產生幾十甚至上百個事件，對資料平臺有著極高的挑戰，隨著Disney+上12月份即將上線廣告，這種挑戰預期將數倍增長。Disney 流媒體廣告資料平臺分為資料演算法和應用服務兩層，其中 Apache Flink 主要應用於資料演算法層，對運營資料中的關鍵指標做實時聚合。

接下來，李丁哲老師分享了 Disney 流媒體廣告資料平臺中實時資料部分的具體情況。在實時鏈路中，從系統及使用者側收集到的資料，由 Flink 進行統一的流式計算，計算出的指標透過資料介面暴露給業務平臺、運維平臺、廣告伺服器等。在離線鏈路中，使用 Spark 生成離線報表和對外資料輸出，使用 Flink 進行指標回填等處理。

李丁哲老師還分享了 Disney 流媒體廣告使用 Flink 的三個實時應用場景。

廣告決策漏斗：廣告決策是一個複雜的過程，需要從龐大的廣告池中，透過粗排、精排以及一系列過濾條件，選擇出最適合使用者的廣告。為了對這個複雜的過程進行錯誤排查，我們將其抽象成漏斗模型，對廣告的投放機會、定向成功與否、是否被過濾、最終是否投放成功、投放失敗原因等資訊進行展示。我們使用 Flink 將從廣告伺服器獲取到的決策資訊進行解碼、關聯，還原出決策漏斗並交由前端展示。在離線鏈路中我們實踐了 Flink 的流批一體，使用同一套程式碼在實時資料出現問題時進行糾錯與資料回填。

廣告曝光監控：廣告主通常會提出一些廣告投放的要求，比如針對特定人群投放、限制同使用者同時間段內的投放次數、避免和競品廣告同時出現等。針對這些需求，我們研發了廣告曝光監控平臺，讓廣告主可以檢視其廣告投放的相關資訊。在這個場景中，我們使用 Flink 對來自廣告系統和客戶端的上下文資訊和使用者行為進行關聯和維度增強，生成一系列的事實指標，並基於特定規則計算出更多衍生指標。

廣告系統大屏：面相管理層與業務方，提供關於廣告系統與廣告投放情況的全域性洞察能力。來自事實資料來源的資料，經過 Flink 的處理，透過指標介面暴露出來，再根據不同的業務規則進行聚合，最終投放給前端做大屏展示。

李丁哲老師介紹，Disney 流媒體廣告的實時資料平臺搭建在雲上，部署在 Kubernetes 容器編排系統上，使用 Flink Operator 管理 Flink 叢集，實踐了 Gang Scheduler、流批作業混部、基於佇列的彈性擴縮容等技術。

在議題的最後，郝又超老師分享了 Flink 未來在 Disney 流媒體廣告平臺上的一些應用場景規劃，包括全流批一體、OLAP、實時歸因、流式機器學習等。

總結

本次大會上，我們欣喜地看到 Apache Flink 社群仍在持續繁榮地向前發展：社群建設方面，全球與中文社群規模與活躍度均屢創新高;技術成長方面，狀態、容錯、Shuffle、資料整合、機器學習等方向都在持續創新，面向未來流式數倉的流批一體儲存 Flink Table Store 也取得了喜人的進展;行業應用方面，正有越來越多不同行業的公司加入到 Flink 生產實踐的隊伍中，將技術積累與新的需求源源不斷地回饋到社群。讓我們共同期待 Apache Flink 越來越好~

Flink Forward Asia 2022

本屆 Flink Forward Asia 更多精彩內容，可點選閱讀原文或掃描圖片二維碼觀看全部議題的影片回放及獲取 FFA 2022 峰會資料!