作者 | QCon 全球軟件開發(fā)大會

策劃 | Kitty

編輯 | 宇琪

大數(shù)據(jù)架構(gòu)經(jīng)過多年的演進(jìn)，傳統(tǒng)數(shù)據(jù)倉庫和數(shù)據(jù)湖的局限性日益凸顯。在此背景下，湖倉一體 Lakehouse 憑借其開放性和成本效益，迅速成為當(dāng)今數(shù)據(jù)平臺的主流架構(gòu)。然而，隨著進(jìn)入 Data + AI 驅(qū)動的新時(shí)代，企業(yè)對實(shí)時(shí)數(shù)據(jù)分析的需求不斷增加，對半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的處理也愈顯重要。那么，應(yīng)該如何高效整合多種數(shù)據(jù)源，實(shí)現(xiàn)實(shí)時(shí)分析與智能決策？

近日 InfoQ《極客有約》X QCon 直播欄目特別邀請了阿里云智能 Flink SQL 負(fù)責(zé)人伍翀擔(dān)任主持人，和阿里云高級開發(fā)工程師羅宇俠、StarRocks 研發(fā)工程師王云霏、字節(jié)跳動研發(fā)工程師閔文俊一起，在 Qcon 全球軟件開發(fā)大會2025 北京站即將召開之際，共同探討最新的 Lakehouse 架構(gòu)演進(jìn)趨勢。

部分精彩觀點(diǎn)如下：

• 未來 Lakehouse 架構(gòu)將從分鐘級逐步向秒級數(shù)據(jù)時(shí)效性邁進(jìn)，以滿足企業(yè)對不同數(shù)據(jù)時(shí)效性的需求。

• 技術(shù)選型需考慮存儲格式、數(shù)據(jù)分析方式和底層數(shù)據(jù)的分層存儲。

• 在計(jì)算引擎方面，可以根據(jù)負(fù)載類型選擇最具性價(jià)比的計(jì)算引擎，許多引擎功能在逐步增強(qiáng)，滿足更多需求，朝著“一個引擎滿足所有需求”的目標(biāo)邁進(jìn)。

• 引擎應(yīng)該越自治越好，功能開箱即用，功能開箱好用。

• 湖格式天然是為了更好地適應(yīng)對象存儲的特性而設(shè)計(jì)的。

• AI 對 Lakehouse 架構(gòu)提出了數(shù)據(jù)時(shí)效性、存儲格式、元數(shù)據(jù)、分析性能、操作語言等各方面的挑戰(zhàn)，但也存在著很多機(jī)會。

在 4 月 10-12 日將于北京舉辦的 Qcon 全球軟件開發(fā)大會上，我們特別設(shè)置了【Lakehouse 架構(gòu)演進(jìn)】專題。該專題將通過分享不同行業(yè)中的實(shí)際應(yīng)用和成功案例，為業(yè)務(wù)發(fā)展提供新思路，并讓參會者對未來的技術(shù)革新做好準(zhǔn)備。

查看大會日程解鎖更多精彩內(nèi)容：https://qcon.infoq.cn/2025/beijing/track

以下內(nèi)容基于直播速記整理，經(jīng) InfoQ 刪減。

完整直播回放可查看：https://www.infoq.cn/video/dZmjyL6SMA5bTeet3oLS

1 Lakehouse 架構(gòu)的演進(jìn)與關(guān)鍵趨勢

伍翀：過去一年 Lakehouse 架構(gòu)在國內(nèi)和國外的發(fā)展都很迅猛，在商業(yè)上也發(fā)生幾大引人注目的事件，比如 Databricks 十億美金收購 Tabular，Snowflake 和 Databricks 都開源了他們的元數(shù)據(jù)產(chǎn)品，很多公司也都引入了或者正在引入 Lakehouse 架構(gòu)，那么Lakehouse 未來的關(guān)鍵發(fā)展趨勢有哪些？

羅宇俠：最重要的趨勢是 Lakehouse 架構(gòu)與 AI 技術(shù)的深度結(jié)合。Lakehouse 本身原生支持多模態(tài)數(shù)據(jù)的統(tǒng)一存儲與管理，并能夠結(jié)合向量嵌入（embedding）和索引技術(shù)，通過特征管理等方法，成為 AI 訓(xùn)練和 RAG 的基礎(chǔ)設(shè)施。

其次，我認(rèn)為另一個重要的趨勢是數(shù)據(jù)時(shí)效性的提升。在 AI 時(shí)代，實(shí)時(shí)數(shù)據(jù)變得尤為重要，因?yàn)閿?shù)據(jù)是否及時(shí)更新，直接影響到 AI 模型的準(zhǔn)確性和有效性。因此，我認(rèn)為未來 Lakehouse 架構(gòu)將從分鐘級逐步向秒級數(shù)據(jù)時(shí)效性邁進(jìn)，以滿足企業(yè)對不同數(shù)據(jù)時(shí)效性的需求。最近，像 Kafka 的商業(yè)化公司 Confluent 提出了 TableFlow，旨在將 Kafka 的數(shù)據(jù)流轉(zhuǎn)移到 Iceberg 以及 Snowflake 公司準(zhǔn)備收購消息隊(duì)列創(chuàng)業(yè)公司 Redpanda 都進(jìn)一步佐證了這一點(diǎn)。

最后，我認(rèn)為未來 Lakehouse 架構(gòu)將會更加標(biāo)準(zhǔn)化。隨著生態(tài)中各個參與者的深入合作，包括數(shù)據(jù)集成服務(wù)商、BI 工具提供商、數(shù)據(jù)庫和計(jì)算存儲服務(wù)商等, 將推動形成一個標(biāo)準(zhǔn)化的 Lakehouse 全套解決方案。

王云霏：Lakehouse 的出現(xiàn)源于數(shù)據(jù)量和企業(yè)開銷的高速增長，特別是在結(jié)構(gòu)化、非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的快速增長推動下。根據(jù) IBM 報(bào)告，企業(yè)在數(shù)據(jù)上的年開銷增長超過 30%，并隨著 AI 的興起，數(shù)據(jù)量和開銷預(yù)計(jì)將繼續(xù)增長。

數(shù)據(jù)的使用方式也在發(fā)生變化。過去，數(shù)據(jù)主要用于商業(yè)分析和 BI 應(yīng)用，但隨著 AI 的發(fā)展，數(shù)據(jù)將更多應(yīng)用于 AI 場景。企業(yè)需要更多的數(shù)據(jù)和實(shí)時(shí)更新的數(shù)據(jù)來挖掘深層洞察，并支持快速決策。新技術(shù)的出現(xiàn)進(jìn)一步改變了數(shù)據(jù)使用方式。對象存儲降低了成本，開放格式使得各種數(shù)據(jù)可以以靈活的方式存儲，進(jìn)而讓不同應(yīng)用選擇最具性價(jià)比的存儲方式。

Lakehouse 架構(gòu)正是基于這些趨勢，它解決了成本問題并滿足了開放存儲的需求。隨著開放標(biāo)準(zhǔn)的確立，預(yù)計(jì)到 2025 年，模塊化的 Lakehouse 架構(gòu)將成為企業(yè)的優(yōu)選，幫助企業(yè)根據(jù)需求選擇最合適的存儲方案、引擎和元數(shù)據(jù)管理方式，從而在滿足不同需求的前提下提升性價(jià)比。

閔文俊：隨著 Databricks 收購 Iceberg 背后的商業(yè)公司，以及 Snowflake 開源其元數(shù)據(jù)層 Polaris，去年還出現(xiàn)了元數(shù)據(jù)目錄項(xiàng)目 Gravitino 的誕生?？梢钥闯?，各大廠商越來越重視元數(shù)據(jù)層的建設(shè)。這背后映射出的是，廠商們對開放標(biāo)準(zhǔn)的重視。開放標(biāo)準(zhǔn)不僅意味著你對云廠商的選擇有更大的靈活性，也意味著你對標(biāo)準(zhǔn)制定的能力有更高的要求。

未來的 Lakehouse 架構(gòu)將更加注重元數(shù)據(jù)的標(biāo)準(zhǔn)化，并且也會關(guān)注跨平臺的兼容性。企業(yè)能從這一趨勢中獲益的主要方面是，通過元數(shù)據(jù)的標(biāo)準(zhǔn)化，可以打破企業(yè)內(nèi)部各個數(shù)據(jù)源之間的數(shù)據(jù)孤島，從而使數(shù)據(jù)能夠發(fā)揮更多的價(jià)值。

另外一個方面是，整體的大背景和企業(yè)面臨的問題，尤其是降本增效的需求。降本增效在 Lakehouse 架構(gòu)中也扮演著重要角色。目前，存算分離已經(jīng)成為一個顯著趨勢。在成本壓力下，用戶對性能的需求并未減弱。因此，Lakehouse 架構(gòu)面臨的一個共同問題是，在降低成本的同時(shí)，如何盡量減少性能損失。為了應(yīng)對這一問題，各家的 Lakehouse 引擎逐漸通過深入挖掘硬件層面的能力，來提升整體性能。例如，向量化引擎和計(jì)算緩存等技術(shù)被廣泛應(yīng)用，以彌補(bǔ)成本與性能之間的平衡。

2 Lakehouse 架構(gòu)的挑戰(zhàn)與技術(shù)創(chuàng)新

伍翀：在 Data + AI 深度融合的當(dāng)下，數(shù)據(jù)規(guī)模與復(fù)雜度劇增，這給 Lakehouse 架構(gòu)在數(shù)據(jù)存儲、實(shí)時(shí)處理及 AI 模型適配等方面帶來了哪些具體且關(guān)鍵的挑戰(zhàn)？其架構(gòu)設(shè)計(jì)又該如何針對性地調(diào)整以應(yīng)對這些沖擊，并實(shí)現(xiàn)創(chuàng)新性的改變？

王云霏：Lakehouse 架構(gòu)的優(yōu)勢主要體現(xiàn)在以下幾個方面：首先，力求實(shí)現(xiàn)“單一數(shù)據(jù)源”，即避免冗余，減少存儲開銷，實(shí)際使用中存儲成本最高可能減少 90%。其次，Lakehouse 希望確保數(shù)據(jù)具有較高的新鮮度，以便快速查詢和使用。第三，簡化 ETL 作業(yè)是 Lakehouse 設(shè)計(jì)的另一目標(biāo)。

然而，實(shí)際應(yīng)用中面臨挑戰(zhàn)著如何確保數(shù)據(jù)分析的性能與傳統(tǒng)數(shù)據(jù)倉庫相當(dāng)這一挑戰(zhàn)。過去一年，我們在性能優(yōu)化方面取得了進(jìn)展，StarRocks 與 Iceberg 或 Paimon 等數(shù)據(jù)湖格式結(jié)合，查詢性能提升至 Databricks 引擎的兩倍。AI 方面，我們面臨的挑戰(zhàn)是如何將 AI agent 與 Lakehouse 中的數(shù)據(jù)結(jié)合，比如如何結(jié)合傳統(tǒng)數(shù)據(jù)平臺的聚合與關(guān)聯(lián)計(jì)算能力，滿足 AI agent 在趨勢性數(shù)據(jù)處理中的需求。

伍翀：AI agent 在某些場景下，特別是在做統(tǒng)計(jì)分析和批處理（batch）任務(wù)時(shí)，展現(xiàn)了很大的潛力。您能否進(jìn)一步展開介紹一下？是否有您那邊觀察到的具體場景或應(yīng)用案例，能夠展示 AI agent 與特定業(yè)務(wù)需求或技術(shù)結(jié)合的情況？

王云霏：AI agent 已有一些原型系統(tǒng)，能夠查詢 Lakehouse 中的數(shù)據(jù)，但還不成熟。AI agent 需要感知理解數(shù)據(jù)，這可能導(dǎo)致元數(shù)據(jù)請求量顯著增加。隨著并發(fā)增加，如何高效解析數(shù)據(jù)成為關(guān)鍵問題，還有就是 AI agent 對實(shí)時(shí)性的要求較高，需要快速交互并采取行動。

AI agent 對數(shù)據(jù)的實(shí)時(shí)性和計(jì)算性能要求較高，當(dāng)前的應(yīng)對方向是增量計(jì)算、預(yù)計(jì)算和緩存系統(tǒng)優(yōu)化，以支持高性能、高并發(fā)、低延遲的需求。與傳統(tǒng)數(shù)據(jù)分析師不同，AI agent 支持更高的并發(fā)和更短的實(shí)時(shí)響應(yīng)，這使得如何處理高并發(fā)、低延遲需求成為系統(tǒng)設(shè)計(jì)中的重要課題。

伍翀：文俊老師和宇俠老師對 Data+ AI 這塊的挑戰(zhàn)有沒有什么想法？

閔文?。?/strong>AI 場景中一個顯著的特點(diǎn)是非結(jié)構(gòu)化數(shù)據(jù)的急劇增加，所以我們需要支持跨數(shù)據(jù)類型的管理。常見的設(shè)計(jì)方法是通過統(tǒng)一的元數(shù)據(jù)目錄，將多模態(tài)數(shù)據(jù)納入 Lakehouse 的元數(shù)據(jù)管理體系中。具體來說，通常我們通過在 Lakehouse 中建立表模型，將多模態(tài)數(shù)據(jù)的一部分進(jìn)行結(jié)構(gòu)化存儲，同時(shí)對于非結(jié)構(gòu)化數(shù)據(jù)，我們?nèi)匀粚⑵浯鎯υ趯ο蟠鎯χ?，并通過路徑指向這些數(shù)據(jù)，從而將相關(guān)的元數(shù)據(jù)進(jìn)行管理。

隨著 AI 與 Lakehouse 架構(gòu)的緊密結(jié)合，Python 作為 AI 生態(tài)中最通用的編程語言，其接口在整個 AI 生態(tài)中起到了至關(guān)重要的作用。因此另一個挑戰(zhàn)是，Lakehouse 架構(gòu)需要提供一套高性能的 Python 讀寫接口，以供 AI 框架使用。在不損失原始讀寫性能的情況下，這對 Lakehouse 架構(gòu)提出了更高的要求。當(dāng)前業(yè)界常見的做法是，使用原生語言（如 C++ 或 Rust）實(shí)現(xiàn)底層功能，并在其上封裝 Python 接口，以調(diào)用這些底層庫。這一做法背后需要一個穩(wěn)定的內(nèi)核支持，也就是我們之前提到的標(biāo)準(zhǔn)化。

此外，隨著多模態(tài)數(shù)據(jù)的不斷增長，相比于傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)，非結(jié)構(gòu)化數(shù)據(jù)在 Lakehouse 中存儲時(shí)通常使用 Parquet 格式。然而，Parquet 格式更多適用于大規(guī)模掃描場景，對于 AI 場景中的高效檢查和更新操作并不理想。在 AI 場景下，可能需要一些新的文件格式來支持更高效的數(shù)據(jù)存儲和處理。

羅宇俠：首先，對于 AI 而言，非結(jié)構(gòu)化數(shù)據(jù)的組織和檢索至關(guān)重要。Lakehouse 架構(gòu)需要更加高效地組織并快速檢索非結(jié)構(gòu)化數(shù)據(jù)，例如，Paimon 正在探索的 Object Table 功能，通過對文本或圖像根據(jù)文件信息建立表，并在其上建立索引，使得可以快速地檢索到數(shù)據(jù)，如快速定位到某個特定日期生成的圖像文件，從而高效支持 AI 訓(xùn)練。

其次，AI 更加傾向于使用嵌入或向量化的格式，而目前的 Lakehouse 架構(gòu)更多側(cè)重于分析場景，AI 大模型的需求與當(dāng)前架構(gòu)的計(jì)算范式并不完全對齊, 傳統(tǒng)的數(shù)據(jù)分析架構(gòu)很難完全匹配 AI 場景下的需求。

目前 Lakehouse 架構(gòu)通常處理的是分鐘級的數(shù)據(jù)新鮮度，實(shí)時(shí)數(shù)據(jù)仍然是一個缺失。我認(rèn)為解決方案之一可能是引入額外的實(shí)時(shí)存儲組件，例如 Kafka。這需要有效地處理 Kafka 中的實(shí)時(shí)數(shù)據(jù)流，并將其傳輸?shù)?Lakehouse 中。Confluent 提供的 TableFlow 可以將數(shù)據(jù)從 Kafka 流轉(zhuǎn)到 Iceberg。我們團(tuán)隊(duì)提出的 Fluss 湖流一體也正是為了彌補(bǔ)這個缺失，自動將實(shí)時(shí)數(shù)據(jù)流轉(zhuǎn)到數(shù)據(jù)湖中, 無縫融合進(jìn) LakeHouse 架構(gòu)中.

伍翀：總結(jié)一下，在 AI 場景中，AI 對數(shù)據(jù)系統(tǒng)提出了更高的性能和實(shí)時(shí)性要求。數(shù)據(jù)的實(shí)時(shí)性對于 AI 應(yīng)用尤為重要，因?yàn)橐粋€好的 AI agent 需要高質(zhì)量、實(shí)時(shí)的數(shù)據(jù)來提升其決策準(zhǔn)確性和價(jià)值。此外，數(shù)據(jù)查詢性能也需要進(jìn)一步優(yōu)化，以滿足 AI 應(yīng)用的需求。同時(shí)，Python 語言在數(shù)據(jù)湖框架中的應(yīng)用也在不斷演進(jìn)。各大數(shù)據(jù)湖框架最近推出了自己的 Python 庫，并且一些新型的數(shù)據(jù)湖格式，如針對 AI 場景構(gòu)建的 LanceDB，也在不斷發(fā)展。

目前在 AI 場景下，哪些開源的開放格式處于領(lǐng)先地位，或者在這一領(lǐng)域做得比較積極？比如 Paimon 提出的 Python 庫和 Object Table，是否有其他相關(guān)的看法？

閔文俊：我認(rèn)為 Paimon 的跟進(jìn)相當(dāng)及時(shí)。此外，Iceberg 在社區(qū)中的參與也非?；钴S，它的 Iceberg C++、Rust 和 Python 接口都很豐富。

王云霏：是的，特別是在國外，Iceberg 被廣泛采用，并且在各個方面的跟進(jìn)也非常及時(shí)。

伍翀：回到實(shí)時(shí)性的問題，大家都提到，在 AI agent 做決策時(shí)，數(shù)據(jù)的實(shí)時(shí)性顯得尤為關(guān)鍵。與傳統(tǒng)的 BI 決策場景不同，AI 應(yīng)用對數(shù)據(jù)的實(shí)時(shí)性要求更加嚴(yán)格，因?yàn)樗鼈冃枰磿r(shí)反饋以支持動態(tài)決策。

企業(yè)對數(shù)據(jù)分析實(shí)時(shí)化需求日益迫切，怎樣在現(xiàn)有技術(shù)?；A(chǔ)上，通過精準(zhǔn)選型、合理配置與高效集成，實(shí)現(xiàn) Lakehouse 架構(gòu)與企業(yè)業(yè)務(wù)流程的無縫融合，從而保障實(shí)時(shí)數(shù)據(jù)分析的低延遲、高并發(fā)與高可靠性？

閔文?。?/strong>從企業(yè)的角度來看，若要引入一套新的架構(gòu)，背后一定有一個需要解決的關(guān)鍵痛點(diǎn)。無論是當(dāng)前架構(gòu)中的時(shí)效性問題，例如基于 Hive 的 T+1 時(shí)效無法滿足需求，還是存儲成本問題，例如 Hive 場景下每天全量增量處理帶來的高存儲成本，這些問題都可能推動企業(yè)引入新的架構(gòu)。此外，企業(yè)可能還面臨如何高效更新湖倉層、實(shí)現(xiàn)流批統(tǒng)一存儲等挑戰(zhàn)。

我認(rèn)為，在做出新的架構(gòu)選型時(shí)，企業(yè)首先應(yīng)從當(dāng)前面臨的實(shí)際業(yè)務(wù)痛點(diǎn)出發(fā)，明確解決這些痛點(diǎn)的需求，之后另一個考量點(diǎn)是 Lakehouse 架構(gòu)的生態(tài)成熟度。具體來說，生態(tài)成熟度包括以下幾個方面：從數(shù)據(jù)攝入的角度來看，是否支持豐富的數(shù)據(jù)導(dǎo)入插件，尤其是如 CDC（Change Data Capture）等技術(shù)？從數(shù)據(jù)開發(fā)的角度，是否支持主流的計(jì)算引擎？在進(jìn)行 OLAP 分析時(shí)，下游工具如支持程度如何？這些因素都會影響企業(yè)在引入實(shí)時(shí) Lakehouse 架構(gòu)時(shí)的選型決策。

在確定選型之后，還需考慮如何讓新的 Lakehouse 架構(gòu)與現(xiàn)有的企業(yè)生態(tài)兼容。正如我們所稱的數(shù)據(jù)湖倉，它不僅僅是數(shù)據(jù)湖，還需要兼容歷史數(shù)據(jù)倉庫的架構(gòu)。引入實(shí)時(shí) Lakehouse 架構(gòu)時(shí)，需要考慮如何在保持現(xiàn)有生態(tài)兼容的情況下，逐步進(jìn)行架構(gòu)的迭代與升級。

伍翀：現(xiàn)在業(yè)界有沒有什么比較成熟、典型的搭建實(shí)時(shí)數(shù)倉的架構(gòu)？并且這個架構(gòu)當(dāng)前還會遇到什么樣的問題嗎？

閔文?。?/strong>我們目前的實(shí)踐基于 Paimon 架構(gòu)，作為數(shù)據(jù)湖倉的底層架構(gòu)，Paimon 提供了 HDFS 作為數(shù)據(jù)存儲基礎(chǔ)。Paimon 的一個顯著特點(diǎn)是其時(shí)效性有保障，并且基于 LSM 結(jié)構(gòu)，在主鍵表的高效更新場景中，表現(xiàn)出非常好的性能。同時(shí)，Paimon 針對流式場景提供了諸如 Changelog Producer 的能力，使得在企業(yè)開發(fā)數(shù)據(jù)管道時(shí)，能夠以增量方式處理數(shù)據(jù)流，這對于流式開發(fā)場景非常友好。對于離線場景，Paimon 同樣提供了良好的性能，包括列式存儲、數(shù)據(jù)聚類、Z-Order 排序、基于數(shù)據(jù)過濾的下推優(yōu)化等功能。此外，它與 Spark 引擎的集成優(yōu)化也進(jìn)一步提升了系統(tǒng)的性能。

目前業(yè)界也有許多優(yōu)秀的選型，如 StarRocks 在社區(qū)中的優(yōu)化，以及 Trino 等技術(shù)的集成。就我們剛才討論的考慮因素，如時(shí)效性更新需求、流批存儲統(tǒng)一性以及與市面查詢引擎的兼容性，Paimon 在這些方面的表現(xiàn)都相當(dāng)出色。

伍翀：我想了解下 Paimon 目前在字節(jié)跳動的實(shí)時(shí)湖倉落地情況。通常情況下，這些數(shù)據(jù)的新鮮度可以達(dá)到什么水平？另外，我不清楚你們內(nèi)部使用的是哪種查詢引擎，查詢延遲能達(dá)到什么程度？

閔文俊：通常來說，Paimon 的數(shù)據(jù)新鮮度大約在分鐘級別，因?yàn)樗艿綌?shù)據(jù)提交時(shí)效性的限制。最終數(shù)據(jù)會提交到 HDFS 上，因此從純粹的 Change Log 角度來看，目前尚無法實(shí)現(xiàn)秒級的新鮮度。不過，Paimon 也支持像 Log System 這樣的方案。

在我們的內(nèi)部，Log System 方案在高時(shí)效場景中得到了廣泛應(yīng)用。所以，可以理解為大多數(shù)場景下的數(shù)據(jù)新鮮度為分鐘級別，而在一些需要秒級時(shí)效的場景中，我們會通過 Log System 來滿足這一需求。至于查詢引擎，在 TP-CDS 等業(yè)務(wù)場景中，查詢時(shí)可以通過添加本地緩存等優(yōu)化手段來提升查詢性能。此外，查詢引擎的優(yōu)化目標(biāo)之一是盡可能減少 Merge-On-Read，最終能將查詢時(shí)效接近內(nèi)表查詢的速度。

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

對于分鐘級別的數(shù)據(jù)，主要選擇四大湖格式：Iceberg、Paimon、Hudi 和 Delta。這些都是成熟的數(shù)據(jù)湖格式。如果對數(shù)據(jù)的更新能力有較高要求，可能會選擇 Paimon 或 Hudi，因?yàn)樗鼈儗?upsert（增量更新）的支持較好，更適合直接從業(yè)務(wù)系統(tǒng)的 binlog 中抽取數(shù)據(jù)并寫入數(shù)據(jù)湖。在這方面，我可能會偏愛 Paimon，因?yàn)樗鼘?Flink 的支持最為完善。

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

接下來，我會考慮數(shù)據(jù)分析的方式。對于實(shí)時(shí)數(shù)據(jù)處理，我會選擇 Flink，可以滿足秒級延遲的數(shù)據(jù)處理。對于批處理數(shù)據(jù)我會選擇 Spark，估計(jì)也沒什么爭議。對于報(bào)表和 BI 分析，如果需要非常高效的實(shí)時(shí)查詢，我會選擇成熟的 OLAP 引擎，如 StarRocks、Trino 等，這些引擎在處理實(shí)時(shí)查詢和高效數(shù)據(jù)分析方面表現(xiàn)出色。

最后，我還會考慮底層數(shù)據(jù)的分層存儲。在 Lakehouse 架構(gòu)中，雖然存儲成本較低，但我希望能在低成本的存儲下提供更快的查詢速度。比如，將低頻訪問的數(shù)據(jù)存放到 OSS（對象存儲服務(wù)）或 HDFS（分布式存儲系統(tǒng)）上，而對高頻查詢的數(shù)據(jù)，則可以使用內(nèi)存或 SSD 進(jìn)行緩存，以提供低延遲的訪問。開源社區(qū)中已經(jīng)有成熟的解決方案，如 Alluxio，它能夠自動地進(jìn)行多層級存儲緩存。

王云霏：我想補(bǔ)充一下在分析引擎選型方面的一些參考。首先，由于我們需要進(jìn)行實(shí)時(shí)查詢，查詢引擎的高性能計(jì)算能力是必須的，特別是在 OLAP 分析方面，性能是關(guān)鍵要素。在此基礎(chǔ)上，引擎需要能夠利用緩存來進(jìn)一步提高性能，同時(shí)降低成本。因?yàn)閿?shù)據(jù)的遠(yuǎn)程訪問，特別是從對象存儲進(jìn)行訪問時(shí)，會帶來一定的成本開銷，而緩存能夠有效減少這些開銷。

其次，引擎如果能夠支持預(yù)計(jì)算或增量計(jì)算，將能顯著提升計(jì)算效率和資源使用效率。然后如果引擎能夠脫離傳統(tǒng)的 OLAP 范疇，支持?jǐn)?shù)據(jù)湖上的數(shù)據(jù)維護(hù)工作，這將對運(yùn)維和整體性能的提升有很大幫助。具體來說，我們希望這些優(yōu)化能夠是“開箱即用”的，最好是系統(tǒng)能夠根據(jù)用戶的使用模式自動進(jìn)行優(yōu)化，從而選擇出高效的優(yōu)化策略。

伍翀：現(xiàn)在業(yè)界內(nèi)像 Iceberg、Paimon 或 Delta 等存儲格式，在提升 Lakehouse 性能方面有什么最新的進(jìn)展可以分享嗎？

王云霏：首先，為了提升 Lakehouse 的性能，數(shù)據(jù)緩存是一個關(guān)鍵部分。無論是基于第三方緩存庫，還是像 StarRocks 將緩存功能集成到自身系統(tǒng)中，大家都在積極進(jìn)行這方面的工作。因?yàn)槿绻麛?shù)據(jù)僅從對象存儲或 HDFS 中提取，往往無法滿足 OLAP 實(shí)時(shí)查詢的要求。

另外，關(guān)于預(yù)計(jì)算，像 Iceberg 已經(jīng)支持物化視圖（MV），它能夠?qū)?shù)據(jù)以 MV 形式存儲，并感知 MV 的新鮮度。在查詢時(shí)，如果能夠命中 MV，之前的預(yù)計(jì)算結(jié)果將直接使用，從而大大提升計(jì)算效率和實(shí)時(shí)性。StarRocks 也支持類似的功能，除了支持 Iceberg MV 外，還提供了一種內(nèi)表格式的 MV 存儲方式，可以在查詢時(shí)自動改寫 SQL，使得查詢能夠直接命中內(nèi)表，從而提升查詢性能，性能提升幅度可達(dá)到 10 倍以上。

盡管每個引擎可能擅長于不同的場景，它們都在拓展和增強(qiáng)自己的功能，許多引擎正在朝著“一個引擎滿足所有需求”的目標(biāo)邁進(jìn)，以最終的目標(biāo)是讓用戶的使用體驗(yàn)更加流暢和高效。

閔文俊：正如剛才提到的，在 Lakehouse 架構(gòu)中，讀取遠(yuǎn)程湖倉表時(shí)，主要的瓶頸通常在于掃描性能。因此，湖倉的一項(xiàng)重要特性就是支持 Deletion Vector。在 Paimon 中支持 Deletion Vector 后，帶來了多方面的好處。首先，避免了 Merge-On-Read 的需求，進(jìn)而減少了對傳統(tǒng)讀取方式的依賴，這樣整體性能得到了顯著提升。

另外，避免 MOR 讀取后，整個讀取的并行度得以提高。因?yàn)樵谖募喜⒌倪^程中，如果數(shù)據(jù)有交叉，就會導(dǎo)致并行讀取受限，而 Deletion Vector 的優(yōu)化可以解決這個問題，顯著提升讀取并行度。這一優(yōu)化主要體現(xiàn)在湖倉表的層面，進(jìn)而幫助上層的 OLAP 引擎提升掃描性能。

此外，在 Paimon 中，不同的湖表數(shù)據(jù)本身有一定的分布特征。例如，桶表（bucket table）已經(jīng)按照用戶指定的字段進(jìn)行了分桶。如果這種分桶數(shù)據(jù)能夠報(bào)告給計(jì)算引擎，像 Spark 的桶連接（bucket join）或是適配引擎中的分區(qū)去除（partition remove）優(yōu)化規(guī)則，就能夠在識別到特定分區(qū)條件后，移除一些不必要的 shuffle 操作。在 OLAP 計(jì)算中，shuffle 是一個非常重量級的操作，通過減少 shuffle 的需求，可以極大地提升性能。因此，這些優(yōu)化不僅針對湖倉表本身，也涉及 OLAP 引擎的操作，從而能在整體架構(gòu)中獲得更大的性能提升。

羅宇俠：我想補(bǔ)充一下關(guān)于增量計(jì)算的部分。我了解到，像 Flink 也在提出 Materialized Table 的概念，基于 Materialized Table 進(jìn)行增量計(jì)算。傳統(tǒng)的流計(jì)算通常是常駐進(jìn)程，而增量計(jì)算則通過啟動批處理任務(wù)來計(jì)算 Delta 數(shù)據(jù)，相比全量計(jì)算，它所需要處理的數(shù)據(jù)量更小，因此能夠大大節(jié)省資源。

3 Lakehouse 在云原生、多云與開源生態(tài)中的發(fā)展

伍翀：Lakehouse 架構(gòu)如何與云原生環(huán)境深度融合，借助云的彈性、可擴(kuò)展性與托管服務(wù)優(yōu)勢，實(shí)現(xiàn)架構(gòu)的輕量化部署與高效運(yùn)維？在多云、混合云場景下，又面臨哪些新的挑戰(zhàn)與機(jī)遇，該如何應(yīng)對？

羅宇俠：我認(rèn)為 Lakehouse 架構(gòu)非常適合這種云原生環(huán)境，主要因?yàn)樗拇鎯陀?jì)算分離的設(shè)計(jì)。在存儲方面，云環(huán)境提供了可靠、按需擴(kuò)展的存儲服務(wù)，尤其是對象存儲。如果你自己維護(hù)存儲集群，可能需要關(guān)注數(shù)據(jù)冗余和擴(kuò)容問題，但在云環(huán)境中，存儲幾乎是免運(yùn)維的，并且提供按量計(jì)費(fèi)服務(wù)，用戶無需擔(dān)心擴(kuò)容或縮容的問題。

在計(jì)算方面，云環(huán)境也提供了無限擴(kuò)展的計(jì)算池，Lakehouse 架構(gòu)的存算分離特點(diǎn)使得計(jì)算節(jié)點(diǎn)的增加和減少非常靈活，能夠輕松適應(yīng)計(jì)算資源的變化。許多云廠商還提供了按量計(jì)費(fèi)的計(jì)算引擎，用戶無需關(guān)心計(jì)算資源是否充足，也不需要手動調(diào)整資源的分配，確保高峰期和低峰期的計(jì)算需求得到滿足。

多云部署的主要優(yōu)勢是避免供應(yīng)商鎖定，從而可以選擇性價(jià)比最高的云服務(wù)。然而，核心挑戰(zhàn)在于異構(gòu)環(huán)境的兼容性問題。不同云廠商提供的 API 差異較大，因此即便你在一個云平臺上部署，也可能需要適配另一個云廠商的 API。應(yīng)對這個挑戰(zhàn)的一個有效方法是采用開源技術(shù)，因?yàn)榛旧喜煌茝S商都會兼容開源 API。

王云霏：在云環(huán)境下，彈性是一個非常重要的考慮因素。在彈性環(huán)境下，如何確保系統(tǒng)的高效運(yùn)作是一個挑戰(zhàn)。比如，在緩存系統(tǒng)中，彈性擴(kuò)縮容可能帶來較大的挑戰(zhàn)。特別是在發(fā)生緩存未命中（cache miss）時(shí)，查詢延遲可能會顯著增加，從而影響整體性能。

如果用戶只需要一個引擎，那么它的部署和運(yùn)維就會變得非常簡單。目前，像 Spark、Flink 和 StarRocks 等引擎各有擅長的領(lǐng)域。例如，StarRocks 可能需要加強(qiáng)批處理能力和實(shí)時(shí)計(jì)算能力，同時(shí)保持其在 OLAP 方面的優(yōu)勢。同時(shí)，所有引擎也在盡量減少用戶需要進(jìn)行的運(yùn)維和優(yōu)化操作。理想情況下，引擎應(yīng)該越自治越好，好的功能開箱即用。

閔文?。?/strong>回顧數(shù)據(jù)湖誕生時(shí)，面臨的許多問題與云環(huán)境密切相關(guān)。在云環(huán)境中，數(shù)據(jù)湖的構(gòu)建通常依賴對象存儲作為存儲系統(tǒng)。對象存儲的優(yōu)勢在于其彈性和成本效益，相比傳統(tǒng)的 HDFS，彈性存儲更加適應(yīng)云環(huán)境，并且成本更低。但對象存儲和傳統(tǒng)文件系統(tǒng)存儲之間有顯著差異，需要在數(shù)據(jù)湖的設(shè)計(jì)中解決這些問題。

傳統(tǒng) Hive 數(shù)據(jù)倉庫在進(jìn)行分區(qū)級計(jì)算時(shí)，通常通過列出分區(qū)目錄來獲取數(shù)據(jù)，而這種列出操作在對象存儲中非常昂貴。與此不同，Lakehouse 架構(gòu)通過元數(shù)據(jù)（如 Manifest 文件）來記錄每個分區(qū)的數(shù)據(jù)文件，因此能夠直接通過元數(shù)據(jù)訪問文件列表，避免了昂貴的目錄列出操作，從而大大減少了掃描和計(jì)劃階段的時(shí)間消耗。

另一個問題是，對象存儲中的小 IO 代價(jià)非常高。當(dāng)進(jìn)行過濾下推（filter pushdown）時(shí)，計(jì)算引擎通常會根據(jù)文件的 footer 中的 min/max 索引來過濾數(shù)據(jù)。在傳統(tǒng) Hive 等數(shù)據(jù)倉庫中，這通常意味著每次都需要打開每個文件來獲取 footer，從而增加了 IO 開銷。尤其是在文件數(shù)量非常多時(shí)，文件打開操作的開銷可能會超過掃描整個文件的數(shù)據(jù)處理開銷。為了降低小 IO 代價(jià)，數(shù)據(jù)湖的設(shè)計(jì)將每個文件的 Manifest 和統(tǒng)計(jì)信息記錄在 Manifest 文件中，通過這些元數(shù)據(jù)進(jìn)行過濾。

在云環(huán)境中使用對象存儲時(shí)，一些云存儲服務(wù)并未提供非原子性的重命名 API，這會帶來一定的問題。為了解決這個問題，通常需要借助分布式鎖來確保數(shù)據(jù)的完整性。雖然存算分離架構(gòu)帶來了更高的資源使用效率和更強(qiáng)的彈性（因?yàn)榇鎯陀?jì)算可以獨(dú)立擴(kuò)展），但它也帶來了遠(yuǎn)程訪問掃描的問題，通常的做法是通過本地緩存或遠(yuǎn)程分布式緩存來緩解。

關(guān)于多云部署，跨云之間的網(wǎng)絡(luò)帶寬限制是一個顯著的挑戰(zhàn)。如果需要在不同云平臺之間進(jìn)行數(shù)據(jù)傳輸，網(wǎng)絡(luò)帶寬的限制會影響整體性能和吞吐量，成為業(yè)務(wù)的瓶頸。業(yè)界的一些解決方案通過使用近端緩存來減少跨云帶寬限制帶來的影響，降低網(wǎng)絡(luò)帶寬對性能的負(fù)面影響。

伍翀：Lakehouse 架構(gòu)憑借其靈活性、高性能和開放性，正成為企業(yè)數(shù)據(jù)管理的未來方向。當(dāng)前，Lakehouse 架構(gòu)在開源生態(tài)建設(shè)方面進(jìn)展如何？有哪些主流的開源項(xiàng)目與工具推動其發(fā)展？如何推動 Lakehouse 架構(gòu)的開放性和兼容性？

王云霏：首先是表格式存儲。在海外，云對象存儲已經(jīng)相當(dāng)成熟，國內(nèi)則可能更多采用如 hdfs 文件系統(tǒng)或其他 OSS（對象存儲服務(wù)）解決方案。在表格式存儲方面，當(dāng)前比較活躍的項(xiàng)目包括 Iceberg、Hudi 和 Delta Lake，這些項(xiàng)目各自占據(jù)著不同的市場領(lǐng)域。

每個引擎都有自己的特點(diǎn)和擅長的領(lǐng)域，同時(shí)它們也在不斷擴(kuò)展自己的功能。目前國際領(lǐng)先的數(shù)據(jù)分析廠商，如 Snowflake 和 Databricks，已開源了自己的元數(shù)據(jù)管理項(xiàng)目。此外，國內(nèi)也有像 Gravitino 等發(fā)展較好的項(xiàng)目。在元數(shù)據(jù)管理方面，目前可以說是百花齊放，在統(tǒng)一標(biāo)準(zhǔn)的前體下，提供針對不同場景的強(qiáng)大功能，從而為用戶提供更高的性價(jià)比。

羅宇俠：我覺得 Iceberg 就是生態(tài)本身，很多項(xiàng)目都在與 Iceberg 兼容。比如說，Paimon,Delta Lake 這種湖格式甚至都兼容 Iceberg。還有一個項(xiàng)目叫做 Apache XTable，它實(shí)際上提供了多種湖格式的互操作性，用戶可以通過 XTable 無縫對接那些支持 Iceberg 的計(jì)算引擎。

另外，像 Lakehouse 的管理系統(tǒng)也有很多支持。比如 Amoro 的項(xiàng)目，也是 Apache 社區(qū)的一個項(xiàng)目，它基于開放湖格式，幫助你構(gòu)建 Lakehouse 管理系統(tǒng)，這樣就能方便地管理 Lakehouse 架構(gòu)。

至于企業(yè)的選型分析和建議，我個人的看法是，最好選擇一些比較主流和成熟的組件。理想的做法是，首先基于一些穩(wěn)定的技術(shù)棧構(gòu)建架構(gòu)，例如 Iceberg 加 Spark，再慢慢引入其他新的引擎?？梢灶惐葹榇罘e木，先從最成熟的組件開始，逐步引入新技術(shù)，最終搭建出完整的 Lakehouse 技術(shù)棧。

閔文?。?/strong>從整體 Lakehouse 架構(gòu)的角度來看，越接近底層的技術(shù)，其生態(tài)的成熟度和行業(yè)標(biāo)準(zhǔn)化程度就越高。例如，HDFS 作為存儲層已經(jīng)發(fā)展多年，基本上已經(jīng)成為企業(yè)級分布式文件存儲的標(biāo)準(zhǔn)。而在它之上，我們可能有多個數(shù)據(jù)湖格式，這些格式各自提供了不同的功能，但在元數(shù)據(jù)層的標(biāo)準(zhǔn)化上，至今還沒有統(tǒng)一的實(shí)時(shí)標(biāo)準(zhǔn)。

在這個市場中，我認(rèn)為像 Iceberg 這樣的格式在國外社區(qū)得到了廣泛的關(guān)注和推進(jìn)。相比之下，國內(nèi)社區(qū)，尤其是像 Paimon 這樣的項(xiàng)目，往往更加注重務(wù)實(shí)性，致力于解決實(shí)際業(yè)務(wù)場景中的問題，并且在設(shè)計(jì)上非常注重可操作性和實(shí)用性。

對于 Lakehouse 架構(gòu)本身的標(biāo)準(zhǔn)化和開放性，市場的需求和選擇會逐漸推選出一種事實(shí)上的標(biāo)準(zhǔn)。例如，HDFS、流計(jì)算和批處理計(jì)算框架如 Spark 和 Flink 等技術(shù)，都是經(jīng)過市場檢驗(yàn)并逐漸成熟的。對于湖格式來說，雖然當(dāng)前大家逐漸向 Iceberg 的格式和元數(shù)據(jù)靠攏，但這并不意味著其他廠商沒有機(jī)會。

伍翀：目前，各個開源項(xiàng)目在每個層級的發(fā)展都非常活躍。比如在開放數(shù)據(jù)格式（open data format）層面，海外的 Iceberg 目前是一個比較標(biāo)準(zhǔn)的格式，而在國內(nèi)，Paimon 使用得較為廣泛。在元數(shù)據(jù)層面，現(xiàn)在呈現(xiàn)出百花齊放的局面，多個項(xiàng)目各有特色。對于實(shí)時(shí)數(shù)據(jù)層，很多流存儲系統(tǒng)也在積極對接并支持?jǐn)?shù)據(jù)湖架構(gòu)。而在查詢引擎層，也有許多不同的引擎各自擁有優(yōu)勢，能夠?qū)痈鞣N數(shù)據(jù)湖。

對于用戶的選型來說，最重要的因素之一是選擇具有活躍社區(qū)的項(xiàng)目。社區(qū)活躍意味著有豐富的資料可以幫助解決問題，同時(shí)也意味著該項(xiàng)目在持續(xù)發(fā)展和演進(jìn)。最終，最關(guān)鍵的還是要根據(jù)自身的需求和問題來選擇最適合自己的技術(shù)棧。

觀眾：Lakehouse 去 Hadoop 會是一個趨勢嗎？

羅宇俠：Lakehouse 架構(gòu)提出之初其實(shí)就假定是在對象存儲上進(jìn)行構(gòu)建。湖格式天然是為了更好地適應(yīng)對象存儲的特性而設(shè)計(jì)的. 以 Iceberg 為例，它的表格式設(shè)計(jì)實(shí)際上也是更加適配對象存儲的特性。比如對象存儲不擅長對目錄進(jìn)行 list 操作，對于這一點(diǎn),Iceberg 通過使用 Manifest 文件來記錄文件列表，從而避免了目錄 list 操作。

我認(rèn)為對象存儲可能是未來的一個大趨勢，但與此同時(shí)，HDFS 仍然會長期存在，特別是對于一些不愿將數(shù)據(jù)存放在云端的企業(yè)，依然會選擇 HDFS。而且對象存儲雖然便宜, 但其實(shí)性能也是一個大問題, HDFS 性能是要比對象存儲更高的, 如果考慮性能的話, 可能還是繞不過 HDFS.

閔文?。?/strong>我個人認(rèn)為這并不是一個必然的趨勢。首先，從云環(huán)境的角度來看，大多數(shù)存儲選型更傾向于使用對象存儲，主要是因?yàn)閷ο蟠鎯υ诔杀痉矫婢哂袃?yōu)勢。然而，在企業(yè)內(nèi)部的實(shí)際情況可能會有所不同。例如，如果從企業(yè)內(nèi)部的角度來看，使用 HDFS 作為存儲未必比對象存儲更昂貴。

HDFS 經(jīng)過多年發(fā)展，已經(jīng)積累了大量技術(shù)沉淀，并且在成本控制和集群治理方面都有很好的優(yōu)化。因此，企業(yè)內(nèi)使用 HDFS 存儲時(shí)，成本并未必比對象存儲更高。若在成本和性能上沒有明顯的優(yōu)勢，那么企業(yè)可能不一定會選擇使用對象存儲來替代 HDFS。

另外，關(guān)于 Lakehouse 是否會取代其他存儲系統(tǒng)，我認(rèn)為背后有一個前提：Lakehouse 架構(gòu)本身依賴于底層存儲系統(tǒng)的支持。正如之前提到的，HDFS 作為底層存儲依然是一個有效的選擇，尤其是在成本和性能都得到優(yōu)化的情況下。因此，即使是 Lakehouse 架構(gòu)，底層的 HDFS 并不會因?yàn)榧軜?gòu)的變化而被完全替代。

王云霏：我們確實(shí)發(fā)現(xiàn)，海外市場對于對象存儲取代 HDFS 的趨勢較國內(nèi)更為明顯，許多國外的廠商已經(jīng)逐步采用了云對象存儲的方式。對象存儲的優(yōu)點(diǎn)在于其標(biāo)準(zhǔn)接口比 HDFS 更加統(tǒng)一。我們發(fā)現(xiàn)，在國內(nèi)，許多廠商的 HDFS 系統(tǒng)經(jīng)過了特殊的優(yōu)化或定制，這使得計(jì)算引擎在對接時(shí)遇到了一些困難。而在海外，S3 基本已經(jīng)成為事實(shí)標(biāo)準(zhǔn)，接口非常統(tǒng)一，這使得對接工作變得更加簡單。

然而，在國內(nèi)，討論 HDFS 是否被替代可能還為時(shí)過早。正如剛才提到的，許多企業(yè)仍然能夠控制自己的 HDFS 系統(tǒng)，并在此基礎(chǔ)上進(jìn)行定制優(yōu)化。在安全性和成本方面，企業(yè)甚至可以通過這種方式使成本低于云對象存儲。因此，HDFS 的存在確實(shí)有其必要性和優(yōu)勢。

會議推薦

在 AI 大模型重塑軟件開發(fā)的時(shí)代，我們?nèi)绾伟盐兆兏?？如何突破技術(shù)邊界？4 月 10-12 日，QCon 全球軟件開發(fā)大會· 北京站 邀你共赴 3 天沉浸式學(xué)習(xí)之約，跳出「技術(shù)繭房」，探索前沿科技的無限可能。

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