Flink 在米哈遊的應用實踐

ApacheFlink發表於2022-12-26

摘要：本文整理自米哈遊大資料實時計算團隊負責人張劍，在 FFA 的分享，本篇內容主要分為三個部分：

  1. 發展歷程和平臺建設
  2. 場景應用實踐
  3. 未來展望

點選檢視直播回放 & 演講PPT

一、發展歷程和平臺建設

米哈遊成立於 2011 年，致力於為使用者提供高品質、超出預期的產品和服務。公司陸續推出多款人氣產品，如崩壞學園 2、崩壞 3、未定事件簿、原神以及社群產品米遊社等。

1

隨著公司的快速發展，實時計算需求應運而生。我們基於 Flink 計算引擎構建了實時計算平臺。依據需求及主要工作的不同劃分為三個階段。

第一階段，以 Datastream API 開發為主的 Flink 平臺。第二階段，以 Flink SQL 為主的一站式開發平臺。第三階段，一站式開發平臺的功能深化和場景覆蓋。

2

為什麼選擇 Flink？首先是基於 Flink 框架優異的特性，如毫秒延遲、視窗計算、狀態管理、容錯恢復。同時蓬勃發展的社群，對 Flink 的引入充滿信心。

3

1.0 階段主要是以 Datastream API 開發為主，初步具備了任務管理以及運維能力。但隨著開發人員增多，基於 Datastream API 開發弊端稍加顯現，如開發難度大，版本易衝突、運維難度大等。

2.0 階段為了解決大家的問題，構建了以 Flink SQL 為主的一站式開發平臺，主要基於 Flink 1.10 和 1.12。平臺的主要工作主要分為如下四個方面：

  1. 加強多雲跨區域任務管理能力的建設。
  2. 增強 Flink SQL 能力以及豐富上下游聯結器。
  3. 構建指標和日誌體系。
  4. 完善後設資料以及任務血緣的管理。

基於一站式開發平臺較大的提高了大家的開發效率。截止目前，Flink SQL 佔比總任務數達 90%以上。

4

隨著業務的發展，大家提出了新的期望。總結起來有如下幾點：

  1. 越來越多的同學加入，對任務的調優和調參方面希望能夠降低成本。
  2. 部分業務的流量波動性較大，希望能有任務的自動擴縮容管理機制。
  3. 部分常見的 ETL 任務，用 Flink SQL 開發也有較大的成本，希望能夠基於配置生成 Flink 任務。
  4. 對資料的時效性有了新的期望，希望資料入倉能夠分鐘可查，或者基於近實時數倉開發。

基於此，3.0 階段主要是一站式平臺開發功能深化和場景覆蓋。我們思考的方向主要有如下四個方面：

  1. 靜態和動態資源調優。
  2. 自動擴縮容。
  3. 資源彈效能力。
  4. 加強近實時數倉的建設。

靜態資源調優指使用者開發完一個任務，依據其基本的業務邏輯及探測當前時刻的任務流量，結合本身任務的設定來給定初始資源，同時最佳化一些不合理的選項，避免使用者反覆除錯。動態調優指一個任務已經上線執行。根據作業收集的指標資訊，不斷調整任務的資源，來滿足任務的正常執行，避免反壓及流量波動所帶來的影響。從中可以看出，動態調優需要平臺具備自動擴縮容的管理機制。而自動擴縮容的管理機制又對底層資源的彈性具有一定的要求。

5

平臺的整體架構，主要分三個部分：

  1. 使用者許可權及鑑權。
  2. 功能和服務。主要包含：概覽大盤、作業開發、版本管理、作業運維、作業日誌、後設資料及血緣、監控告警、資源調優、自動擴縮容、彈性資源管理、安全管控。
  3. 資源和環境。主要包含：多元環境執行端、資源管理器、跨雲跨區域的環境管理。

6

二、場景應用實踐

第一個重要的應用場景是全球遊戲日誌標準化採集加工。眾所周知，日誌處理是大資料處理的重要方面，有些日誌的重要性不亞於資料庫裡的資料。Flink 承擔著公司全球遊戲業務每天近百億的日誌處理，峰值流量過千萬。依據採集方式的不同將資料來源分為兩大類。

  1. 透過 Filebeat 的採集。
  2. 透過日誌上報服務接收之後傳輸到 Kafka 實時資料匯流排。

經過 Flink SQL 處理、加工、寫入下游的儲存，比如 Clickhouse、Doris、Iceberg。同時，我們會對採集、加工、處理等環節的資料延遲和資料質量加以監控和校正。提供給下游的業務，比如客服查詢系統、運營實時分析、離線數倉等。

7

第二個應用場景是實時報表和實時大屏。放到一起是因為它們通常會涉及到聚合指標的計算。我們針對重要的指標，根據業務需求提供實時大屏服務，同時針對運營基於 BI 報表提供實時指標的應用檢視，讓運營能夠及時瞭解當前遊戲的執行狀況，方便給業務側做分析判斷。

8

基於實時指標的應用的案例：社群帖子排序。主要用到的是實時指標。社群帖子排序通常會涉及到資料關聯，這也是 Flink 比較強項的能力。

社群帖子排序的資料主要源於兩個方面。第一個是透過客戶端埋點上報，透過 Kafka 接收，Flink 透過流式消費 Kafka 來實現資料的接入。第二個是在業務庫，比如 MySQL 的分庫分表，我們透過 Flink CDC 能夠很方便的獲取 Binlog 的實時資料，然後將分庫分表的資料寫入下游 KV 儲存，透過另外一個任務進行流表關聯，實現資料打寬的目的。

9

但為什麼和上圖內容不一樣呢？這是因為這一常見鏈路有兩個弊端。第一個是引入了 KV 儲存，如 Hbase，任務鏈路的複雜度就會提高。第二個是這裡假定流的速度慢於維表更新的速度，否則就會導致資料關聯不上。

為了解決這些問題，我們在 Flink SQL 中將流表關聯任務和 Flink CDC 任務在同一個任務裡進行接入，採用的是 Regular Join 的方式。這裡可能就會有同學會有疑問，用 Flink SQL 需要設定一個統一的狀態過期時間，那麼維表狀態資料會被清理掉，這樣不就沒辦法進行關聯了嗎？

這裡我們擴充了 Flink SQL 的能力，能夠在 SQL 層面控制底層狀態細化的生存週期。比如可以將維表的狀態設定為不過期，從而實現資料關聯，之後再經過指標計算，提供給後端帖子排序服務做前端展示。

第三個應用場景是近實時數倉。主要有兩個方面：

第一個方面是離線入倉近實時化改造。

以前資料離線入倉往往是透過小時級 ETL 任務進行的，每個小時資料入倉後，下游的排程任務才能夠依次啟動。對於較大的日誌資料，更是可能會耗費 10-20 分鐘不等，佔據每個小時的 20%~30% 的時間。

經過日誌入倉近實時化的改造，透過實時任務來寫入 Iceberg 表，同時對採集、加工、寫入的延遲加以監控，透過日誌檔案的元資訊和實時計算的元資訊進行比對來保證資料質量。最後，針對 Iceberg 表建立 Iceberg Manager 管理中心，主要是小檔案合併最佳化、快照清理等。

從離線日誌近實時數倉改造能得到兩個明顯的收益。一是離線儲存的 IO 從之前的每個小時波動性較大到現在較為平穩，二是資料入倉的時效從以前的每小時到分鐘級。

第二個方面是資料庫資料一鍵入湖。

相較日誌，資料庫的資料 Schema 相對具有結構化，我們可以自動探測 Schema 一鍵生成入湖的任務。依託平臺的自動調優以及擴縮容的能力，自動提交任務執行。

10

針對資料庫的資料同步，主要會分為兩條鏈路。第一個是透過 Flink CDC 進行全量同步寫入 Iceberg V2 表，同步時關閉 upsert 功能，保證寫入不會產生太多 delete file。第二個是採用 Flink CDC 做增量同步，透過 Flink SQL 再寫入同一個 Iceberg V2 表。過程中我們發現，有時候很多工可能會對同一個資料來源進行消費，這一過程會對上游業務庫有一定的壓力。所以我們做了一定的最佳化，將 Flink CDC 採集的資料先寫入 Kafka。後面如果再有新的任務對同一個資料來源消費，會被自動感知，切換到已經同步過資料的 Kafka 上，避免對業務庫產生壓力。

資料庫資料一鍵入湖的收益：一方面是從原來需要經過 Flink SQL 到現在基於配置式任務開發，在開發效率上有較大的提高，另一方面從以前離線的批次拉取，過渡到現在對 Binlog 的實時消費，避免了資料庫的壓力。

下面分享一個近實時數倉的應用案例。如下圖所示，這是我們提供的玩家戰績查詢，主要是透過 Flink SQL 任務將實時資料寫入 Iceberg 表，然後透過實時任務進行排序、計算等操作，寫入中間 Iceberg 表，最後透過同步任務將資料同步給戰績服務，給玩家提供查詢。

11

第四個應用場景是實時風控。在米哈遊，風控團隊和實時計算團隊聯絡密切，我們一起擴充了在風控領域的作用。良好的風控服務無疑也是彰顯 Flink 在風控領域較為強大的作用，我們基於風控引擎構建了一套相對自動化的任務管理方式，讓實時計算平臺服務化。

首先根據指標規則，自動拆解任務，自動化做任務建立以及任務調優執行。依靠底層的彈效能力能夠比較方便的保證任務的正常執行。同時，我們會對計算完成的指標資料以及原始資料實時入湖。經過每個小時做全量指標校驗以及線上規則全面監控來保證實時資料的準確性。擴充的應用場景比如登陸校驗、遊戲反作弊、人機校驗等。

12

三、未來展望

第一、Flink 奠定了實時計算領域的基礎，我們將著重加強平臺能力的建設，主要有如下四個方面：

  1. 加強 Flink SQL 及本身能力的建設，包括流處理、批處理的能力。
  2. 增強資源調優，包括靜態資源調優，動態資源調優。目的是讓業務開發人員更多的關注業務本身，而無需關心其他技術性問題。
  3. 做好自動化運維的工作，降低使用者的運維成本。
  4. 擴充彈效能力。我們現在是基於 Yarn On K8s 的模式，未來我們將推進 Flink Native K8s，藉助 K8s 本身優秀的資源管理能力，來實現彈性和更好的應用體驗。

13

第二、探索更多的使用場景，有如下三個方面：

  1. 基於 Flink SQL 實現延遲訊息的服務結合 Kafka，就能相對簡單的提供給訊息佇列團隊，幫助其更好的發展。
  2. 基於 Flink CDC 的 Binlog 服務提供給運維團隊，助力業務發展。
  3. 加強應用級別指標能力建設，幫助業務開發團隊更好的發展業務。

14

最後，資料湖和 Table Store 的不斷實踐，主要有如下方面：

首先，資料湖正處於高速發展，Table Store 也嶄露頭角。隨著新版本的釋出，讓我們基於流批一體的生產實踐有了基礎，我們也在不斷探索流批一體的生產實踐。

15

其次，在進一步探索近實時數倉的建設。過去離線數倉、實時數倉相對割裂，在建設近實時數倉時，如何基於資料的確定性和資料的無界性，在近實時數倉中得以平衡。比如，我們是否可以基於近資料來源產生類似 WaterMark 的一種機制來在流資料上保證一定的確定性，或者是檔案的 FileMark 來實現等同於離線批處理的確定性含義呢？另外，離線數倉往往有完善的任務排程和依賴，方便使用者進行補數、重跑等操作。那麼在建設近實時數倉管理中心的時候，我們是否也需要相應的功能呢？這些都是值得我們探索和思考的地方。

點選檢視直播回放 & 演講PPT

更多內容

Flink Forward Asia 2022

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

PC 端觀看：https://flink-forward.org.cn/ 「建議前往 FFA 2022 大會官網觀看全部議題的影片回放」

活動推薦

阿里雲基於 Apache Flink 構建的企業級產品-實時計算Flink版現開啟活動：
99 元試用 實時計算Flink版（包年包月、10CU）即有機會獲得 Flink 獨家定製衛衣；另包 3 個月及以上還有 85 折優惠！
瞭解活動詳情：https://www.aliyun.com/produc...

image.png

相關文章