日均万亿条数据如何处理？爱奇艺实时计算平台这样做
摘要：本文由愛奇藝大數據服務負責人梁建煌分享，介紹愛奇藝如何基于 Apache Flink 技術打造實時計算平臺，并通過業務應用案例分享幫助用戶了解 Apache Flink 的技術特點及應用場景。提綱如下：
1.愛奇藝 Flink 服務現狀
愛奇藝從 2012 年開始開展大數據業務，一開始只有二十幾個節點，主要是 MapReduce、Hive 等離線計算任務。到 2014 年左右上線了 Storm、Spark 實時計算服務，并隨后發布了基于 Spark 的實時計算平臺 Europa。2017 年開始引入 Flink，用來替代部分 Spark Streaming 場景，滿足更低延遲的實時計算需求。在這之后，相繼推出流式 SQL 引擎、實時分析平臺、實時數據生產平臺等一系列工具，用來提升實時計算開發效率。
目前公司內 Flink 類型節點機器 15000 多臺，主要有兩種部署模式：
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 的依賴鏈：
2.3 StreamingSQL
為了便于用戶開發流任務，愛奇藝自研了支持 Spark、Flink 的流式 SQL 引擎 StreamingSQL。用戶只需要通過編寫 SQL 即可完成流計算 ETL 任務的開發。同時，我們也提供 IDE 編輯器和大量常用的預定義函數。
StreamingSQL 定義了 4 種類型數據表：
- 流表：定義計算邏輯的輸入，目前支持Kafka
- 維度表：靜態表，用于與流表join，比如字典映射
- 臨時表：定義中間結果，簡化子查詢邏輯
- 結果表：定義計算邏輯的輸出
數據從流表流入，通過一系列 SQL 語句描述的計算，計算結果寫入結果表。對于計算邏輯比較復雜的計算，可能需要定義多層嵌套的子查詢對計算邏輯進行描述，此時可以通過定義臨時表，將計算邏輯進行拆分，降低子查詢嵌套的深度。
下圖展示了 StreamingSQL 例子：
3.實時計算平臺
愛奇藝從 2015 年開始陸續推出實時計算管理、實時數據生產、實時數據分析等多個平臺，滿足作業開發、數據生產、數據分析等不同場景下的開發需求，提升用戶的使用體驗和開發效率。
3.1 實時計算管理平臺
實時計算管理平臺用于 Spark、Flink 任務的開發與管理。用戶可以在 Web IDE 上配置相關參數進行任務的開發、上傳、啟動、停止等常規操作。計算管理平臺提供了大量管理模塊以提高用戶的操作體驗，主要包括以下幾項：
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 實現了端到端分鐘級低延時的實時報表功能，且支持大規模數據亞秒級查詢。
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/features/2018/03/01/end-to-end-exactly-once-apache-flink.html
5.挑戰與規劃
隨著 Flink 在愛奇藝得到越來越廣泛的應用，我們在資源管理、穩定性、實時開發等層面面臨新的挑戰。
接下來，我們會推進流批一體化，進一步完善和推廣 StreamingSQL 技術，降低開發門檻。同時，積極嘗試基于 Flink 的機器學習、Flink on Kubernetes、Flink 動態資源調整等前沿方向。
作者介紹：
梁建煌，愛奇藝大數據服務負責人，2012-碩士畢業于上海交通大學后，先后在 SAP、愛奇藝工作，從 2013 年起開始負責愛奇藝大數據服務體系的建設工作，包括大數據存儲、計算、OLAP 以及開發平臺等。
原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。
總結
以上是生活随笔為你收集整理的日均万亿条数据如何处理？爱奇艺实时计算平台这样做的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Nexus协议，闲鱼一体化开发的幕后玩家
- 下一篇： 阿里云正式推出内容平台“云栖号”：全面助