愛奇藝大數據生態的實時化建設

數據作爲互聯網時代的基礎生產資料，在各大公司企業擁有舉足輕重的地位。數據的價值在互聯網公司的體現，大致而言可以分成三類：

（1）發掘數據中的信息來指導決策，如產品運營、用戶增長相關的 BI 報表

（2）依託數據優化用戶體驗和變現效率，如信息分發場景下的個性化推薦、效果廣告等

（3）基於數據統計的業務監控，如監控大盤、安全風控等

在這些體現大數據價值的業務場景上，存在一個普遍的規律，即數據產生的價值，隨着時間的推移而衰減。因此，隨着公司業務的發展，傳統的 T+1 式（隔日）的離線大數據模式越來越無法滿足新興業務的發展需求。開展實時化的大數據業務，是企業深入挖掘數據價值的一條必經之路。

愛奇藝大數據團隊自 2014 年開始引入 Kafka、Storm、Spark Streaming 等實時化技術，2017 年引入 Apache Flink 實時計算框架，逐步建設了一套打通數據採集、加工、分發、分析、應用等完整數據流程的實時大數據體系。這套實時大數據體系支持了峯值超過 3000 萬 QPS 的實時數據處理，支持瞭如春晚直播、青春有你、尖叫之夜等大型活動的實時計算需求。本文將介紹愛奇藝實時大數據體系的主要架構、平臺功能以及發展過程中的一些思考。

01

在實時技術發展初期，大團隊爲各業務提供的是單純的日誌數據的實時解析服務。通過 Flink ETL 程序，將用戶端上報日誌、後臺服務器日誌、數據庫 binlog 日誌，解析成 key-value 組裝的 json 形態的結構化數據，發送到 Kafka 中供各業務使用。其中，ETL 邏輯可以由外部配置平臺注入，方便在解析邏輯修改時可以動態加載，減少 Flink 任務的重啓頻率。這個實時 ETL 的體系如下圖所述：

隨着實時大數據業務的發展，它的弊端不斷出現：

（1）實時數據大量重複生產，各業務煙囪式開發，數據難以複用

（2）數據治理水平低下，數據生產者不知道數據在被誰消費

（3）穩定性差，不能抵禦 Flink 和 Kafka 故障

爲了解決這些問題，愛奇藝大數據團隊開始建設實時大數據體系，推出管理 Kafka 的流數據服務平臺、基於 Flink 的實時數據生產平臺、基於 Kafka 的實時數倉等組件，打通實時數據流程。

02

實時數倉與傳統數倉的區別

在傳統的 BI 體系中，基於離線大數據構建數據倉庫的過程，大部分是 T+1 的隔日離線計算。即每天凌晨開始從原始日誌數據構建數倉，將多層級的離線計算任務，通過工作流系統進行串聯。數倉構建任務失敗後可以有由工作流系統觸發任務重跑。一般來說，離線數倉構建任務的失敗重跑，隻影響數據生產出來的時間，不影響數據的完整性、正確性。

在設計離線數倉模型和對應的計算任務時，一般會從以下幾個角度去兼顧平衡：

（1）數據膨脹的成本約束（Hive 存儲）

（2）計算資源的成本約束（YARN 隊列）

（3）開發的人力成本約束

（4）用戶體驗，包含數據的時效性以及數倉表使用的便捷性

在實時數倉中，這幾個約束條件發生了巨大的變化：

基於這些變化，構建實時數倉的時候，切記不能照搬離線數倉的分層模型和構建邏輯，需要結合實時大數據業務的需求，按照實時業務的特點進行構建。實時數倉的構建，核心有以下幾個特點：

1、重視數倉的水平拆分。在離線數倉中，數據的載體是 Hive 表，藉助 Hive 的分區字段和謂詞下推機制，我們可以在各個層級構建一些稍大的表，而將關鍵的維度字段設置成分區，使用戶在查大表的時候達到查小表的效果。在實時數倉中，數據的載體是 Kafka 隊列，如果向用戶提供一個大流，需要用戶在消費數據實時過濾出其中的一小部分數據進行使用，那麼對 Kafka 的帶寬資源和 Flink 的計算資源都是極大的浪費。因此，我們需要儘量將常用的維度進行水平拆分構建，例如 “移動端用戶行爲”“PC 端用戶行爲” 可以拆分到兩個流供用戶使用。

2、重視維度退化。在離線數倉中，一個維度放在事實表裏還是放在維度表裏是一件可權衡的事情。一些不太常用的維度可以保留在維度表裏，讓用戶查詢使用時再進行 Join。而在實時數倉裏，用戶在使用數據時如果需要進行 “實時流 Join 維度表” 的操作，涉及實時計算中比較複雜的流與外部表 Join 的操作，對應的 Flink 代碼開發和優化難度都較高。因此，在建設實時數倉時應該儘量幫助數據下游方減少這些代價，提前將會用到的維度退化到數倉的事實流中，將實時流變成一個寬流，避免下游業務方在使用數據時，自行去處理流 Join 外部表的這類複雜場景。

3、重視層級縮短。在實時數倉的構建過程中，數據在多層級 Kafka 中傳遞，數據處理的鏈路越長，數據的延遲越大、穩定性越差。因此，在實時數倉中，要儘可能引導用戶使用短鏈路生產的實時數據。我們建議，實時數倉下游使用的數據，在數倉構建中經過的 Kafka 層級最好控制在 4 層以內，例如在 ODS 層、DWD 層之後，最多再加工一次就可以交付用戶使用。在很多實時報表的場景上，我們可以選擇將 DWD 層的實時數據灌入 OLAP 體系（如 Druid、Clickhouse），將用戶的數據清洗過濾聚合需求轉移到 OLAP 層，減少實時數據在數倉層的加工處理。

03

流數據服務平臺

實時數倉的載體是 Kafka 服務，然而，Kafka 作爲一個分佈式消息隊列，它原生的組織和管理方式仍然是一個資源型服務，向用戶交付的是 Kafka 集羣。這種管理組織方式對於開展實時大數據業務而言，有一些顯著的缺點，例如難以註冊和管理數據的輸入和輸出，無法構建數據血緣鏈路和高可用體系等等。

爲了更好地支持實時數倉等業務的開展，愛奇藝大數據團隊建設了流數據服務平臺，以一種面向數據的角度，重新組織和管理 Kafka 服務。

流數據服務平臺，自下而上分爲三層：

1、運維管理層：負責 Kafka、Pulsar、RocketMQ 等消息隊列集羣的資源和運維管理，包括資產登記、容量管理、集羣監控、自動化運維、工單審批體系等。

2、流數據管理層：負責登記和管理所有流數據的元信息，面向用戶提供數據地圖（檢索尋找數據）、數據質量監控（生產延遲、消費積壓等等）、數據血緣追蹤、一鍵 HA 切換集羣等功能。

3、客戶端 SDK 層：封裝原生 Kafka Client，向用戶提供 Flink、Spark、Java 等場景下的 Kafka SDK，將讀寫操作全部封裝在 SDK 中，對用戶屏蔽 Kafka 集羣版本和地址信息，由 SDK 通過心跳向配置中心獲取數據地址。同時 SDK 還具備生產消費任務的自動登記註冊、Kafka 切換時觸發任務重啓等功能。

依託流數據服務平臺，我們大幅提升了 Kafka 的運維管理和服務提供能力：

1、基於 SDK 的訪問控制模式，極大提高了實時大數據的治理水平。用戶看到和訪問的都是流數據，無需再關心 Kafka 集羣和地址等信息。

2、在 Kafka 集羣發生故障災難時，運維人員可以簡單的在後臺切換數據流對應的 Kafka 集羣，生產消費兩側的流任務同時重啓，即可將故障的 Kafka 從鏈路中摘除，替換成備用的 Kafka 集羣。

3、流數據服務平臺能根據 SDK 上報的信息，分析並繪製數據血緣，用於數據鏈路排障、數據熱度分析、數倉模型優化。

4、依託流數據的元數據中心，提供數據地圖的產品，供用戶方便的查詢檢索數據及其 Schema 相關信息，提高流數據的複用性。

附圖：Kafka 故障時，通過 SDK 使讀寫兩側流量請快速切換到備集羣

04

 實時數據生產分發平臺

Kafka 服務的高度治理化是實時數倉工作的基礎，下一步要建設的是構建實時數倉的工具平臺，通過平臺降低用戶開發管理實時數據處理任務的成本。

愛奇藝大數據團隊建設了實時數據生產分發平臺 Talos。Talos 平臺兼具實時數據處理和數據集成分發功能，支持用戶通過自定義數據處理邏輯，將實時數據加工處理後分發到下游數據流或其他異構存儲中。

Talos 平臺上，用戶可以通過簡單拖拽生成 DAG 圖的方式構建自己的數據處理邏輯，也可以通過 SQL 算子來表達處理邏輯。對於實時計算的新手用戶，使用 DAG 圖可以直觀看到數據的處理邏輯和含義。在調試任務時，Talos 平臺支持查看數據在 DAG 圖中每一步的變化值，非常有利於排查複雜數據處理邏輯中的問題，解決了傳統 Flink SQL 任務調試不便的痛點。

附圖：通過拖拽算子形成 DAG 圖的方式構建數據處理邏輯

在愛奇藝的實時數倉體系中，實時數據的接入、處理、分發任務都通過 Talos 平臺構建和維護，數倉建設者只需要關心數倉模型的定義和設計，無需撰寫 Flink 代碼，也不用關心 Flink 實時計算任務的提交管理和運維監控等工作，極大的簡化了數倉的開發和維護成本。

05

實時分析平臺

在實時大數據的下游業務場景中，實時報表和實時分析是最普遍的一種需求場景。傳統的 Kafka->Flink SQL/Spark SQL->MySQL 的實時報表模式只適用於一些指標固定的實時報表，欠缺靈活性。

愛奇藝大數據團隊基於 Druid+Spark/Flink 建設了一套實時分析平臺（Realtime Analytics Platform，簡稱 RAP）, 打通了實時數倉到實時分析的鏈路，大幅簡化了實時報表的生產和使用成本。

在 RAP 平臺中，我們將實時數倉中生成的 Kafka 流，通過 Druid 的 Kafka Index Service (簡稱 KIS) 直接導入 Druid。用戶通過平臺提供的 Web 嚮導配置，自動建立 OLAP 模型、查詢統計條件，即可生產對應的實時報表。同時，平臺也提供瞭如 Ad-hoc 分析、實時指標報警、實時數據發佈、Grafana 圖表輸出等功能，方便用戶快速接入使用。

更多關於 RAP 平臺的介紹，可以閱讀《愛奇藝大數據實時分析平臺的建設與實踐》

06

愛奇藝實時大數據的主要應用

依託以上這些平臺建設，實時大數據技術在愛奇藝各個業務線都實現了落地。主要有三種典型的應用場景，即實時監控、實時數據分析、在線學習訓練等。

在實時監控場景中，用戶可以依託實時大盤進行指標觀察，或者將關鍵指標配置成實時監控報警，也可以將實時日誌流灌入 Elasticsearch 等系統中進行實時日誌查詢等。

在實時數據分析場景中，比較典型的是實時運營。通過實時大數據體系，爲運營部門提供更實時的運營效果數據，從而可以及時調整內容運營策略，進行流量資源再分配，助力用戶增長。

除了 BI 報表和分析類場景外，實時數據在效果廣告、信息流推薦等場景上也有大量落地，幫助推薦、廣告等團隊實現近線 / 在線機器學習、模型快速迭代、AB 測試結果的實時觀察統計等。

07

未來展望

隨着公司業務的發展，實時大數據的需求場景逐漸多樣化，愛奇藝實時大數據體系會朝着以下幾個方向繼續迭代：

1、流批一體：在存儲和計算兩個方向上探索流批一體的應用場景，逐漸替代傳統 MapReduce/Spark 離線任務的數倉構建，圍繞 Flink 引擎構建流批一體的數倉體系。

2、湖倉一體：打通實時流灌入數據湖（Iceberg）的數據通路，依託實時更新的數據湖體系，支持更多更豐富的 OLAP 業務場景

3、ETL->ELT：引導實時數倉的架構變遷，將實時數據構建環節中的部分計算轉移到實時數倉下游的 OLAP 體系和數據湖中，依託 OLAP 引擎的強大性能來滿足用戶的過濾 / 聚合等需求，將實時數倉的鏈路做短，提升實時數據的質量和穩定性、降低延遲。

4、BI+AI：打通實時數據生產 -> 實時特徵生產 -> 在線模型訓練 -> 線上推理的鏈路，方便用戶一站式的實現從數據準備到 AI 算法模型訓練的相關工作。

毫無疑問，實時化一定是大數據未來最重要的方向之一。愛奇藝大數據團隊會沿着上述這些方向繼續探索和發展，通過技術創新去支持和孵化更多落地的業務場景，繼續推動愛奇藝的數據和產品向着實時化的方向發展。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pOsDl6Ird9fhmYYlRhIyYA