即使採用這種基本設置，您的資料也可以很好地支援資料的所有三個主要用例：1. BI 分析 2. 資料密集型 API和3. 機器學習演算法。
事實上，這種架構足夠靈活，可以支援
所有這三種方式，這說明了物件儲存的優勢，特別是它們在與各種資料處理引擎整合方面的靈活性。
使用Spark進行記憶體分佈式處理?沒問題。像Snowflake這樣的列式資料倉儲？小菜一碟。像Trino這樣的分散式查詢引擎？大膽試試吧。
第 1 級：現代表格格式
隨著資料湖的採用呈爆炸性成長，這項基本架構得到了許多改進。第一個也是最明顯的改進是取代那些討厭的 CSV 檔案。
對 CSV 的一項流行改進過去是，現在仍然是柱狀鑲木地板檔案格式。 Parquet 非常適合分析用例，因為它具有以下特點：
柱狀。高度可壓縮
能夠支援複雜的嵌套資料類型。
雖然這些是關鍵改進，但物件儲存 瑞典 WhatsApp 號碼數據 的物件（無論它們如何優化）永遠只能是鬆散的物件集合（不採用單獨的元儲存服務）。
人們意識到，這些物件集合中缺
少的是表的抽象。在資料庫中，表格無所不在，它們提供的所有好處在物件儲存中同樣有效。
這就是表格式的用處：Apache Iceberg、Apache Hudi和Delta Lake。當以這些格式保存資料時，在物件儲存本身內建立表格變得非常容易——具有定義的模式、版本控制歷史記錄以及原子更新的能力。
這極大地增強了資料湖的效能
和可用性。很快我們的基本資料湖將看起來更像這樣：
一級表格式湖數據
這些表格格式如何運作？嗯，它們背 資料來源：美國商業資訊 後的想法是維護從湖中某些前綴添加（和刪除）的物件的交易日誌。這為寫入操作的原子性提供了重要的保證，讓我們在同時讀寫資料時避免查詢錯誤。
有關更多詳細信息，這裡有兩篇
文章深入探討了更多細節：
現代資料湖儲存層簡介
Hudi、Iceberg 與 Delta Lake：資料湖表格式比較
第 2 級：資料來源控制
雖然表格格式使我們 加拿大數據 的資料湖更加令人印象深刻，但我們還沒有完成對其的改進。在表格層級提供的現代文件格式的所有好處都可以進一步擴展以涵蓋我們的整個資料湖！
你怎麼問？使用LakeFS 這樣的資料來源
控制工具，可以將物件儲存的儲存桶轉變為資料儲存庫，我們可以在其中追蹤多個資料集。
雖然之前的架構對您來說仍然記憶猶新，但我們的資料湖在這個層級上是這樣的：
資料夾層次結構中新增了一個新層，該層對應於分支的名稱。 LakeFS 允許我們建立、更改和合併任意數量的分支，從而可以執行以下操作：
建立所有表格的多個副本（不複製物件！）
將表的跨集合快照保存為提交和它們之間的時間旅行
例如，可以透過從一個分支到另一個分支的合併操作來同步同一 LakeFS 儲存庫中的兩個 Iceberg 表（甚至 Hudi 和 Iceberg 表）的更新。
當涉及到在 ML 實驗中重現訓練資料的狀態或更新資料資產為關鍵 API 提供動力時，以這種方式保持資料的靈活性使得即使在最大的資料湖上也能高效工作。