1.愛奇藝 Flink 服務(wù)現(xiàn)狀

愛奇藝從 2012 年開始開展大數(shù)據(jù)業(yè)務(wù)，一開始只有二十幾個(gè)節(jié)點(diǎn)，主要是 MapReduce、Hive 等離線計(jì)算任務(wù)。到 2014 年左右上線了 Storm、Spark 實(shí)時(shí)計(jì)算服務(wù)，并隨后發(fā)布了基于 Spark 的實(shí)時(shí)計(jì)算平臺(tái) Europa。2017 年開始引入 Flink，用來替代部分 Spark Streaming 場景，滿足更低延遲的實(shí)時(shí)計(jì)算需求。在這之后，相繼推出流式 SQL 引擎、實(shí)時(shí)分析平臺(tái)、實(shí)時(shí)數(shù)據(jù)生產(chǎn)平臺(tái)等一系列工具，用來提升實(shí)時(shí)計(jì)算開發(fā)效率。

目前公司內(nèi) Flink 類型節(jié)點(diǎn)機(jī)器 15000 多臺(tái)，主要有兩種部署模式：

混部模式：Flink、Spark、MapReduce 等服務(wù)混合部署，15000 多臺(tái)規(guī)模

獨(dú)立模式：Flink 服務(wù)獨(dú)立部署，用于重要業(yè)務(wù)，約 700 多臺(tái)規(guī)模

Flink 作業(yè)規(guī)模達(dá)到 800 個(gè)，每日數(shù)據(jù)生產(chǎn)量維持在萬億級(jí)別，日均 2500 TB。

下圖所示為愛奇藝實(shí)時(shí)計(jì)算服務(wù)體系：

2.Flink 改進(jìn)

2.1 監(jiān)控和報(bào)警

Flink 原有的監(jiān)控比較簡單，無法滿足業(yè)務(wù)細(xì)粒度的監(jiān)控報(bào)警需求。當(dāng)計(jì)算過程出現(xiàn)問題時(shí)，無法清晰了解計(jì)算作業(yè)內(nèi)部情況，不利于進(jìn)一步分析。因此，我們改進(jìn)了 Flink 監(jiān)控報(bào)警機(jī)制，增加了很多細(xì)粒度的監(jiān)控指標(biāo)，主要包括三種：

• Job 級(jí)別監(jiān)控指標(biāo)：監(jiān)控 Job 狀態(tài)、Checkpoint 狀態(tài)及耗時(shí)，當(dāng) Job 異常時(shí)自動(dòng)通過實(shí)時(shí)計(jì)算平臺(tái)重啟。
• Operator 級(jí)別監(jiān)控指標(biāo)：監(jiān)控 Flink 任務(wù)的時(shí)延、反壓、Source/Sink 流量，并對(duì)每個(gè) Operator 進(jìn)行指標(biāo)聚合，以便用戶查看。
• TaskManager 級(jí)別監(jiān)控指標(biāo)：監(jiān)控 CPU 使用率、內(nèi)存使用率、JVM GC 等常規(guī)指標(biāo)。

2.2 狀態(tài)管理

由于 checkpoint 是 Flink job 內(nèi)部狀態(tài)，當(dāng) job 重啟時(shí)，上一個(gè) job 的狀態(tài)就丟失掉，導(dǎo)致部分?jǐn)?shù)據(jù)丟失，影響到業(yè)務(wù)。

針對(duì)上述問題，我們對(duì) Flink 作業(yè)狀態(tài)管理進(jìn)行了改進(jìn)。用戶提交 Flink job 時(shí)，會(huì)在實(shí)時(shí)計(jì)算管理平臺(tái)上配置 checkpoint 路徑。通過實(shí)時(shí)計(jì)算管理平臺(tái)重啟 Flink job 時(shí)，先找到上一次成功的 checkpoint，從中恢復(fù) job 丟失的狀態(tài)(flink run -s :checkpointPath/chk-n/_metadata)。

改進(jìn)后解決了狀態(tài)丟失的問題，但帶來新的缺陷。對(duì)于狀態(tài)數(shù)據(jù)很大的作業(yè)，使用 RocksDBStateBackend 做增量 checkpoint，重啟后，上一個(gè) job 的 checkpoint 被依賴而無法刪除。隨著 Flink 作業(yè)長時(shí)間運(yùn)行且發(fā)生多次 job 重啟，系統(tǒng)中堆積大量無用的 checkpoint。

針對(duì)該問題，我們使用 savepoint 方式打斷增量 checkpoint 的依賴鏈：

主動(dòng)重啟：通過計(jì)算平臺(tái)主動(dòng)重啟 Flink job 前，系統(tǒng)會(huì)先對(duì) job 進(jìn)行 savepoint 操作再關(guān)閉 job，然后從該 savepoint 啟動(dòng)(flink run -s :savepointPath)。

異常重啟：當(dāng)平臺(tái)監(jiān)測到 Flink job 異常時(shí)，會(huì)自動(dòng)從上次 checkpoint 開始啟動(dòng)該 job。一旦 job 進(jìn)入到 RUNNING 狀態(tài)，會(huì)先做一次 savepoint，解除對(duì)上一個(gè) checkpoint 的依賴。

2.3 StreamingSQL

為了便于用戶開發(fā)流任務(wù)，愛奇藝自研了支持 Spark、Flink 的流式 SQL 引擎 StreamingSQL。用戶只需要通過編寫 SQL 即可完成流計(jì)算 ETL 任務(wù)的開發(fā)。同時(shí)，我們也提供 IDE 編輯器和大量常用的預(yù)定義函數(shù)。

StreamingSQL 定義了 4 種類型數(shù)據(jù)表：

• 流表：定義計(jì)算邏輯的輸入，目前支持Kafka
• 維度表：靜態(tài)表，用于與流表join，比如字典映射
• 臨時(shí)表：定義中間結(jié)果，簡化子查詢邏輯
• 結(jié)果表：定義計(jì)算邏輯的輸出

數(shù)據(jù)從流表流入，通過一系列 SQL 語句描述的計(jì)算，計(jì)算結(jié)果寫入結(jié)果表。對(duì)于計(jì)算邏輯比較復(fù)雜的計(jì)算，可能需要定義多層嵌套的子查詢對(duì)計(jì)算邏輯進(jìn)行描述，此時(shí)可以通過定義臨時(shí)表，將計(jì)算邏輯進(jìn)行拆分，降低子查詢嵌套的深度。

下圖展示了 StreamingSQL 例子：

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

愛奇藝從 2015 年開始陸續(xù)推出實(shí)時(shí)計(jì)算管理、實(shí)時(shí)數(shù)據(jù)生產(chǎn)、實(shí)時(shí)數(shù)據(jù)分析等多個(gè)平臺(tái)，滿足作業(yè)開發(fā)、數(shù)據(jù)生產(chǎn)、數(shù)據(jù)分析等不同場景下的開發(fā)需求，提升用戶的使用體驗(yàn)和開發(fā)效率。

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

實(shí)時(shí)計(jì)算管理平臺(tái)用于 Spark、Flink 任務(wù)的開發(fā)與管理。用戶可以在 Web IDE 上配置相關(guān)參數(shù)進(jìn)行任務(wù)的開發(fā)、上傳、啟動(dòng)、停止等常規(guī)操作。計(jì)算管理平臺(tái)提供了大量管理模塊以提高用戶的操作體驗(yàn)，主要包括以下幾項(xiàng)：

文件管理：通過平臺(tái)的文件管理功能用戶可以方便的管理任務(wù)的 Jar 包及依賴庫。

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

版本管理：用戶可以實(shí)現(xiàn)任務(wù)、文件的版本對(duì)比及舊版本的回滾。

系統(tǒng)同時(shí)提供了監(jiān)控大盤、報(bào)警訂閱、資源審計(jì)、異常診斷等多種功能輔助用戶實(shí)時(shí)掌握作業(yè)情況。

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

愛奇藝的數(shù)據(jù)處理平臺(tái)經(jīng)歷了 3 個(gè)階段的迭代升級(jí)，從原先的離線數(shù)據(jù)采集系統(tǒng)一步步演變成支撐千萬 QPS 的實(shí)時(shí)數(shù)據(jù)生產(chǎn)平臺(tái)。

■ Venus 1.0 – 數(shù)據(jù)采集系統(tǒng)

2015 年開始，我們推出了第一代數(shù)據(jù)采集平臺(tái) Venus 1.0。數(shù)據(jù)來源于兩個(gè)方面，從客戶端端收集到的用戶觀看視頻的行為數(shù)據(jù)及后臺(tái)服務(wù)的日志數(shù)據(jù)。用戶數(shù)據(jù)從 PC、App 等客戶端采集投遞給平臺(tái)后端的 Nginx 接收器，并落盤到本地文件中，再由 Venus agent 解析文件進(jìn)行數(shù)據(jù)采集。服務(wù)日志數(shù)據(jù)是由機(jī)器上的 Venus agent 解析 log 文件采集。Venus 采集的數(shù)據(jù)直接上傳到 HDFS 進(jìn)行后續(xù)的離線 ETL 處理，生成離線報(bào)表供數(shù)據(jù)分析使用。

Venus 1.0 版本主要基于 Apache Flume 框架進(jìn)行開發(fā)，并通過 tail+grep、awk、sed 等腳本進(jìn)行數(shù)據(jù)過濾。在數(shù)據(jù)量較小時(shí)，該平臺(tái)很好的解決了數(shù)據(jù)處理的需求。

■ Venus 2.0 – 實(shí)時(shí)數(shù)據(jù)處理平臺(tái)

在 2017 年，隨著數(shù)據(jù)量的增長及實(shí)時(shí)業(yè)務(wù)需求的出現(xiàn)，Venus 1.0 漸漸變得力不從心。眾多業(yè)務(wù)需求導(dǎo)致 agent 上存在大量過濾規(guī)則，過多占用機(jī)器資源甚至影響到機(jī)器上服務(wù)的穩(wěn)定性。同時(shí)，每次變更都需要重啟所有 agents，大大提高上線成本及風(fēng)險(xiǎn)。

因此，我們?cè)O(shè)計(jì)實(shí)現(xiàn)了實(shí)時(shí)數(shù)據(jù)處理平臺(tái) Venus 2.0 版本，將實(shí)時(shí)過濾功能從 Venus agent 遷移到 Flink 中并采用兩級(jí) Kafka 結(jié)構(gòu)。改進(jìn)后的數(shù)據(jù)平臺(tái)無需重啟即可動(dòng)態(tài)增減數(shù)據(jù)處理規(guī)則，數(shù)據(jù)處理能力也提升了 10 倍以上，大大優(yōu)化了平臺(tái)的實(shí)時(shí)效果。

■ Venus 3.0 – 實(shí)時(shí)數(shù)據(jù)生產(chǎn)平臺(tái)

隨著實(shí)時(shí)業(yè)務(wù)的大量增加，Venus 2.0 也帶來了 Kafka 數(shù)據(jù)冗余、不方便分享等問題，我們?cè)?2019 年進(jìn)行了第三次改造，從數(shù)據(jù)處理升級(jí)到數(shù)據(jù)生產(chǎn)，推出了實(shí)時(shí)數(shù)據(jù)生產(chǎn)平臺(tái) Venus 3.0 版本。

用戶可以在新平臺(tái)上配置實(shí)時(shí)數(shù)據(jù)處理規(guī)則，并可自由組合 Filter、Split、Window 等常見算子，生產(chǎn)出來的流數(shù)據(jù)可以存儲(chǔ)到流式數(shù)倉里。流式數(shù)倉是我們參考離線數(shù)倉概念打造的基于 Kafka 的數(shù)據(jù)倉庫，用于以數(shù)據(jù)倉庫的形式統(tǒng)一管理流數(shù)據(jù)。

借助實(shí)時(shí)數(shù)據(jù)生產(chǎn)平臺(tái)及流式數(shù)倉，用戶可以更加便捷地加工實(shí)時(shí)流數(shù)據(jù)，并通過業(yè)務(wù)線間的數(shù)據(jù)分享來減少流數(shù)據(jù)的重復(fù)生產(chǎn)。

3.3 實(shí)時(shí)數(shù)據(jù)分析平臺(tái)

RAP(Realtime Analysis Platform)是愛奇藝基于 Apache Druid + Spark / Flink 構(gòu)建的分鐘級(jí)延時(shí)的實(shí)時(shí)分析平臺(tái)，支持通過 web 向?qū)渲猛瓿沙笠?guī)模實(shí)時(shí)數(shù)據(jù)的多維度分析，為用戶提供一體化的 OLAP 分析操作流程，只需要幾步簡單的配置，即可自動(dòng)建立 OLAP 模型、生成分鐘級(jí)延時(shí)的可視化報(bào)表，并提供實(shí)時(shí)報(bào)警功能。

RAP 實(shí)時(shí)分析平臺(tái)解決了用戶在數(shù)據(jù)分析中遇到的幾個(gè)困難：

1.OLAP 選型困難：愛奇藝目前提供了 Kylin、Impala、Kudu、Druid、ElasticSearch 等不同的數(shù)據(jù)存儲(chǔ)/查詢引擎，用戶需要了解不同 OLAP 引擎的優(yōu)缺點(diǎn)，花費(fèi)大量精力學(xué)習(xí)，依然可能選錯(cuò)。RAP 幫用戶屏蔽了這層，無需考慮中間數(shù)據(jù)、結(jié)果數(shù)據(jù)存到哪里、怎么查詢。2. 開發(fā)成本高：用戶需要寫 Spark 或 Flink 代碼進(jìn)行實(shí)時(shí)流數(shù)據(jù)處理，并進(jìn)行報(bào)表前端開發(fā)，流程冗長而復(fù)雜。在 RAP 實(shí)時(shí)分析平臺(tái)上，用戶無需編寫Spark/Flink 程序或 SQL，只需要通過 web 配置處理規(guī)則、分析規(guī)則、報(bào)表模板、報(bào)警規(guī)則即可，大幅降低開發(fā)門檻，提升了開發(fā)效率，從以往的幾天開發(fā)一張報(bào)表縮短到半小時(shí)。3. 數(shù)據(jù)實(shí)時(shí)性差：從數(shù)據(jù)產(chǎn)生到數(shù)據(jù)可被查詢，中間存在較高時(shí)延(從數(shù)十分鐘到天級(jí)別不等)，且查詢較慢。借助于 Flink 的實(shí)時(shí)處理能力，RAP 實(shí)現(xiàn)了端到端分鐘級(jí)低延時(shí)的實(shí)時(shí)報(bào)表功能，且支持大規(guī)模數(shù)據(jù)亞秒級(jí)查詢。

維護(hù)耗費(fèi)時(shí)間：數(shù)據(jù)源發(fā)生改變時(shí)，修改的范圍會(huì)覆蓋整個(gè)流程，從數(shù)據(jù)處理到報(bào)表配置全部需要變更，很難操作和維護(hù)。RAP 提供了自動(dòng)更新功能，幫助用戶免去人工維護(hù)的麻煩。

RAP 實(shí)時(shí)分析平臺(tái)架構(gòu)圖：

4.Flink 業(yè)務(wù)案例

4.1 信息流推薦實(shí)時(shí)化

愛奇藝很早就開始了基于網(wǎng)格式的長視頻推薦業(yè)務(wù)，近幾年隨著短視頻的興起，信息流形式的推薦發(fā)展迅速。信息流場景里，需要在幾秒內(nèi)根據(jù)用戶的觀看行為實(shí)時(shí)推薦相關(guān)性更高的視頻，對(duì)數(shù)據(jù)的時(shí)效性要求更高。

原本基于 Spark Streaming 的實(shí)時(shí)數(shù)據(jù)處理架構(gòu)無法滿足這類低延遲的需求，因此，我們協(xié)助業(yè)務(wù)遷移到 Flink 平臺(tái)上，消除了批量數(shù)據(jù)處理帶來的延遲。單個(gè)任務(wù)的延遲從 1 分鐘縮短到 1-2 秒，端到端的性能提升了 86 倍，顯著提升了推薦效果。

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

深度學(xué)習(xí)大量應(yīng)用于愛奇藝內(nèi)部的各項(xiàng)業(yè)務(wù)，幫助業(yè)務(wù)更好的挖掘數(shù)據(jù)的價(jià)值。在深度學(xué)習(xí)場景中，訓(xùn)練數(shù)據(jù)的時(shí)效性非常關(guān)鍵。我們使用 Flink 幫助業(yè)務(wù)更加實(shí)時(shí)地生產(chǎn)訓(xùn)練數(shù)據(jù)。

下圖所示為愛奇藝廣告點(diǎn)擊率預(yù)測訓(xùn)練的架構(gòu)，業(yè)務(wù)原先通過 Hive/Spark 離線 ETL 方式生成訓(xùn)練數(shù)據(jù)，每 6 小時(shí)才能更新一次算法模型，導(dǎo)致用戶特征關(guān)聯(lián)不及時(shí)、不精確，影響到廣告投放效果。

我們基于 Flink 進(jìn)行了實(shí)時(shí)化改造，將最近 24 小時(shí)的用戶數(shù)據(jù)實(shí)時(shí)寫到 Kafka 中，通過 Flink 與存儲(chǔ)在 HBase 中的過去 7 天的用戶特征進(jìn)行實(shí)時(shí) join，實(shí)時(shí)產(chǎn)出包含最新用戶特征的訓(xùn)練數(shù)據(jù)，將算法模型更新周期縮短到 1 小時(shí)以內(nèi)，從而支持更加實(shí)時(shí)、精確的 CTR (Click-Through-Rate)預(yù)估，大幅提升廣告投放效果。

4.3 端到端 Exactly-Once 處理

當(dāng) Kafka 節(jié)點(diǎn)出現(xiàn)故障重啟或進(jìn)行人工運(yùn)維時(shí)，Flink 作業(yè)會(huì)重復(fù)消費(fèi)數(shù)據(jù)導(dǎo)致數(shù)據(jù)失準(zhǔn)，影響后續(xù)的數(shù)據(jù)處理，比如模型訓(xùn)練。針對(duì)該問題，我們?cè)O(shè)計(jì)實(shí)現(xiàn)了基于 Kafka Exactly Once Semantics 及 Flink two-phase commit 特性的端到端 Exactly-Once 處理方案。經(jīng)過我們測試，該方案會(huì)帶來 20% 的計(jì)算性能損耗，但數(shù)據(jù)重復(fù)率會(huì)從原先的最高 300% 降低到 0，很好地解決了節(jié)點(diǎn)重啟帶來的數(shù)據(jù)精確度問題。

關(guān)于 Exactly-once two-phase commit 的原理，可以閱讀 Apache Flink Blog 上的詳細(xì)介紹：

https://flink.apache.org/features/2018/03/01/end-to-end-exactly-once-apache-flink.html

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

隨著 Flink 在愛奇藝得到越來越廣泛的應(yīng)用，我們?cè)谫Y源管理、穩(wěn)定性、實(shí)時(shí)開發(fā)等層面面臨新的挑戰(zhàn)。

接下來，我們會(huì)推進(jìn)流批一體化，進(jìn)一步完善和推廣 StreamingSQL 技術(shù)，降低開發(fā)門檻。同時(shí)，積極嘗試基于 Flink 的機(jī)器學(xué)習(xí)、Flink on Kubernetes、Flink 動(dòng)態(tài)資源調(diào)整等前沿方向。

總結(jié)

以上是生活随笔為你收集整理的kylin如何支持flink_日均万亿条数据如何处理？爱奇艺实时计算平台这样做的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。