01
概述
數據是洞察用戶、市場、運營決策的基礎資料,在愛奇藝被廣泛應用在推薦、廣告、用戶增長、營銷等場景中。愛奇藝大數據業務之前採用 Lambda 架構,滿足海量數據處理、時效性等方面需求,但開發維護及資源成本高,同時還存在數據孤島問題。最近幾年興起的以 Iceberg、Hudi、Delta Lake 爲代表的數據湖技術爲構建統一的數據架構提供了基礎。愛奇藝大數據團隊在 2020 年引入 Iceberg 作爲數據湖基座,並基於 Iceberg + Flink 構建了流批一體化數據生產架構替代傳統的 Lambda 架構,打造了實時湖倉,已在 BI 數倉、會員、推薦、日誌等多種場景落地。當前每日處理 PB 級的數據,延遲從小時級降低到 1 至 5 分鐘,大幅提升數據流通效率。本文介紹了愛奇藝流批一體架構及實時湖倉建設實踐過程。
02
傳統 Lambda 架構:離線 + 實時兩套數據生產鏈路
-
離線通路:使用 HDFS、Hive、Spark 等工具,按 ODS、DWD、DWS 分層的數倉架構構建了離線數倉。通過 Venus 日誌採集、MySQLIO CDC 同步、Hubble 監控平臺等工具將不同數據源集成到離線數倉,同時提供魔鏡離線分析、Babel 離線計算兩個開發平臺支持數據應用開發。數倉中的 Hive 表按小時分區,從數據產生到業務場景應用通常有小時級的延時。 -
實時通路:數據價值隨生命週期增長而迅速衰減,離線通路的延遲導致業務無法快速利用數據的價值,因此又構建了實時通路。參考離線數倉,使用 Kafka 和 Flink 搭建實時流式數倉。Venus、MySQLIO、Hubble 等數據集成工具支持不同數據源集成到實時流式數倉。在數據開發層面,新增 RCP 實時計算平臺、RAP 實時分析平臺,用於支持實時數據應用開發。實時數據通路可以達到秒級延時。
-
系統複雜度高:服務提供方需要提供多種組件,業務需要學習多個組件,並開發維護離線、實時兩套程序。 -
數據一致性難保障:實時、離線兩套代碼,要做到數據處理邏輯統一、數據一致,存在較大挑戰。 -
資源成本高:數據鏈路多個環節存在兩套重複的存儲和計算,成本較高。 -
數據延時大:實時數據雖然延時低,但是存儲時間短,數據查詢分析需求仍然依靠離線數據,具有 T+1 的延時。
03
實時湖倉一體化
-
可控的數據延時:snapshot 的生成速度決定了數據生成的延時,snapshot 生成越快,數據延時越低,最快可以到 1 分鐘以內。 -
流批一體:Iceberg 既支持 Spark、Flink 引擎以批模式讀寫數據,也支持以流模式讀寫數據,能做到存儲層面的流批一體。 -
資源成本低:底層存儲在 HDFS 上,支持列存儲及數據壓縮,理論上與 Hive 的存儲成本相當,遠小於 Kafka 的存儲成本。Iceberg 在元數據層加入了統計信息,可用於查詢優化,查詢成本比 Hive 低。 -
支持數據變更:Iceberg V2 格式的表支持行級數據變更,可以更好的集成數據庫數據。
-
湖倉一體:既具備數據湖的靈活性,也具備數倉的結構化數據管理能力,可以統一存儲結構化、半結構化、非結構化的數據,形成統一的數據底座,消除數據孤島。 -
流批一體:將 Lambda 架構下的實時、離線兩條數倉生產通路合併成一條,數倉的每個層次生產一份數據,既能用於按小時、天讀數據的批計算,也能用於流式消費的實時計算。一套數倉避免了開發兩套代碼、計算邏輯對齊的問題,能大幅提高數據開發效率 -
資源成本低:相比於實時、離線兩個數倉生產通路,流批一體的實時湖倉的數據生產、存儲成本更低。相比Hive,Iceberg 元數據層更豐富的統計信息,也有助於查詢性能提升,降低查詢成本。 -
延時低:Iceberg 支持分鐘級的數據可見性,通過實時寫入 Iceberg,實時湖倉可以達到分鐘級的延時。數據的使用方不需要在應用側採用流、批數據融合的方式支持最新的全量數據,簡化業務側處理邏輯。
挑戰
-
單任務生產多表問題:在愛奇藝的埋點、容器日誌等數據源中,不同業務的日誌混合在一起,需要按日誌特徵拆分到不同業務的 ODS 層表。單個任務消費一個數據源可能拆分出 500 多張表,最大的任務需要拆分到3000 多張表,總共拆分到上萬張表。當前的 Flink Iceberg Sink 僅支持寫入到一張表,而一個 Flink 任務也無法添加如此多的 Iceberg Sink。因此,如何解決單任務生產多表的問題是我們面臨的首要難題。 -
數據生產進度評估:需要在實時生產數據的過程中評估數據生產進度,以便數據的使用方瞭解湖倉中數據的完整度,觸發下游批任務。 -
流式消費的積壓監控:對於下游的流式消費任務,需要像消費 Kafka 一樣給出消費積壓監控。 -
數據完備性保障:在 Lambda 架構下,在數據通路故障時,可以通過重新調度批計算修正數據,保證數據的最終完備性。實時湖倉架構也需要有保證數據完備性的機制。
04
解決方案
單任務生產多表
-
定義 MultiTableRow 類型。相比 Row,增加了所屬的 Table 名稱。 -
爲避免每個 Writer 算子的 Task 寫入過多表,出現小文件過多、內存使用過大及性能問題,在 Writer 算子之前加入 Partitioner 算子。通過 Partitioner 算子將相同表的數據路由到固定幾個 Writer Task,一個 Writer Task 只處理部分表的寫入。 -
Writer 算子基於 MultiTableRow 中的表名字加載表,將數據寫入到對應表的文件。在 Checkpoint 時,首先按表名彙總各表新寫入的文件構建 MultiTableWriteResult 對象,MultiTableWriteResult 對象相比 WriterResult 增加了表名信息。然後按表名 Shuffle 後發送給 Committer 算子。 -
Committer 算子的並行度不爲 1,爲默認並行度。在 Checkpoint 時,每個 Committer 算子的 Task 基於收到的MultiTableWriteResult 彙總各表的寫入文件,提交到對應的表生成新的 Snapshot。
數據生產進度評估
流式消費積壓監控
-
Split Enumerator:發現 Iceberg 表的新 Snapshot,讀取 Snapshot 中的文件,並切分成 Split 塊。 -
Reader:接收 Split Enumerator 分配的 Split 塊,讀取 Split 塊中的數據,發送到下游算子。
數據完備性保障
圖 10 數據修正
05
落地效果
-
Venus:Venus 是愛奇藝的日誌平臺,負責後端日誌採集、存儲、分析。原來日誌統一存儲在 Elasticsearch,與大數據體系割裂,現在大部分日誌都統一入湖,對應實時湖倉的 ODS 層表。容器類日誌原來先採集到統一的Kafka topic,然後按業務分割到業務 topic,再寫入 Elasticsearch。遷移到實時湖倉架構後,從統一 Kafka topic 按業務拆分後直接寫入 Iceberg,省掉了業務 topic 環節。Venus 總共寫入超過 1 萬張 Iceberg 表,每日寫入 PB 級日誌,延時 5 分鐘,每年節省上千萬成本。Venus 入湖改造的詳細介紹見之前發佈的文章《 愛奇藝數據湖實戰 - 基於數據湖的日誌平臺架構演進 》 -
Pingback:Pingback 是愛奇藝埋點數據的統稱,大部分埋點數據需要經過數倉架構 ODS、DWD、DWS 分層處理。我們按照數倉層次從前到後、業務重要程度從低到高的順序使用實時湖倉 Iceberg 表替代 Hive 表。同時,也推動了部分能接受分鐘級延時的業務從 Kafka 數據遷移到 Iceberg 表。目前已上線 1300 多張 Iceberg 表,每日新增數百 TB 數據,每一層的 Iceberg 表最低延時 1 分鐘。 -
數據庫數據:Flink CDC 支持全量、增量數據的透明切換並實時寫入 Iceberg,數據庫數據入湖統一切換成了 Flink CDC。目前已同步廣告、會員、用戶增長等業務的近百張表。
06
未來規劃
-
繼續上線更多業務場景,完全替代 Hive,並替代接受分鐘級延時的 Kafka 數據。 -
將 Flink CDC 從 2.x 升級到 3.x,支持 Schema 自動變更,降低數據庫數據入湖的維護代價。 -
Iceberg 不支持更新部分列、基於變更數據繼續構建 Pipeline 等功能,限制了一些應用場景,正在引入新興的數據湖技術 Paimon 作爲這類場景的替補。
本文分享自微信公衆號 - 愛奇藝技術產品團隊(iQIYI-TP)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。