導(dǎo)讀：隨著大數(shù)據(jù)的快速發(fā)展，行業(yè)大數(shù)據(jù)服務(wù)越來越重要。同時(shí)，對(duì)大數(shù)據(jù)實(shí)時(shí)計(jì)算的要求也越來越高。今天會(huì)和大家分享下愛奇藝基于Apache Flink的實(shí)時(shí)計(jì)算平臺(tái)建設(shè)實(shí)踐。

今天的介紹會(huì)圍繞下面三點(diǎn)展開：

• Flink的現(xiàn)狀與改進(jìn)

• 平臺(tái)化的探索和實(shí)踐：實(shí)時(shí)計(jì)算平臺(tái)

• Flink業(yè)務(wù)案例

1. Flink現(xiàn)狀

首先和大家分享下愛奇藝大數(shù)據(jù)服務(wù)的發(fā)展史。

我們從2012年到2019年，大數(shù)據(jù)服務(wù)經(jīng)過了一系列持續(xù)的改進(jìn)和發(fā)展：

• 2012年搭建了第一個(gè)Hadoop集群，當(dāng)時(shí)只有大概20幾個(gè)節(jié)點(diǎn)，使用的計(jì)算框架是MapReduce和Hive等

• 到2013，2014年，開始使用Hadoop 2.0，上線了Storm和Spark，由于Storm的使用性和穩(wěn)定性不夠好，被放棄使用，轉(zhuǎn)而使用Spark

• 2015年發(fā)布了第一個(gè)實(shí)時(shí)計(jì)算平臺(tái)Europa，上線了Kafka

• 2017年使用了Flink，同時(shí)我們基于Spark和Flink打造了流式計(jì)算引擎StreamingSQL

• 2018年推出了自研的實(shí)時(shí)計(jì)算平臺(tái)Real-time Analytics Platform (RAP)

• 2019年基于Flink達(dá)到了內(nèi)部的流數(shù)據(jù)生態(tài)平臺(tái)；

然后介紹一下Flink在愛奇藝的使用情況：

這是Flink在愛奇藝的一些使用情況，目前的節(jié)點(diǎn)規(guī)模大約15000多臺(tái)，總的作業(yè)規(guī)模有800多個(gè)，每天的數(shù)據(jù)流的生產(chǎn)量大概在萬(wàn)億級(jí)別，約2500TB左右。注：本數(shù)據(jù)僅代表嘉賓分享時(shí)的數(shù)據(jù)。

下面是目前愛奇藝基于Spark，F(xiàn)link打造的實(shí)時(shí)計(jì)算平臺(tái)框架：

• 底層存儲(chǔ)使用的HDFS，HBase，Kafka和OSS。

• 實(shí)時(shí)計(jì)算框架通過Spark和Flink部署，在這兩個(gè)服務(wù)之上，構(gòu)建了一個(gè)獨(dú)立的流式系統(tǒng)引擎StreamingSQL。

• 在引擎之上，打造了多種類型的平臺(tái)，用來實(shí)現(xiàn)管理計(jì)算的任務(wù)，流數(shù)據(jù)的生產(chǎn)分發(fā)和實(shí)時(shí)數(shù)據(jù)分析等不同需求。

• 實(shí)時(shí)計(jì)算在愛奇藝業(yè)務(wù)上有些典型的應(yīng)用場(chǎng)景：實(shí)時(shí)分析、報(bào)警，信息流(如廣告類)推薦，內(nèi)部數(shù)據(jù)在線訓(xùn)練，實(shí)時(shí)風(fēng)控（內(nèi)容追蹤等）。

2. Flink改進(jìn)

Flink改進(jìn)-監(jiān)控和報(bào)警：

以前只是做了簡(jiǎn)單的狀態(tài)監(jiān)控，在出現(xiàn)問題之后，不知道內(nèi)部狀態(tài)是怎么樣的。近期做了一些改進(jìn)，并和內(nèi)部的監(jiān)控平臺(tái)Hubble進(jìn)行集成，主要有三個(gè)級(jí)別的監(jiān)控指標(biāo)：

• Job級(jí)別監(jiān)控指標(biāo)：Job狀態(tài)、Checkpoint狀態(tài)和耗時(shí)。如果沒有進(jìn)入到running狀態(tài)，會(huì)對(duì)其進(jìn)行重啟操作，防止其查詢卡在不健康狀態(tài)下

• Operator級(jí)別監(jiān)控指標(biāo)：時(shí)延、反壓、Source/Sink流量，對(duì)每個(gè)Operator進(jìn)行指標(biāo)聚合

• TaskManager級(jí)別監(jiān)控指標(biāo)：CPU使用率、內(nèi)存使用率、JVM GC等

Flink改進(jìn)-狀態(tài)管理：

問題一：長(zhǎng)時(shí)間運(yùn)行Flink job，會(huì)因?yàn)楦鞣N原因?qū)е滤貑?。Checkpoint只在Flink作業(yè)內(nèi)部有效，一旦主動(dòng)重啟或異常重啟時(shí)，上一個(gè)job的狀態(tài)會(huì)全部丟失。

解決方法：作業(yè)重啟時(shí)，找到上一次運(yùn)行成功的Checkpoint，從中恢復(fù)。

缺陷：對(duì)于狀態(tài)很大的作業(yè)，會(huì)使用RockDBStateBackend做增量Checkpoint；上一次的Checkpoint被依賴而無(wú)法刪除，會(huì)導(dǎo)致狀態(tài)堆積（生產(chǎn)環(huán)境中的一個(gè)作業(yè)的Checkpoint總共多達(dá)8TB）。

對(duì)于這個(gè)缺陷也就是：

問題二：Checkpoint無(wú)限依賴

解決方法：使用Savepoint打斷增量Checkpoint的依賴鏈，并與流計(jì)算平臺(tái)集成。

主要有兩種產(chǎn)品，一種是通過業(yè)務(wù)通過平臺(tái)主動(dòng)重啟，重啟之前對(duì)此job做一次Savepoint操作，啟動(dòng)時(shí)從Savepoint的路徑去啟動(dòng)。

第二種是發(fā)生異常重啟時(shí)，來不及做Savepoint。那么會(huì)在Checkpoint啟動(dòng)起來，一旦job進(jìn)入到running狀態(tài)以后，立即做一次Savepoint，解決依賴問題。

StreamingSQL：

StreamingSQL是基于Spark和Flink構(gòu)建的一個(gè)統(tǒng)一的流數(shù)據(jù)ETL工具，具有以下一些特征：

• SQL化：業(yè)務(wù)上去寫流計(jì)算任務(wù)時(shí)，不需要去寫Scala程序，只需要編寫一些SQL代碼即可完成流計(jì)算ETL任務(wù)的開發(fā)。

• DDL：流表、臨時(shí)表、維度表、結(jié)果表。

• UDF：系統(tǒng)預(yù)定義常用函數(shù)、用戶自定義函數(shù)。

• 提供SQL編輯器。

下面是StreamingSQL的一個(gè)實(shí)例：

1. 實(shí)時(shí)計(jì)算管理平臺(tái)

上圖是Spark、Flink任務(wù)開發(fā)和管理的web IDE的例子，用戶可以在頁(yè)面上配置一些參數(shù)和字段，進(jìn)行任務(wù)的開發(fā)，上傳，作業(yè)的重啟，運(yùn)行狀態(tài)的查看等常規(guī)操作。

此外，還提供其他的一些管理：

• 文件管理：任務(wù)Jar包、依賴庫(kù)。

• 函數(shù)管理：提供豐富的系統(tǒng)函數(shù)、支持用戶注冊(cè)UDF。

• 版本管理：支持任務(wù)、文件的版本對(duì)比以及回滾。

• 常規(guī)管理：監(jiān)控大盤、報(bào)警訂閱、資源審計(jì)、異常診斷。

2. 實(shí)時(shí)數(shù)據(jù)處理平臺(tái)

為了確保數(shù)據(jù)發(fā)揮該有的價(jià)值，讓數(shù)據(jù)的流轉(zhuǎn)更加通暢，讓業(yè)務(wù)處理數(shù)據(jù)、使用數(shù)據(jù)和分析數(shù)據(jù)更加便捷，我們改進(jìn)服務(wù)，推出了數(shù)據(jù)處理平臺(tái)和數(shù)據(jù)分析平臺(tái)。

以下是實(shí)時(shí)數(shù)據(jù)處理平臺(tái)演進(jìn)過程：

2015 – 2016

• 場(chǎng)景：離線報(bào)表為主，少量實(shí)時(shí)報(bào)表需求，數(shù)據(jù)生產(chǎn)規(guī)模50萬(wàn)QPS；

• Venus 1.0數(shù)據(jù)采集平臺(tái)：基于Apache Flume；在Venus agents上通過tail+grep/awk/sed等腳本過濾；

• 缺陷：不方便變更過濾規(guī)則，需重啟所有agents；不同用戶需求存在大量重復(fù)處理邏輯。

2017 – 2018

• 場(chǎng)景：實(shí)時(shí)分析、信息流推薦等實(shí)時(shí)需求增加，500萬(wàn)QPS

• Venus 2.0數(shù)據(jù)采集分析平臺(tái)：實(shí)時(shí)過濾從Venus agent遷移到Flink，采用兩級(jí)Kafka；無(wú)需重啟即可動(dòng)態(tài)增減處理規(guī)則

• 缺陷：Kafka數(shù)據(jù)冗余，不方便分享Kafka數(shù)據(jù)

2019

• 場(chǎng)景：大量實(shí)時(shí)業(yè)務(wù)需求，1500萬(wàn)QPS

• Venus 3.0流數(shù)據(jù)生產(chǎn)分發(fā)平臺(tái)：通過web配置實(shí)時(shí)處理規(guī)則，可自由組合常見算子；參考離線數(shù)倉(cāng)，按照數(shù)據(jù)使用場(chǎng)景構(gòu)建流式數(shù)倉(cāng)

• 優(yōu)點(diǎn)：減少流數(shù)據(jù)重復(fù)生產(chǎn)，促進(jìn)流數(shù)據(jù)共享

下面是一個(gè)例子，流數(shù)據(jù)處理平臺(tái)的一個(gè)頁(yè)面。目前平臺(tái)支持Projection、Filter、Split、Union、Window、UDF等常見算子。

3. 實(shí)時(shí)分析平臺(tái)

目前我們實(shí)時(shí)數(shù)據(jù)OLAP分析平臺(tái)主要有兩大類：一類是實(shí)時(shí)報(bào)表，主要有A/B測(cè)試、精細(xì)化運(yùn)營(yíng)等；另一類是實(shí)時(shí)報(bào)警，主要有VV/UV、播放故障等。

下圖是現(xiàn)在的一個(gè)架構(gòu)圖：

目前支持流處理平臺(tái)，Kafka，Hubble監(jiān)控系統(tǒng)，MySQL binlog這些數(shù)據(jù)源。用戶可以通過UI配置處理規(guī)則，分析規(guī)則，需要展示的報(bào)表的風(fēng)格，以及一些報(bào)警的規(guī)則。這些處理規(guī)則和分析規(guī)則等，后臺(tái)會(huì)自動(dòng)把它們的function對(duì)應(yīng)的服務(wù)轉(zhuǎn)成一個(gè)job，然后自動(dòng)把結(jié)果上傳到MySQL里。此外，用戶可以在多平臺(tái)上面進(jìn)行分析查看、觀測(cè)報(bào)警率等，也可以方便的通過api對(duì)接到自己的第三方的定制化平臺(tái)里。

目前，我們實(shí)時(shí)分析平臺(tái)擁有以下一些優(yōu)勢(shì)：

• 開發(fā)門檻低：無(wú)需寫程序或SQL

• 開發(fā)效率高：由以前的幾天到現(xiàn)在的半小時(shí)就能完成

• 報(bào)表實(shí)時(shí)：從小時(shí)級(jí)別優(yōu)化到現(xiàn)在只需要1分鐘

• 查詢更快：支持大規(guī)模數(shù)據(jù)亞秒級(jí)查詢

下面展示的是一些頁(yè)面的模塊。

配置處理規(guī)則：

配置OLAP模型：

1. 信息流推薦

我們所有的數(shù)據(jù)都是通過實(shí)時(shí)收集到二級(jí)Kafka里面，通過Stream處理平臺(tái)分級(jí)成點(diǎn)擊、查看、訂閱、搜索等一系列行為不同的Kafka里。然后再經(jīng)過處理平臺(tái)處理以后，生產(chǎn)相應(yīng)的用戶特征，用戶畫像等實(shí)時(shí)流，最后被推薦引擎去使用。

我們從Spark Streaming遷移到Flink，消除了批處理延遲。目前單個(gè)任務(wù)延遲從1分鐘縮短到1-2秒，端到端性能提升86倍，并且顯著提升了推薦效果。

2. 使用Flink生產(chǎn)深度學(xué)習(xí)訓(xùn)練數(shù)據(jù)

上圖是一個(gè)廣告推薦相關(guān)的例子，這是以前的一個(gè)架構(gòu)，通過Hive/Spark離線ETL生成廣告深度學(xué)習(xí)算法所需要的訓(xùn)練數(shù)據(jù)，算法模型更新周期為6小時(shí)。

從2018年初開始，對(duì)框架做了實(shí)時(shí)的一個(gè)改造。實(shí)時(shí)過來的用戶行為數(shù)據(jù)會(huì)實(shí)時(shí)投遞到Kafka里，通過Flink處理完以后，生成一些新的Delta數(shù)據(jù)；過去7天分析的廣告特征、用戶特征投到Kafka，通過Flink處理完以后，存到HBase里。Kafka實(shí)時(shí)流（最近24小時(shí)）和HBase維度表（最近7天）這兩部分?jǐn)?shù)據(jù)Join之后生成一個(gè)Session流，再給算法預(yù)測(cè)使用。

通過框架的改進(jìn)，目前算法模型更新從6小時(shí)縮短到1小時(shí)，并且支持實(shí)時(shí)CTR預(yù)估，更好指導(dǎo)廣告決策，提升廣告收益。

3. 端到端Exactly-Once處理

由于目前存在一個(gè)問題：Kafka節(jié)點(diǎn)故障重啟或人工運(yùn)維時(shí)，業(yè)務(wù)方重復(fù)消費(fèi)數(shù)據(jù)。因此最近正在研究端到端Exactly-Once處理的一個(gè)方案：Kafka Exactly-Once Semantics + Flink two-phase commit.      

但是，這個(gè)方案會(huì)造成Flink任務(wù)計(jì)算性能的20%損耗，從業(yè)務(wù)方向角度來講，這個(gè)是在可接受范圍內(nèi)的。

4. 挑戰(zhàn)與規(guī)劃

以下是未來的一些規(guī)劃：

• 流批一體化

• SQL化：進(jìn)一步完善和推廣StreamingSQL，降低開發(fā)門檻

• 基于Flink的機(jī)器學(xué)習(xí)的嘗試和使用

• 提高Flink作業(yè)的資源利用率，支持動(dòng)態(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ù)存儲(chǔ)、計(jì)算、OLAP 以及開發(fā)平臺(tái)等。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝