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

摘要： 本文整理自愛奇藝資深研發工程師李恆，在 FFA 2022 平臺建設專場的分享。本篇內容主要分爲四個部分：

  1. 統一實時計算平臺建設

  2. 近實時數據架構

  3. 業務實踐

  4. 未來計劃

01 統一實時計算平臺建設

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

早期我們支持用戶通過腳本和 Jar 包提交流任務，引擎以 Storm 和 Spark 爲主。2017 年，我們引入了 Flink，並且意識到 SQL 相比 Jar 包在開發和運維上有着明顯優勢，於是我們提供了 SQL 開發平臺，支持用戶通過 SQL 開發流任務。

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

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

  1. 實時平臺多，用戶使用成本和服務方維護成本很高。

  2. 數據分散在各個平臺，無法共享。

  3. 規模大，諮詢量大，報障多。

  4. 任務數量多，版本雜，導致支持用戶的成本高。

  5. 架構老，難以適應新的技術架構。

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

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

  1. 實現流數據、流任務的統一管理，促進共享，降低成本。

  2. 通過優化的設計，更好地幫助用戶實現穩定、高效的數據生產。

  3. 通過數據湖、流批一體等新技術，進一步提升業務效果。

上圖是 RCP 的整體架構，分爲平臺層、解析引擎、計算框架、調度層、運行層。

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

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

  1. 一部分用戶，不熟悉 SQL，他們希望有門檻更低的開發方式。

  2. 很多作業中，數據表的字段多，導致 SQL 冗長，難以維護。

  3. 開發中需要適配很多不同的版本，解決依賴衝突問題。

  4. 作業中有很多 hardcode 的部分，比如數據表的連接信息和配置。

爲了解決好這些問題，我們設計了全視角開發模式，讓用戶從三層不同的視角來看待數據。

  1. 第一層，數據流視角。這是最具體的視角，開發者關注底層數據的具體處理邏輯，適合通過底層 API 來實現。

  2. 第二層，數據表視角。開發者關注在數據表之間傳遞數據的邏輯，適合通過 SQL 來處理。

  3. 第三層，數據流轉視角。開發者更關注上游輸入經過怎樣的流轉之後輸出到下游，這裏通過數據流程圖的方式來描述，非常直接、高效。

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

  1. API 開發，用戶可以基於底層 API 進行完全定製的開發，然後將 Jar 包提交到平臺來運行，我們支持 Flink 和 Spark Streaming 兩種框架。

  2. SQL 開發，適合熟悉 SQL 的開發者，爲了提升開發效率，我們提供了 SQL 編輯器、語法校驗、SQL 格式化等工具。

  3. DAG 開發，這是門檻最低的方式，用戶將數據流的加工邏輯通過流程圖的方式來描述，達到了設計即開發的效果。

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

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

  1. 降低了開發門檻，連 SQL 語法也不需要深入掌握。

  2. 針對不同場景，用戶可以選擇效率最高的開發方式。

  3. 對於 SQL 和 DAG 任務開發，平臺提供了一些提升效率的工具，如 SQL 語法校驗，格式化等；DAG 中算子的 schema 可以逐級往下傳播，不需要用戶去手動編輯字段。

  4. 所有類型的作業底層對接統一的元數據中心，用戶創建的數據表和 UDF 是通用的。不同類型的作業經過解析之後，運行起來也是等效的。

平臺建設的第二部分工作是數據源管理，我們實現了一套數據統一集成方案，分爲三個模塊。

  1. Catalog，它是一個持久化的元數據中心，是統一訪問數據表和函數的入口。

  2. 數據表，它代表各類形態的數據流和數據集，歸屬於某個項目，使用時通過 Catalog 名，項目名，數據表名三級限定符來訪問。

  3. Connector，它是訪問數據表的具體實現，包含如下功能，一是按指定的數據格式解析數據，比如 json, PB, 另外，適配 hadoop2 和 hadoop3 兩大集羣版本，適配了 Flink 1.12，1.15 這兩個引擎版本，以及各類數據源版本，比如 HBase 等等。

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

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

  1. 對所有類型的任務是共用的，Connector 的代碼是完全複用的。

  2. 對任務裏每個數據表的 Connector 按需加載，靈活裝配。

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

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

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

任務的啓停，我們做了如下優化。

任務運行時的狀態數據，平臺統一進行託管，用戶無需關心。停止時會自動觸發狀態保存，再啓動時會嘗試從上次的狀態中恢復，最大程度避免狀態的丟失；任務啓動時支持用戶指定消費的位點，從而實現靈活消費。

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

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

任務日誌採集這部分，爲了讓用戶更便捷地查看日誌，平臺將所有任務的日誌進行了採集，通過 Log4j KafkaAppender 實時將任務日誌發送到 Kafka，經過解析後，發送到 ES，在 ES 中對任務名等字段進行索引，在任務管理頁面上，用戶就能方便地檢索日誌了。

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

  1. 日誌是異步發送的，不會影響任務的正常運行。

  2. 日誌可查的範圍比較大，目前支持查詢當前到最近一週的歷史日誌。

  3. 查詢分析方便，支持關鍵詞檢索；可以集中分析 JobManager 和全部 TaskManager 的日誌。

  4. 另外，目前我們正在做的一項工作，是對異常日誌做自動的分析，幫助用戶更快定位問題。

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

02 近實時數據架構

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

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

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

  1. 數據的範圍，涵蓋分鐘級到歷史全量數據。

  2. 計算上，只需要開發一次，任務能流式運行，也能批式運行。

  3. 數據來源上，支持變更數據。

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

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

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

  1. 實現存量數據加增量數據的統一存儲。

  2. 支持流式和批式的讀寫，從而與兩種運行模式的計算任務適配。

  3. 支持行級更新，從而能導入 MySQL 等數據庫的數據。

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

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

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

  1. 存量和增量數據在兩份存儲中，使用不方便。

  2. 維護兩個同步鏈路，維護成本較高。

  3. 難以保障數據一致性，特別是存量同步切換到增量同步的時候。

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

  1. 能很好的實現先同步存量數據，再無縫對接到增量同步，且端到端數據一致。

  2. Flink CDC2.0 版本之後，實現了無鎖同步方案，對源庫的影響較小。

  3. 支持邊同步邊數據加工，一個任務實現數據同步、加工、分發，架構簡潔。

爲了將 Flink CDC 集成到 RCP 平臺，我們做了以下工作：將當時 Flink CDC 的版本和 Flink 1.15 做了適配；對 MySQL CDC 類型數據表進行了統一集成，平臺對接了 MySQL 服務，打通賬號和權限流程，從而規範和簡化了用戶使用；解決了我們在實踐中遇到的數據同步失敗的問題。

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

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

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

  1. 增加了表維護成本，需要不斷地進行文件合併。

  2. 存儲上提供的能力還是不夠全面。比如隨機讀取能力較弱。

03 業務實踐

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

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

  1. 整個通路的數據都是流動的，一份存儲支持了近實時指標和離線指標的計算。

  2. 統一了數據口徑，新通路的數據誤差與原來的差距在 0.1% 以內。

  3. 成本顯著降低，主要是資源成本和維護成本。

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

  1. 歷史數據可以存在 Iceberg 表中，解除了線上存儲的瓶頸。

  2. 批量掃描的查詢都走 Iceberg，緩解了線上服務的查詢壓力。

  3. 支持即席查詢，從而能支持快速統計審覈效果，數據批量導出等需求。

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

  1. 定時任務有不可避免的調度延遲。

  2. 每次讀取 MySQL 全表數據再做關聯計算，計算量較大，效率比較低。

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

04 未來規劃

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

  1. 第一個方向是平臺治理。數據層面，實現數據資產更好的管理，進一步提升數據的共享率；任務層面，平臺支持自動排障，減輕用戶的運維負擔；資源層面，實現計算資源的主動伸縮，更合理利用資源，降低成本。

  2. 第二個方向是實現流式數倉。這方面我們跟社區的理念是一致的，希望整個數據通路能實時流動起來，且每個環節的數據都可支持分析，從而實現更高程度的流批統一，爲業務創造新的價值。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/SqmeInv62smb_qCeVp5JYQ

猜你喜歡