Apache Hudi 1.x 版本重磅功能展望與討論

Apache Hudi 社區正在對Apache Hudi 1.x版本功能進行討論,歡迎感興趣同學參與討論,PR鏈接:https://github.com/apache/hudi/pull/8679/files

摘要

RFC 提議對 Hudi 中的事務數據庫層進行令人興奮和強大的重構,以推動未來幾年整個社區的持續創新。 在過去的幾年裏,社區成長(https://git-contributor.com/?chart=contributorOverTime&repo=apache/hudi)) 超過 6 倍的貢獻者,這個 RFC 是圍繞核心願景澄清和調整社區的絕佳機會。 此 RFC 旨在作爲此討論的起點,然後徵求反饋、接受新想法並協作建立共識,以實現有影響力的 Hudi 1.X 願景,然後提煉出構成第一個版本——Hudi 1.0 的內容。

項目狀態

衆所周知,Hudi 最初於 2016 年在 Uber 創建,用於解決 大規模數據攝取](https://www.uber.com/blog/uber-big-data-platform/)) 和 [增量數據處理] ](https://www.uber.com/blog/ubers-lakehouse-architecture/)) 問題,後來 捐贈](https://www.uber.com/blog/apache-hudi/)) 給 ASF。自 2020 年作爲頂級 Apache 項目畢業以來,社區在 [流數據湖願景](https://hudi.apache.org/blog/2021/07/21/streaming-data-lake-platform),通過在一組強大的平臺組件之上進行增量處理,使數據湖更加實時和高效。最新的 0.13 彙集了幾個顯着的功能來增強增量數據管道,包括 [RFC-51 Change Data Capture](https://github.com/apache/hudi/blob/master/rfc/rfc-51/rfc- 51.md),更高級的索引技術consistent hash indexes](https://github.com/apache/hudi/blob/master/rfc/rfc-42/rfc-42.md)) 和諸如 早期衝突檢測](https://github.com/apache/hudi/blob/master/rfc/rfc-56/rfc-56.md)) 之類的創新。

如今 Hudi 用戶](https://hudi.apache.org/powered-by)) 能夠使用 Hudi 作爲數據湖平臺解決終端用例,該平臺在可互操作的開放存儲格式之上提供大量自動化。用戶可以從文件/流系統/數據庫中增量攝取,並將該數據插入/更新/刪除到 Hudi 表中,並提供多種高性能索引選擇。由於記錄級元數據和增量/CDC 查詢等核心設計選擇,藉助強大的流處理支持,用戶能夠始終如一地將攝取的數據鏈接到下游管道,近年來在 Apache Spark、Apache Flink 和 Kafka Connect 等框架中。 Hudi 表格服務會自動處理這些攝取和派生的數據,以管理表格簿記、元數據和存儲佈局的不同方面。最後,Hudi 對不同目錄的廣泛支持和跨各種查詢引擎的廣泛集成意味着 Hudi 表也可以“批量”處理老式風格或從交互式查詢引擎訪問。

未來的機會

我們一直在 0.x 版本中添加新功能,但我們也可以將 Hudi 的核心變成更通用的湖數據庫體驗。 作爲 lakehouse 的第一個實現(我們稱之爲“交易數據湖”或“流數據湖”,分別是倉庫用戶和數據工程師的語言),我們根據當時的生態系統做了一些保守的選擇。 然而,重新審視這些選擇很重要,以便看看它們是否仍然有效。

  • 深度查詢引擎集成: 當時 Presto、Spark、Flink、Trino 和 Hive 等查詢引擎擅長查詢列式數據文件,但很難集成到其中。 隨着時間的推移,我們期望清晰的 API 抽象圍繞 parquet/orc 讀取路徑中的索引/元數據/錶快照,像 Hudi 這樣的項目可以利用這些路徑輕鬆利用像 Velox/PrestoDB 這樣的創新。 然而大多數引擎更喜歡單獨的集成——這導致 Hudi 維護自己的 Spark 數據源,Presto 和 Trino 連接器。 然而現在這爲在查詢計劃和執行期間充分利用 Hudi 的多模式索引功能提供了機會。
  • 廣義數據模型: 雖然 Hudi 支持主鍵,但我們專注於更新 Hudi 表,就好像它們是鍵值存儲一樣,而 SQL 查詢在上面運行,保持不變並且無感知。 當時根據生態系統的位置推廣對主鍵的支持還爲時過早,因爲生態系統仍在執行大批量 MR 作業。 如今,Apache Spark 和 Apache Flink 等性能更高的高級引擎具有成熟的可擴展 SQL 支持,可以支持 Hudi 表的通用關係數據模型。
  • 有服務器和無服務器:數據湖歷來都是關於定期或按需觸發的作業。 儘管許多元數據擴展挑戰可以通過精心設計的元服務器來解決(類似於現代雲倉庫所做的),社區一直對除了數據目錄或 Hive 元服務器之外的長期運行服務猶豫不決。 事實上我們的時間線服務器由於社區缺乏共識工作停滯不前。 然而隨着併發控制等需求的發展,出現了圍繞開放格式的這些問題的專有解決方案。 現在可能是時候通過採用混合架構來爲社區轉向真正開放的解決方案了,在該架構中,我們爲表元數據使用服務器組件,同時爲數據保留無服務器。
  • 除了結構化數據:即使我們解決了有關在 parquet/avro/orc 中攝取、存儲、管理和轉換數據的挑戰,仍然有大多數其他數據無法從這些功能中受益。 使用 Hudi 的 HFile 表進行 ML 模型服務是一個新興的用例,用戶希望以低成本、輕量級的方式直接從湖存儲中提供計算數據。 通常,非結構化數據,如 JSON 和 blob類似的圖像必須使用某種結構進行僞建模,從而導致性能或可管理性不佳。 隨着近年來 AI/ML 的迅速崛起,像 Hudi 這樣的項目缺乏對複雜、非結構化、大 blob 的支持,只會讓數據碎片化在湖泊中。爲此,我們需要支持所有主要的圖像、視頻和 ML/AI 格式,並在索引、變異或捕獲變化方面具有相同深度的功能。
  • 更強大的自我管理:Hudi 在開源數據湖管理方面提供了當今最廣泛的功能集,從攝取數據到優化數據以及自動化各種簿記活動以自動管理表數據和元數據。 看到社區如何使用這個管理層來提升他們的數據湖體驗令人印象深刻。

但是,我們有很多功能要添加,例如,反向流數據到其他系統或快照管理](https://github.com/apache/hudi/pull/6576/files))或[診斷報告器](https://github.com/apache/hudi/pull/6600)或跨地域邏輯複製或記錄級 生存時間管理](https://github.com/apache/hudi/pull/8062))

Hudi 1.X

鑑於我們更像是一個數據庫問題來處理 Hudi,因此 Hudi 有許多構成數據庫的構建塊也就不足爲奇了。 從開創性的數據庫系統架構論文(參見第 4 頁)中繪製基線,我們可以看到 Hudi 如何構成針對湖優化的數據庫的下半部分,具有多個查詢引擎層 - SQL、編程訪問、專門用於 ML /AI、實時分析和其他引擎處於領先地位。 下面的主要區域直接映射了我們如何跟蹤 Hudi 路線圖。 我們將看到我們如何專門針對數據湖的規模和湖工作負載的特徵調整這些組件。

突出顯示現有(綠色)和新(黃色)Hudi 組件以及外部組件(藍色)的參考圖。

數據庫中的日誌管理器組件有助於組織日誌,以便在崩潰期間恢復數據庫等。 在事務層,Hudi 實現了將數據組織到文件組和文件切片中的方法,並將修改表狀態的事件存儲在時間軸中。 Hudi 還使用標記文件跟蹤進行中的事務以實現有效回滾。 由於該湖存儲的數據比典型的操作數據庫或數據倉庫多得多,同時需要更長的記錄版本跟蹤,因此 Hudi 生成了記錄級元數據,可以很好地壓縮以幫助更改數據捕獲或增量查詢等功能,有效地將數據本身視爲日誌 . 未來我們希望繼續完善 Hudi 的數據組織,提供可擴展的、無限的時間線和數據歷史、時間旅行寫入、存儲聯邦等功能。

鎖管理器組件有助於在數據庫中實現併發控制機制。 Hudi 附帶了幾個外部鎖管理器,儘管我們最終希望通過我們今天僅提供時間線元數據的元服務器來簡化這一點。 這篇論文(第 81 頁)描述了數據庫中常見的併發控制技術之間的權衡:2Phase Locking(沒有中央事務管理器很難實現)、OCC(在沒有爭用的情況下工作良好,在爭用時效率很差)和 MVCC(收益率 高吞吐量,但在某些情況下放鬆了可串行化性)。 Hudi 在併發寫入器之間實現了 OCC,同時爲寫入器和表服務提供了基於 MVCC 的併發,以避免它們之間的任何阻塞。 退一步,我們需要問問自己,如果我們正在構建一個 OLTP 關係數據庫,以避免盲目地將適用於它們的相同併發控制技術應用到寫入湖的高吞吐量管道/作業的陷阱。 Hudi 並不是非常傾向於 OCC ,並鼓勵通過輸入流序列化更新/刪除/插入,以避免 OCC 對快速變化的表或流式工作負載造成性能損失。 即使我們實施了早期衝突檢測等技術來改進 OCC,此 RFC 也建議 Hudi 應該追求更通用的基於非阻塞 MVCC 的併發控制,同時爲簡單和批量附加的用例保留 OCC。

訪問方法組件包括索引、元數據和存儲佈局組織技術,這些技術暴露給數據庫的讀/寫。 去年我們新增了多模態索引,支持基於MVCC的異步建索引,建索引時不阻塞寫者,建完後仍與表數據保持一致。 到目前爲止,我們的重點一直更狹隘地針對使用索引技術來提高寫入性能,而查詢則受益於文件和列統計元數據以進行規劃。 未來我們希望支持在寫入和查詢中統一使用各種索引類型,以便可以在 Hudi 的索引之上高效地規劃、優化和執行查詢。 由於 Hudi 的連接器適用於 Presto、Spark 和 Trino 等流行的開源引擎,現在這成爲可能。 已經添加了新的二級索引方案和內置索引函數的建議,以索引從列派生的值。

緩衝區管理器組件管理髒存儲塊並緩存數據以加快查詢響應速度。 在 Hudi 的上下文中,我們希望讓我們現在期待已久的列式緩存服務煥發生機,該服務可以透明地位於湖存儲和查詢引擎之間,同時瞭解事務邊界和記錄突變。 RUM 猜想詳細介紹了設計平衡讀取、更新和內存成本的系統的權衡。 我們這裏的基本想法是優化讀取(從緩存中提供更快的查詢)和更新(通過不斷壓縮內存來分攤 MoR 合併成本)成本,同時將緩存/內存成本添加到系統中。 目前,這個想法可能有很多候選設計,我們需要一個單獨的設計/RFC 來實現它們。

共享組件包括複製、加載和各種實用程序,以及目錄或元數據服務器。 大多數數據庫隱藏了底層格式/存儲的複雜性,爲用戶提供了許多數據管理工具。 Hudi 也不例外,Hudi 擁有久經考驗的批量和連續數據加載實用程序(deltastreamer、flinkstreamer 工具以及 Kafka Connect Sink)、一套全面的表服務(清理、歸檔、壓縮、集羣、索引……)、admin CLI 等等。 社區一直致力於開發新的服務器組件,例如元服務器,它可以擴展爲使用高級數據結構(例如區域映射/間隔樹)或表服務管理器來索引表元數據,以集中管理 Hudi 表。 我們很樂意朝着擁有一組水平可擴展、高度可用的元服務器的方向發展,這些元服務器可以提供這些功能以及一些鎖管理功能。 另一個有趣的方向是反向加載器/流數據實用程序,它也可以將數據從 Hudi 移出到其他外部存儲系統中。

總而言之我們提出 Hudi 1.x 作爲 Hudi 的重新構想,作爲湖的事務數據庫,具有多語言持久性,將 Hudi 數據湖的抽象和平臺化水平提高到更高。

Hudi 1.0 發佈

本節概述了第一個 1.0 版本目標和可能必須進行的前端加載更改。 此 RFC 徵求社區的更多反饋和貢獻,以擴大範圍或在 1.0 版本中爲用戶提供更多價值。

簡而言之,我們提出 Hudi 1.0 嘗試並實現以下目標。

  • 合併對格式的所有/任何更改 - 時間線、日誌、元數據表...
  • 跨表元數據、快照、索引/元數據表、主鍵生成、記錄合併等建立新的 API(如果有的話)
  • 將內部代碼分層/抽象到位 - 例如 HoodieData、文件組讀取器/寫入器、存儲...
  • 以配置保護的安全方式登陸所有主要的、傑出的 "needle mover" PR
  • 集成 Spark/Flink/Presto 的部分/全部現有索引,並驗證預期的功能和性能提升。

所有更改都應向後兼容,並且不需要重寫現有表中的基本/鑲木地板文件。 但是,從 0.x 版本遷移到 1.0 版本時,可能需要完全壓縮日誌或計劃停機時間以重寫時間線或重建元數據表。

該 RFC 將通過對 Hudi 不同部分的具體更改進行擴展。 請注意此 RFC 僅用於識別這些領域,對於影響存儲格式、向後兼容性或新公共 API 的任何更改,應給出單獨的 RFC。

推出/採用計劃

我們建議 1.0 的執行在下面的三個版本系列中完成。

  • alpha(2023 年 7 月):所有格式更改均已落地,內部代碼分層/抽象工作,主要未完成的 PR 已安全落地。 0.X 表可以無縫升級,核心 Hudi 寫入/查詢流程經過認證。
  • beta(2023 年 8 月):添加了新的 API,更改了代碼路徑以使用新的 API,索引集成了性能/功能資格。
  • Generally available(2023 年 9 月):在一般發佈之前由社區進行規模測試、壓力測試和生產強化。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章