日均萬億條數據如何處理？愛奇藝實時計算平臺這樣作

摘要：本文由愛奇藝大數據服務負責人梁建煌分享，介紹愛奇藝如何基於 Apache Flink 技術打造實時計算平臺，並經過業務應用案例分享幫助用戶瞭解 Apache Flink 的技術特色及應用場景。提綱以下：

1. 愛奇藝 Flink 服務現狀
2. Flink 改進
3. 實時計算平臺
4. Flink 業務案例
5. 挑戰與規劃

1.愛奇藝 Flink 服務現狀

愛奇藝從 2012 年開始開展大數據業務，一開始只有二十幾個節點，主要是 MapReduce、Hive 等離線計算任務。到 2014 年左右上線了 Storm、Spark 實時計算服務，並隨後發佈了基於 Spark 的實時計算平臺 Europa。2017 年開始引入 Flink，用來替代部分 Spark Streaming 場景，知足更低延遲的實時計算需求。在這以後，相繼推出流式 SQL 引擎、實時分析平臺、實時數據生產平臺等一系列工具，用來提高實時計算開發效率。

目前公司內 Flink 類型節點機器 15000 多臺，主要有兩種部署模式：

1. 混部模式：Flink、Spark、MapReduce 等服務混合部署，15000 多臺規模
2. 獨立模式：Flink 服務獨立部署，用於重要業務，約 700 多臺規模

Flink 做業規模達到 800 個，每日數據生產量維持在萬億級別，日均 2500 TB。

下圖所示爲愛奇藝實時計算服務體系：

2.Flink 改進

2.1 監控和報警

Flink 原有的監控比較簡單，沒法知足業務細粒度的監控報警需求。當計算過程出現問題時，沒法清晰瞭解計算做業內部狀況，不利於進一步分析。所以，咱們改進了 Flink 監控報警機制，增長了不少細粒度的監控指標，主要包括三種：

• Job 級別監控指標：監控 Job 狀態、Checkpoint 狀態及耗時，當 Job 異常時自動經過實時計算平臺重啓。
• Operator 級別監控指標：監控 Flink 任務的時延、反壓、Source/Sink 流量，並對每一個 Operator 進行指標聚合，以便用戶查看。
• TaskManager 級別監控指標：監控 CPU 使用率、內存使用率、JVM GC 等常規指標。

2.2 狀態管理

因爲 checkpoint 是 Flink job 內部狀態，當 job 重啓時，上一個 job 的狀態就丟失掉，致使部分數據丟失，影響到業務。

針對上述問題，咱們對 Flink 做業狀態管理進行了改進。用戶提交 Flink job 時，會在實時計算管理平臺上配置 checkpoint 路徑。經過實時計算管理平臺重啓 Flink job 時，先找到上一次成功的 checkpoint，從中恢復 job 丟失的狀態（flink run -s :checkpointPath/chk-n/_metadata）。

改進後解決了狀態丟失的問題，但帶來新的缺陷。對於狀態數據很大的做業，使用 RocksDBStateBackend 作增量 checkpoint，重啓後，上一個 job 的 checkpoint 被依賴而沒法刪除。隨着 Flink 做業長時間運行且發生屢次 job 重啓，系統中堆積大量無用的 checkpoint。

針對該問題，咱們使用 savepoint 方式打斷增量 checkpoint 的依賴鏈：

1. 主動重啓：經過計算平臺主動重啓 Flink job 前，系統會先對 job 進行 savepoint 操做再關閉 job，而後從該 savepoint 啓動（flink run -s :savepointPath）。
2. 異常重啓：當平臺監測到 Flink job 異常時，會自動從上次 checkpoint 開始啓動該 job。一旦 job 進入到 RUNNING 狀態，會先作一次 savepoint，解除對上一個 checkpoint 的依賴。

2.3 StreamingSQL

爲了便於用戶開發流任務，愛奇藝自研了支持 Spark、Flink 的流式 SQL 引擎 StreamingSQL。用戶只須要經過編寫 SQL 便可完成流計算 ETL 任務的開發。同時，咱們也提供 IDE 編輯器和大量經常使用的預約義函數。

StreamingSQL 定義了 4 種類型數據表：

• 流表：定義計算邏輯的輸入，目前支持Kafka
• 維度表：靜態表，用於與流表join，好比字典映射
• 臨時表：定義中間結果，簡化子查詢邏輯
• 結果表：定義計算邏輯的輸出

數據從流表流入，經過一系列 SQL 語句描述的計算，計算結果寫入結果表。對於計算邏輯比較複雜的計算，可能須要定義多層嵌套的子查詢對計算邏輯進行描述，此時能夠經過定義臨時表，將計算邏輯進行拆分，下降子查詢嵌套的深度。

下圖展現了 StreamingSQL 例子：

3.實時計算平臺

愛奇藝從 2015 年開始陸續推出實時計算管理、實時數據生產、實時數據分析等多個平臺，知足做業開發、數據生產、數據分析等不一樣場景下的開發需求，提高用戶的使用體驗和開發效率。

3.1 實時計算管理平臺

實時計算管理平臺用於 Spark、Flink 任務的開發與管理。用戶能夠在 Web IDE 上配置相關參數進行任務的開發、上傳、啓動、中止等常規操做。計算管理平臺提供了大量管理模塊以提升用戶的操做體驗，主要包括如下幾項：

1. 文件管理：經過平臺的文件管理功能用戶能夠方便的管理任務的 Jar 包及依賴庫。
2. 函數管理：爲用戶提供了豐富的系統函數，並支持用戶註冊 UDF。
3. 版本管理：用戶能夠實現任務、文件的版本對比及舊版本的回滾。
4. 系統同時提供了監控大盤、報警訂閱、資源審計、異常診斷等多種功能輔助用戶實時掌握做業狀況。

3.2 實時數據處理平臺

愛奇藝的數據處理平臺經歷了 3 個階段的迭代升級，從原先的離線數據採集系統一步步演變成支撐千萬 QPS 的實時數據生產平臺。

■ Venus 1.0 – 數據採集系統

2015 年開始，咱們推出了第一代數據採集平臺 Venus 1.0。數據來源於兩個方面，從客戶端端收集到的用戶觀看視頻的行爲數據及後臺服務的日誌數據。用戶數據從 PC、App 等客戶端採集投遞給平臺後端的 Nginx 接收器，並落盤到本地文件中，再由 Venus agent 解析文件進行數據採集。服務日誌數據是由機器上的 Venus agent 解析 log 文件採集。Venus 採集的數據直接上傳到 HDFS 進行後續的離線 ETL 處理，生成離線報表供數據分析使用。

Venus 1.0 版本主要基於 Apache Flume 框架進行開發，並經過 tail+grep、awk、sed 等腳本進行數據過濾。在數據量較小時，該平臺很好的解決了數據處理的需求。

■ Venus 2.0 – 實時數據處理平臺

在 2017 年，隨着數據量的增加及實時業務需求的出現，Venus 1.0 漸漸變得力不從心。衆多業務需求致使 agent 上存在大量過濾規則，過多佔用機器資源甚至影響到機器上服務的穩定性。同時，每次變動都須要重啓全部 agents，大大提升上線成本及風險。

所以，咱們設計實現了實時數據處理平臺 Venus 2.0 版本，將實時過濾功能從 Venus agent 遷移到 Flink 中並採用兩級 Kafka 結構。改進後的數據平臺無需重啓便可動態增減數據處理規則，數據處理能力也提高了 10 倍以上，大大優化了平臺的實時效果。

■ Venus 3.0 – 實時數據生產平臺

隨着實時業務的大量增長，Venus 2.0 也帶來了 Kafka 數據冗餘、不方便分享等問題，咱們在 2019 年進行了第三次改造，從數據處理升級到數據生產，推出了實時數據生產平臺 Venus 3.0 版本。

用戶能夠在新平臺上配置實時數據處理規則，並可自由組合 Filter、Split、Window 等常見算子，生產出來的流數據能夠存儲到流式數倉裏。流式數倉是咱們參考離線數倉概念打造的基於 Kafka 的數據倉庫，用於以數據倉庫的形式統一管理流數據。

藉助實時數據生產平臺及流式數倉，用戶能夠更加便捷地加工實時流數據，並經過業務線間的數據分享來減小流數據的重複生產。

3.3 實時數據分析平臺

RAP（Realtime Analysis Platform）是愛奇藝基於 Apache Druid + Spark / Flink 構建的分鐘級延時的實時分析平臺，支持經過 web 嚮導配置完成超大規模實時數據的多維度分析，爲用戶提供一體化的 OLAP 分析操做流程，只須要幾步簡單的配置，便可自動創建 OLAP 模型、生成分鐘級延時的可視化報表，並提供實時報警功能。

RAP 實時分析平臺解決了用戶在數據分析中遇到的幾個困難：

1.OLAP 選型困難：愛奇藝目前提供了 Kylin、Impala、Kudu、Druid、ElasticSearch 等不一樣的數據存儲/查詢引擎，用戶須要瞭解不一樣 OLAP 引擎的優缺點，花費大量精力學習，依然可能選錯。RAP 幫用戶屏蔽了這層，無需考慮中間數據、結果數據存到哪裏、怎麼查詢。
2. 開發成本高：用戶須要寫 Spark 或 Flink 代碼進行實時流數據處理，並進行報表前端開發，流程冗長而複雜。在 RAP 實時分析平臺上，用戶無需編寫Spark/Flink 程序或 SQL，只須要經過 web 配置處理規則、分析規則、報表模板、報警規則便可，大幅下降開發門檻，提高了開發效率，從以往的幾天開發一張報表縮短到半小時。
3. 數據實時性差：從數據產生到數據可被查詢，中間存在較高時延（從數十分鐘到天級別不等），且查詢較慢。藉助於 Flink 的實時處理能力，RAP 實現了端到端分鐘級低延時的實時報表功能，且支持大規模數據亞秒級查詢。

1. 維護耗費時間：數據源發生改變時，修改的範圍會覆蓋整個流程，從數據處理到報表配置所有須要變動，很難操做和維護。RAP 提供了自動更新功能，幫助用戶免去人工維護的麻煩。

RAP 實時分析平臺架構圖：

4.Flink 業務案例

4.1 信息流推薦實時化

愛奇藝很早就開始了基於網格式的長視頻推薦業務，近幾年隨着短視頻的興起，信息流形式的推薦發展迅速。信息流場景裏，須要在幾秒內根據用戶的觀看行爲實時推薦相關性更高的視頻，對數據的時效性要求更高。

本來基於 Spark Streaming 的實時數據處理架構沒法知足這類低延遲的需求，所以，咱們協助業務遷移到 Flink 平臺上，消除了批量數據處理帶來的延遲。單個任務的延遲從 1 分鐘縮短到 1-2 秒，端到端的性能提高了 86 倍，顯著提高了推薦效果。

4.2 使用 Flink 生產深度學習訓練數據

深度學習大量應用於愛奇藝內部的各項業務，幫助業務更好的挖掘數據的價值。在深度學習場景中，訓練數據的時效性很是關鍵。咱們使用 Flink 幫助業務更加實時地生產訓練數據。

下圖所示爲愛奇藝廣告點擊率預測訓練的架構，業務原先經過 Hive/Spark 離線 ETL 方式生成訓練數據，每 6 小時才能更新一次算法模型，致使用戶特徵關聯不及時、不精確，影響到廣告投放效果。

咱們基於 Flink 進行了實時化改造，將最近 24 小時的用戶數據實時寫到 Kafka 中，經過 Flink 與存儲在 HBase 中的過去 7 天的用戶特徵進行實時 join，實時產出包含最新用戶特徵的訓練數據，將算法模型更新週期縮短到 1 小時之內，從而支持更加實時、精確的 CTR （Click-Through-Rate）預估，大幅提高廣告投放效果。

4.3 端到端 Exactly-Once 處理

當 Kafka 節點出現故障重啓或進行人工運維時，Flink 做業會重複消費數據致使數據失準，影響後續的數據處理，好比模型訓練。針對該問題，咱們設計實現了基於 Kafka Exactly Once Semantics 及 Flink two-phase commit 特性的端到端 Exactly-Once 處理方案。通過咱們測試，該方案會帶來 20% 的計算性能損耗，但數據重複率會從原先的最高 300% 下降到 0，很好地解決了節點重啓帶來的數據精確度問題。

關於 Exactly-once two-phase commit 的原理，能夠閱讀 Apache Flink Blog 上的詳細介紹：

https://flink.apache.org/feat...

5.挑戰與規劃

隨着 Flink 在愛奇藝獲得愈來愈普遍的應用，咱們在資源管理、穩定性、實時開發等層面面臨新的挑戰。

接下來，咱們會推動流批一體化，進一步完善和推廣 StreamingSQL 技術，下降開發門檻。同時，積極嘗試基於 Flink 的機器學習、Flink on Kubernetes、Flink 動態資源調整等前沿方向。

做者介紹：

梁建煌，愛奇藝大數據服務負責人，2012-碩士畢業於上海交通大學後，前後在 SAP、愛奇藝工做，從 2013 年起開始負責愛奇藝大數據服務體系的建設工做，包括大數據存儲、計算、OLAP 以及開發平臺等。