基於 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 以及開發平臺等。