愛奇藝統一實時計算平臺建設

這是愛奇藝實時計算平臺的演變過程。

早期我們支援使用者透過指令碼和 Jar 包提交流任務，引擎以 Storm 和 Spark 為主。2017 年，我們引入了 Flink，並且意識到 SQL 相比 Jar 包在開發和運維上有著明顯優勢，於是我們提供了 SQL 開發平臺，支援使用者透過 SQL 開發流任務。

接下來隨著實時業務的爆發式增長，為了支援構建實時數倉，我們上線了低程式碼開發平臺，支援圖形化開發作業。今年我們對這些平臺進行了系統的整合，和最佳化設計，建設了統一的實時計算平臺 RCP。

實時計算平臺在愛奇藝實時資料體系中處於非常重要的一環，它支援使用者開發和管理流任務，實現資料的實時攝取、加工、分發。在建設 RCP 平臺之前，我們面臨這樣幾個問題：

我們希望透過 RCP 平臺達成三個目標：

上圖是 RCP 的整體架構，分為平臺層、解析引擎、計算框架、排程層、執行層。

平臺層使用者操作的入口，提供資料表的管理，作業的開發和運維功能；引擎層是作業的解析引擎。計算框架層是 Flink 和 Spark Streaming；排程層我們目前正在進行流批一體化建設，分別有流任務和批任務的排程器，負責任務的提交和狀態監控；任務執行層主要在自建叢集，少量在公有云上。

平臺建設的第一部分工作是作業開發，結合服務使用者的經驗，我們總結了以下四個痛點：

為了解決好這些問題，我們設計了全視角開發模式，讓使用者從三層不同的視角來看待資料。

下面詳細為大家介紹下全視角開發模式。

全視角開發上線後，使用這三種開發方式的使用者都比較多，它實現的效果有以下四點：

平臺建設的第二部分工作是資料來源管理，我們實現了一套資料統一整合方案，分為三個模組。

上圖是使用者在平臺上管理資料表的頁面，可以看到平臺支援使用者集中化的管理各類資料表，包括實時佇列，KV 庫，離線儲存等。每個資料表歸屬於某個專案，所有者負責維護，實現了專案間資料表的許可權隔離。其他專案的使用者，經過審批後，也能申請訪問這些資料表，從而實現共享。

訪問資料表的具體實現是在任務提交中完成的，使用者上線作業後，平臺會解析出作業使用的所有資料表和函式，查詢 Catalog，獲取資料表的具體資訊，然後從檔案伺服器獲取對應的 Connector Jar 和 UDF Jar，和引擎 Jar 一起提交。這個流程有這樣三個特點：

3. 平臺統一來完成了不同版本的適配和解決依賴衝突，減輕了使用者的開發負擔。

平臺建設的第三部分工作是任務管理，主要考慮任務的啟動、執行、故障和修復這四個階段的需求。

任務啟動時，要能指定消費位置，以及從之前的狀態恢復。任務執行時，需要對任務的執行狀態進行監控；能便捷查詢到執行指標和日誌。發生故障時，能及時發現併發出報警通知，最好平臺還能進行故障診斷。最後，還能有一些手段能修復或者減輕故障影響。

任務的啟停，我們做了如下最佳化。

任務執行時的狀態資料，平臺統一進行託管，使用者無需關心。停止時會自動觸發狀態儲存，再啟動時會嘗試從上次的狀態中恢復，最大程度避免狀態的丟失；任務啟動時支援使用者指定消費的位點，從而實現靈活消費。

在任務的執行管理中，指標和監控報警是非常重要的一環。

在整體的架構中，指標投遞和報警策略主要依賴 prometheus，報警通知依賴愛奇藝內部的報警服務實現。平臺支援了豐富的報警策略配置，包括流量的波動；資料來源的消費延遲；以及 CPU，記憶體相關的指標。報警訂閱方面支援靈活配置報警級別，通知策略等。另外，這一套架構我們同樣適配了 Spark 流任務。

任務日誌採集這部分，為了讓使用者更便捷地檢視日誌，平臺將所有任務的日誌進行了採集，透過 Log4j KafkaAppender 實時將任務日誌傳送到 Kafka，經過解析後，傳送到 ES，在 ES 中對任務名等欄位進行索引，在任務管理頁面上，使用者就能方便地檢索日誌了。

這套流程有這樣幾個特點：

目前 RCP 平臺上線了接近一年的時間，已經替代了全部舊的實時平臺。有來自各業務團隊的近 300 個開發者，他們在 RCP 上構建了 5000 多個實時任務，這些任務總共處理的資料流量峰值達到了 8 千萬條每秒，平臺日均處理萬億條資料。

我們公司傳統的數倉體系中，資料來源主要是愛奇藝各類 app 等終端的埋點日誌以及各個服務的後臺日誌，經過日誌採集服務分別採集到 Kafka 和 hdfs，形成實時和離線兩條資料生產線，最後提供給下游應用，這是典型的 Lambda 架構。

主要存在的問題是兩套資料生產線開發維護成本高，指標不一致，以及傳統實時，離線鏈路固有的問題。

為了解決這些問題，我們引入了 Iceberg, Flink CDC 等技術，構建了一個近實時的資料通路，我們是這樣定義它的：

計算方面，我們採用 Flink 作為統一的計算引擎，在 Flink 1.15 版本，已經提供了較為完備的流批統一 API，具備較成熟的批處理能力。

平臺側，RCP 正在支援流批一體化的開發，在開發時能分別配置兩種執行模式下 讀取資料來源的規則，比如批執行時按分割槽讀取資料表，流執行時讀取表的新增資料，分別進行批式執行和流式執行。從而實現一次開發，兩種方式執行。

在儲存上，我們目前以 Iceberg 作為近實時的儲存。它主要有三個特點：

引入 Iceberg 後，我們做了一些適配工作：對 Iceberg 表進行了平臺化管理。包括建表、配置資料的 TTL、檔案合併策略等等；支援構建近資料生產 Pipeline，比如分割槽寫入完成後可以生成 done 標記。增量消費時，可以進行延時監控；利用 alluxio 加速 Iceberg 表的查詢，在實際業務查詢中，起到了比較明顯的效果。

接下來是 MySQL 資料接入。很多業務資料在 MySQL 中的，為了對這些資料進行查詢分析，一般會把它們同步到大資料系統中。常見的做法會有兩個鏈路，存量資料透過離線方式同步到 Hive，增量資料實時同步到 ES，Kudu 等儲存中。

這個方案主要存在以下幾個問題：

經過調研，我們認為 Flink CDC 技術非常適合我們的場景，可以解決剛才提到的問題。主要考慮到它有以下幾個優勢：

為了將 Flink CDC 整合到 RCP 平臺，我們做了以下工作：將當時 Flink CDC 的版本和 Flink 1.15 做了適配；對 MySQL CDC 型別資料表進行了統一整合，平臺對接了 MySQL 服務，打通賬號和許可權流程，從而規範和簡化了使用者使用；解決了我們在實踐中遇到的資料同步失敗的問題。

下面我們對近實時架構做個總結。首先，它適用的場景是對資料時效性和資料分析範圍，這兩個需求比較均衡的業務。即時效性不要求秒級延遲，同時需要分析較長時間範圍的資料，這類業務比較適合。

它相比傳統 Lambda 架構的優勢主要體現在 ，一套流程帶來的開發維護效率提升，以及成本的降低。另外，它能提供時效性和完整性均衡的資料，且能支援接入傳統資料庫的資料。

同時，也存在一些不足，目前主要是兩點：

第一個案例是 BI 普通播放報表近實時通路建設。之前這是一個傳統的 Lambda 架構，也遇到了我們剛才談到的問題。經過和業務同學溝通，瞭解到這個業務延遲從秒級降級到分鐘級是可以接受的，因此我們著手構建了近實時鏈路，來替代現有的流批兩條鏈路。

在這個鏈路中，原始資料傳送到 Kafka 之後，會儲存一份到 hdfs，做故障恢復。然後 ODS 層和 DWD 層都是基於 Iceberg 構建，整個鏈路是流式執行的。改造完成後的效果主要有 3 點：

第二個案例是稽核業務資料入湖的改造。這個業務的資料架構的稽核資料會存到到 mongodb 中，在 ES 裡構建二級索引，提供線上查詢。舊方案的痛點是，經常會有出統計報表或者批次匯出資料的需求，對線上服務構成較大壓力。引入資料湖能較好地解決當前問題，原始資料流透過 Kafka，實時同步到 Iceberg 表中，透過 SparkSQL 進行即時分析。達到了以下三個效果：

第三個是透過 Flink CDC 實現了庫存計算業務的改造。整體流程上，業務 MySQL 庫中的多張表需要做關聯後，結果同步到 Redis 作維度表，實時流再來查詢這個維度表。在改造前，是一個定時任務，每隔 10 分鐘讀取 MySQL 表的全量資料，多張表做關聯後，結果寫入 Redis，主要存在兩個問題。

因此，我們在改造方案中，我們引入了 Flink CDC , 進行一次存量同步後，無縫切換到增量同步，多張表的關聯計算的結果寫入 Redis，相比舊方案有明顯的優勢：整個過程是實時的，沒有排程延遲，整體延遲從 20 分鐘提升到了秒級，因此計算結果的準確性大大提高了；存量同步階段完成後，後續都是基於增量資料計算，無需重複讀取 MySQL 表的全量資料，計算效率顯著提升了。

我們規劃了兩個大的方向。