在近期的 Streaming Lakehouse Meetup · Online EP.2｜Paimon × StarRocks 共話實時湖倉 直播中，Apache Paimon PMC 成員/阿里雲數據湖資深工程師葉俊豪帶來了關於 Paimon 多模態數據湖的深度技術分享。
隨着大模型訓練對數據規模與多樣性的要求不斷提升，傳統以批處理為中心的數據湖架構已難以滿足 AI 工作負載對實時性、靈活性和成本效率的綜合需求。特別是在推薦系統、AIGC 等典型場景中，工程師既要高頻迭代結構化特徵，又要高效管理圖像、音頻、視頻等非結構化數據。面對這一挑戰，Paimon 作為新一代流式數據湖存儲引擎，正通過一系列底層創新，構建面向 AI 原生時代的統一數據基礎設施。
一、結構化場景下的“列變更”困境
在推薦、廣告等 AI 應用中，特徵工程是一個持續演進的過程。例如，電商團隊可能今天新增“用户近7日點擊品類分佈”，明天又加入“跨端行為一致性評分”。這種動態列變更導致“列爆炸”問題：表結構頻繁擴展，而歷史數據需與新特徵對齊。
然而，已知的解決方案在此場景下仍然存在一些問題：
- 主鍵表 partial-update：雖支持按主鍵更新部分列，但其基於 LSM 樹的實現會在寫入頻繁時產生大量小文件，查詢性能急劇下降；Compaction 雖可合併文件，卻帶來數倍的臨時存儲開銷。
- odps 存新特徵值 + Join 拼接方案：將新特徵寫入獨立表，查詢時通過主鍵 Join 合併。看似避免了重寫，但 Join 操作本身在 PB 級數據上開銷巨大，且難以優化。
- Append 表 + MERGE INTO：SQL 語法簡潔，但底層仍需重寫整個數據文件。對於每天增量達 PB 級的訓練集，全量重寫不僅成本高昂，還顯著拖慢特徵上線週期。
這些方案本質上都未能解耦“列”的物理存儲，導致靈活性與效率不可兼得。
二、Paimon 的列分離架構：以全局 Row ID 為核心
Paimon 提出了 列分離存儲架構，其核心是引入 全局唯一且連續的 Row ID。每行數據在首次寫入時被分配一個在整個表生命週期內不變的 ID，且每個數據文件內的 Row ID 是連續的，元數據會記錄該文件的起始 Row ID。
這一設計帶來兩個關鍵能力：
- 精準定位任意行：通過 Row ID 可直接定位到具體文件及偏移；
- 跨文件自動關聯：當查詢涉及多個列時，系統能根據 Row ID 範圍自動將分散在不同文件中的列數據在存儲層合併。
例如，當新增“用户興趣標籤”列時，Paimon 僅需寫入一個包含該列與對應 Row ID 的新文件，無需修改原始特徵文件。查詢時，引擎透明地將兩組文件按 Row ID 對齊合併，無需 SQL 層 Join，也無需重寫歷史數據。這種機制將列變更的存儲成本從 O(N) 降至 O(ΔN)，極大提升了特徵迭代效率，同時節省了數十倍的存儲空間。
三、邁向多模態：Blob 數據類型的三大突破
AI 訓練不再侷限於結構化特徵。AIGC、多模態大模型等場景要求數據湖能高效處理圖像、短視頻、長音頻等非結構化數據。這類數據具有兩大特點：體積差異大（幾 MB 到數十 GB）、訪問稀疏（訓練時通常只讀取片段）。
傳統列式格式（如 Parquet）將多模態數據與結構化字段混存，導致即使只查用户 ID，也需加載整個含視頻的大文件，I/O 效率極低。
Paimon 引入 Blob 數據類型，實現三大突破：
- 物理分離存儲：Blob 列獨立成文件，與結構化數據完全解耦。查詢結構化字段時，Blob 文件完全不參與 I/O，避免資源浪費。
- 多引擎統一抽象：無論使用 Spark、Flink、Java SDK 還是 Python 客户端，均可通過標準的
BYTES或BINARY或 BLOB 類型定義 Blob 字段，接口一致，降低接入成本。 - blob-as-descriptor 機制：針對超大非結構化數據（如十幾GB的視頻/日誌文件），傳統計算引擎（如Flink/Spark）無法將其全量加載到內存中處理。為此，系統引入了 blob-as-descriptor 機制——它是一種協議，通過記錄數據在外部存儲（如OSS）中的位置、文件路徑、起始偏移和長度等元信息，將實際數據讀取任務交給下游系統按需流式加載。這樣避免了內存溢出，實現了大文件高效入湖。
四、生產驗證與未來演進
當前，Paimon Blob 已在淘寶、天貓等核心業務中實現大規模落地，每天有近 10PB 的多模態數據（如視頻、音頻、圖像）通過 Blob Descriptor 協議高效寫入 Paimon 湖，避免了 Flink 或 Spark 將大文件全量加載到內存的問題。然而，在實際使用中仍面臨三大關鍵挑戰：
- 數據重複與刪除問題，用户常因多次上傳相同內容導致大量冗餘（預估約 1PB/天的重複數據），亟需高效的去重與刪除機制；
- 小文件碎片化問題，頻繁的小規模寫入產生海量微小 Blob 文件，嚴重影響讀取性能和存儲效率；
- 點查召回延遲高，缺乏對主鍵（如 UID）或向量特徵的快速索引支持，難以滿足毫秒級實時查詢需求。
針對上述問題，團隊已規劃清晰的演進路徑。
- 點查性能優化方面，推進熱 ID 下推能力，並構建統一的全局索引框架，同時支持標量索引（如字符串、數值）和向量索引（用於 AI 召回），其中基礎版標量索引預計本月在開源 Master 分支可用。
-
多模態數據管理方面，啓動兩項核心功能：
- 一是基於 Deletion Vector + 佔位符 的邏輯刪除方案，在 Compaction 階段安全清理重複或無效數據；
- 二是開發 Blob Compaction 機制，自動合併小文件以提升讀性能和存儲密度。
此外，團隊還前瞻性地提出跨表 Blob 複用的構想——多個表引用同一視頻時僅存儲一份物理數據，雖因涉及多表狀態同步與一致性保障而技術難度較高，但已列入長期優化方向。整體目標是打造一個高效、緊湊、可快速檢索的多模態數據湖底座，支撐未來 AIGC 與智能推薦等場景的規模化應用。
結語
Paimon 的技術演進，從結構化場景的列分離，到多模態數據的 Blob 抽象，每一項創新都源於真實業務痛點，並反哺於工程效率的提升。它不再只是“存儲數據的地方”，而是成為 AI 原生時代的數據操作系統——高效、靈活、智能。
Paimon 將長期、持續且大力投入全模態數據湖建設，全面支持圖像、音視頻等非結構化數據的高效入湖、去重、合併與毫秒級點查。通過 Deletion Vector、Compaction 優化和全局索引等能力，Paimon 正構建面向 AI 時代的統一數據底座。作為開放湖表格式。
阿里雲DLF 在雲上提供全託管的Paimon存儲服務，支持Paimon的智能存儲優化與冷熱分層。同時，DLF提供安全、開放、支持全模態數據的一體化Lakehouse管理平台，深度融入兼容其他例如 Iceberg、Lance 等主流格式，無縫對接 Flink、Spark 等計算引擎，，為 AIGC 與多模態智能應用提供高性能、低成本、易治理的數據基礎設施。
在數據驅動的 AI 時代，基礎設施的價值，最終要體現在對業務效率的實質性推動上。 Paimon 的實踐，正為整個行業提供一條通往高效、統一、智能數據湖的新路徑。
