資料湖表格式比較(Iceberg、Hudi 和 Delta Lake)
表格格式是資料工具和語言與資料湖進行互動的方式,就像我們與資料庫進行互動一樣。表格格式允許我們將不同的資料檔案抽象為一個單一的資料集,一個表格。
資料湖中的資料通常可以跨越多個檔案。我們可以使用 Spark 和 Flink 等工具,使用 R、Python、Scala 和 Java 來設計和分析這些資料。能夠將這些檔案的組定義為單個資料集(例如表格),使分析它們變得更加容易(與手動分組檔案或一次分析一個檔案相比)。最重要的是,SQL 依賴於表的概念,而 SQL 可能是進行分析最容易使用的語言。
Hive是第一代表格式
最原始表格式是 Apache Hive。在 Hive 中,表被定義為一個或多個特定目錄中的所有檔案。雖然這使 SQL 表示式和其他分析能夠在資料湖上執行,但它無法有效地擴充套件到滿足當今需求所需的分析量和複雜性,所以現在開發了其他表格格式以提供所需的可伸縮性。
新一代表格式
Apache Iceberg、Apache Hudi 和 Databricks Delta Lake。這三者都採用了類似的方法來利用後設資料來處理繁重的工作。後設資料結構用於定義:
- 什麼是桌子?
- 表的架構是什麼?
- 表是如何分割槽的?
- 該表由哪些資料檔案組成?
雖然從類似的前提開始,但每種格式都有許多差異,這可能會使一種表格格式在資料湖上啟用分析時比另一種更具吸引力。
在本文中,我們將比較這三種格式的目標提供的功能、相容的工具和社群貢獻,以確保它們是長期投資的良好格式。
Iceberg、Hudi 和 Delta Lake三種下一代格式中的任何一種可能會取代傳統Hive,成為在資料湖上表示表的行業標準。當您選擇長期採用哪種格式時,請務必問自己以下問題:
- 哪種格式具有我需要的最強大的功能版本?
- 哪種格式使我能夠使用 SQL 來利用其大部分功能,以便我的資料消費者可以訪問它?
- 哪種格式具有引擎支援和社群支援的勢頭?
- 哪種格式可以讓我訪問最強大的版本控制工具?
本文將主要關注比較開源表格式,這些格式使您能夠使用不同的引擎和工具在資料湖上使用開放架構執行分析,因此我們將重點關注 Delta Lake 的開源版本。開放式架構有助於最大限度地降低成本,避免供應商鎖定,並確保始終可以使用最新和同類最佳的工具來處理您的資料。
請記住,Databricks 擁有自己的 Delta Lake 專有分支,該分支具有僅在 Databricks 平臺上可用的功能。Spark 也是如此——Databricks 管理的 Spark 叢集執行專有的 Spark 分支,其功能僅適用於 Databricks 客戶。這些專有分支未開放以使其他引擎和工具能夠充分利用它們,因此不是本文的重點。
Apache Iceberg
Apache Iceberg 的做法是透過三類後設資料來定義表。這些類別是:
- 定義表的“後設資料檔案”
- 定義錶快照的“清單列表”
- “清單”定義了可能是一個或多個快照的一部分的資料檔案組
查詢最佳化和 Iceberg 的所有功能都是由這三層後設資料中的資料實現的。
透過後設資料樹(即後設資料檔案、清單列表和清單),Iceberg 提供了快照隔離和 ACID 支援。執行查詢時,Iceberg 將使用最新的快照,除非另有說明。對任何給定表的寫入會建立一個新快照,這不會影響併發查詢。併發寫入透過樂觀併發處理(誰先寫新快照,誰先寫,然後再嘗試其他寫)。
除了典型的建立、插入和合並之外,Apache Iceberg 還可以進行行級更新和刪除。所有這些事務都可以使用SQL 命令進行。
Apache Iceberg 是目前唯一支援分割槽演化的表格式。根據分割槽列和列上的轉換(如將時間戳轉換為一天或一年)來跟蹤分割槽。
分割槽允許更有效的查詢,而不是每次都掃描表的完整深度。當您有效地組織要查詢的資料時,分割槽是一個重要的概念。通常,表的分割槽方案需要隨著時間而改變。使用 Hive,更改分割槽方案是一項非常繁重的操作。如果資料按年分割槽並且我們想將其更改為按月分割槽,則需要重寫整個表。大規模管理資料需要更有效的分割槽。
分割槽演化允許我們更新表的分割槽方案,而無需重寫所有以前的資料。
每次對 Iceberg 表進行更新時,都會建立一個快照。您可以指定快照 ID 或時間戳,並像使用 Apache Iceberg 一樣查詢資料。要維護 Apache Iceberg 表,您需要使用 expireSnapshots 過程定期使快照過期以減少儲存的檔案數量(例如,您可能希望使所有早於當年的快照過期。)。快照過期後,您將無法穿越回它。
Apache Hudi
Apache Hudi 的方法是將所有事務分組為沿時間線發生的不同型別的操作。Hudi 使用基於目錄的方法來處理帶有時間戳的檔案和跟蹤該資料檔案中記錄更改的日誌檔案。Hudi 允許您選擇啟用後設資料表以進行查詢最佳化(後設資料表現在預設開啟,從 0.11.0 版本開始)。該表將跟蹤可用於查詢計劃而不是檔案操作的檔案列表,從而避免大型資料集的潛在瓶頸。
Apache Hudi 還為CREATE TABLE、INSERT、UPDATE、DELETE和Queries提供原子事務和 SQL 支援
Hudi 表格格式圍繞表格時間線展開,使您能夠沿時間線查詢以前的點。要維護 Hudi 表,請使用Hoodie cleaner應用程式。一旦你清理了提交,你將不再能夠對它們進行時間旅行。
Delta Lake
Delta Lake 的方法是跟蹤兩種檔案中的後設資料:
- 增量日誌按順序跟蹤表的更改。
- 檢查點彙總了到該點為止對錶的所有更改減去相互取消的事務。
Delta Lake 還支援 ACID 事務,幷包括 對建立、插入、合併、更新和刪除的 SQL 支援。
每個 Delta 檔案都代表表相對於前一個 Delta 檔案的更改,因此您可以針對特定的 Delta 檔案或檢查點來查詢表的早期狀態。預設情況下,Delta Lake 在表的可調整資料保留設定中保留最近 30 天的歷史記錄。使用 Vacuum 實用程式從過期快照中清理資料檔案。使用 Delta Lake,您無法在沒有檢查點可參考的情況下穿越到已刪除日誌檔案的點。
根據清理的日誌,您可以禁用對一組快照的時間旅行。例如,假設您有日誌 1-30,並在日誌 15 處建立了一個檢查點。清理日誌 1 將禁用到日誌 1-14 的時間旅行,因為沒有更早的檢查點可以從中重建表。
詳細點選標題
相關文章
- 資料湖倉比較:Apache Hudi、Delta Lake、Apache IcebergApache
- 常見的三大資料湖技術 - Delta、Hudi、Iceberg大資料
- Delta Lake 資料湖原理和實戰
- 資料湖揭祕—Delta Lake
- 資料湖選型指南|Hudi vs Iceberg 資料更新能力深度對比
- 深度對比Apache CarbonData、Hudi和Open Delta三大開源資料湖方案Apache
- Databricks決定開源其Delta Lake資料湖
- 使用iceberg-使用Iceberg資料湖需要注意的點
- 為什麼Databricks Delta Lake表格式開源很重要?
- Presto+Alluxio 加速 Iceberg 資料湖訪問RESTUX
- 使用Apache Spark和Apache Hudi構建分析資料湖ApacheSpark
- Apache Hudi:雲資料湖解決方案Apache
- Flink CDC 系列 - 同步 MySQL 分庫分表,構建 Iceberg 實時資料湖MySql
- 比較 Apache Hadoop 資料儲存格式 - techwellApacheHadoop
- 通過Apache Hudi和Alluxio建設高效能資料湖ApacheUX
- 使用 Iceberg on Kubernetes 打造新一代雲原生資料湖
- 使用 Flink Hudi 構建流式資料湖平臺
- 基於Apache Hudi + MinIO 構建流式資料湖Apache
- 通過 Apache Zeppelin深入瞭解Delta LakeApache
- 亞馬遜雲科技推出安全資料湖Amazon Security Lake亞馬遜
- 探索多種資料格式:JSON、YAML、XML、CSV等資料格式詳解與比較JSONYAMLXML
- 資料湖Iceberg技術在小米的落地與場景應用
- 對話Apache Hudi VP, 洞悉資料湖的過去現在和未來Apache
- 資料庫圈周盤點:達夢擬科創板IPO;Delta Lake 2.0開源資料庫
- Uber基於Apache Hudi構建PB級資料湖實踐Apache
- 使用Apache Hudi構建大規模、事務性資料湖Apache
- 基於Apache Hudi + Flink的億級資料入湖實踐Apache
- KLOOK客路旅行基於Apache Hudi的資料湖實踐Apache
- 基於Apache Hudi在Google雲構建資料湖平臺ApacheGo
- Flink CDC + Hudi 海量資料入湖在順豐的實踐
- 關於Delta Lake的ACID事務機制簡介
- 大資料檔案格式比較:AVRO vs. PARQUET vs. ORC大資料VR
- 從訊息到資料湖:看 Apache RocketMQ、Hudi、Kyuubi 最新進展ApacheMQ
- Apache Hudi 在 B 站構建實時資料湖的實踐Apache
- 主流資料庫比較資料庫
- 圖資料庫比較資料庫
- 消除資料重力,從智慧湖倉(Lake House)讀懂實現資料價值的未來
- 談談如何從資料湖(Data Lake)架構轉向資料網格(Data Mesh)架構架構