愛奇藝大數(shù)據(jù)生態(tài)的實(shí)時(shí)化建設(shè)

大數(shù)據(jù)文摘授權(quán)轉(zhuǎn)載自愛奇藝技術(shù)產(chǎn)品團(tuán)隊(duì)

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

（1）發(fā)掘數(shù)據(jù)中的信息來指導(dǎo)決策，如產(chǎn)品運(yùn)營、用戶增長相關(guān)的BI報(bào)表

（2）依托數(shù)據(jù)優(yōu)化用戶體驗(yàn)和變現(xiàn)效率，如信息分發(fā)場景下的個(gè)性化推薦、效果廣告等

（3）基于數(shù)據(jù)統(tǒng)計(jì)的業(yè)務(wù)監(jiān)控，如監(jiān)控大盤、安全風(fēng)控等

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

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

傳統(tǒng)實(shí)時(shí)ETL模式的問題

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

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

（1）實(shí)時(shí)數(shù)據(jù)大量重復(fù)生產(chǎn)，各業(yè)務(wù)煙囪式開發(fā)，數(shù)據(jù)難以復(fù)用

（2）數(shù)據(jù)治理水平低下，數(shù)據(jù)生產(chǎn)者不知道數(shù)據(jù)在被誰消費(fèi)

（3）穩(wěn)定性差，不能抵御Flink和Kafka故障

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

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

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

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

（1）數(shù)據(jù)膨脹的成本約束（Hive存儲(chǔ)）

（2）計(jì)算資源的成本約束（YARN隊(duì)列）

（3）開發(fā)的人力成本約束

（4）用戶體驗(yàn)，包含數(shù)據(jù)的時(shí)效性以及數(shù)倉表使用的便捷性

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

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

1、重視數(shù)倉的水平拆分。在離線數(shù)倉中，數(shù)據(jù)的載體是Hive表，借助Hive的分區(qū)字段和謂詞下推機(jī)制，我們可以在各個(gè)層級(jí)構(gòu)建一些稍大的表，而將關(guān)鍵的維度字段設(shè)置成分區(qū)，使用戶在查大表的時(shí)候達(dá)到查小表的效果。在實(shí)時(shí)數(shù)倉中，數(shù)據(jù)的載體是Kafka隊(duì)列，如果向用戶提供一個(gè)大流，需要用戶在消費(fèi)數(shù)據(jù)實(shí)時(shí)過濾出其中的一小部分?jǐn)?shù)據(jù)進(jìn)行使用，那么對(duì)Kafka的帶寬資源和Flink的計(jì)算資源都是極大的浪費(fèi)。因此，我們需要盡量將常用的維度進(jìn)行水平拆分構(gòu)建，例如“移動(dòng)端用戶行為”“PC端用戶行為”可以拆分到兩個(gè)流供用戶使用。

2、重視維度退化。在離線數(shù)倉中，一個(gè)維度放在事實(shí)表里還是放在維度表里是一件可權(quán)衡的事情。一些不太常用的維度可以保留在維度表里，讓用戶查詢使用時(shí)再進(jìn)行Join。而在實(shí)時(shí)數(shù)倉里，用戶在使用數(shù)據(jù)時(shí)如果需要進(jìn)行“實(shí)時(shí)流Join維度表”的操作，涉及實(shí)時(shí)計(jì)算中比較復(fù)雜的流與外部表Join的操作，對(duì)應(yīng)的Flink代碼開發(fā)和優(yōu)化難度都較高。因此，在建設(shè)實(shí)時(shí)數(shù)倉時(shí)應(yīng)該盡量幫助數(shù)據(jù)下游方減少這些代價(jià)，提前將會(huì)用到的維度退化到數(shù)倉的事實(shí)流中，將實(shí)時(shí)流變成一個(gè)寬流，避免下游業(yè)務(wù)方在使用數(shù)據(jù)時(shí)，自行去處理流Join外部表的這類復(fù)雜場景。

3、重視層級(jí)縮短。在實(shí)時(shí)數(shù)倉的構(gòu)建過程中，數(shù)據(jù)在多層級(jí)Kafka中傳遞，數(shù)據(jù)處理的鏈路越長，數(shù)據(jù)的延遲越大、穩(wěn)定性越差。因此，在實(shí)時(shí)數(shù)倉中，要盡可能引導(dǎo)用戶使用短鏈路生產(chǎn)的實(shí)時(shí)數(shù)據(jù)。我們建議，實(shí)時(shí)數(shù)倉下游使用的數(shù)據(jù)，在數(shù)倉構(gòu)建中經(jīng)過的Kafka層級(jí)最好控制在4層以內(nèi)，例如在ODS層、DWD層之后，最多再加工一次就可以交付用戶使用。在很多實(shí)時(shí)報(bào)表的場景上，我們可以選擇將DWD層的實(shí)時(shí)數(shù)據(jù)灌入OLAP體系（如Druid、Clickhouse），將用戶的數(shù)據(jù)清洗過濾聚合需求轉(zhuǎn)移到OLAP層，減少實(shí)時(shí)數(shù)據(jù)在數(shù)倉層的加工處理。

流數(shù)據(jù)服務(wù)平臺(tái)

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

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

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

1、運(yùn)維管理層：負(fù)責(zé)Kafka、Pulsar、RocketMQ等消息隊(duì)列集群的資源和運(yùn)維管理，包括資產(chǎn)登記、容量管理、集群監(jiān)控、自動(dòng)化運(yùn)維、工單審批體系等。

2、流數(shù)據(jù)管理層：負(fù)責(zé)登記和管理所有流數(shù)據(jù)的元信息，面向用戶提供數(shù)據(jù)地圖（檢索尋找數(shù)據(jù)）、數(shù)據(jù)質(zhì)量監(jiān)控（生產(chǎn)延遲、消費(fèi)積壓等等）、數(shù)據(jù)血緣追蹤、一鍵HA切換集群等功能。

3、客戶端SDK層：封裝原生Kafka Client，向用戶提供Flink、Spark、Java等場景下的Kafka SDK，將讀寫操作全部封裝在SDK中，對(duì)用戶屏蔽Kafka集群版本和地址信息，由SDK通過心跳向配置中心獲取數(shù)據(jù)地址。同時(shí)SDK還具備生產(chǎn)消費(fèi)任務(wù)的自動(dòng)登記注冊、Kafka切換時(shí)觸發(fā)任務(wù)重啟等功能。

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

1、基于SDK的訪問控制模式，極大提高了實(shí)時(shí)大數(shù)據(jù)的治理水平。用戶看到和訪問的都是流數(shù)據(jù)，無需再關(guān)心Kafka集群和地址等信息。

2、在Kafka集群發(fā)生故障災(zāi)難時(shí)，運(yùn)維人員可以簡單的在后臺(tái)切換數(shù)據(jù)流對(duì)應(yīng)的Kafka集群，生產(chǎn)消費(fèi)兩側(cè)的流任務(wù)同時(shí)重啟，即可將故障的Kafka從鏈路中摘除，替換成備用的Kafka集群。

3、流數(shù)據(jù)服務(wù)平臺(tái)能根據(jù) SDK 上報(bào)的信息，分析并繪制數(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ù)用性。

附圖：Kafka故障時(shí)，通過SDK使讀寫兩側(cè)流量請快速切換到備集群

實(shí)時(shí)數(shù)據(jù)生產(chǎn)分發(fā)平臺(tái)

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

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

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

附圖：通過拖拽算子形成DAG圖的方式構(gòu)建數(shù)據(jù)處理邏輯

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

實(shí)時(shí)分析平臺(tái)

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

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

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

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

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

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

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

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

未來展望

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

1、流批一體：在存儲(chǔ)和計(jì)算兩個(gè)方向上探索流批一體的應(yīng)用場景，逐漸替代傳統(tǒng)MapReduce/Spark離線任務(wù)的數(shù)倉構(gòu)建，圍繞Flink引擎構(gòu)建流批一體的數(shù)倉體系。

2、湖倉一體：打通實(shí)時(shí)流灌入數(shù)據(jù)湖（Iceberg）的數(shù)據(jù)通路，依托實(shí)時(shí)更新的數(shù)據(jù)湖體系，支持更多更豐富的OLAP業(yè)務(wù)場景

3、ETL->ELT：引導(dǎo)實(shí)時(shí)數(shù)倉的架構(gòu)變遷，將實(shí)時(shí)數(shù)據(jù)構(gòu)建環(huán)節(jié)中的部分計(jì)算轉(zhuǎn)移到實(shí)時(shí)數(shù)倉下游的OLAP體系和數(shù)據(jù)湖中，依托OLAP引擎的強(qiáng)大性能來滿足用戶的過濾/聚合等需求，將實(shí)時(shí)數(shù)倉的鏈路做短，提升實(shí)時(shí)數(shù)據(jù)的質(zhì)量和穩(wěn)定性、降低延遲。

4、BI+AI：打通實(shí)時(shí)數(shù)據(jù)生產(chǎn)->實(shí)時(shí)特征生產(chǎn)->在線模型訓(xùn)練->線上推理的鏈路，方便用戶一站式的實(shí)現(xiàn)從數(shù)據(jù)準(zhǔn)備到AI算法模型訓(xùn)練的相關(guān)工作。

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

點(diǎn)「在看」的人都變好看了哦！