譯者 | 陳峻
審校 | 重樓
近年來,開放表格式(Open table formats)和對象存儲(object storage)正在重新定義各個組織構建其數據系統的方式,并為可擴展、高效、且面向未來的數據湖倉(data lakehouse)奠定了基礎。通過利用對象存儲的成本效益等獨特優勢,以及 Apache Iceberg、Delta Lake 和 Apache Hudi 等開放表格式的高級元數據管理功能,組織正在創建滿足現代化數據工作負載需求的模塊化架構。
本指南將從開放表格式和對象存儲在構建現代化數據湖倉中的作用與演變出發,深入探討各種頂級的表格式的特征比較,進而介紹在針對高級分析和 AI 工作負載架構進行性能優化時的注意事項。據此,你將能夠設計出可擴展、高效、且能夠適應數據驅動時代快速變化需求的數據系統。
開放表格式的適用范圍
現代數據湖倉架構建立在三個關鍵組件之上,即:以對象存儲為基礎的存儲層、位于中心的開放表格式、以及最終傳遞到可擴容的計算引擎。這種模塊化設計經過優化,可以充分利用對象存儲的可擴展性和成本效益,實現無縫的元數據管理,以及橫跨不同計算引擎的互操作性。
如下圖所示,此類架構轉變的核心在于計算和存儲的分解。作為基礎,對象存儲提供了對于結構化、半結構化、以及非結構化數據的無縫管理;而開放表格式充當著元數據的抽象層,支持類似數據庫的功能,包括:模式(schema)演變、時間旅行、分區和 ACID(原子性、一致性、隔離性和持久性)事務等。而Spark、Presto、Trino 和 Dremio 等計算引擎通過與這些表格式的交互,提供了大規模處理和分析數據的靈活性,而不會受制于供應商。
數據架構的演變
如上圖所示,數據湖倉的興起可以被理解為數據架構一種更廣泛的演變。過去,在線事務處理 (OTLP) 數據庫等早期系統優先考慮的是事務的完整性,但缺乏分析功能。之后,在線分析處理(OLAP) 系統的出現引入了數據倉庫,優化了結構化數據的查詢,但是其代價是無法有效地處理半結構化與非結構化的數據。數據湖的出現解決了此類限制,為各種數據類型提供了可擴展的存儲和讀時模式 (Schema-on-Read) 功能。然而,數據湖缺乏事務的保證,這引發了數據湖倉的出現。它能夠將數據湖和數據倉庫的優勢集成到一個統一的架構中。
說到數據湖倉,它是基于開放表格式和對象存儲構建、且完全解耦的。這種分解式架構既提供了數據庫的事務一致性,又提供了對象存儲的可擴展性。
為何開放表格式是對象存儲的理想選擇
經過專門設計的數據湖倉架構,旨在充分利用諸如 Amazon Web Services (AWS) S3、Google Cloud Storage 和 Azure Blob Storage等對象存儲系統的可擴展性和成本效益。也就是說,這種集成支持在一個統一的平臺中,無縫地管理各種數據類型(如:結構化、半結構化和非結構化)。總體而言,對象存儲上的數據湖倉架構的主要功能包括:
- 統一存儲層:通過利用對象存儲,數據湖倉可以其原生的格式存儲大量數據,而無需在存儲之前進行復雜的數據轉換。這種方法不但簡化了數據的攝取,而且實現了與各種數據源的兼容。
- 可擴展性:對象存儲系統具有原生的可擴展性,使得數據湖倉能夠容納不斷增長的數據量,而無需對基礎設施進行重大更改。這種可擴展性使得組織能夠有效地管理不斷增多的數據集和不斷變化的分析要求。
- 靈活性:一流的對象存儲可以部署在包括:本地、私有云、公共云、主機托管設施、數據中心、以及邊緣等任何地方。這種靈活性使組織能夠根據特定的運營和地理需求,定制其數據基礎設施。通過集成上述功能,數據湖倉架構結合了數據湖和數據倉庫的優勢,進而提供了一套全面的解決方案。由于所有這些設計都是建立在可擴展且靈活的對象存儲系統之上,因此也就實現了高效的數據存儲、管理和分析。
典型的開放表格式
開放表格式是一種標準化的開源框架,旨在高效管理大規模的分析性數據集。通常,它作為數據文件之上的元數據層來執行,可以促進橫跨各種處理引擎的無縫數據管理和訪問。以下是三種典型的開放表格式--Iceberg、Delta Lake 和 Hudi:
Apache Iceberg
Apache Iceberg 是一種高性能的表格式,專為海量數據集而設計。作為現代化分析工作負載的基石,該架構優先考慮了高效的讀取操作和可擴展性。其定義功能之一是將元數據與普通數據分離,從而允許基于快照的高效隔離和規劃。這種設計消除了成本高昂的元數據操作,并能夠支持橫跨大型數據集的并行查詢與規劃。
Iceberg 生態系統的最新發展凸顯了它在整個行業上的日益普及。其S3 表能夠讓查詢引擎直接訪問存儲在 S3 兼容系統中的表元數據和數據文件,從而減少了延遲,提高了互操作性,并簡化了數據管理。與此同時,Databricks 對 Tabular 的收購凸顯了 Iceberg 在開放式湖倉平臺中的首要作用,并強化了其對于性能和治理的關注。而Snowflake將 Polaris 開源化的決定,則表明了該行業對于開放性和互操作性的承諾,也進一步鞏固了 Iceberg 作為領先表格式的地位。
Delta Lake
與 Apache Spark 密切相關的Delta Lake 最初由 Databricks 開發。它既能夠與 Spark API 完全兼容,又可與 Spark 的結構化流式處理相集成,實現了批處理和流式處理操作。其中,Delta Lake 的一個關鍵性功能是:它使用事務日志來記錄對于數據所做的所有更改,從而確保了一致性的視圖和寫入隔離。而且,該設計支持并發數據操作,能夠適用于高吞吐量的環境。
Apache Hudi
Apache Hudi 旨在應對實時數據攝取和分析的挑戰,尤其是在那些數據需要頻繁更新的環境中。也就是說,其架構既支持用于高效數據攝取的寫入優化存儲(write-optimized storage,WOS) ,又可用于查詢的讀取優化存儲(read-optimized storage,ROS),從而實現了數據集的最新視圖。
通過逐步處理數據流中的更改,Hudi 實現了大規模的實時分析。bloom篩選條件和全局索引等功能可以優化 I/O 操作,從而提高查詢和寫入的性能。此外,Hudi 還包含了用于集群、壓縮和清理的工具。這些工具有助于維護數據表的組織和性能。而且,其處理記錄級更新和刪除的能力,已成為高速數據流和嚴格數據管理與合規場景的實用選擇。
比較開放表格式
Apache Iceberg、Delta Lake 和 Apache Hudi 都為數據湖倉化的架構帶來了各自獨特的優勢。以下是基于它們主要特征的比較:
- ACID 事務:所有三種格式都能符合 ACID 的要求,能夠確保可靠的數據操作。其中,Iceberg 采用快照隔離來實現事務完整性;Delta Lake 利用事務日志實現一致的視圖和寫入隔離;而Hudi 為高并發的場景提供了文件級的并發控制。
- 架構演變:每種格式都支持架構的更改,并允許添加、刪除或修改數據列。Iceberg 提供了靈活的架構演變,而無需重寫現有數據;Delta Lake 在運行時會強制執行架構,以保持數據的質量;而 Hudi 提供了預提交轉換功能,以提高靈活性。
- 分區演變:Iceberg 支持分區演變,無需重寫現有數據,即可無縫更新分區方案;Delta Lake 允許分區更改,但可能需要手動干預,才能獲得最佳性能;而 Hudi 提供精細的集群,作為傳統分區的替代方案。
- 時間旅行:這三種格式都能提供時間旅行功能,允許用戶查詢歷史數據狀態。顯然,該功能對于審計和調試來說非常實用。
- 廣泛采用:Iceberg 是數據社區最廣泛被采用的開放表格式。從 Databricks 到 Snowflake 再到 AWS,許多大型平臺都投資了 Iceberg。如果你已經是這些生態系統的一部分或正在考慮加入它們,那么 Iceberg 可能會自然成為你的不二之選。
- 索引:Hudi 通過提供多模式索引功能,包括 Bloom 過濾器和記錄級索引,來提高查詢性能。Delta Lake 和 Iceberg 則依賴于元數據的優化,并不提供相同級別的索引靈活性。
- 并發和流式處理:Hudi 專為實時分析而設計,帶有高級并發控制和內置工具(如 DeltaStreamer),可用于增量數據的攝取;Delta Lake 支持通過更改數據源,實現流式處理;而 Iceberg 提供了基本的增量讀取功能。雖然上述三種格式都為現代化數據架構提供了強大的基礎,但是由于各自的特點比較明顯,因此具體該如何選擇則取決于特定的工作負載要求和組織需求。
性能預期
在數據湖倉架構中,實現最佳性能對于充分利用開放表格式的功能是至關重要的。而相關性能往往取決于存儲層和計算層的效率。其中,
- 存儲層必須能夠提供低延遲和高吞吐量,以滿足大規模的數據分析需求。因此,選用的對象存儲解決方案應有助于快速訪問數據,并支持高速傳輸,而且即便是在高工作負載下也能確保平穩的運行。此外,高效的每秒輸入/輸出操作數 (input/output operations per second,IOPS) 對于處理大量并發的數據請求也非常重要,它能夠實現無瓶頸的響應式數據交互。
- 計算層性能同樣也會直接影響數據處理和查詢的執行速度。計算引擎需要通過可擴展性,在不影響性能的情況下,管理不斷增長的數據量和用戶查詢。采用優化的查詢執行計劃和資源管理策略,則可以進一步提高處理效率。此外,計算引擎需要通過與開放表格式的無縫集成,來充分利用 ACID 事務、架構演變和時間旅行等高級功能。
通過正確配置和完全優化,開放表格式也能夠將元數據與普通數據分開管理,從而實現更快的查詢規劃和執行。同時,數據分區會將數據分組成多個子集,通過減少操作期間掃描的數據量,來提高查詢性能。而通過對架構演變的支持,表格式則能夠適應數據結構的變化,而無需進行大量的數據重寫,實現了在確保靈活性的同時,最大限度地減少了處理的開銷。
可見,通過關注存儲和計算層的上述性能方面,組織可以確保其數據湖倉環境的高效與可擴展性,并能夠滿足現代化分析和 AI 工作負載的需求。當然,這些考慮因素也會使得開放表格式能夠充分地發揮其潛力,并提供實時洞察和決策所需的高性能。
開放數據湖倉和互操作性
為了提供統一的數據管理方法,數據湖倉架構往往會基于開放表格式來構建。不過,實現真正的開放性,光靠采用開放的表格式是不夠的。開放的數據湖倉必須集成各種模塊化、以及存儲引擎、目錄和計算引擎等可互操作的開源組件,來實現橫跨不同平臺的無縫操作。
好在開放表格式是一套開放的標準,可以根據其設計,來支持整個技術棧的互操作性和開放性。不過,在實際使用中,挑戰仍然存在。例如,需要確保目錄互操作性,以及避免依賴專有服務進行數據表的管理。新近推出的 Apache XTable 等工具,便展示了其在通用兼容性方面的進展,并為“一次性寫入、隨處查詢”的系統提供了新的途徑。需要注意的是,XTable 并不允許用戶以多種開放的表格式寫入,而只允許讀取。
開放表格式的未來
隨著數據湖倉的不斷發展,各種趨勢和進步正在塑造其未來。其中,
- 一個重要增長領域便是將 AI 和機器學習 (ML) 工作負載直接集成到湖倉的架構中。對于存儲層而言,它可能是與 Hugging Face 和 OpenAI 等關鍵 AI 平臺直接集成的平臺。而對于計算層,AI 集成可能會導致創建針對 ML 算法優化的專用計算引擎,從而提高湖倉生態系統中訓練和推理過程的效率。
- 另一個顯著增長的領域則可能是開源社區。當 Databricks、Snowflake 和 AWS 等大型私營公司大行其道時,人們很可能忘記了開放表格式其實是一個真正的開放標準。Iceberg、Hudi 和 Delta Lake 可供任何貢獻者開展協作,或集成到開源的工具和平臺中。換句話說,它們是充滿活力且不斷發展的開放式標準數據生態系統的一部分。我們可以預見到各種開源應用、插件、目錄和創新在該領域的持續激增。
- 最后,隨著企業為 AI 和其他高級用例構建更多大規模、高性能的數據湖倉,開放表格式的采用率也將繼續上升。一些行業專業人士甚至將開放表格式的流行視同于 2000 年代初 Hadoop 的崛起和后續的霸主地位。
小結
通過將開放表格式與高性能對象存儲相結合,架構師能夠構建出開放、可互操作且能夠滿足 AI、ML 和高級分析需求的數據系統。而通過采用上述提到的各項技術,組織可以創建出可擴展且靈活的架構,從而在數據驅動時代推動業務的創新和提效。
譯者介紹
陳峻(Julian Chen),51CTO社區編輯,具有十多年的IT項目實施經驗,善于對內外部資源與風險實施管控,專注傳播網絡與信息安全知識與經驗。
原標題:The Architect’s Guide to Open Table Formats and Object Storage,作者:Brenna Buuck