基于Apache Flink的愛奇藝實時計算平臺建設(shè)實踐
導(dǎo)讀：隨著大數(shù)據(jù)的快速發(fā)展，行業(yè)大數(shù)據(jù)服務(wù)越來越重要。同時，對大數(shù)據(jù)實時計算的要求也越來越高。今天會和大家分享下愛奇藝基于Apache Flink的實時計算平臺建設(shè)實踐。
今天的介紹會圍繞下面三點展開：
Flink的現(xiàn)狀與改進
平臺化的探索和實踐：實時計算平臺
Flink業(yè)務(wù)案例
1. Flink現(xiàn)狀
首先和大家分享下愛奇藝大數(shù)據(jù)服務(wù)的發(fā)展史。
我們從2012年到2019年，大數(shù)據(jù)服務(wù)經(jīng)過了一系列持續(xù)的改進和發(fā)展：
2012年搭建了第一個Hadoop集群，當(dāng)時只有大概20幾個節(jié)點，使用的計算框架是MapReduce和Hive等
到2013，2014年，開始使用Hadoop 2.0，上線了Storm和Spark，由于Storm的使用性和穩(wěn)定性不夠好，被放棄使用，轉(zhuǎn)而使用Spark
2015年發(fā)布了第一個實時計算平臺Europa，上線了Kafka
2017年使用了Flink，同時我們基于Spark和Flink打造了流式計算引擎StreamingSQL
2018年推出了自研的實時計算平臺Real-time Analytics Platform (RAP)
2019年基于Flink達到了內(nèi)部的流數(shù)據(jù)生態(tài)平臺；
然后介紹一下Flink在愛奇藝的使用情況：
這是Flink在愛奇藝的一些使用情況，目前的節(jié)點規(guī)模大約15000多臺，總的作業(yè)規(guī)模有800多個，每天的數(shù)據(jù)流的生產(chǎn)量大概在萬億級別，約2500TB左右。注：本數(shù)據(jù)僅代表嘉賓分享時的數(shù)據(jù)。
下面是目前愛奇藝基于Spark，F(xiàn)link打造的實時計算平臺框架：
底層存儲使用的HDFS，HBase，Kafka和OSS。
實時計算框架通過Spark和Flink部署，在這兩個服務(wù)之上，構(gòu)建了一個獨立的流式系統(tǒng)引擎StreamingSQL。
在引擎之上，打造了多種類型的平臺，用來實現(xiàn)管理計算的任務(wù)，流數(shù)據(jù)的生產(chǎn)分發(fā)和實時數(shù)據(jù)分析等不同需求。
實時計算在愛奇藝業(yè)務(wù)上有些典型的應(yīng)用場景：實時分析、報警，信息流(如廣告類)推薦，內(nèi)部數(shù)據(jù)在線訓(xùn)練，實時風(fēng)控（內(nèi)容追蹤等）。
2. Flink改進
Flink改進-監(jiān)控和報警：
以前只是做了簡單的狀態(tài)監(jiān)控，在出現(xiàn)問題之后，不知道內(nèi)部狀態(tài)是怎么樣的。近期做了一些改進，并和內(nèi)部的監(jiān)控平臺Hubble進行集成，主要有三個級別的監(jiān)控指標(biāo)：
Job級別監(jiān)控指標(biāo)：Job狀態(tài)、Checkpoint狀態(tài)和耗時。如果沒有進入到running狀態(tài)，會對其進行重啟操作，防止其查詢卡在不健康狀態(tài)下
Operator級別監(jiān)控指標(biāo)：時延、反壓、Source/Sink流量，對每個Operator進行指標(biāo)聚合
TaskManager級別監(jiān)控指標(biāo)：CPU使用率、內(nèi)存使用率、JVM GC等
Flink改進-狀態(tài)管理：
問題一：長時間運行Flink job，會因為各種原因?qū)е滤貑?。Checkpoint只在Flink作業(yè)內(nèi)部有效，一旦主動重啟或異常重啟時，上一個job的狀態(tài)會全部丟失。
解決方法：作業(yè)重啟時，找到上一次運行成功的Checkpoint，從中恢復(fù)。
缺陷：對于狀態(tài)很大的作業(yè)，會使用RockDBStateBackend做增量Checkpoint；上一次的Checkpoint被依賴而無法刪除，會導(dǎo)致狀態(tài)堆積（生產(chǎn)環(huán)境中的一個作業(yè)的Checkpoint總共多達8TB）。
對于這個缺陷也就是：
問題二：Checkpoint無限依賴
解決方法：使用Savepoint打斷增量Checkpoint的依賴鏈，并與流計算平臺集成。
主要有兩種產(chǎn)品，一種是通過業(yè)務(wù)通過平臺主動重啟，重啟之前對此job做一次Savepoint操作，啟動時從Savepoint的路徑去啟動。
第二種是發(fā)生異常重啟時，來不及做Savepoint。那么會在Checkpoint啟動起來，一旦job進入到running狀態(tài)以后，立即做一次Savepoint，解決依賴問題。
StreamingSQL：
StreamingSQL是基于Spark和Flink構(gòu)建的一個統(tǒng)一的流數(shù)據(jù)ETL工具，具有以下一些特征：
SQL化：業(yè)務(wù)上去寫流計算任務(wù)時，不需要去寫Scala程序，只需要編寫一些SQL代碼即可完成流計算ETL任務(wù)的開發(fā)。
DDL：流表、臨時表、維度表、結(jié)果表。
UDF：系統(tǒng)預(yù)定義常用函數(shù)、用戶自定義函數(shù)。
提供SQL編輯器。
下面是StreamingSQL的一個實例：
1. 實時計算管理平臺
上圖是Spark、Flink任務(wù)開發(fā)和管理的web IDE的例子，用戶可以在頁面上配置一些參數(shù)和字段，進行任務(wù)的開發(fā)，上傳，作業(yè)的重啟，運行狀態(tài)的查看等常規(guī)操作。
此外，還提供其他的一些管理：
文件管理：任務(wù)Jar包、依賴庫。
函數(shù)管理：提供豐富的系統(tǒng)函數(shù)、支持用戶注冊UDF。
版本管理：支持任務(wù)、文件的版本對比以及回滾。
常規(guī)管理：監(jiān)控大盤、報警訂閱、資源審計、異常診斷。
2. 實時數(shù)據(jù)處理平臺
為了確保數(shù)據(jù)發(fā)揮該有的價值，讓數(shù)據(jù)的流轉(zhuǎn)更加通暢，讓業(yè)務(wù)處理數(shù)據(jù)、使用數(shù)據(jù)和分析數(shù)據(jù)更加便捷，我們改進服務(wù)，推出了數(shù)據(jù)處理平臺和數(shù)據(jù)分析平臺。
以下是實時數(shù)據(jù)處理平臺演進過程：
2015 – 2016
場景：離線報表為主，少量實時報表需求，數(shù)據(jù)生產(chǎn)規(guī)模50萬QPS；
Venus 1.0數(shù)據(jù)采集平臺：基于Apache Flume；在Venus agents上通過tail+grep/awk/sed等腳本過濾；
缺陷：不方便變更過濾規(guī)則，需重啟所有agents；不同用戶需求存在大量重復(fù)處理邏輯。
2017 – 2018
場景：實時分析、信息流推薦等實時需求增加，500萬QPS
Venus 2.0數(shù)據(jù)采集分析平臺：實時過濾從Venus agent遷移到Flink，采用兩級Kafka；無需重啟即可動態(tài)增減處理規(guī)則
缺陷：Kafka數(shù)據(jù)冗余，不方便分享Kafka數(shù)據(jù)
2019
場景：大量實時業(yè)務(wù)需求，1500萬QPS
Venus 3.0流數(shù)據(jù)生產(chǎn)分發(fā)平臺：通過web配置實時處理規(guī)則，可自由組合常見算子；參考離線數(shù)倉，按照數(shù)據(jù)使用場景構(gòu)建流式數(shù)倉
優(yōu)點：減少流數(shù)據(jù)重復(fù)生產(chǎn)，促進流數(shù)據(jù)共享
下面是一個例子，流數(shù)據(jù)處理平臺的一個頁面。目前平臺支持Projection、Filter、Split、Union、Window、UDF等常見算子。
3. 實時分析平臺
目前我們實時數(shù)據(jù)OLAP分析平臺主要有兩大類：一類是實時報表，主要有A/B測試、精細(xì)化運營等；另一類是實時報警，主要有VV/UV、播放故障等。
下圖是現(xiàn)在的一個架構(gòu)圖：
目前支持流處理平臺，Kafka，Hubble監(jiān)控系統(tǒng)，MySQL binlog這些數(shù)據(jù)源。用戶可以通過UI配置處理規(guī)則，分析規(guī)則，需要展示的報表的風(fēng)格，以及一些報警的規(guī)則。這些處理規(guī)則和分析規(guī)則等，后臺會自動把它們的function對應(yīng)的服務(wù)轉(zhuǎn)成一個job，然后自動把結(jié)果上傳到MySQL里。此外，用戶可以在多平臺上面進行分析查看、觀測報警率等，也可以方便的通過api對接到自己的第三方的定制化平臺里。
目前，我們實時分析平臺擁有以下一些優(yōu)勢：
開發(fā)門檻低：無需寫程序或SQL
開發(fā)效率高：由以前的幾天到現(xiàn)在的半小時就能完成
報表實時：從小時級別優(yōu)化到現(xiàn)在只需要1分鐘
查詢更快：支持大規(guī)模數(shù)據(jù)亞秒級查詢
下面展示的是一些頁面的模塊。
配置處理規(guī)則：
配置OLAP模型：
1. 信息流推薦
我們所有的數(shù)據(jù)都是通過實時收集到二級Kafka里面，通過Stream處理平臺分級成點擊、查看、訂閱、搜索等一系列行為不同的Kafka里。然后再經(jīng)過處理平臺處理以后，生產(chǎn)相應(yīng)的用戶特征，用戶畫像等實時流，最后被推薦引擎去使用。
我們從Spark Streaming遷移到Flink，消除了批處理延遲。目前單個任務(wù)延遲從1分鐘縮短到1-2秒，端到端性能提升86倍，并且顯著提升了推薦效果。
2. 使用Flink生產(chǎn)深度學(xué)習(xí)訓(xùn)練數(shù)據(jù)
上圖是一個廣告推薦相關(guān)的例子，這是以前的一個架構(gòu)，通過Hive/Spark離線ETL生成廣告深度學(xué)習(xí)算法所需要的訓(xùn)練數(shù)據(jù)，算法模型更新周期為6小時。
從2018年初開始，對框架做了實時的一個改造。實時過來的用戶行為數(shù)據(jù)會實時投遞到Kafka里，通過Flink處理完以后，生成一些新的Delta數(shù)據(jù)；過去7天分析的廣告特征、用戶特征投到Kafka，通過Flink處理完以后，存到HBase里。Kafka實時流（最近24小時）和HBase維度表（最近7天）這兩部分?jǐn)?shù)據(jù)Join之后生成一個Session流，再給算法預(yù)測使用。
通過框架的改進，目前算法模型更新從6小時縮短到1小時，并且支持實時CTR預(yù)估，更好指導(dǎo)廣告決策，提升廣告收益。
3. 端到端Exactly-Once處理
由于目前存在一個問題：Kafka節(jié)點故障重啟或人工運維時，業(yè)務(wù)方重復(fù)消費數(shù)據(jù)。因此最近正在研究端到端Exactly-Once處理的一個方案：Kafka Exactly-Once Semantics + Flink two-phase commit.
但是，這個方案會造成Flink任務(wù)計算性能的20%損耗，從業(yè)務(wù)方向角度來講，這個是在可接受范圍內(nèi)的。
4. 挑戰(zhàn)與規(guī)劃
以下是未來的一些規(guī)劃：
流批一體化
SQL化：進一步完善和推廣StreamingSQL，降低開發(fā)門檻
基于Flink的機器學(xué)習(xí)的嘗試和使用
提高Flink作業(yè)的資源利用率，支持動態(tài)資源調(diào)整
Flink on Kubernetes
作者介紹：
linkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;white-space: normal;background-color: rgb(255, 255, 255);line-height: 2em;box-sizing: border-box !important;overflow-wrap: break-word !important;">梁建煌，愛奇藝大數(shù)據(jù)服務(wù)負(fù)責(zé)人，2012-碩士畢業(yè)于上海交通大學(xué)后，先后在 SAP、愛奇藝工作，從 2013 年起開始負(fù)責(zé)愛奇藝大數(shù)據(jù)服務(wù)體系的建設(shè)工作，包括大數(shù)據(jù)存儲、計算、OLAP 以及開發(fā)平臺等。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
