概括
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，並繼續近乎實時地支持更高級的工作負載。 Snowflake 宣佈與 Iceberg 更強大的外表集成，甚至能夠將 Delta 表作爲外表進行查詢。 BigQuery 宣佈與所有三種格式集成，首先是 Iceberg。
所有這些不同的選項都提供了混合支持，我們甚至還沒有開始列出各種開源查詢引擎、數據目錄或數據質量產品的支持。 這種越來越大的兼容性矩陣會讓組織擔心他們會被鎖定在一組特定的供應商或可用工具的子集中，從而在進入數據湖之旅時產生不確定性和焦慮。
爲什麼要建立 Onetable？
在過去的一年裏，我們發佈了開源項目之間的全面比較，展示了 Hudi 如何具有顯着的技術差異化優勢，尤其是在爲 Hudi 和 Onehouse 的增量數據服務提供支持的更新繁重工作負載方面。 此外Hudi 用於管理和優化表格的自動化表格服務爲數據基礎架構奠定了全面的基礎，同時完全開源。 在選擇表格格式時，工程師目前面臨着一個艱難的選擇，即哪些好處對他們來說最重要。 例如選擇 Hudi 的表服務或像 Databricks Photon 這樣快速的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的好處，同時使用他們喜歡的工具和查詢引擎維護他們現有的工作流程。
例如Databricks 是運行 Apache Spark 工作負載的一個非常受歡迎的選擇，其專有的 Photon 引擎可在使用 Delta Lake 表格式時提供性能加速。 爲了確保使用 Onehouse 和 Databricks 的客戶獲得良好的體驗而沒有任何性能缺陷，我們使用 1TB TPC-DS 數據集來對查詢性能進行基準測試。 我們比較了 Apache Hudi 和 Delta Lake 表，有/沒有 Onetable 和 Databricks 的平臺加速，如磁盤緩存和 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 的強大功能。
最重要的是我們很高興看到這如何幫助用戶使用靈活的分層數據架構取得成功，這種架構已經在許多大型數據組織中流行。 Apache Hudi 爲數據湖上的增量攝取/etl 提供行業領先的速度和成本效益，這是 Onehouse 的基礎。 用戶利用 Hudi 將這種高效、成本優化的數據攝取到原始/銅銀表中。 Onehouse 的表管理服務可以直接在湖級別優化此數據的佈局，以獲得更好的查詢性能。 然後用戶可以使用 BigQuery、Redshift、Snowflake 等倉庫引擎或 Databricks、AWS EMR、Presto 和 Trino 等湖引擎轉換這些優化表。 然後將派生數據提供給最終用戶，以構建個性化、近實時儀表板等數據應用程序。 Onetable 爲用戶提供了非常需要的可移植性，讓他們可以根據自己的需求和成本/性能權衡來選擇他們喜歡的查詢引擎。 同時用戶可以通過 Hudi 經驗證的具有挑戰性的變更數據捕獲場景的效率以及 Onehouse 的表優化/管理服務來降低計算成本。
未來工作
數據空間中查詢引擎、開源工具和新產品的格局在不斷髮展。 每年湧現的這些現有服務和新服務中的每一項都對這些表格格式提供了不同程度的支持。 Onetable 允許我們的客戶使用任何與三種格式中的至少一種集成的服務，從而爲他們提供儘可能多的選擇。
Onehouse 致力於開源，其中包括 Onetable。 最初這將是爲 Onehouse 客戶保留的內部功能，因爲我們會迭代設計和實施。 我們正在尋找來自其他項目和社區的合作伙伴來迭代這個共享的表標準表示，並最終爲整個生態系統開源該項目。 例如當底層 Hudi 表發生變化時，Hudi 的目錄同步表服務會增量維護此類目錄元數據。 與 Onetable 的類似實現，將通過單個集成使不同引擎之間的元數據保持同步，從而爲數據湖用戶創造巨大的價值。