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

摘要：本文整理自愛奇藝資深研發工程師李恆，在 FFA 2022 平臺建設專場的分享。本篇內容主要分為四個部分：
統一實時計算平臺建設
近實時資料架構
業務實踐
未來規劃

一、統一實時計算平臺建設

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

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

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

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

實時平臺多，使用者使用成本和服務方維護成本很高。
資料分散在各個平臺，無法共享。
規模大，諮詢量大，報障多。
任務數量多，版本雜，導致支援使用者的成本高。
架構老，難以適應新的技術架構。

基於這樣的背景，我們開始建設統一的實時計算平臺 RCP。

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

第一，實現流資料、流任務的統一管理，促進共享，降低成本。
第二，透過最佳化的設計，更好地幫助使用者實現穩定、高效的資料生產。
第三，透過資料湖、流批一體等新技術，進一步提升業務效果。

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

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

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

一部分使用者，不熟悉 SQL，他們希望有門檻更低的開發方式。
很多作業中，資料表的欄位多，導致 SQL 冗長，難以維護。
開發中需要適配很多不同的版本，解決依賴衝突問題。
作業中有很多 hardcode 的部分，比如資料表的連線資訊和配置。

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

第一層，資料流視角。這是最具體的視角，開發者關注底層資料的具體處理邏輯，適合透過底層 API 來實現。
第二層，資料表視角。開發者關注在資料表之間傳遞資料的邏輯，適合透過 SQL 來處理。
第三層，資料流轉視角。開發者更關注上游輸入經過怎樣的流轉之後輸出到下游，這裡透過資料流程圖的方式來描述，非常直接、高效。

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

第一種 API 開發，使用者可以基於底層 API 進行完全定製的開發，然後將 Jar 包提交到平臺來執行，我們支援 Flink 和 Spark Streaming 兩種框架。
第二種 SQL 開發，適合熟悉 SQL 的開發者，為了提升開發效率，我們提供了 SQL 編輯器、語法校驗、SQL 格式化等工具。
第三種 DAG 開發，這是門檻最低的方式，使用者將資料流的加工邏輯透過流程圖的方式來描述，達到了設計即開發的效果。

同樣一段邏輯，分別透過 SQL 和 DAG 來開發，在實際生產中，資料表通常有上百個欄位，SQL 會比較冗長，難以維護；而透過 DAG 的方式，資料處理流程非常清晰，迭代維護效率高。

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

降低了開發門檻，連 SQL 語法也不需要深入掌握。
針對不同場景，使用者可以選擇效率最高的開發方式。
對於 SQL 和 DAG 任務開發，平臺提供了一些提升效率的工具，如 SQL 語法校驗，格式化等；DAG 中運算元的 schema 可以逐級往下傳播，不需要使用者去手動編輯欄位。
所有型別的作業底層對接統一的後設資料中心，使用者建立的資料表和 UDF 是通用的。不同型別的作業經過解析之後，執行起來也是等效的。

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

Catalog，它是一個持久化的後設資料中心，是統一訪問資料表和函式的入口。
資料表，它代表各類形態的資料流和資料集，歸屬於某個專案，使用時透過 Catalog 名，專案名，資料表名三級限定符來訪問。
Connector，它是訪問資料表的具體實現，包含如下功能，一是按指定的資料格式解析資料，比如 json, PB, 另外，適配 hadoop2 和 hadoop3 兩大叢集版本，適配了 Flink 1.12，1.15 這兩個引擎版本，以及各類資料來源版本，比如 HBase 等等。

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

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

對所有型別的任務是共用的，Connector 的程式碼是完全複用的。
對任務裡每個資料表的 Connector 按需載入，靈活裝配。
平臺統一來完成了不同版本的適配和解決依賴衝突，減輕了使用者的開發負擔。

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

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

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

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

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

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

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

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

日誌是非同步傳送的，不會影響任務的正常執行。
日誌可查的範圍比較大，目前支援查詢當前到最近一週的歷史日誌。
查詢分析方便，支援關鍵詞檢索；可以集中分析 JobManager 和全部 TaskManager 的日誌。
另外，目前我們正在做的一項工作，是對異常日誌做自動的分析，幫助使用者更快定位問題。

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

二、近實時資料架構

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

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

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

資料的範圍，涵蓋分鐘級到歷史全量資料。
計算上，只需要開發一次，任務能流式執行，也能批式執行。
資料來源上，支援變更資料。

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

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

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

實現存量資料加增量資料的統一儲存。
支援流式和批式的讀寫，從而與兩種執行模式的計算任務適配。
支援行級更新，從而能匯入 MySQL 等資料庫的資料。

引入 Iceberg 後，我們做了一些適配工作：

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

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

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

存量和增量資料在兩份儲存中，使用不方便。
維護兩個同步鏈路，維護成本較高。
難以保障資料一致性，特別是存量同步切換到增量同步的時候。

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

能很好的實現先同步存量資料，再無縫對接到增量同步，且端到端資料一致。
Flink CDC2.0 版本之後，實現了無鎖同步方案，對源庫的影響較小。
支援邊同步邊資料加工，一個任務實現資料同步、加工、分發，架構簡潔。

為了將 Flink CDC 整合到 RCP 平臺，我們做了以下工作：

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

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

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

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

增加了表維護成本，需要不斷地進行檔案合併。
儲存上提供的能力還是不夠全面。比如隨機讀取能力較弱。

三、業務實踐

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

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

整個通路的資料都是流動的，一份儲存支援了近實時指標和離線指標的計算。
統一了資料口徑，新通路的資料誤差與原來的差距在 0.1%以內。
成本顯著降低，主要是資源成本和維護成本。

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

歷史資料可以存在 Iceberg 表中，解除了線上儲存的瓶頸。
批次掃描的查詢都走 Iceberg，緩解了線上服務的查詢壓力。
支援即席查詢，從而能支援快速統計稽核效果，資料批次匯出等需求。

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

定時任務有不可避免的排程延遲。
每次讀取 MySQL 全表資料再做關聯計算，計算量較大，效率比較低。

因此，我們在改造方案中，我們引入了 Flink CDC , 進行一次存量同步後，無縫切換到增量同步，多張表的關聯計算的結果寫入 Redis，相比舊方案有明顯的優勢：

整個過程是實時的，沒有排程延遲，整體延遲從 20 分鐘提升到了秒級，因此計算結果的準確性大大提高了。
存量同步階段完成後，後續都是基於增量資料計算，無需重複讀取 MySQL 表的全量資料，計算效率顯著提升了。

四、未來規劃

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

第一個方向是平臺治理。資料層面，實現資料資產更好的管理，進一步提升資料的共享率；任務層面，平臺支援自動排障，減輕使用者的運維負擔；資源層面，實現計算資源的主動伸縮，更合理利用資源，降低成本。
第二個方向是實現流式數倉。這方面我們跟社群的理念是一致的，希望整個資料通路能實時流動起來，且每個環節的資料都可支援分析，從而實現更高程度的流批統一，為業務創造新的價值。

點選檢視直播回放和演講 PPT

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

一、統一實時計算平臺建設

二、近實時資料架構

三、業務實踐

四、未來規劃

更多內容

相關文章