簡介：實(shí)時(shí)化是大數(shù)據(jù)未來最重要的方向之一。

作者｜愛奇藝大數(shù)據(jù)團(tuán)隊(duì)

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

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

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

基于數(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)：

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

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

穩(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ì)算任務(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ù)倉模型和對應(yīng)的計(jì)算任務(wù)時(shí)，一般會(huì)從以下幾個(gè)角度去兼顧平衡：

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

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

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

用戶體驗(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è)層級構(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)行使用，那么對 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 的操作，對應(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、重視層級縮短。在實(shí)時(shí)數(shù)倉的構(gòu)建過程中，數(shù)據(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 層級最好控制在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 集群。這種管理組織方式對于開展實(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 中，對用戶屏蔽 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ù)提供能力：

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

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

流數(shù)據(jù)服務(wù)平臺(tái)能根據(jù) SDK 上報(bào)的信息，分析并繪制數(shù)據(jù)血緣，用于數(shù)據(jù)鏈路排障、數(shù)據(jù)熱度分析、數(shù)倉模型優(yōu)化。

依托流數(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á)處理邏輯。對于實(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ū)渲?#xff0c;自動(dòng)建立 OLAP模型、查詢統(tǒng)計(jì)條件，即可生產(chǎn)對應(yīng)的實(shí)時(shí)報(bào)表。同時(shí)，平臺(tái)也提供了如 Ad-hoc 分析、實(shí)時(shí)指標(biāo)報(bào)警、實(shí)時(shí)數(shù)據(jù)發(fā)布、Grafana 圖表輸出等功能，方便用戶快速接入使用。

更多關(guān)于 RAP 平臺(tái)的介紹，可以閱讀《愛奇藝大數(shù)據(jù)實(shí)時(shí)分析平臺(tái)的建設(shè)與實(shí)踐》。

六、愛奇藝實(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ù)迭代：

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

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

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)定性、降低延遲。

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ā)展。

原文鏈接：https://developer.aliyun.com/article/783255?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的爱奇艺大数据生态的实时化建设的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。