基於 Apache Flink 的愛奇藝實時計算平臺建設實踐
導讀: 隨着大數據的快速發展,行業大數據服務越來越重要。同時,對大數據實時計算的要求也越來越高。今天會和大家分享下愛奇藝基於 Apache Flink 的實時計算平臺建設實踐。
今天的介紹會圍繞下面三點展開:
- Flink 的現狀與改進
- 平臺化的探索和實踐:實時計算平臺
- Flink 業務案例
01 Flink 的現狀與改進
1. Flink 現狀
首先和大家分享下愛奇藝大數據服務的發展史。
我們從 2012 年到 2019 年,大數據服務經過了一系列持續的改進和發展:
- 2012 年搭建了第一個 Hadoop 集羣,當時只有大概 20 幾個節點,使用的計算框架是 MapReduce 和 Hive 等
- 到 2013,2014 年,開始使用 Hadoop 2.0,上線了 Storm 和 Spark,由於 Storm 的使用性和穩定性不夠好,被放棄使用,轉而使用 Spark
- 2015 年發佈了第一個實時計算平臺 Europa,上線了 Kafka
- 2017 年使用了 Flink,同時我們基於 Spark 和 Flink 打造了流式計算引擎 StreamingSQL
- 2018 年推出了自研的實時計算平臺 Real-time Analytics Platform (RAP)
- 2019 年基於 Flink 達到了內部的流數據生態平臺;
然後介紹一下 Flink 在愛奇藝的使用情況:
這是 Flink 在愛奇藝的一些使用情況,目前的節點規模大約 15000 多臺,總的作業規模有 800 多個,每天的數據流的生產量大概在萬億級別,約 2500TB 左右。 注:本數據僅代表嘉賓分享時的數據 。
下面是目前愛奇藝基於 Spark,Flink 打造的實時計算平臺框架:
- 底層存儲使用的 HDFS,HBase,Kafka 和 OSS。
- 實時計算框架通過 Spark 和 Flink 部署,在這兩個服務之上,構建了一個獨立的流式系統引擎 StreamingSQL。
- 在引擎之上,打造了多種類型的平臺,用來實現管理計算的任務,流數據的生產分發和實時數據分析等不同需求。
- 實時計算在愛奇藝業務上有些典型的應用場景:實時分析、報警,信息流 (如廣告類) 推薦,內部數據在線訓練,實時風控(內容追蹤等)。
2. Flink 改進
Flink 改進 - 監控和報警:
以前只是做了簡單的狀態監控,在出現問題之後,不知道內部狀態是怎麼樣的。近期做了一些改進,並和內部的監控平臺 Hubble 進行集成,主要有三個級別的監控指標:
- Job 級別監控指標:Job 狀態、Checkpoint 狀態和耗時。如果沒有進入到 running 狀態,會對其進行重啓操作,防止其查詢卡在不健康狀態下
- Operator 級別監控指標:時延、反壓、Source/Sink 流量,對每個 Operator 進行指標聚合
- TaskManager 級別監控指標:CPU 使用率、內存使用率、JVM GC 等
Flink 改進 - 狀態管理:
問題一: 長時間運行 Flink job,會因爲各種原因導致它重啓。Checkpoint 只在 Flink 作業內部有效,一旦主動重啓或異常重啓時,上一個 job 的狀態會全部丟失。
解決方法:作業重啓時,找到上一次運行成功的 Checkpoint,從中恢復。
缺陷:對於狀態很大的作業,會使用 RockDBStateBackend 做增量 Checkpoint;上一次的 Checkpoint 被依賴而無法刪除,會導致狀態堆積(生產環境中的一個作業的 Checkpoint 總共多達 8TB)。
對於這個缺陷也就是:
問題二: Checkpoint 無限依賴
解決方法:使用 Savepoint 打斷增量 Checkpoint 的依賴鏈,並與流計算平臺集成。
主要有兩種產品,一種是通過業務通過平臺主動重啓,重啓之前對此 job 做一次 Savepoint 操作,啓動時從 Savepoint 的路徑去啓動。
第二種是發生異常重啓時,來不及做 Savepoint。那麼會在 Checkpoint 啓動起來,一旦 job 進入到 running 狀態以後,立即做一次 Savepoint,解決依賴問題。
StreamingSQL:
StreamingSQL 是基於 Spark 和 Flink 構建的一個統一的流數據 ETL 工具,具有以下一些特徵:
- SQL 化:業務上去寫流計算任務時,不需要去寫 Scala 程序,只需要編寫一些 SQL 代碼即可完成流計算 ETL 任務的開發。
- DDL:流表、臨時表、維度表、結果表。
- UDF:系統預定義常用函數、用戶自定義函數。
- 提供 SQL 編輯器。
下面是 StreamingSQL 的一個實例:
02 實時計算平臺
1. 實時計算管理平臺
上圖是 Spark、Flink 任務開發和管理的 web IDE 的例子,用戶可以在頁面上配置一些參數和字段,進行任務的開發,上傳,作業的重啓,運行狀態的查看等常規操作。
此外,還提供其他的一些管理:
- 文件管理:任務 Jar 包、依賴庫。
- 函數管理:提供豐富的系統函數、支持用戶註冊 UDF。
- 版本管理:支持任務、文件的版本對比以及回滾。
- 常規管理:監控大盤、報警訂閱、資源審計、異常診斷。
2. 實時數據處理平臺
爲了確保數據發揮該有的價值,讓數據的流轉更加通暢,讓業務處理數據、使用數據和分析數據更加便捷,我們改進服務,推出了數據處理平臺和數據分析平臺。
以下是實時數據處理平臺演進過程:
2015 – 2016
- 場景:離線報表爲主,少量實時報表需求,數據生產規模 50 萬 QPS;
- Venus 1.0 數據採集平臺:基於 Apache Flume;在 Venus agents 上通過 tail+grep/awk/sed 等腳本過濾;
- 缺陷:不方便變更過濾規則,需重啓所有 agents;不同用戶需求存在大量重複處理邏輯。
2017 – 2018
- 場景:實時分析、信息流推薦等實時需求增加,500 萬 QPS
- Venus 2.0 數據採集分析平臺:實時過濾從 Venus agent 遷移到 Flink,採用兩級 Kafka;無需重啓即可動態增減處理規則
- 缺陷:Kafka 數據冗餘,不方便分享 Kafka 數據
2019
- 場景:大量實時業務需求,1500 萬 QPS
- Venus 3.0 流數據生產分發平臺:通過 web 配置實時處理規則,可自由組合常見算子;參考離線數倉,按照數據使用場景構建流式數倉
- 優點:減少流數據重複生產,促進流數據共享
下面是一個例子,流數據處理平臺的一個頁面。目前平臺支持 Projection、Filter、Split、Union、Window、UDF 等常見算子。
3. 實時分析平臺
目前我們實時數據 OLAP 分析平臺主要有兩大類:一類是實時報表,主要有 A/B 測試、精細化運營等;另一類是實時報警,主要有 VV/UV、播放故障等。
下圖是現在的一個架構圖:
目前支持流處理平臺,Kafka,Hubble 監控系統,MySQL binlog 這些數據源。用戶可以通過 UI 配置處理規則,分析規則,需要展示的報表的風格,以及一些報警的規則。這些處理規則和分析規則等,後臺會自動把它們的 function 對應的服務轉成一個 job,然後自動把結果上傳到 MySQL 裏。此外,用戶可以在多平臺上面進行分析查看、觀測報警率等,也可以方便的通過 api 對接到自己的第三方的定製化平臺裏。
目前,我們實時分析平臺擁有以下一些優勢:
- 開發門檻低:無需寫程序或 SQL
- 開發效率高:由以前的幾天到現在的半小時就能完成
- 報表實時:從小時級別優化到現在只需要 1 分鐘
- 查詢更快:支持大規模數據亞秒級查詢
下面展示的是一些頁面的模塊。
配置處理規則:
配置 OLAP 模型:
03 Flink 業務案例
1. 信息流推薦
我們所有的數據都是通過實時收集到二級 Kafka 裏面,通過 Stream 處理平臺分級成點擊、查看、訂閱、搜索等一系列行爲不同的 Kafka 裏。然後再經過處理平臺處理以後,生產相應的用戶特徵,用戶畫像等實時流,最後被推薦引擎去使用。
我們從 Spark Streaming 遷移到 Flink,消除了批處理延遲。目前單個任務延遲從 1 分鐘縮短到 1-2 秒,端到端性能提升 86 倍,並且顯著提升了推薦效果。
2. 使用 Flink 生產深度學習訓練數據
上圖是一個廣告推薦相關的例子,這是以前的一個架構,通過 Hive/Spark 離線 ETL 生成廣告深度學習算法所需要的訓練數據,算法模型更新週期爲 6 小時。
從 2018 年初開始,對框架做了實時的一個改造。實時過來的用戶行爲數據會實時投遞到 Kafka 裏,通過 Flink 處理完以後,生成一些新的 Delta 數據;過去 7 天分析的廣告特徵、用戶特徵投到 Kafka,通過 Flink 處理完以後,存到 HBase 裏。Kafka 實時流(最近 24 小時)和 HBase 維度表(最近 7 天)這兩部分數據 Join 之後生成一個 Session 流,再給算法預測使用。
通過框架的改進,目前算法模型更新從 6 小時縮短到 1 小時,並且支持實時 CTR 預估,更好指導廣告決策,提升廣告收益。
3. 端到端 Exactly-Once 處理
由於目前存在一個問題:Kafka 節點故障重啓或人工運維時,業務方重複消費數據。因此最近正在研究端到端 Exactly-Once 處理的一個方案:Kafka Exactly-Once Semantics + Flink two-phase commit.
但是,這個方案會造成 Flink 任務計算性能的 20% 損耗,從業務方向角度來講,這個是在可接受範圍內的。
4. 挑戰與規劃
以下是未來的一些規劃:
- 流批一體化
- SQL 化:進一步完善和推廣 StreamingSQL,降低開發門檻
- 基於 Flink 的機器學習的嘗試和使用
- 提高 Flink 作業的資源利用率,支持動態資源調整
- Flink on Kubernetes
作者介紹:
梁建煌,愛奇藝大數據服務負責人,2012- 碩士畢業於上海交通大學後,先後在 SAP、愛奇藝工作,從 2013 年起開始負責愛奇藝大數據服務體系的建設工作,包括大數據存儲、計算、OLAP 以及開發平臺等。