數(shù)據(jù)作為互聯(lián)網(wǎng)時代的基礎(chǔ)生產(chǎn)資料，在各大公司企業(yè)擁有舉足輕重的地位。數(shù)據(jù)的價值在互聯(lián)網(wǎng)公司的體現(xiàn)，大致而言可以分成三類：

1. 發(fā)掘數(shù)據(jù)中的信息來指導(dǎo)決策，如產(chǎn)品運營、用戶增長相關(guān)的BI報表
2. 依托數(shù)據(jù)優(yōu)化用戶體驗和變現(xiàn)效率，如信息分發(fā)場景下的個性化推薦、效果廣告等
3. 基于數(shù)據(jù)統(tǒng)計的業(yè)務(wù)監(jiān)控，如監(jiān)控大盤、安全風(fēng)控等

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

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

一、傳統(tǒng)實時ETL模式的問題

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

隨著實時大數(shù)據(jù)業(yè)務(wù)的發(fā)展，它的弊端不斷出現(xiàn)：

• 實時數(shù)據(jù)大量重復(fù)生產(chǎn)，各業(yè)務(wù)煙囪式開發(fā)，數(shù)據(jù)難以復(fù)用
• 數(shù)據(jù)治理水平低下，數(shù)據(jù)生產(chǎn)者不知道數(shù)據(jù)在被誰消費
• 穩(wěn)定性差，不能抵御Flink和Kafka故障

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

二、實時數(shù)倉與傳統(tǒng)數(shù)倉的區(qū)別

在傳統(tǒng)的BI體系中，基于離線大數(shù)據(jù)構(gòu)建數(shù)據(jù)倉庫的過程，大部分是T+1的隔日離線計算。即每天凌晨開始從原始日志數(shù)據(jù)構(gòu)建數(shù)倉，將多層級的離線計算任務(wù)，通過工作流系統(tǒng)進行串聯(lián)。數(shù)倉構(gòu)建任務(wù)失敗后可以有由工作流系統(tǒng)觸發(fā)任務(wù)重跑。一般來說，離線數(shù)倉構(gòu)建任務(wù)的失敗重跑，只影響數(shù)據(jù)生產(chǎn)出來的時間，不影響數(shù)據(jù)的完整性、正確性。

在設(shè)計離線數(shù)倉模型和對應(yīng)的計算任務(wù)時，一般會從以下幾個角度去兼顧平衡：

1. 數(shù)據(jù)膨脹的成本約束(Hive存儲)
2. 計算資源的成本約束(YARN隊列)
3. 開發(fā)的人力成本約束
4. 用戶體驗，包含數(shù)據(jù)的時效性以及數(shù)倉表使用的便捷性

在實時數(shù)倉中，這幾個約束條件發(fā)生了巨大的變化：

基于這些變化，構(gòu)建實時數(shù)倉的時候，切記不能照搬離線數(shù)倉的分層模型和構(gòu)建邏輯，需要結(jié)合實時大數(shù)據(jù)業(yè)務(wù)的需求，按照實時業(yè)務(wù)的特點進行構(gòu)建。實時數(shù)倉的構(gòu)建，核心有以下幾個特點：

1. 重視數(shù)倉的水平拆分。在離線數(shù)倉中，數(shù)據(jù)的載體是Hive表，借助Hive的分區(qū)字段和謂詞下推機制，我們可以在各個層級構(gòu)建一些稍大的表，而將關(guān)鍵的維度字段設(shè)置成分區(qū)，使用戶在查大表的時候達到查小表的效果。在實時數(shù)倉中，數(shù)據(jù)的載體是Kafka隊列，如果向用戶提供一個大流，需要用戶在消費數(shù)據(jù)實時過濾出其中的一小部分數(shù)據(jù)進行使用，那么對Kafka的帶寬資源和Flink的計算資源都是極大的浪費。因此，我們需要盡量將常用的維度進行水平拆分構(gòu)建，例如“移動端用戶行為”“PC端用戶行為”可以拆分到兩個流供用戶使用。
2. 重視維度退化。在離線數(shù)倉中，一個維度放在事實表里還是放在維度表里是一件可權(quán)衡的事情。一些不太常用的維度可以保留在維度表里，讓用戶查詢使用時再進行Join。而在實時數(shù)倉里，用戶在使用數(shù)據(jù)時如果需要進行“實時流Join維度表”的操作，涉及實時計算中比較復(fù)雜的流與外部表Join的操作，對應(yīng)的Flink代碼開發(fā)和優(yōu)化難度都較高。因此，在建設(shè)實時數(shù)倉時應(yīng)該盡量幫助數(shù)據(jù)下游方減少這些代價，提前將會用到的維度退化到數(shù)倉的事實流中，將實時流變成一個寬流，避免下游業(yè)務(wù)方在使用數(shù)據(jù)時，自行去處理流Join外部表的這類復(fù)雜場景。
3. 重視層級縮短。在實時數(shù)倉的構(gòu)建過程中，數(shù)據(jù)在多層級Kafka中傳遞，數(shù)據(jù)處理的鏈路越長，數(shù)據(jù)的延遲越大、穩(wěn)定性越差。因此，在實時數(shù)倉中，要盡可能引導(dǎo)用戶使用短鏈路生產(chǎn)的實時數(shù)據(jù)。我們建議，實時數(shù)倉下游使用的數(shù)據(jù)，在數(shù)倉構(gòu)建中經(jīng)過的Kafka層級最好控制在4層以內(nèi)，例如在ODS層、DWD層之后，最多再加工一次就可以交付用戶使用。在很多實時報表的場景上，我們可以選擇將DWD層的實時數(shù)據(jù)灌入OLAP體系(如Druid、Clickhouse)，將用戶的數(shù)據(jù)清洗過濾聚合需求轉(zhuǎn)移到OLAP層，減少實時數(shù)據(jù)在數(shù)倉層的加工處理。

三、流數(shù)據(jù)服務(wù)平臺

實時數(shù)倉的載體是Kafka服務(wù)，然而，Kafka作為一個分布式消息隊列，它原生的組織和管理方式仍然是一個資源型服務(wù)，向用戶交付的是Kafka集群。這種管理組織方式對于開展實時大數(shù)據(jù)業(yè)務(wù)而言，有一些顯著的缺點，例如難以注冊和管理數(shù)據(jù)的輸入和輸出，無法構(gòu)建數(shù)據(jù)血緣鏈路和高可用體系等等。

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

流數(shù)據(jù)服務(wù)平臺，自下而上分為三層：

1. 運維管理層：負責(zé)Kafka、Pulsar、RocketMQ等消息隊列集群的資源和運維管理，包括資產(chǎn)登記、容量管理、集群監(jiān)控、自動化運維、工單審批體系等。
2. 流數(shù)據(jù)管理層：負責(zé)登記和管理所有流數(shù)據(jù)的元信息，面向用戶提供數(shù)據(jù)地圖(檢索尋找數(shù)據(jù))、數(shù)據(jù)質(zhì)量監(jiān)控(生產(chǎn)延遲、消費積壓等等)、數(shù)據(jù)血緣追蹤、一鍵HA切換集群等功能。
3. 客戶端SDK層：封裝原生Kafka Client，向用戶提供Flink、Spark、Java等場景下的Kafka SDK，將讀寫操作全部封裝在SDK中，對用戶屏蔽Kafka集群版本和地址信息，由SDK通過心跳向配置中心獲取數(shù)據(jù)地址。同時SDK還具備生產(chǎn)消費任務(wù)的自動登記注冊、Kafka切換時觸發(fā)任務(wù)重啟等功能。

依托流數(shù)據(jù)服務(wù)平臺，我們大幅提升了Kafka的運維管理和服務(wù)提供能力：

1. 基于SDK的訪問控制模式，極大提高了實時大數(shù)據(jù)的治理水平。用戶看到和訪問的都是流數(shù)據(jù)，無需再關(guān)心Kafka集群和地址等信息。
2. 在Kafka集群發(fā)生故障災(zāi)難時，運維人員可以簡單的在后臺切換數(shù)據(jù)流對應(yīng)的Kafka集群，生產(chǎn)消費兩側(cè)的流任務(wù)同時重啟，即可將故障的Kafka從鏈路中摘除，替換成備用的Kafka集群。
3. 流數(shù)據(jù)服務(wù)平臺能根據(jù) SDK 上報的信息，分析并繪制數(shù)據(jù)血緣，用于數(shù)據(jù)鏈路排障、數(shù)據(jù)熱度分析、數(shù)倉模型優(yōu)化。
4. 依托流數(shù)據(jù)的元數(shù)據(jù)中心，提供數(shù)據(jù)地圖的產(chǎn)品，供用戶方便的查詢檢索數(shù)據(jù)及其Schema相關(guān)信息，提高流數(shù)據(jù)的復(fù)用性。 

四、實時數(shù)據(jù)生產(chǎn)分發(fā)平臺

Kafka服務(wù)的高度治理化是實時數(shù)倉工作的基礎(chǔ)，下一步要建設(shè)的是構(gòu)建實時數(shù)倉的工具平臺，通過平臺降低用戶開發(fā)管理實時數(shù)據(jù)處理任務(wù)的成本。

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

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

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

五、實時分析平臺

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

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

在RAP平臺中，我們將實時數(shù)倉中生成的Kafka流，通過Druid的Kafka Index Service (簡稱KIS) 直接導(dǎo)入Druid。用戶通過平臺提供的Web向?qū)渲茫詣咏LAP模型、查詢統(tǒng)計條件，即可生產(chǎn)對應(yīng)的實時報表。同時，平臺也提供了如Ad-hoc分析、實時指標報警、實時數(shù)據(jù)發(fā)布、Grafana圖表輸出等功能，方便用戶快速接入使用。 

六、愛奇藝實時大數(shù)據(jù)的主要應(yīng)用

依托以上這些平臺建設(shè)，實時大數(shù)據(jù)技術(shù)在愛奇藝各個業(yè)務(wù)線都實現(xiàn)了落地。主要有三種典型的應(yīng)用場景，即實時監(jiān)控、實時數(shù)據(jù)分析、在線學(xué)習(xí)訓(xùn)練等。

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

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

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

七、未來展望

隨著公司業(yè)務(wù)的發(fā)展，實時大數(shù)據(jù)的需求場景逐漸多樣化，愛奇藝實時大數(shù)據(jù)體系會朝著以下幾個方向繼續(xù)迭代：

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

毫無疑問，實時化一定是大數(shù)據(jù)未來最重要的方向之一。愛奇藝大數(shù)據(jù)團隊會沿著上述這些方向繼續(xù)探索和發(fā)展，通過技術(shù)創(chuàng)新去支持和孵化更多落地的業(yè)務(wù)場景，繼續(xù)推動愛奇藝的數(shù)據(jù)和產(chǎn)品向著實時化的方向發(fā)展。