概括
Onehouse 客戶現在可以将他們的 Hudi 表查詢為 Apache Iceberg 和/或 Delta Lake 表，享受從雲上查詢引擎到頂級開源項目的原生性能優化。
在資料平台需求層次結構的基礎上，存在攝取、存儲、管理和轉換資料的基本需求。Onehouse 提供這種基礎資料基礎架構作為服務，以在客戶資料湖中攝取和管理資料。随着資料湖在組織内的規模和種類不斷增長，将基礎資料基礎架構與處理資料的計算引擎分離變得勢在必行。不同的團隊可以利用專門的計算架構，例如 Apache Flink（流處理）、Ray（機器學習）或 Dask（Python 資料處理），以解決對其組織重要的問題。解耦允許開發人員在以開放格式存儲的資料的單個執行個體上使用這些架構中的一個或多個，而無需将其複制到和存儲緊密耦合的另一服務中。Apache Hudi、Apache Iceberg 和 Delta Lake 已成為領先的開源項目，為這個解耦存儲層提供一組強大的原語，這些原語在雲存儲中圍繞打開的檔案提供事務和中繼資料（通常稱為表格式）層，像 Apache Parquet 這樣的格式。
背景
AWS 和 Databricks 在 2019 年為此類技術創造了最初的商業勢頭，分别支援 Apache Hudi 和 Delta Lake。如今大多數雲資料供應商都支援其中一種或多種格式。然而他們繼續建構一個垂直優化的平台以推動對他們自己的查詢引擎的粘性，其中資料優化被鎖定到某些存儲格式， 例如要解鎖 Databricks 的 Photon 引擎的強大功能需要使用 Delta Lake。多年來 AWS 已在其所有分析服務中預安裝 Apache Hudi[1]，并繼續近乎實時地支援更進階的工作負載。Snowflake 宣布與 Iceberg 更強大的外表內建，甚至能夠将 Delta 表作為外表進行查詢。BigQuery 宣布與所有三種格式內建，首先是 Iceberg[2]。
所有這些不同的選項都提供了混合支援，我們甚至還沒有開始列出各種開源查詢引擎、資料目錄或資料品質産品的支援。這種越來越大的相容性矩陣會讓組織擔心他們會被鎖定在一組特定的供應商或可用工具的子集中，進而在進入資料湖之旅時産生不确定性和焦慮。
為什麼要建立 Onetable？
在過去的一年裡，我們釋出了開源項目之間的全面比較[3]，展示了 Hudi 如何具有顯着的技術差異化優勢，尤其是在為 Hudi 和 Onehouse 的增量資料服務提供支援的更新繁重工作負載方面。此外Hudi 用于管理和優化表格的自動化表格服務為資料基礎架構奠定了全面的基礎，同時完全開源。在選擇表格格式時，工程師目前面臨着一個艱難的選擇，即哪些好處對他們來說最重要。例如選擇 Hudi 的表服務[4]或像 Databricks Photon[5] 這樣快速的Spark引擎。在 Onehouse我們會問真的有必要進行選擇嗎？我們希望客戶在處理他們的資料時獲得盡可能好的體驗，這意味着支援 Hudi 以外的格式以利用資料生态系統中不斷增長的工具和查詢引擎集。作為一家倡導跨查詢引擎互操作性的公司，如果我們不對中繼資料格式應用相同的标準以幫助避免将資料分解成孤島，那我們的表現就很虛僞。今天我們通過 Onetable 朝着這個方向邁出了一大步。
什麼是 Onetable？
Onehouse 緻力于開放，并希望通過我們的雲産品 Onetable 上的一項新功能，幫助組織享受 Hudi 解鎖的成本效率和進階功能，而不受目前市場産品的限制。當資料靜止在湖中時三種格式并沒有太大差別。它們都提供了對一組檔案的表抽象，以及模式、送出曆史、分區和列統計資訊。Onetable 采用源中繼資料格式并将表中繼資料提取為通用格式，然後可以将其同步為一種或多種目标格式。這使我們能夠将通過 Hudi 攝取的表公開為 Iceberg 和/或 Delta Lake 表，而無需使用者複制或移動用于該表的底層資料檔案，同時維護類似的送出曆史記錄以啟用适當的時間點查詢。
這種方法類似于 Snowflake 為 Iceberg 表保留其内部中繼資料，同時為外部互操作性建立 Iceberg 中繼資料的方式。Hudi 還已經支援與 BigQuery 的內建，大型開源使用者和 Onehouse 使用者正在使用它。
我們為什麼興奮？
Onehouse 客戶可以選擇啟用 Onetable 作為目錄來自動将他們的資料公開為 Hudi 表以及 Iceberg 和/或 Delta Lake 表。以這些不同的中繼資料格式公開表使客戶能夠輕松地加入 Onehouse 并享受托管Lakehouse[6]的好處，同時使用他們喜歡的工具和查詢引擎維護他們現有的工作流程。
例如Databricks 是運作 Apache Spark 工作負載的一個非常受歡迎的選擇，其專有的 Photon[7] 引擎可在使用 Delta Lake 表格式時提供性能加速。為了確定使用 Onehouse 和 Databricks 的客戶獲得良好的體驗而沒有任何性能缺陷，我們使用 1TB TPC-DS 資料集來對查詢性能進行基準測試。我們比較了 Apache Hudi 和 Delta Lake 表，有/沒有 Onetable 和 Databricks 的平台加速，如磁盤緩存[8]和 Photon。下圖顯示了 Onetable 如何通過基于 Delta Lake 協定轉換中繼資料來解鎖 Onehouse/Hudi 表上 Databricks 内部的更高性能。
此外我們将 Snowflake 中的同一張表公開為外部表，該表通常用于數倉。我們執行了類似的 1TB TPC-DS 基準測試，比較了 Snowflake 的原生/專有表、外部Parquet表和使用 Onetable 的 Hudi 表。下圖顯示 Onetable 如何向 Snowflake 查詢公開 Hudi 表的一緻快照，同時提供與 Snowflake 的 parquet 表類似的性能。
雖然上述外表的性能不如本地 Snowflake 表快，Onetable 提供了公開 Snowflake 内部資料湖的最新視圖的功能，以幫助支援下遊 ETL/轉換或在組織過渡到建構Lakehouse以補充其 Snowflake 資料倉庫時保持查詢運作。這種方法避免了将全套資料複制到倉庫或使存儲成本加倍，同時仍允許工程師和分析師派生出更有意義的聚合原生表，以快速提供報告和儀表闆，充分利用 Snowflake 的強大功能。
最重要的是我們很高興看到這如何幫助使用者使用靈活的分層資料架構取得成功，這種架構已經在許多大型資料組織[9]中流行。Apache Hudi 為資料湖上的增量攝取/etl 提供行業領先[10]的速度和成本效益，這是 Onehouse 的基礎。使用者利用 Hudi 将這種高效、成本優化的資料攝取到原始[11]/銅銀[12]表中。Onehouse 的表管理服務可以直接在湖級别優化此資料的布局，以獲得更好的查詢性能。然後使用者可以使用 BigQuery、Redshift、Snowflake 等倉庫引擎或 Databricks、AWS EMR、Presto 和 Trino 等湖引擎轉換這些優化表。然後将派生資料提供給最終使用者，以建構個性化、近實時儀表闆等資料應用程式。Onetable 為使用者提供了非常需要的可移植性，讓他們可以根據自己的需求和成本/性能權衡來選擇他們喜歡的查詢引擎。同時使用者可以通過 Hudi 經驗證的具有挑戰性的變更資料捕獲場景的效率以及 Onehouse 的表優化/管理服務來降低計算成本。
未來工作
資料空間中查詢引擎、開源工具和新産品的格局在不斷發展。每年湧現的這些現有服務和新服務中的每一項都對這些表格格式提供了不同程度的支援。Onetable 允許我們的客戶使用任何與三種格式中的至少一種內建的服務，進而為他們提供盡可能多的選擇。
Onehouse 緻力于開源，其中包括 Onetable。最初這将是為 Onehouse 客戶保留的内部功能，因為我們會疊代設計和實施。我們正在尋找來自其他項目和社群的合作夥伴來疊代這個共享的表标準表示，并最終為整個生态系統開源該項目。例如當底層 Hudi 表發生變化時，Hudi 的目錄同步表服務會增量維護此類目錄中繼資料。與 Onetable 的類似實作，将通過單個內建使不同引擎之間的中繼資料保持同步，進而為資料湖使用者創造巨大的價值。
引用連結
[1]
預安裝 Apache Hudi: [https://www.onehouse.ai/blog/apache-hudi-native-aws-integrations](https://www.onehouse.ai/blog/apache-hudi-native-aws-integrations)
[2]
首先是 Iceberg: [https://cloud.google.com/bigquery/docs/iceberg-tables](https://cloud.google.com/bigquery/docs/iceberg-tables)
[3]
全面比較: [https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison](https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison)
[4]
表服務: [https://hudi.apache.org/docs/clustering](https://hudi.apache.org/docs/clustering)
[5]
Databricks Photon: [https://www.databricks.com/product/photon](https://www.databricks.com/product/photon)
[6]
托管Lakehouse: [https://onehouse.ai/product](https://onehouse.ai/product)
[7]
Photon: [https://www.databricks.com/product/photon](https://www.databricks.com/product/photon)
[8]
磁盤緩存: [https://docs.databricks.com/optimizations/disk-cache.html#optimize-performance-with-caching-on-databricks](https://docs.databricks.com/optimizations/disk-cache.html#optimize-performance-with-caching-on-databricks)
[9]
大型資料組織: [https://www.uber.com/blog/uber-big-data-platform/](https://www.uber.com/blog/uber-big-data-platform/)
[10]
行業領先: [https://aws.amazon.com/blogs/big-data/how-amazon-transportation-service-enabled-near-real-time-event-analytics-at-petabyte-scale-using-aws-glue-with-apache-hudi/](https://aws.amazon.com/blogs/big-data/how-amazon-transportation-service-enabled-near-real-time-event-analytics-at-petabyte-scale-using-aws-glue-with-apache-hudi/)
[11]
原始: [https://robinhood.engineering/author-balaji-varadarajan-e3f496815ebf](https://robinhood.engineering/author-balaji-varadarajan-e3f496815ebf)
[12]
銅銀: [https://www.databricks.com/glossary/medallion-architecture](https://www.databricks.com/glossary/medallion-architecture)