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

1. 發掘數據中的信息來指導決策，如產品運營、用戶增長相關的BI報表
2. 依托數據優化用戶體驗和變現效率，如信息分發場景下的個性化推薦、效果廣告等
3. 基于數據統計的業務監控，如監控大盤、安全風控等

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

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

一、傳統實時ETL模式的問題

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

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

• 實時數據大量重復生產，各業務煙囪式開發，數據難以復用
• 數據治理水平低下，數據生產者不知道數據在被誰消費
• 穩定性差，不能抵御Flink和Kafka故障

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

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

在傳統的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層，減少實時數據在數倉層的加工處理。

三、流數據服務平臺

實時數倉的載體是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服務的高度治理化是實時數倉工作的基礎，下一步要建設的是構建實時數倉的工具平臺，通過平臺降低用戶開發管理實時數據處理任務的成本。

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

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

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

五、實時分析平臺

在實時大數據的下游業務場景中，實時報表和實時分析是最普遍的一種需求場景。傳統的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圖表輸出等功能，方便用戶快速接入使用。 

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

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

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

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

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

七、未來展望

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

• 流批一體：在存儲和計算兩個方向上探索流批一體的應用場景，逐漸替代傳統MapReduce/Spark離線任務的數倉構建，圍繞Flink引擎構建流批一體的數倉體系。
• 湖倉一體：打通實時流灌入數據湖(Iceberg)的數據通路，依托實時更新的數據湖體系，支持更多更豐富的OLAP業務場景
• ETL->ELT：引導實時數倉的架構變遷，將實時數據構建環節中的部分計算轉移到實時數倉下游的OLAP體系和數據湖中，依托OLAP引擎的強大性能來滿足用戶的過濾/聚合等需求，將實時數倉的鏈路做短，提升實時數據的質量和穩定性、降低延遲。
• BI+AI：打通實時數據生產->實時特征生產->在線模型訓練->線上推理的鏈路，方便用戶一站式的實現從數據準備到AI算法模型訓練的相關工作。

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