資料作為網際網路時代的基礎生産資料，在各大公司企業擁有舉足輕重的地位。資料的價值在網際網路公司的展現，大緻而言可以分成三類：
- 發掘資料中的資訊來指導決策，如産品營運、使用者增長相關的 BI 報表
- 依托資料優化使用者體驗和變現效率，如資訊分發場景下的個性化推薦、效果廣告等
- 基于資料統計的業務監控，如監控大盤、安全風控等
在這些展現大資料價值的業務場景上，存在一個普遍的規律，即資料産生的價值，随着時間的推移而衰減。是以，随着公司業務的發展，傳統的 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 的隔日離線計算。即每天淩晨開始從原始日志資料建構數倉，将多層級的離線計算任務，通過工作流系統進行串聯。數倉建構任務失敗後可以有由工作流系統觸發任務重跑。一般來說，離線數倉建構任務的失敗重跑，隻影響資料生産出來的時間，不影響資料的完整性、正确性。
在設計離線數倉模型和對應的計算任務時，一般會從以下幾個角度去兼顧平衡：
- 資料膨脹的成本限制（Hive 存儲）
- 計算資源的成本限制（YARN 隊列）
- 開發的人力成本限制
- 使用者體驗，包含資料的時效性以及數倉表使用的便捷性
在實時數倉中，這幾個限制條件發生了巨大的變化：
基于這些變化，建構實時數倉的時候，切記不能照搬離線數倉的分層模型和建構邏輯，需要結合實時大資料業務的需求，按照實時業務的特點進行建構。實時數倉的建構，核心有以下幾個特點：
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 的運維管理和服務提供能力：
- 基于 SDK 的通路控制模式，極大提高了實時大資料的治理水準。使用者看到和通路的都是流資料，無需再關心 Kafka 叢集和位址等資訊。
- 在 Kafka 叢集發生故障災難時，運維人員可以簡單的在背景切換資料流對應的 Kafka 叢集，生産消費兩側的流任務同時重新開機，即可将故障的 Kafka 從鍊路中摘除，替換成備用的 Kafka 叢集。
- 流資料服務平台能根據 SDK 上報的資訊，分析并繪制資料血緣，用于資料鍊路排障、資料熱度分析、數倉模型優化。
- 依托流資料的中繼資料中心，提供資料地圖的産品，供使用者友善的查詢檢索資料及其 Schema 相關資訊，提高流資料的複用性。
附圖：Kafka 故障時，通過 SDK 使讀寫兩側流量請快速切換到備叢集
四、實時資料生産分發平台
Kafka 服務的高度治理化是實時數倉工作的基礎，下一步要建設的是建構實時數倉的工具平台，通過平台降低使用者開發管理實時資料處理任務的成本。
愛奇藝大資料團隊建設了實時資料生産分發平台 Talos。Talos 平台兼具實時資料處理和資料內建分發功能，支援使用者通過自定義資料處理邏輯，将實時資料加工處理後分發到下遊資料流或其他異構存儲中。
Talos 平台上，使用者可以通過簡單拖拽生成 DAG 圖的方式建構自己的資料處理邏輯，也可以通過 SQL 算子來表達處理邏輯。對于實時計算的新手使用者，使用 DAG 圖可以直覺看到資料的處理邏輯和含義。在調試任務時，Talos 平台支援檢視資料在 DAG 圖中每一步的變化值，非常有利于排查複雜資料處理邏輯中的問題，解決了傳統 Flink SQL 任務調試不便的痛點。
附圖：通過拖拽算子形成 DAG 圖的方式建構資料處理邏輯
在愛奇藝的實時數倉體系中，實時資料的接入、處理、分發任務都通過 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 圖表輸出等功能，友善使用者快速接入使用。
更多關于 RAP 平台的介紹，可以閱讀《愛奇藝大資料實時分析平台的建設與實踐》。
六、愛奇藝實時大資料的主要應用
依托以上這些平台建設，實時大資料技術在愛奇藝各個業務線都實作了落地。主要有三種典型的應用場景，即實時監控、實時資料分析、線上學習訓練等。
在實時監控場景中，使用者可以依托實時大盤進行名額觀察，或者将關鍵名額配置成實時監控報警，也可以将實時日志流灌入 Elasticsearch 等系統中進行實時日志查詢等。
在實時資料分析場景中，比較典型的是實時營運。通過實時大資料體系，為營運部門提供更實時的營運效果資料，進而可以及時調整内容營運政策，進行流量資源再配置設定，助力使用者增長。
除了 BI 報表和分析類場景外，實時資料在效果廣告、資訊流推薦等場景上也有大量落地，幫助推薦、廣告等團隊實作近線/線上機器學習、模型快速疊代、AB 測試結果的實時觀察統計等。
七、未來展望
- 流批一體：在存儲和計算兩個方向上探索流批一體的應用場景，逐漸替代傳統 MapReduce/Spark 離線任務的數倉建構，圍繞 Flink 引擎建構流批一體的數倉體系。
- 湖倉一體：打通實時流灌入資料湖（Iceberg）的資料通路，依托實時更新的資料湖體系，支援更多更豐富的 OLAP 業務場景
- ETL->ELT：引導實時數倉的架構變遷，将實時資料建構環節中的部分計算轉移到實時數倉下遊的 OLAP 體系和資料湖中，依托 OLAP 引擎的強大性能來滿足使用者的過濾/聚合等需求，将實時數倉的鍊路做短，提升實時資料的品質和穩定性、降低延遲。
- BI+AI：打通實時資料生産->實時特征生産->線上模型訓練->線上推理的鍊路，友善使用者一站式的實作從資料準備到AI算法模型訓練的相關工作。