大資料架構經過多年的演進，傳統資料倉庫和資料湖的侷限性日益凸顯。在此背景下，湖倉一體 Lakehouse 憑藉其開放性和成本效益，迅速成為當今資料平臺的主流架構。然而，隨著進入 Data + AI 驅動的新時代，企業對即時資料分析的需求不斷增加，對半結構化和非結構化資料的處理也愈顯重要。那麼，應該如何高效整合多種資料來源，實現即時分析與智慧決策？

近日 InfoQ《極客有約》X QCon 直播欄目特別邀請了 阿里雲智慧 Flink SQL 負責人伍翀 擔任主持人，和 阿里雲高階開發工程師羅宇俠、StarRocks 研發工程師王雲霏、字節跳動研發工程師閔文俊 一起，在 Qcon 全球軟體開發大會2025 北京站 即將召開之際，共同探討最新的 Lakehouse 架構演進趨勢。

部分精彩觀點如下：

https://qcon.infoq.cn/2025/beijing/track

伍翀： 過去一年 Lakehouse 架構在國內和國外的發展都很迅猛，在商業上也發生幾大引人注目的事件，比如 Databricks 十億美金收購 Tabular，Snowflake 和 Databricks 都開源了他們的元資料產品，很多公司也都引入了或者正在引入 Lakehouse 架構，那麼 Lakehouse 未來的關鍵發展趨勢有哪些？

羅宇俠： 最重要的趨勢是 Lakehouse 架構與 AI 技術的深度結合。Lakehouse 本身原生支援多模態資料的統一儲存與管理，並能夠結合向量嵌入（embedding）和索引技術，透過特徵管理等方法，成為 AI 訓練和 RAG 的基礎設施。

其次，我認為另一個重要的趨勢是資料時效性的提升。在 AI 時代，即時資料變得尤為重要，因為資料是否及時更新，直接影響到 AI 模型的準確性和有效性。因此，我認為未來 Lakehouse 架構將從分鐘級逐步向秒級資料時效性邁進，以滿足企業對不同資料時效性的需求。最近，像 Kafka 的商業化公司 Confluent 提出了 TableFlow，旨在將 Kafka 的資料流轉移到 Iceberg 以及 Snowflake 公司準備收購訊息佇列創業公司 Redpanda 都進一步佐證了這一點。

最後，我認為未來 Lakehouse 架構將會更加標準化。隨著生態中各個參與者的深入合作，包括資料整合服務商、BI 工具提供商、資料庫和計算儲存服務商等, 將推動形成一個標準化的 Lakehouse 全套解決方案。

王雲霏：Lakehouse 的出現源於資料量和企業開銷的高速增長，特別是在結構化、非結構化和半結構化資料的快速增長推動下。根據 IBM 報告，企業在資料上的年開銷增長超過 30%，並隨著 AI 的興起，資料量和開銷預計將繼續增長。

資料的使用方式也在發生變化。過去，資料主要用於商業分析和 BI 應用，但隨著 AI 的發展，資料將更多應用於 AI 場景。企業需要更多的資料和即時更新的資料來挖掘深層洞察，並支援快速決策。新技術的出現進一步改變了資料使用方式。物件儲存降低了成本，開放格式使得各種資料可以以靈活的方式儲存，進而讓不同應用選擇最具價效比的儲存方式。

Lakehouse 架構正是基於這些趨勢，它解決了成本問題並滿足了開放儲存的需求。隨著開放標準的確立，預計到 2025 年，模組化的 Lakehouse 架構將成為企業的優選，幫助企業根據需求選擇最合適的儲存方案、引擎和元資料管理方式，從而在滿足不同需求的前提下提升價效比。

閔文俊： 隨著 Databricks 收購 Iceberg 背後的商業公司，以及 Snowflake 開源其元資料層 Polaris，去年還出現了元資料目錄專案 Gravitino 的誕生。可以看出，各大廠商越來越重視元資料層的建設。這背後映射出的是，廠商們對開放標準的重視。開放標準不僅意味著你對雲廠商的選擇有更大的靈活性，也意味著你對標準制定的能力有更高的要求。

未來的 Lakehouse 架構將更加註重元資料的標準化，並且也會關注跨平臺的相容性。企業能從這一趨勢中獲益的主要方面是，透過元資料的標準化，可以打破企業內部各個資料來源之間的資料孤島，從而使資料能夠發揮更多的價值。

另外一個方面是，整體的大背景和企業面臨的問題，尤其是降本增效的需求。降本增效在 Lakehouse 架構中也扮演著重要角色。目前，存算分離已經成為一個顯著趨勢。在成本壓力下，使用者對效能的需求並未減弱。因此，Lakehouse 架構面臨的一個共同問題是，在降低成本的同時，如何儘量減少效能損失。為了應對這一問題，各家的 Lakehouse 引擎逐漸透過深入挖掘硬體層面的能力，來提升整體效能。例如，向量化引擎和計算快取等技術被廣泛應用，以彌補成本與效能之間的平衡。

王雲霏：Lakehouse 架構的優勢主要體現在以下幾個方面：首先，力求實現“單一資料來源”，即避免冗餘，減少儲存開銷，實際使用中儲存成本最高可能減少 90%。其次，Lakehouse 希望確保資料具有較高的新鮮度，以便快速查詢和使用。第三，簡化 ETL 作業是 Lakehouse 設計的另一目標。

然而，實際應用中面臨挑戰著如何確保資料分析的效能與傳統資料倉庫相當這一挑戰。過去一年，我們在效能最佳化方面取得了進展，StarRocks 與 Iceberg 或 Paimon 等資料湖格式結合，查詢效能提升至 Databricks 引擎的兩倍。AI 方面，我們面臨的挑戰是如何將 AI agent 與 Lakehouse 中的資料結合，比如如何結合傳統資料平臺的聚合與關聯計算能力，滿足 AI agent 在趨勢性資料處理中的需求。

伍翀：AI agent 在某些場景下，特別是在做統計分析和批處理（batch）任務時，展現了很大的潛力。您能否進一步展開介紹一下？是否有您那邊觀察到的具體場景或應用案例，能夠展示 AI agent 與特定業務需求或技術結合的情況？

王雲霏：AI agent 已有一些原型系統，能夠查詢 Lakehouse 中的資料，但還不成熟。AI agent 需要感知理解資料，這可能導致元資料請求量顯著增加。隨著併發增加，如何高效解析資料成為關鍵問題，還有就是 AI agent 對即時性的要求較高，需要快速互動並採取行動。

AI agent 對資料的即時性和計算效能要求較高，當前的應對方向是增量計算、預計算和快取系統最佳化，以支援高效能、高併發、低延遲的需求。與傳統資料分析師不同，AI agent 支援更高的併發和更短的即時響應，這使得如何處理高併發、低延遲需求成為系統設計中的重要課題。

伍翀： 文俊老師和宇俠老師對 Data+ AI 這塊的挑戰有沒有什麼想法？

閔文俊：AI 場景中一個顯著的特點是非結構化資料的急劇增加，所以我們需要支援跨資料型別的管理。常見的設計方法是透過統一的元資料目錄，將多模態資料納入 Lakehouse 的元資料管理體系中。具體來說，通常我們透過在 Lakehouse 中建立表模型，將多模態資料的一部分進行結構化儲存，同時對於非結構化資料，我們仍然將其儲存在物件儲存中，並透過路徑指向這些資料，從而將相關的元資料進行管理。

隨著 AI 與 Lakehouse 架構的緊密結合，Python 作為 AI 生態中最通用的程式語言，其介面在整個 AI 生態中起到了至關重要的作用。因此另一個挑戰是，Lakehouse 架構需要提供一套高效能的 Python 讀寫介面，以供 AI 框架使用。在不損失原始讀寫效能的情況下，這對 Lakehouse 架構提出了更高的要求。當前業界常見的做法是，使用原生語言（如 C++ 或 Rust）實現底層功能，並在其上封裝 Python 介面，以呼叫這些底層庫。這一做法背後需要一個穩定的核心支援，也就是我們之前提到的標準化。

此外，隨著多模態資料的不斷增長，相比於傳統的結構化資料，非結構化資料在 Lakehouse 中儲存時通常使用 Parquet 格式。然而，Parquet 格式更多適用於大規模掃描場景，對於 AI 場景中的高效檢查和更新操作並不理想。在 AI 場景下，可能需要一些新的檔案格式來支援更高效的資料儲存和處理。

羅宇俠： 首先，對於 AI 而言，非結構化資料的組織和檢索至關重要。Lakehouse 架構需要更加高效地組織並快速檢索非結構化資料，例如，Paimon 正在探索的 Object Table 功能，透過對文字或影像根據檔案資訊建立表，並在其上建立索引，使得可以快速地檢索到資料，如快速定位到某個特定日期生成的影像檔案，從而高效支援 AI 訓練。

其次，AI 更加傾向於使用嵌入或向量化的格式，而目前的 Lakehouse 架構更多側重於分析場景，AI 大模型的需求與當前架構的計算正規化並不完全對齊, 傳統的資料分析架構很難完全匹配 AI 場景下的需求。

目前 Lakehouse 架構通常處理的是分鐘級的資料新鮮度，即時資料仍然是一個缺失。我認為解決方案之一可能是引入額外的即時儲存元件，例如 Kafka。這需要有效地處理 Kafka 中的即時資料流，並將其傳輸到 Lakehouse 中。Confluent 提供的 TableFlow 可以將資料從 Kafka 流轉到 Iceberg。我們團隊提出的 Fluss 湖流一體也正是為了彌補這個缺失，自動將即時資料流轉到資料湖中, 無縫融合進 LakeHouse 架構中.

伍翀： 總結一下，在 AI 場景中，AI 對資料系統提出了更高的效能和即時性要求。資料的即時性對於 AI 應用尤為重要，因為一個好的 AI agent 需要高質量、即時的資料來提升其決策準確性和價值。此外，資料查詢效能也需要進一步最佳化，以滿足 AI 應用的需求。同時，Python 語言在資料湖框架中的應用也在不斷演進。各大資料湖框架最近推出了自己的 Python 庫，並且一些新型的資料湖格式，如針對 AI 場景構建的 LanceDB，也在不斷發展。

閔文俊： 我認為 Paimon 的跟進相當及時。此外，Iceberg 在社群中的參與也非常活躍，它的 Iceberg C++、Rust 和 Python 介面都很豐富。

王雲霏： 是的，特別是在國外，Iceberg 被廣泛採用，並且在各個方面的跟進也非常及時。

伍翀： 回到即時性的問題，大家都提到，在 AI agent 做決策時，資料的即時性顯得尤為關鍵。與傳統的 BI 決策場景不同，AI 應用對資料的即時性要求更加嚴格，因為它們需要即時反饋以支援動態決策。

閔文俊： 從企業的角度來看，若要引入一套新的架構，背後一定有一個需要解決的關鍵痛點。無論是當前架構中的時效性問題，例如基於 Hive 的 T+1 時效無法滿足需求，還是儲存成本問題，例如 Hive 場景下每天全量增量處理帶來的高儲存成本，這些問題都可能推動企業引入新的架構。此外，企業可能還面臨如何高效更新湖倉層、實現流批統一儲存等挑戰。

我認為，在做出新的架構選型時，企業首先應從當前面臨的實際業務痛點出發，明確解決這些痛點的需求，之後另一個考量點是 Lakehouse 架構的生態成熟度。具體來說，生態成熟度包括以下幾個方面：從資料攝入的角度來看，是否支援豐富的資料匯入外掛，尤其是如 CDC（Change Data Capture）等技術？從資料開發的角度，是否支援主流的計算引擎？在進行 OLAP 分析時，下游工具如支援程度如何？這些因素都會影響企業在引入即時 Lakehouse 架構時的選型決策。

在確定選型之後，還需考慮如何讓新的 Lakehouse 架構與現有的企業生態相容。正如我們所稱的資料湖倉，它不僅僅是資料湖，還需要相容歷史資料倉庫的架構。引入即時 Lakehouse 架構時，需要考慮如何在保持現有生態相容的情況下，逐步進行架構的迭代與升級。

伍翀： 現在業界有沒有什麼比較成熟、典型的搭建即時數倉的架構？並且這個架構當前還會遇到什麼樣的問題嗎？

閔文俊： 我們目前的實踐基於 Paimon 架構，作為資料湖倉的底層架構，Paimon 提供了 HDFS 作為資料儲存基礎。Paimon 的一個顯著特點是其時效性有保障，並且基於 LSM 結構，在主鍵表的高效更新場景中，表現出非常好的效能。同時，Paimon 針對流式場景提供了諸如 Changelog Producer 的能力，使得在企業開發資料管道時，能夠以增量方式處理資料流，這對於流式開發場景非常友好。對於離線場景，Paimon 同樣提供了良好的效能，包括列式儲存、資料聚類、Z-Order 排序、基於資料過濾的下推最佳化等功能。此外，它與 Spark 引擎的整合最佳化也進一步提升了系統的效能。

目前業界也有許多優秀的選型，如 StarRocks 在社群中的最佳化，以及 Trino 等技術的整合。就我們剛才討論的考慮因素，如時效性更新需求、流批儲存統一性以及與市面查詢引擎的相容性，Paimon 在這些方面的表現都相當出色。

伍翀： 我想了解下 Paimon 目前在字節跳動的即時湖倉落地情況。通常情況下，這些資料的新鮮度可以達到什麼水平？另外，我不清楚你們內部使用的是哪種查詢引擎，查詢延遲能達到什麼程度？

閔文俊： 通常來說，Paimon 的資料新鮮度大約在分鐘級別，因為它受到資料提交時效性的限制。最終資料會提交到 HDFS 上，因此從純粹的 Change Log 角度來看，目前尚無法實現秒級的新鮮度。不過，Paimon 也支援像 Log System 這樣的方案。

在我們的內部，Log System 方案在高時效場景中得到了廣泛應用。所以，可以理解為大多數場景下的資料新鮮度為分鐘級別，而在一些需要秒級時效的場景中，我們會透過 Log System 來滿足這一需求。至於查詢引擎，在 TP-CDS 等業務場景中，查詢時可以透過新增本地快取等最佳化手段來提升查詢效能。此外，查詢引擎的最佳化目標之一是儘可能減少 Merge-On-Read，最終能將查詢時效接近內表查詢的速度。

羅宇俠： 如果我來做選型，我會從幾個部分來考慮。首先是儲存格式的選擇，我會將它分為兩部分：分鐘級別延遲的資料和秒級延遲的資料。

對於分鐘級別的資料，主要選擇四大湖格式：Iceberg、Paimon、Hudi 和 Delta。這些都是成熟的資料湖格式。如果對資料的更新能力有較高要求，可能會選擇 Paimon 或 Hudi，因為它們對 upsert（增量更新）的支援較好，更適合直接從業務系統的 binlog 中抽取資料並寫入資料湖。在這方面，我可能會偏愛 Paimon，因為它對 Flink 的支援最為完善。

對於秒級延遲的資料，可能會選擇 Kafka 等流式儲存解決方案，或者使用最近開源的 Fluss，這些工具可以提供秒級新鮮度的資料處理能力。但需要注意的是，這類流式工具通常不擅長做資料分析，最終還是需要將資料流轉到資料湖中，來進行進一步的資料分析處理。

接下來，我會考慮資料分析的方式。對於即時資料處理，我會選擇 Flink，可以滿足秒級延遲的資料處理。對於批處理資料我會選擇 Spark，估計也沒什麼爭議。對於報表和 BI 分析，如果需要非常高效的即時查詢，我會選擇成熟的 OLAP 引擎，如 StarRocks、Trino 等，這些引擎在處理即時查詢和高效資料分析方面表現出色。

最後，我還會考慮底層資料的分層儲存。在 Lakehouse 架構中，雖然儲存成本較低，但我希望能在低成本的儲存下提供更快的查詢速度。比如，將低頻訪問的資料存放到 OSS（物件儲存服務）或 HDFS（分散式儲存系統）上，而對高頻查詢的資料，則可以使用記憶體或 SSD 進行快取，以提供低延遲的訪問。開源社群中已經有成熟的解決方案，如 Alluxio，它能夠自動地進行多層級儲存快取。

王雲霏：我想補充一下在分析引擎選型方面的一些參考。首先，由於我們需要進行即時查詢，查詢引擎的高效能計算能力是必須的，特別是在 OLAP 分析方面，效能是關鍵要素。在此基礎上，引擎需要能夠利用快取來進一步提高效能，同時降低成本。因為資料的遠端訪問，特別是從物件儲存進行訪問時，會帶來一定的成本開銷，而快取能夠有效減少這些開銷。

其次，引擎如果能夠支援預計算或增量計算，將能顯著提升計算效率和資源使用效率。然後如果引擎能夠脫離傳統的 OLAP 範疇，支援資料湖上的資料維護工作，這將對運維和整體效能的提升有很大幫助。具體來說，我們希望這些最佳化能夠是“開箱即用”的，最好是系統能夠根據使用者的使用模式自動進行最佳化，從而選擇出高效的最佳化策略。

伍翀： 現在業界內像 Iceberg、Paimon 或 Delta 等儲存格式，在提升 Lakehouse 效能方面有什麼最新的進展可以分享嗎？

王雲霏： 首先，為了提升 Lakehouse 的效能，資料快取是一個關鍵部分。無論是基於第三方快取庫，還是像 StarRocks 將快取功能整合到自身系統中，大家都在積極進行這方面的工作。因為如果資料僅從物件儲存或 HDFS 中提取，往往無法滿足 OLAP 即時查詢的要求。

另外，關於預計算，像 Iceberg 已經支援物化檢視（MV），它能夠將資料以 MV 形式儲存，並感知 MV 的新鮮度。在查詢時，如果能夠命中 MV，之前的預計算結果將直接使用，從而大大提升計算效率和即時性。StarRocks 也支援類似的功能，除了支援 Iceberg MV 外，還提供了一種內表格式的 MV 儲存方式，可以在查詢時自動改寫 SQL，使得查詢能夠直接命中內表，從而提升查詢效能，效能提升幅度可達到 10 倍以上。

儘管每個引擎可能擅長於不同的場景，它們都在拓展和增強自己的功能，許多引擎正在朝著“一個引擎滿足所有需求”的目標邁進，以最終的目標是讓使用者的使用體驗更加流暢和高效。

閔文俊： 正如剛才提到的，在 Lakehouse 架構中，讀取遠端湖倉表時，主要的瓶頸通常在於掃描效能。因此，湖倉的一項重要特性就是支援 Deletion Vector。在 Paimon 中支援 Deletion Vector 後，帶來了多方面的好處。首先，避免了 Merge-On-Read 的需求，進而減少了對傳統讀取方式的依賴，這樣整體效能得到了顯著提升。

另外，避免 MOR 讀取後，整個讀取的並行度得以提高。因為在檔案合併的過程中，如果資料有交叉，就會導致並行讀取受限，而 Deletion Vector 的最佳化可以解決這個問題，顯著提升讀取並行度。這一最佳化主要體現在湖倉表的層面，進而幫助上層的 OLAP 引擎提升掃描效能。

此外，在 Paimon 中，不同的湖表資料本身有一定的分佈特徵。例如，桶表（bucket table）已經按照使用者指定的欄位進行了分桶。如果這種分桶資料能夠報告給計算引擎，像 Spark 的桶連線（bucket join）或是適配引擎中的分割槽去除（partition remove）最佳化規則，就能夠在識別到特定分割槽條件後，移除一些不必要的 shuffle 操作。在 OLAP 計算中，shuffle 是一個非常重量級的操作，透過減少 shuffle 的需求，可以極大地提升效能。因此，這些最佳化不僅針對湖倉表本身，也涉及 OLAP 引擎的操作，從而能在整體架構中獲得更大的效能提升。

羅宇俠： 我想補充一下關於增量計算的部分。我瞭解到，像 Flink 也在提出 Materialized Table 的概念，基於 Materialized Table 進行增量計算。傳統的流計算通常是常駐程序，而增量計算則透過啟動批處理任務來計算 Delta 資料，相比全量計算，它所需要處理的資料量更小，因此能夠大大節省資源。

羅宇俠： 我認為 Lakehouse 架構非常適合這種雲原生環境，主要因為它的儲存和計算分離的設計。在儲存方面，雲環境提供了可靠、按需擴充套件的儲存服務，尤其是物件儲存。如果你自己維護儲存叢集，可能需要關注資料冗餘和擴容問題，但在雲環境中，儲存幾乎是免運維的，並且提供按量計費服務，使用者無需擔心擴容或縮容的問題。

在計算方面，雲環境也提供了無限擴充套件的計算池，Lakehouse 架構的存算分離特點使得計算節點的增加和減少非常靈活，能夠輕鬆適應計算資源的變化。許多雲廠商還提供了按量計費的計算引擎，使用者無需關心計算資源是否充足，也不需要手動調整資源的分配，確保高峰期和低峰期的計算需求得到滿足。

多雲部署的主要優勢是避免供應商鎖定，從而可以選擇價效比最高的雲服務。然而，核心挑戰在於異構環境的相容性問題。不同雲廠商提供的 API 差異較大，因此即便你在一個雲平臺上部署，也可能需要適配另一個雲廠商的 API。應對這個挑戰的一個有效方法是採用開源技術，因為基本上不同雲廠商都會相容開源 API。

王雲霏： 在雲環境下，彈性是一個非常重要的考慮因素。在彈性環境下，如何確保系統的高效運作是一個挑戰。比如，在快取系統中，彈性擴縮容可能帶來較大的挑戰。特別是在發生快取未命中（cache miss）時，查詢延遲可能會顯著增加，從而影響整體效能。

如果使用者只需要一個引擎，那麼它的部署和運維就會變得非常簡單。目前，像 Spark、Flink 和 StarRocks 等引擎各有擅長的領域。例如，StarRocks 可能需要加強批處理能力和即時計算能力，同時保持其在 OLAP 方面的優勢。同時，所有引擎也在儘量減少使用者需要進行的運維和最佳化操作。理想情況下，引擎應該越自治越好，好的功能開箱即用。

閔文俊： 回顧資料湖誕生時，面臨的許多問題與雲環境密切相關。在雲環境中，資料湖的構建通常依賴物件儲存作為儲存系統。物件儲存的優勢在於其彈性和成本效益，相比傳統的 HDFS，彈性儲存更加適應雲環境，並且成本更低。但物件儲存和傳統檔案系統儲存之間有顯著差異，需要在資料湖的設計中解決這些問題。

傳統 Hive 資料倉庫在進行分割槽級計算時，通常透過列出分割槽目錄來獲取資料，而這種列出操作在物件儲存中非常昂貴。與此不同，Lakehouse 架構透過元資料（如 Manifest 檔案）來記錄每個分割槽的資料檔案，因此能夠直接透過元資料訪問檔案列表，避免了昂貴的目錄列出操作，從而大大減少了掃描和計劃階段的時間消耗。

另一個問題是，物件儲存中的小 IO 代價非常高。當進行過濾下推（filter pushdown）時，計算引擎通常會根據檔案的 footer 中的 min/max 索引來過濾資料。在傳統 Hive 等資料倉庫中，這通常意味著每次都需要開啟每個檔案來獲取 footer，從而增加了 IO 開銷。尤其是在檔案數量非常多時，檔案開啟操作的開銷可能會超過掃描整個檔案的資料處理開銷。為了降低小 IO 代價，資料湖的設計將每個檔案的 Manifest 和統計資訊記錄在 Manifest 檔案中，透過這些元資料進行過濾。

在雲環境中使用物件儲存時，一些雲端儲存服務並未提供非原子性的重新命名 API，這會帶來一定的問題。為了解決這個問題，通常需要藉助分散式鎖來確保資料的完整性。雖然存算分離架構帶來了更高的資源使用效率和更強的彈性（因為儲存和計算可以獨立擴充套件），但它也帶來了遠端訪問掃描的問題，通常的做法是透過本地快取或遠端分散式快取來緩解。

關於多雲部署，跨雲之間的網路頻寬限制是一個顯著的挑戰。如果需要在不同雲平臺之間進行資料傳輸，網路頻寬的限制會影響整體效能和吞吐量，成為業務的瓶頸。業界的一些解決方案透過使用近端快取來減少跨雲頻寬限制帶來的影響，降低網路頻寬對效能的負面影響。

王雲霏： 首先是表格式儲存。在海外，雲物件儲存已經相當成熟，國內則可能更多采用如 hdfs 檔案系統或其他 OSS（物件儲存服務）解決方案。在表格式儲存方面，當前比較活躍的專案包括 Iceberg、Hudi 和 Delta Lake，這些專案各自佔據著不同的市場領域。

每個引擎都有自己的特點和擅長的領域，同時它們也在不斷擴充套件自己的功能。目前國際領先的資料分析廠商，如 Snowflake 和 Databricks，已開源了自己的元資料管理專案。此外，國內也有像 Gravitino 等發展較好的專案。在元資料管理方面，目前可以說是百花齊放，在統一標準的前體下，提供針對不同場景的強大功能，從而為使用者提供更高的價效比。

羅宇俠： 我覺得 Iceberg 就是生態本身，很多專案都在與 Iceberg 相容。比如說，Paimon,Delta Lake 這種湖格式甚至都相容 Iceberg。還有一個專案叫做 Apache XTable，它實際上提供了多種湖格式的互操作性，使用者可以透過 XTable 無縫對接那些支援 Iceberg 的計算引擎。

另外，像 Lakehouse 的管理系統也有很多支援。比如 Amoro 的專案，也是 Apache 社群的一個專案，它基於開放湖格式，幫助你構建 Lakehouse 管理系統，這樣就能方便地管理 Lakehouse 架構。

至於企業的選型分析和建議，我個人的看法是，最好選擇一些比較主流和成熟的元件。理想的做法是，首先基於一些穩定的技術棧構建架構，例如 Iceberg 加 Spark，再慢慢引入其他新的引擎。可以類比為搭積木，先從最成熟的元件開始，逐步引入新技術，最終搭建出完整的 Lakehouse 技術棧。

閔文俊： 從整體 Lakehouse 架構的角度來看，越接近底層的技術，其生態的成熟度和行業標準化程度就越高。例如，HDFS 作為儲存層已經發展多年，基本上已經成為企業級分散式檔案儲存的標準。而在它之上，我們可能有多個數據湖格式，這些格式各自提供了不同的功能，但在元資料層的標準化上，至今還沒有統一的即時標準。

在這個市場中，我認為像 Iceberg 這樣的格式在國外社群得到了廣泛的關注和推進。相比之下，國內社群，尤其是像 Paimon 這樣的專案，往往更加註重務實性，致力於解決實際業務場景中的問題，並且在設計上非常注重可操作性和實用性。

對於 Lakehouse 架構本身的標準化和開放性，市場的需求和選擇會逐漸推選出一種事實上的標準。例如，HDFS、流計算和批處理計算框架如 Spark 和 Flink 等技術，都是經過市場檢驗並逐漸成熟的。對於湖格式來說，雖然當前大家逐漸向 Iceberg 的格式和元資料靠攏，但這並不意味著其他廠商沒有機會。

伍翀： 目前，各個開源專案在每個層級的發展都非常活躍。比如在開放資料格式（open data format）層面，海外的 Iceberg 目前是一個比較標準的格式，而在國內，Paimon 使用得較為廣泛。在元資料層面，現在呈現出百花齊放的局面，多個專案各有特色。對於即時資料層，很多流儲存系統也在積極對接並支援資料湖架構。而在查詢引擎層，也有許多不同的引擎各自擁有優勢，能夠對接各種資料湖。

對於使用者的選型來說，最重要的因素之一是選擇具有活躍社群的專案。社群活躍意味著有豐富的資料可以幫助解決問題，同時也意味著該專案在持續發展和演進。最終，最關鍵的還是要根據自身的需求和問題來選擇最適合自己的技術棧。

羅宇俠：Lakehouse 架構提出之初其實就假定是在物件儲存上進行構建。湖格式天然是為了更好地適應物件儲存的特性而設計的. 以 Iceberg 為例，它的表格式設計實際上也是更加適配物件儲存的特性。比如物件儲存不擅長對目錄進行 list 操作，對於這一點,Iceberg 透過使用 Manifest 檔案來記錄檔案列表，從而避免了目錄 list 操作。

我認為物件儲存可能是未來的一個大趨勢，但與此同時，HDFS 仍然會長期存在，特別是對於一些不願將資料存放在雲端的企業，依然會選擇 HDFS。而且物件儲存雖然便宜, 但其實效能也是一個大問題, HDFS 效能是要比物件儲存更高的, 如果考慮效能的話, 可能還是繞不過 HDFS.

閔文俊： 我個人認為這並不是一個必然的趨勢。首先，從雲環境的角度來看，大多數儲存選型更傾向於使用物件儲存，主要是因為物件儲存在成本方面具有優勢。然而，在企業內部的實際情況可能會有所不同。例如，如果從企業內部的角度來看，使用 HDFS 作為儲存未必比物件儲存更昂貴。

HDFS 經過多年發展，已經積累了大量技術沉澱，並且在成本控制和叢集治理方面都有很好的最佳化。因此，企業內使用 HDFS 儲存時，成本並未必比物件儲存更高。若在成本和效能上沒有明顯的優勢，那麼企業可能不一定會選擇使用物件儲存來替代 HDFS。

另外，關於 Lakehouse 是否會取代其他儲存系統，我認為背後有一個前提：Lakehouse 架構本身依賴於底層儲存系統的支援。正如之前提到的，HDFS 作為底層儲存依然是一個有效的選擇，尤其是在成本和效能都得到最佳化的情況下。因此，即使是 Lakehouse 架構，底層的 HDFS 並不會因為架構的變化而被完全替代。

王雲霏： 我們確實發現，海外市場對於物件儲存取代 HDFS 的趨勢較國內更為明顯，許多國外的廠商已經逐步採用了雲物件儲存的方式。物件儲存的優點在於其標準介面比 HDFS 更加統一。我們發現，在國內，許多廠商的 HDFS 系統經過了特殊的最佳化或定製，這使得計算引擎在對接時遇到了一些困難。而在海外，S3 基本已經成為事實標準，介面非常統一，這使得對接工作變得更加簡單。

然而，在國內，討論 HDFS 是否被替代可能還為時過早。正如剛才提到的，許多企業仍然能夠控制自己的 HDFS 系統，並在此基礎上進行定製最佳化。在安全性和成本方面，企業甚至可以透過這種方式使成本低於雲物件儲存。因此，HDFS 的存在確實有其必要性和優勢。

在 AI 大模型重塑軟體開發的時代，我們如何把握變革？如何突破技術邊界？4 月 10-12 日，QCon 全球軟體開發大會· 北京站 邀你共赴 3 天沉浸式學習之約，跳出「技術繭房」，探索前沿科技的無限可能。

本次大會將匯聚頂尖技術專家、創新實踐者，共同探討多行業 AI 落地應用，分享一手實踐經驗，深度參與 DeepSeek 主題圓桌，洞見未來趨勢。