1. 首頁 > 生活百科 > >

Arctic 基于 Hive 的流批一體實踐

生活百科

背景隨著大數據業務的發展，基于 Hive 的數倉體系逐漸難以滿足日益增長的業務需求，一方面已有很大體量的用戶，但是在實時性，功能性上嚴重缺失；另一方面 Hudi，Iceberg 這類系統在事務性，快照管理上帶來巨大提升，但是對已經存在的 Hive 用戶有較大的遷移成本，并且難以滿足流式計算毫秒級延遲的需求 。為了滿足網易內外部客戶對于流批一體業務的需求，網易數帆基于 Apache Iceberg 研發了新一代流式湖倉，相較于 Hudi，Iceberg 等傳統湖倉，它提供了流式更新，維表 Join，partial upsert 等功能，并且將 Hive，Iceberg，消息隊列整合為一套流式湖倉服務，實現了開箱即用的流批一體，能幫助業務平滑地從 Hive 過渡到 Streaming Lakehouse 。
Arctic 是什么

Arctic 基于 Hive 的流批一體實踐

文章插圖
Arctic 是搭建在 Apache Iceberg 之上的流式湖倉服務 （ Streaming LakeHouse Service ) 。相比 Iceberg、Hudi、Delta 等數據湖，Arctic 提供了更加優化的 CDC，流式更新，OLAP 等功能，并且結合了 Iceberg 高效的離線處理能力，Arctic 能服務于更多的流批混用場景 。Arctic 還提供了包括結構自優化、并發沖突解決、標準化的湖倉管理功能等，可以有效減少數據湖在管理和優化上負擔 。
Arctic 基于 Hive 的流批一體實踐

文章插圖
Arctic Table 依賴 Iceberg 作為基礎表格式 ， 但是 Arctic 沒有傾入 Iceberg 的實現 ， 而是將 Iceberg 做為 lib 使用 ， 同時 Arctic 作為專門為流批一體計算設計的流式湖倉 ， Arctic Table 還封裝了消息隊列作為表的一部分，在流式計算場景下可以提供更低的消息延遲，并且提供了流式更新，主鍵唯一性保證等功能 。
流體一批的解決方案在實時計算中，由于低延遲的要求，業務通常采用 Kafka 這類消息隊列作為流表方案，但是在離線計算中，通常采用 Hive 作為離線表，并且由于消息隊列不支持 AP 查詢，通常還需要額外的 OLAP 系統如 Kudu 以支持實時計算鏈接的最終數據輸出 。這就是典型的 Lambda 架構：
Arctic 基于 Hive 的流批一體實踐

文章插圖
這套架構最明顯的問題就是多套系統帶來的運維成本和重復開發帶來的低效率，其次就是兩套系統同時建模帶來的語義二義性問題，并且真實生產場景中，還會出現實時和離線視圖合并的需求，或者引入 KV 的實時維表關聯的需求 。Arctic 的核心目標之一 ， 就是為業務提供基于數據湖的去 Lambda 化，業務系統使用 Arctic 替代 Kafka 和Hive，實現存儲底座的流批一體 。
Arctic 基于 Hive 的流批一體實踐

文章插圖
為此 Arctic 提供了以下功能：
  • Message Queue 的封裝：Arctic 通過將 MessageQueue 和數據湖封裝成一張表 ， 實現了 Spark、Flink、Trino 等不同計算引擎訪問時不需要區分流表和批表，實現了計算指標上的統一 。
  • 毫秒級流計算延遲：Message Queue 提供了毫秒級的讀延遲 ， 并且提供了數據寫入和讀取的一致性保障 。
  • 分鐘級的 OLAP 延遲：Arctic 支持流式寫入以及流式更新 ， 在查詢時通過 Merge on Read 實現分鐘級的 OLAP 查詢 。
Table StoreArctic Table 由不同的 Table Store 組成，TableStore 是 Arctic 在存儲系統中定義的表格式實體，Tablestore 類似于數據庫中的 cluster index，代表獨立的存儲結構 ， 目前分為三種 TableStore 。
Arctic 基于 Hive 的流批一體實踐

文章插圖

    推薦閱讀