一、Apache Hudi 簡介

Hudi 是一個高效的事務型數據湖倉平臺，其核心特色是一個開放性的表格式定義和一套全面的事務數據庫核心層。這一核心層不僅支持索引功能，還能高效地處理并發事務，并具備強大的變更數據捕獲能力。在數據管道中，Hudi 能夠從上游數據源如 Kafka 接收數據，并利用 Spark 和 Flink 等執行引擎進行數據導入與處理。平臺還提供自動文件大小調整、增量處理和變更捕獲等功能，以優化數據的清理與轉換。此外，Hudi 具備豐富的表服務能力，如數據清理和聚類，確保數據管理的高效性。Hudi 已與眾多數據生態系統組件廣泛集成，包括目錄同步和多種查詢引擎，以實現數據處理的多樣化和靈活性。

上圖是 Hudi 的架構分層圖，展示了其作為數據湖倉平臺的三個核心層級。最底層用綠色表示的是開放的存儲層，負責底層數據的存儲，使用諸如 Parquet、Avro 和 ORC 等開源文件格式。其上一層是事務性數據庫核心層，該層定義了數據表格式、數據表服務、索引機制以及并發控制，確保了數據的一致性和高效處理。最頂層是開放平臺服務層，提供了一套開發的 API，支持與各類集成生態技術的讀寫操作，并實現了平臺的功能性，包括元數據服務、數據入湖工具和與不同查詢引擎的集成。這些層級共同構成了 Hudi 的平臺架構，使得用戶和開發人員能夠直接與平臺服務及工具交互，而機器則通過底層的讀寫支持與數據庫核心層交互。在 Hudi 1.0 版本中，這些架構層級經過了新的性能和功能優化，以滿足現代數據管理的需求。

二、Hudi 1.0 的重新思考

Hudi 1.0 的構想源于對 Hudi 成長歷程的回顧。Hudi 最初旨在解決大規模數據攝取、增量數據處理和快速創建的問題，并需要與 Presto、Spark、Flink、Trino 等查詢引擎集成。雖然這些引擎在列式數據查詢方面表現出色，但它們的整合過程卻充滿挑戰。

作為湖倉領域的先鋒，Hudi 曾被稱為事務性數據湖。在生態系統的早期階段，Hudi 做出了一些保守的設計選擇，例如為不同的查詢引擎開發了各自的連接器。在過去的五年中，Hudi 社區蓬勃發展，同時也暴露出更多元化的需求，特別是在事務性操作、快速更新和刪除功能方面。因此，Hudi 團隊認識到有必要對現有設計進行深層次的重新思考和優化，以適應不斷變化的數據處理需求。

Hudi 1.0 的五大發展方向體現了對當前數據湖架構的深度思考和對未來規劃的遠見：

• 深度查詢引擎集成：Hudi 將探索更深層次的查詢引擎集成，減少對多個專屬連接器的依賴。通過深入集成 Hudi 的多模索引（metadata table）功能，并結合如 Velox 等組件，以提升查詢性能。
• 泛化的關系型數據模型：隨著越來越多的引擎支持更全面的 SQL 語法，Hudi 將擴展其數據模型，以更好地適應關系型數據處理的需求，充分利用現代數據生態系統的優勢。
• 有服務器和無服務器的架構配置：Hudi 將發展混合架構，結合有服務器和無服務器配置，以適應不同的數據處理需求。元數據服務將得到加強，以支持更高效的并發控制和商用元數據服務的集成。
• 非結構化數據支持：Hudi 將擴展對非結構化數據（如圖像、視頻）的支持，以避免數據湖的碎片化，并實現非結構化數據的索引更新和變更捕獲功能，以適應 AI 等新興技術的需求。
• 數據庫表的自我管理能力提升：Hudi 將繼續完善其數據湖表管理服務，包括數據入湖、表服務計劃執行和運維工具。未來將增加更多功能，如反向流數據導入、快照管理、檢驗分析報告工具、跨區域備份和記錄級別的 TTL 管理，以實現更全面的數據表管理。

在對比數據庫的經典設計架構與 Hudi 的架構時，我們可以看到 Hudi 在數據湖倉領域實現了一個類似數據庫的功能層次。最頂層的客戶端模塊是用戶與系統交互的接口，負責處理 SQL 層的請求。在此之下，Hudi 集成了不同查詢引擎的查詢解析和優化功能，目前主要依賴各引擎自身的優化，但未來可能引入 Hudi 內部的優化機制。

藍色的模塊代表與外部系統的集成，而中間的方塊則展示了 Hudi 實現的事務性管理機制，這與傳統數據庫中的鎖管理、日志管理等模塊相對應。已經實現的組件用綠色方塊表示，而像緩存管理這樣的未來愿景則用其他顏色表示，這表明了 Hudi 1.0 版本的發展方向。

三、Hudi 1.0-beta 的重點新功能

接下來，將介紹 Hudi 1.0 的一些關鍵功能。Hudi 1.0 版本的設計理念可以在其RFC（Request for Comments）文檔中找到，該文檔詳細介紹了版本的主要設計方向和預期特性。

接下來將重點討論幾個關鍵功能，首先是 Hudi 的 LSM tree 時間線。Hudi 的時間線本質上是一個不可變的事務日志，記錄了表上所有已完成交易的詳細信息。這個事務日志通常會隨著每次提交而線性增長。Hudi 0.x 版本維護了兩個時間線：活躍時間線和歸檔時間線。活躍時間線用于快速檢索最新信息，而歸檔時間線則用于滿足特定場景下的歷史數據查詢需求。由于歸檔數據采用了不同的存儲機制，訪問這些數據的成本相對較高。

為了優化 Hudi 時間線的存儲效率，我們考慮采用 LSM tree 這種經過驗證的高效數據結構，它特別適合處理大規模寫入操作。在 Hudi 1.0 中，我們重新實現了寫入時間線的機制，現在每次寫入都會記錄其起始和結束時間。此外，我們將現有的線性存儲結構轉換成了 LSM tree 結構，這允許進行更高效的壓縮操作。

LSM tree 的優勢在于其樹形分層結構，能夠在頂層（如內存或緩存）快速檢索信息，同時在更長的時間線上，可以通過壓縮多個事務到更大的 parquet 文件中，來提高讀取效率和存儲效率。這種結構不僅優化了數據的快速訪問，還提升了整體存儲的緊湊性和性能。

接下來對 LSM Tree 時間線進行了一系列測試，其中包括模擬了 100 萬次提交的交易日志。在無需加載所有元數據的情況下，僅訪問開始時間和結束時間以及事務中涉及的文件，我們實現了在 367ms 內加載整個時間線。這一性能提升得益于將時間線數據存儲為 parquet 文件，這不僅減少了讀取所需的元數據量，還提供了更高的讀取靈活性，從而顯著提高了加載效率。

接下來探討另一個關鍵功能：函數索引。Hudi 的當前版本已經集成了一個多模式索引子系統，支持文件索引、列統計和布隆過濾器等功能，且這些索引可以異步構建。在 Hudi 1.0 中，我們希望進一步增強多模式索引的通用性。受到數據庫索引機制的啟發，我們考慮了基于 R 樹的空間索引和基于 Lucene 的搜索索引等高級功能。例如，PostgreSQL 能夠在表達式上創建索引，這啟發了我們實現函數索引的思路。函數索引的引入將使 Hudi 的索引功能更加靈活和強大，從而提高查詢效率和處理復雜查詢的能力。

函數索引的一個典型用例是在處理包含組織 ID 和時間戳的事件流數據時。通常，我們希望根據組織 ID 進行分區，然后進一步根據時間戳細分。例如，如果有1,000 個組織的一整年數據，我們可能會創建 365,000 個分區。然而，這種做法可能會導致數據傾斜和大量小文件的問題，這既影響了存儲效率，也降低了查詢性能。

為了解決這個問題，Hudi 1.0 引入了函數索引。我們僅根據組織 ID 進行物理分區，然后為時間戳定義一個函數，比如將 Unix 時間戳轉換為小時，并記錄每個小時的最大值和最小值。這樣就可以在索引中實現高效的 data skipping，即跳過不需要掃描的數據，同時保持文件存儲的高效率，無需進行更細粒度的物理分區。這種方法既保留了存儲效率，又提供了更靈活的分區結構，優化了查詢性能和數據管理。

函數索引的使用可以通過一個簡單的示例來解釋。在左側的 SQL 示例中，使用 city 來分區，同時還有一個時間戳字段。我們不需要針對時間戳進一步分區，而是可以使用 create index 的語法來生成一個新的索引，該索引將時間戳轉換為小時。一旦生成了這個索引，隨后的 SELECT 語句就可以利用時間戳進行高效的數據跳過。

在右側的兩個 Spark DAG（有向無環圖）演示中，展示了在有函數索引和沒有函數索引的情況下，數據跳過是如何實現的。使用函數索引，Spark 查詢可以更有效地跳過不相關數據，從而提高查詢性能和減少資源消耗。這種索引策略不僅簡化了數據分區，還提升了整體的數據處理效率。

另一個重要的功能改進是 Hudi 新開發的文件組讀取器和寫入器。Hudi 自創建之初就設計了一個基于主鍵的概念。在 MOR（Merge-On-Read）表類型中，我們實現了一個合并操作，從第一天起就支持快照查詢，即實時地將日志數據合并到基礎文件中。這一機制確保了即使在數據不斷寫入和更新時，也能高效地執行查詢操作，提供了對歷史和最新數據的統一視圖。

對于 Hudi 中的合并操作，我們發現了潛在的優化空間。具體來說，我們可以在記錄日志的同時，記錄下日志所需更新的基礎文件的位置信息。這樣，在進行合并操作時，能夠直接定位到文件的具體位置，從而高效地執行合并。

此外，Hudi 1.0 增加了對部分更新（partial update）的優先支持。傳統的日志文件默認記錄整條更新語句，但在許多情況下，只需記錄更新的字段。通過僅記錄更新的字段及其值和位置，能夠極大優化合并過程。

設計文件組讀取器和寫入器的另一個好處是，它使得與各種查詢引擎的集成變得更加簡便。這種設計統一了接口，使得擴展對不同引擎的支持變得更加方便，從而提升了 Hudi 的整體靈活性和可擴展性。

針對基于位置的合并操作，我們進行了一系列基準測試。這些測試涉及了兩個不同規模的合并表，一個包含 500GB、7.5 億條記錄，另一個包含 1TB、15 億條記錄。每條記錄大約 1KB 大小，表包含 1000 個分區，每個文件大約 256MB。

在測試中，我們首先批量加載數據，然后執行刪除和更新操作，更新表中 50% 的記錄。通過使用文件組讀取器并利用位置信息進行合并操作，我們觀察到了 12% 到 20% 的性能提升。這一提升隨著數據量的增加而變得更加顯著。對于具體的性能數據和詳細分析，可以參考 Hudi 的 PR 10167。

在部分更新（partial update）的測試中，我們觀察到了更為顯著的性能提升。上圖中展示了更新操作的結果對比。當使用全量更新，即整條記錄的所有字段與僅更新部分字段時，更新的延遲降低了 1.4 倍。同時，寫入的文件大小減少了 70 倍，這是因為我們節省了大量未更新的數據。由于寫入更為高效，節省了空間，合并操作也變得更為高效，我們觀察到了 5.7 倍的性能提升。這些優化不僅提高了更新操作的效率，還顯著減少了存儲空間的占用。

最后一個重點功能是非阻塞并發控制。這個設計基于一個常見場景：一個每分鐘寫入的進程和每小時執行一次的 GDPR 刪除作業。如果采用樂觀鎖機制，刪除作業可能會頻繁遇到沖突，因為刪除操作是隨機的，這會導致刪除作業在大多數情況下都需要重試，從而浪費資源。

Hudi 從一開始就采用了 MVCC（多版本并發控制）機制。在寫入側，允許不加阻塞地寫入，而在使用 MOR 模式時，在合并側執行異步合并操作。此外，我們可以利用合并的機會進行類聚操作，以優化存儲。這種設計確保了在處理并發寫入和刪除操作時，系統的效率和資源利用率得到提高。

為了解決多個寫入器并發控制的問題，Hudi 支持樂觀鎖的使用，也引入了早期沖突檢測機制。此外，Hudi 探索了更通用的非阻塞多版本并發控制機制。在 Hudi 1.0 中，我們實現了一個基于 MOR 寫入過程的非阻塞并發控制。

當 MOR 寫入操作在不同寫入器上生成不同的日志文件時，Hudi 最初不會阻塞寫入過程。通過使用全局單調遞增的時間戳來記錄每個寫入的開始和結束時間，我們可以在合并或快照讀取階段解決潛在的沖突。這種方法允許在寫入時保持非阻塞狀態，從而提高了寫入效率，同時確保了數據的最終一致性。

今天的重點內容已經介紹完畢。關于 Hudi 1.0，這里再提供一些額外信息。Hudi 1.0 的技術文檔已經發表，可以在相應的鏈接中查閱。此外，相關的RFC 文檔和設計文檔也已公開，供社區參考。Hudi 1.0 beta1 的 jar 包也已經發布。這些資源將為希望深入了解 Hudi 1.0 的用戶和開發者提供幫助。

最后，展示一下 Hudi 社區的活躍情況。社區非常歡迎新成員的加入，這里提供了豐富的文檔鏈接和資源，以便大家更好地了解和參與 Hudi 項目。此外，歡迎關注 Hudi 的公眾號來獲取最新信息，也歡迎加入我們的社區，共同推動 Hudi 的發展。

四、相關鏈接

1.0技術spec：https://hudi.apache.org/tech-specs-1 point0。

Docs : https://hudi.apache.org。

Blogs : https://hudi.apache.org/blog。

slack：https://join.slack.com/t/apache-hudi/shared_invite/zt-2ggm1fub8-_yt4Reu9djwqqVRFC7X49g。

Twitter : https://twitter.com/apachehudi。

Github: https://github.com/apache/hudi/。

Mailing list(s) : dev-subscribe@hudi.apache.org (send an empty email to subscribe)。