導讀： 隨着大數據的快速發展，行業大數據服務越來越重要。同時，對大數據實時計算的要求也越來越高。今天會和大家分享下愛奇藝基於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 以及開發平臺等。
本文來自 DataFunTalk
原文鏈接：