AIGC标识 [Lakehouse] 数据湖仓的技术选型

1 数据湖表格式与 AI Lakehouse 系统性调研

调研时间 = 2026.09

下面按“技术定位 → 存储格式 → 写入/更新 → 查询/索引 → 版本与 Schema → 多模态 → 生态/市占 → 前景 → 选型”来做一次系统性调研。

先给一个最重要的结论：

Hudi / Iceberg / Delta Lake / Paimon 本质上属于同一大类：Lakehouse Table Format / Lake Format。

LanceDB 则不是它们的直接同类产品。 LanceDB 是建立在 Lance 文件/表格式 + Catalog + Vector/Full-text Search 之上的 AI/多模态 Lakehouse / Retrieval Database。

如果把数据湖比作“操作系统”：

  • Parquet / ORC / Avro / Lance ≈ 文件格式
  • Iceberg / Hudi / Delta / Paimon / Lance Table ≈ 表格式 / 存储管理层
  • Spark / Flink / Trino / Presto / StarRocks ≈ 计算引擎
  • LanceDB ≈ 在 AI 数据存储之上进一步提供搜索、索引、检索能力的数据库/湖仓系统

而在四个传统 Lakehouse Format 中，我会把它们概括成：

Iceberg = 最强“开放标准/生态/多引擎”路线
Hudi = 最强“实时更新/CDC/增量处理/索引”路线
Delta Lake = 最强“Spark/Databricks 生态 + 工程成熟度”路线
Paimon = 最强“Flink 实时湖仓/Streaming Lakehouse”路线
LanceDB = 最强“AI/向量/多模态数据湖”路线

以下结论以 2026 年 9 月的公开资料为准。(Apache Iceberg)

一技术定位

先建立整体认知：它们到底是什么关系？

flowchart TB A[企业数据 / AI 数据] A --> B[物理文件格式 File Format] B --> B1[Parquet] B --> B2[ORC] B --> B3[Avro] B --> B4[JSON / CSV] B --> B5[Lance] B --> C[Table Format / Lake Format] C --> C1[Apache Iceberg] C --> C2[Apache Hudi] C --> C3[Delta Lake] C --> C4[Apache Paimon] C --> C5[Lance Table] C1 --> D[计算引擎] C2 --> D C3 --> D C4 --> D C5 --> E[LanceDB] D --> D1[Spark] D --> D2[Flink] D --> D3[Trino] D --> D4[Presto] D --> D5[Hive] D --> D6[StarRocks] D --> D7[Doris] E --> E1[Vector Search] E --> E2[Full-text Search] E --> E3[Hybrid Search] E --> E4[AI / RAG] E --> E5[Multimodal Data]

这里最容易混淆的是：

Parquet ≠ Iceberg ≠ Spark。

例如：

S3
 │
 ├── Iceberg Table
 │      ├── metadata
 │      ├── manifest
 │      └── data/*.parquet
 │
 ├── Hudi Table
 │      ├── .hoodie
 │      ├── base/*.parquet
 │      └── log/*.log
 │
 └── Delta Table
        ├── _delta_log
        └── data/*.parquet

也就是说：

Parquet 主要解决“数据怎么存”。

Iceberg/Hudi/Delta/Paimon 主要解决“这些文件如何组成一张可靠、可更新、可版本化、可并发访问的表”。

Iceberg 官方明确把自己定义为面向巨大分析数据集的 open table format；Hudi 则进一步强调 transactional storage、index、incremental processing；Delta 通过 transaction log 把数据湖变成 Lakehouse；Paimon则从 Flink Table Store 演化而来，重点解决实时湖仓问题。(Apache Iceberg)

五者定位总览

维度 Apache Hudi Apache Iceberg Delta Lake Apache Paimon LanceDB / Lance
核心定位 实时更新型 Lakehouse 开放标准型 Lakehouse Table Format Lakehouse Transaction Layer 实时流式 Lakehouse AI / 多模态 Lakehouse
核心思想 Update / CDC / Incremental Open Table Format / Multi-engine Transaction Log / Lakehouse Streaming + Primary Key Table Vector + Multimodal + Random Access
最擅长 高频更新、CDC 企业级统一数据湖 Spark/Databricks Flink 实时数仓 AI/RAG/Embedding/多模态
最强能力 Record-level update/index 开放性/生态 工程成熟度 Streaming Upsert Vector Search
典型用户 Uber 等大数据实时场景 Snowflake/AWS/Netflix/Apple 等生态 Databricks 用户 阿里/实时湖仓场景 AI/ML 应用
数据模型 Updateable Table Analytical Table Transactional Table PK Table / Append Table AI Dataset / Vector Table
Parquet 强 核心 核心 默认推荐 非核心
多模态 ★★★ ★★★ ★★★ ★★★ ★★★★★
向量检索 ★★～★★★ ★★ ★★ ★★★ ★★★★★
CDC ★★★★★ ★★★★ ★★★★ ★★★★★ ★★
Flink ★★★★★ ★★★★ ★★★★ ★★★★★ ★
Spark ★★★★★ ★★★★★ ★★★★★ ★★★★ ★★
Trino ★★★★ ★★★★★ ★★★★ ★★★★ ★★
生态开放性 ★★★★ ★★★★★ ★★★★ ★★★ ★★★
AI 数据集 ★★★ ★★★★ ★★★★ ★★★★ ★★★★★

Apache Iceberg

3.1 产品定位

Iceberg 最核心的定位是：

一个面向超大规模分析数据的开放 Table Format，而不是一个计算引擎。

它重点解决：

  • 文件管理
  • Snapshot
  • Schema Evolution
  • Partition Evolution
  • Concurrent Write
  • Time Travel
  • Metadata
  • Multi-engine interoperability

官方直接把 Spark、Trino、PrestoDB、Flink、Hive、Impala 等作为其生态的一部分。(Apache Iceberg)

3.2 核心优势

第一：开放标准属性非常强

Iceberg 的最大战略价值不是某个单点性能，而是：

它正在成为跨计算引擎的“共同表协议”。

             Iceberg Table
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
     Spark      Flink      Trino
       ↓          ↓          ↓
     Hive      StarRocks   Doris

Iceberg 本身不要求你绑定 Spark。

这是它和 Delta 早期设计思想非常重要的区别。

3.3 Hidden Partitioning

这是 Iceberg 非常重要的设计。

传统 Hive：

dt=2026-09-09/

业务查询可能必须理解：

WHERE dt = '2026-09-09'

Iceberg：

PARTITIONED BY days(event_time)

用户只需要：

WHERE event_time >= ...

Iceberg 自动推导 partition。

而且 partition scheme 后续可以演进。(Apache Iceberg)

Iceberg 的更新、删除、版本控制

Iceberg 的核心是：

Table
 │
 ├── Snapshot
 │     ├── Manifest List
 │     │      ├── Manifest
 │     │      │     ├── Data File
 │     │      │     └── Delete File
 │
 └── Metadata

它不是靠简单修改 Parquet 文件来实现版本控制。

而是：

数据文件基本不可变 + Metadata/Snapshot 指向不同的数据状态。

所以可以做到：

Snapshot 100
     ↓
Snapshot 101
     ↓
Snapshot 102
     ↓
Snapshot 103

查询：

SELECT ... AT VERSION 101

或者时间旅行。

同时支持：

  • position delete
  • equality delete
  • merge
  • update
  • delete

Iceberg 的性能优化主要来自：

  • Manifest
  • Manifest List
  • Partition pruning
  • Column statistics
  • Min/Max
  • Null count
  • Value count

官方文档明确说明，Iceberg 在规划阶段先过滤 Manifest，再利用 partition data 和 column statistics 排除 Data Files。(Apache Iceberg)

Iceberg 对 Parquet 的支持

★★★★★

默认：

Parquet

同时支持：

Parquet
ORC
Avro

默认数据文件格式就是 Parquet。(Apache Iceberg)

Parquet compression 支持：

  • ZSTD
  • Snappy
  • GZIP
  • LZ4
  • Brotli
  • Uncompressed

(Apache Iceberg)

所以：

Iceberg ≈ Table Format

Parquet ≈ Data File Format

这是理解 Iceberg 的核心。

Iceberg 最大短板

主要不是“功能少”，恰恰相反，而是：

1. 高频更新并不是它最强的设计目标

如果你有：

每秒几十万 CDC
大量 update
大量 delete
实时 upsert

Hudi/Paimon 往往更自然。

2. Metadata 管理复杂

大型 streaming workload：

大量 commit
      ↓
大量 snapshot
      ↓
大量 manifest
      ↓
需要 rewrite manifests
      ↓
需要 expire snapshots
      ↓
需要 compact files

Iceberg 官方也明确提醒 streaming 写入容易产生大量小文件，需要 compaction / manifest rewrite。(Apache Iceberg)

Apache Hudi

如果 Iceberg 是：

“开放的 Lakehouse Table Format”

那么 Hudi 更像：

“给 Data Lake 加数据库式 Update / Index / CDC 能力”。

Hudi 官方现在甚至直接使用：

Cloud Native Database

这样的定位。(Apache Hudi)

Hudi 最核心的设计

Hudi 最有代表性的能力：

Record Key
   ↓
Index
   ↓
File Group
   ↓
File Slice
   ↓
Base File + Log File

它实际上非常强调：

“我知道一条记录在哪个文件里。”

这是 Hudi 和 Iceberg 最大的思维差异之一。

Hudi CoW vs MoR

这是 Hudi 必须掌握的两个概念。

Copy-on-Write
Update
  ↓
重新写 Parquet
  ↓
Query 很快

适合：

读多写少
Merge-on-Read
Base Parquet
      +
Log Files
      ↓
Query 时 Merge

适合：

高频 Update
CDC
Streaming

Hudi 官方当前技术规范仍然把 CoW / MoR 作为核心表类型。(Apache Hudi)

Hudi 的索引能力非常突出

Hudi 可以利用：

  • Bloom Filter
  • Metadata Table
  • File Index
  • Column Stats
  • Record-level Index
  • Expression Index
  • Secondary Index
  • Bucket
  • External KV Store

来减少：

Record → File

的查找成本。

这是 Hudi 相比 Iceberg/Delta 很重要的竞争优势。

(Apache Hudi)

Hudi 的 Parquet 支持

非常强。

当前 Hudi 1.2 技术规范支持：

Parquet
ORC
HFile
Lance

其中 Parquet 是核心格式之一。(Apache Hudi)

而且一个非常有意思的新趋势：

Hudi 已经开始拥抱 Lance。

也就是说：

Hudi
 ├── Parquet
 ├── ORC
 ├── HFile
 └── Lance

这恰好体现了 Hudi 正在向：

通用 Storage Engine

方向发展。

Hudi 的最大优势

如果你的数据场景是：

MQTT
 ↓
Kafka
 ↓
Flink
 ↓
CDC
 ↓
频繁 Upsert
 ↓
Data Lake

那么 Hudi 非常有吸引力。

例如：

车辆实时数据
设备状态
IoT
订单状态
用户画像
实时宽表
CDC

这类场景 Hudi 非常自然。

Hudi 的短板

1. 系统复杂度较高

Hudi 有：

Timeline
File Group
File Slice
Base File
Log File
Compaction
Clustering
Cleaning
Index
Metadata Table
Record Merge

学习成本明显高于简单的 Parquet + Hive。

2. 对查询引擎的透明性略弱于 Iceberg

Iceberg 更强调：

“我是一个标准 Table Format。”

Hudi 更强调：

“我本身就是一个具有 Storage Engine 能力的 Lakehouse。”

因此 Hudi 的“系统感”更强。

Delta Lake

Delta Lake 可以理解为：

Databricks/Spark 体系推动起来的 Lakehouse Transaction Layer。

它的基本模型：

Parquet
+
_delta_log
=
Delta Table

Delta 官方明确提供：

  • ACID
  • Schema enforcement
  • Time Travel
  • Upsert
  • Delete
  • Streaming
  • Batch
  • CDF

(Delta Lake)

Delta 的最大优势

Spark / Databricks 生态

如果企业本身就是：

Databricks
+
Spark
+
Delta

那么 Delta 的工程体验非常成熟。

所以 Delta 的优势不只是技术：

生态 + 平台 + 工具链 + 企业用户

形成了非常强的网络效应。

Delta Lake 官方目前也强调有来自 70+ 组织、190+ 开发者参与。(Delta Lake)

Delta 的 Transaction Log

典型：

_delta_log/

00000000000000000000.json
00000000000000000001.json
00000000000000000002.json
...

这些日志记录：

AddFile
RemoveFile
Metadata
Protocol
CommitInfo
...

于是：

Snapshot N
     ↓
Snapshot N+1
     ↓
Snapshot N+2

这就是 Delta 的核心。

Delta Deletion Vector

Delta 最近非常重要的一项能力：

Deletion Vector

传统：

删除一行
 ↓
重新写整个 Parquet

Deletion Vector：

Parquet
  +
Deletion Vector

只记录：

row 123
row 567
row 889

已经删除。

从而减少 rewrite。

官方文档说明，Deletion Vector 已支持 DELETE、UPDATE、MERGE 等操作。(Delta Lake)

Delta Liquid Clustering

Delta 还有一个重要趋势：

Hive Partition
      ↓
Z-Order
      ↓
Liquid Clustering

Liquid Clustering 可以动态改变 clustering columns，而且不需要像传统 partition 一样进行大规模重写。(Delta Lake)

所以 Delta 正在逐渐解决：

“传统 Partition 一旦选错就很难改变”

这个经典问题。

Delta 的主要短板

1. 生态历史包袱偏 Spark

虽然现在：

Spark
Flink
Trino
Presto
Hive
Athena

等都有 Delta 支持，但整体生态历史上仍然明显受到 Spark/Databricks 影响。(Delta Lake)

2. 开放性虽然很强，但 Iceberg 的“标准化气质”更强

如果企业目标是：

多云 + 多计算引擎 + 最大程度避免单一生态绑定

Iceberg 往往更有吸引力。

Apache Paimon

Apache Paimon

Paimon 非常有意思。

它原来的名字是：

Flink Table Store

后来成为 Apache Paimon。

因此它的基因非常明显：

Flink First / Streaming First

官方定位就是：

Realtime Lakehouse Architecture。(GitHub)

Paimon 的核心设计

Paimon 更强调：

Streaming
   ↓
Primary Key Table
   ↓
Upsert
   ↓
Merge Engine
   ↓
Realtime Lakehouse

尤其适合：

Kafka
 ↓
Flink
 ↓
Paimon
 ↓
实时数据湖

Paimon Primary Key Table

例如：

CREATE TABLE user (
    id BIGINT,
    name STRING,
    age INT,
    PRIMARY KEY (id) NOT ENFORCED
)

然后：

id=100

不断更新。

Paimon 可以通过：

  • Deduplicate
  • Partial Update
  • Aggregation
  • First Row
  • Last Row

等 Merge Engine 处理。

Paimon 的一个非常强的特点

它同时支持：

Append Table
+
Primary Key Table

Append：

INSERT
INSERT
INSERT

Primary Key：

INSERT
UPDATE
DELETE
UPSERT

所以 Paimon 实际上把：

Streaming Table + Data Lake

结合得非常紧。

Paimon 对 Parquet

非常强。

当前 Paimon 支持：

Parquet
Avro
ORC
CSV
JSON
Lance
Vortex
Mosaic
Row

而官方仍然把：

Parquet 作为推荐 column format

同时把 Lance 推荐给 ML workloads。(Apache Paimon)

这是一个非常值得关注的信号：

Paimon
 ├── Analytics → Parquet
 ├── Streaming → Row/Avro
 └── ML → Lance

Paimon 的索引

Paimon 当前也越来越不像传统“简单 Data Lake”。

包括：

  • BloomFilter
  • Bitmap
  • Range Bitmap
  • Partition stats
  • Column stats
  • Aggregate pushdown
  • Z-Order
  • Hilbert
  • Sort

官方文档明确列出了 BloomFilter、Bitmap、Range Bitmap 以及 Z-order/Hilbert 等优化能力。(Apache Paimon)

Paimon 的短板

第一：生态广度仍然不如 Iceberg

GitHub 社区规模也明显较小：

项目 GitHub Stars（约）
LanceDB 10K+
Iceberg 9K+
Delta 8K+
Hudi 6K+
Paimon 3K+

注意：

GitHub Stars ≠ 市占率。

但可以作为开源社区热度的粗略代理指标。当前公开仓库数据显示 Iceberg 约 9.2K、Delta 约 8.8K、Hudi 约 6.2K、Paimon 约 3.3K，而 LanceDB 已超过 10K。(GitHub)

LanceDB：完全不同的一条路线

这里必须特别强调：

不要把 LanceDB 简单理解成“第五个 Iceberg/Hudi”。

它的核心方向完全不同。

LanceDB 官方现在把自己定位为：

Multimodal Lakehouse for AI

底层是：

Lance Format

(LanceDB)

LanceDB 的核心数据模型

传统 Lakehouse：

文本
数字
时间
指标

LanceDB：

文本
图片
音频
视频
PDF
Embedding
Metadata
Vector
Blob

可以放在同一张表里。

例如：

Document Table

id
title
text
image
audio
embedding
metadata

LanceDB 原生支持 binary columns，把图片、音频、视频、PDF 等数据和 embedding / metadata 放在同一数据体系中。(LanceDB)

Lance 为什么不用 Parquet？

这是 LanceDB 最核心的问题之一。

官方的答案很直接：

Parquet 对现代 ML 场景的 random access / vector workload 不够好。

Lance 的目标：

Columnar Scan
       +
Random Access
       +
Vector Search
       +
Multimodal

而不是只优化：

OLAP Scan

LanceDB 官方甚至给出了其 benchmark 中 Lance 相对于 Parquet 随机访问性能可达到数量级提升的结果，不过这属于 LanceDB 自己的 benchmark，应当视为厂商数据而不是通用结论。(LanceDB)

LanceDB 的索引

这是 LanceDB 和前四者最大的区别。

它天然关注：

Vector Index
Full-text Index
Scalar Index

例如：

IVF
PQ
IVF-PQ

官方文档明确将 IVF-PQ 作为核心 disk-based ANN indexing 路线。(LanceDB)

所以：

Iceberg
    ↓
File pruning / metadata

Hudi
    ↓
Record index / bloom / metadata

LanceDB
    ↓
Vector ANN Index

三者的“索引”其实不是一个层面的东西。

LanceDB 的版本控制

Lance 也支持：

Version 1
Version 2
Version 3
...

而且：

新版本只写新增/修改的数据和 manifest，而不是复制整个 Dataset。

这非常适合：

ML Dataset
Embedding Dataset
Training Dataset
Feature Dataset

Lance 官方称之为 zero-copy data evolution。(LanceDB)

二、存储格式与核心架构

五种技术的核心架构差异

这是我认为最值得你记住的一张表。

技术 核心解决的问题
Parquet 怎么高效保存列式数据
Iceberg 怎么把大量数据文件组织成可靠的表
Hudi 怎么高效更新大量 Lake 数据
Delta 怎么给 Lake 加 Transaction / Version / ACID
Paimon 怎么把 Streaming + Lakehouse 结合起来
Lance 怎么高效存储/访问 AI 多模态数据
LanceDB 怎么在 AI 数据上做 Vector/Retrieval/Search

Parquet 支持情况

能力 Hudi Iceberg Delta Paimon LanceDB
Parquet ✅ 核心 核心 默认推荐 ⚠️ 非底层核心
ORC ✅ ✅ ❌/非核心 ✅ ❌
Avro Log/Metadata ✅ ❌ ✅ ❌
Lance ✅ 当前版本支持 ❌原生表格式 ❌ ✅ 核心
JSON 非主要 ❌ ❌ ✅ Blob/结构化
CSV ❌ ❌ ❌ ✅ 可通过生态
Vortex ❌ ❌ ❌ ✅ ❌

Paimon 当前已经明显开始形成“多文件格式”战略，而 Hudi 也在 1.2.0 中加入 Lance base-file 支持。(Apache Paimon)

压缩方式

这里必须避免一个常见误区：

Table Format 通常不是压缩算法本身。

压缩主要取决于：

底层 File Format

例如 Parquet：

Parquet
 ├── Snappy
 ├── ZSTD
 ├── GZIP
 ├── LZ4
 ├── Brotli
 └── None

Iceberg 当前 Parquet writer 官方支持 ZSTD、Brotli、LZ4、GZIP、Snappy 等。(Apache Iceberg)

Paimon 也可以直接配置 Parquet compression，例如：

zstd

(Apache Paimon)

三、写入与更新能力

更新写入能力对比

能力 Hudi Iceberg Delta Paimon LanceDB
Append ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★
Upsert ★★★★★ ★★★★ ★★★★ ★★★★★ ★★★★
Update ★★★★★ ★★★★ ★★★★★ ★★★★★ ★★★★
Delete ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★
CDC ★★★★★ ★★★★ ★★★★★ ★★★★★ ★★
Partial Update ★★★★★ ★★★ ★★★★ ★★★★★ ★★★★
高频 Streaming Write ★★★★★ ★★★★ ★★★★ ★★★★★ ★★★
Random Point Update ★★★★★ ★★～★★★ ★★★ ★★★★ ★★★★★

四、查询与索引能力

版本控制 / Time Travel

能力 Hudi Iceberg Delta Paimon Lance
Snapshot ✅ ✅ ✅ ✅ ✅
Time Travel ✅ ★★★★★ ★★★★★ ✅ ✅
Rollback ✅ ✅ ✅ ✅ ✅
Branch ★★ ★★★★★ ★★★ ★★ ★★
Tag ★★ ★★★★★ ★★★ ★★ ★★
Audit ★★★★★ ★★★★★ ★★★★★ ★★★★ ★★★★

Iceberg 的一个明显优势是原生把：

Branch
Tag
Snapshot

纳入 Table Format 能力。(Apache Iceberg)

Partition 策略

Hudi Iceberg Delta Paimon LanceDB
Hive Partition ✅ ✅ ✅ ✅ ⚠️
Hidden Partition ❌/弱 ★★★★★ 部分替代方案 ❌/弱 ❌
Partition Evolution ★★★ ★★★★★ ★★★ ★★★ ★★
Hash/Bucket ✅ ✅ ✅/clustering ★★★★★ ★★★
Z-Order ★★★★ ★★★ ★★★★★ ★★★★★ ★★★
Hilbert ★★ ★★ ★★ ✅ ★★
Liquid Clustering ❌ ❌ ★★★★★ 类似布局优化 ❌

Schema Evolution

能力 Hudi Iceberg Delta Paimon LanceDB
Add Column ✅ ✅ ✅ ✅ ✅
Drop Column ✅ ✅ ✅ ✅ ✅
Rename ✅ ✅ ✅ ✅ ✅
Type Evolution ✅ ★★★★★ ★★★★ ★★★★ ★★★★
Nested Schema ✅ ★★★★★ ★★★★ ★★★★ ★★★★★
Zero-copy Evolution ★★★ ★★★ ★★★ ★★★ ★★★★★

Iceberg 的 schema evolution 是其设计核心之一；Paimon 当前也支持 add/drop/update/rename，并进一步支持 append table 的 partial column update。(Apache Iceberg)

五、多模态能力

多模态能力

这一项差距非常明显。

多模态 Hudi Iceberg Delta Paimon LanceDB
Text ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★
Image ★★★ ★★★ ★★★ ★★★ ★★★★★
Audio ★★ ★★ ★★ ★★ ★★★★★
Video ★★ ★★ ★★ ★★★ ★★★★★
PDF ★★ ★★ ★★ ★★★ ★★★★★
Embedding ★★★ ★★★ ★★★ ★★★★ ★★★★★
Vector Search ★★ ★★ ★★ ★★★ ★★★★★
Blob ★★★ ★★★ ★★★ ★★★ ★★★★★

LanceDB 的设计从一开始就是：

Raw Multimodal Data
+
Metadata
+
Embedding
+
Vector Index

因此它不是简单在传统 Lakehouse 上“增加一个 vector column”，而是围绕 AI 数据访问模式设计。(LanceDB)

六、生态与市占

计算引擎生态

引擎 Hudi Iceberg Delta Paimon LanceDB
Spark ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐
Flink ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐
Trino ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐
Presto ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐
Hive ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐
StarRocks ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐
Doris ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐
DuckDB ⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐
Python ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐

Iceberg 官方当前直接把 Spark、Trino、PrestoDB、Flink、Hive、Impala 等列为主要计算生态。(Apache Iceberg)

开源组织 / 治理

项目 组织 开源许可 治理特点
Hudi Apache Software Foundation Apache 2.0 Apache 社区
Iceberg Apache Software Foundation Apache 2.0 Apache 社区
Paimon Apache Software Foundation Apache 2.0 Apache 社区
Delta Lake Linux Foundation Apache 2.0 独立开放治理
Lance LanceDB 社区/公司主导 Apache 2.0 新兴 AI 数据生态
LanceDB LanceDB Apache 2.0 OSS + Commercial Enterprise

Delta Lake 在 2019 年进入 Linux Foundation，官方强调其治理并不由单一公司控制。(Linux Foundation)

“市占率”应该怎么理解？

这里我要特别纠正一个容易误导的问题：

目前没有一个可靠、统一、公开的“Apache Hudi / Iceberg / Delta / Paimon / LanceDB 全球市占率 %”统计。

所以如果看到：

Iceberg 38%
Delta 32%
Hudi 20%
Paimon 10%

这种表，我会非常谨慎。

更合理的是看：

生产采用
+
云厂商支持
+
计算引擎支持
+
开源社区
+
商业生态
+
GitHub
+
招聘市场
+
大型互联网公司采用

当前市场态势，我会这样判断

第一梯队
                 ┌── Iceberg
Lakehouse        │
                 └── Delta Lake

这两个目前明显是主流竞争。

第二梯队
Hudi
Paimon

但二者路线完全不同：

Hudi
 ↓
CDC / Update / Incremental

Paimon
 ↓
Flink / Streaming / Realtime
AI 新赛道
Lance
 ↓
LanceDB
 ↓
Multimodal AI Data

它并不是在直接争夺：

“谁替代 Iceberg？”

而是在争：

“AI 数据基础设施下一代底层格式是什么？”

GitHub 热度只能作为“生态热度代理”

截至当前公开仓库数据，大致：

LanceDB      ~10K+
Iceberg       ~9K+
Delta         ~9K
Hudi          ~6K
Paimon        ~3K

这并不能说明 LanceDB 的企业市场规模已经超过 Iceberg/Delta。

原因非常简单：

LanceDB 是 AI 开源项目，GitHub developer adoption 非常快。

而 Iceberg/Delta 大量商业使用来自：

Cloud
Databricks
Snowflake
AWS
Google
Azure
Enterprise

很多企业用户根本不会贡献 GitHub Star。

因此：

GitHub Star ≠ Market Share。

七、技术哲学与互补关系

五者真正的“哲学差异”

如果把五个项目压缩成一句话：

Iceberg

“让任何计算引擎都能可靠地访问同一张开放表。”

Hudi

“让 Data Lake 像数据库一样可以高频更新。”

Delta

“让 Parquet Data Lake 获得 ACID、Transaction、Version 能力。”

Paimon

“让 Streaming 数据可以直接成为 Lakehouse。”

LanceDB

“让 AI 的原始数据、Embedding、Vector Index、多模态数据成为同一套 Lakehouse。”

非常重要：它们不是完全互斥的

这是企业架构设计时最容易犯的错误。

不是：

Iceberg OR Hudi OR Paimon OR LanceDB

而可能是：

                     Enterprise Data Platform
                              │
           ┌──────────────────┼─────────────────┐
           ↓                  ↓                 ↓
       Iceberg              Hudi             Paimon
           │                  │                 │
        BI/OLAP              CDC            Streaming
           │                  │                 │
           └──────────────────┼─────────────────┘
                              ↓
                       Data Lakehouse
                              │
                              ↓
                       AI Data Pipeline
                              │
                              ↓
                           Lance
                              │
                              ↓
                          LanceDB
                              │
                 ┌────────────┼────────────┐
                 ↓            ↓            ↓
                RAG        Vector       Multimodal

这实际上非常符合未来企业 AI 数据架构。

一个更有意思的未来架构

如果结合你之前一直研究的 Enterprise Agent / Data Platform / Knowledge Platform，我反而更推荐这样理解：

flowchart TB subgraph Business["业务数据层"] DB[业务数据库] API[业务 API] MQ[Kafka / MQTT] FILE[文档 / 图片 / 视频] end subgraph Lakehouse["Enterprise Lakehouse"] H[Hudi] I[Iceberg] D[Delta Lake] P[Paimon] end subgraph FileFormat["Data File / AI File Format"] PQ[Parquet] ORC[ORC] AV[Avro] LN[Lance] end subgraph AIData["AI Data Layer"] LDB[LanceDB] V[Vector Index] FT[Full Text] EMB[Embedding] end subgraph AI["AI / Agent"] RAG[RAG] AGENT[Agent] MODEL[LLM / VLM] end DB --> H API --> I MQ --> P FILE --> LDB H --> PQ I --> PQ D --> PQ P --> PQ H --> LN P --> LN LN --> LDB LDB --> V LDB --> FT LDB --> EMB V --> RAG FT --> RAG EMB --> RAG RAG --> AGENT AGENT --> MODEL

这时候：

Iceberg/Hudi/Paimon/Delta

负责：

企业结构化/半结构化数据 Lakehouse

而：

Lance/LanceDB

负责：

AI-native Data Layer

这两层不是竞争关系，而可能是互补关系。

八、选型建议

如果从企业架构选型，我会这样选

场景 第一选择 第二选择
企业统一 Data Lake Iceberg Delta
Databricks Delta Iceberg
Spark 为主 Delta / Iceberg Hudi
Flink 为主 Paimon Hudi
CDC / 高频 Upsert Hudi Paimon
实时数仓 Paimon Hudi
多计算引擎 Iceberg Hudi
大规模 OLAP Iceberg Delta
数据共享 Iceberg Delta
AI Dataset Lance Iceberg
Embedding Dataset Lance Parquet
RAG LanceDB Milvus/Qdrant 等
图片/视频/音频 + Vector LanceDB 专业 Vector DB
ML Feature Store Lance/LanceDB Iceberg
企业 Agent Memory LanceDB + Lakehouse 专业 Vector DB
传统 BI Iceberg/Delta Hudi
IoT Hudi/Paimon Iceberg
汽车/设备实时数据 Hudi/Paimon Iceberg

九、前景判断与本质总结

未来 3～5 年，我对它们的判断

我会给出这样的判断：

项目 前景 我的判断
Iceberg ⭐⭐⭐⭐⭐ 最值得长期押注的开放 Lakehouse Table Format
Delta Lake ⭐⭐⭐⭐⭐ Databricks 生态仍会非常强
Hudi ⭐⭐⭐⭐½ CDC / Update / Incremental 仍有独特价值
Paimon ⭐⭐⭐⭐ Flink + Realtime Lakehouse 有明确生态位置
Lance/LanceDB ⭐⭐⭐⭐⭐ AI Data Infrastructure 潜力巨大，但赛道仍在形成

我尤其看好一个趋势：Lakehouse → AI Lakehouse

传统：

Data Lake
   ↓
Parquet
   ↓
Iceberg/Hudi/Delta/Paimon
   ↓
BI / SQL

未来可能变成：

                    AI Lakehouse

                        │
          ┌─────────────┼──────────────┐
          ↓             ↓              ↓
     Structured      Knowledge      Multimodal
        Data           Data           Data
          │             │              │
      Iceberg         RAG          Lance
      Hudi            Vector       LanceDB
      Paimon          Graph        Vector Index
      Delta
          │             │              │
          └─────────────┼──────────────┘
                        ↓
                   Agent Platform
                        ↓
                 LLM / VLM / Agent

这也是为什么 Lance/LanceDB 值得特别关注。

LanceDB 当前已经明确把自己定位在：

AI / ML
RAG
Agent
Recommendation
Multimodal
Feature Engineering
Training Data

而不是传统 BI。(LanceDB)

最后给你一张“本质区别”表

技术 本质
Parquet 列式文件格式
ORC 列式文件格式
Avro 行式/序列化文件格式
Lance AI/ML 优化的现代列式文件 + 数据集格式
Iceberg 开放 Table Format
Delta Lake Transaction Log + Lakehouse Table Format
Hudi Update-oriented Lakehouse Storage Engine + Table Format
Paimon Streaming-oriented Lake Format / Table Store
LanceDB 基于 Lance 的 AI / Multimodal Lakehouse + Retrieval Engine

如果让我给出最终排名

如果不是单纯比较“谁功能最多”，而是站在 2026 年企业数据平台 + AI Agent 基础设施角度：

企业 Lakehouse 总体

① Iceberg

最值得作为企业级开放 Lakehouse 标准考虑。

Spark / Databricks

① Delta Lake

平台生态优势太强。

CDC / 高频更新

① Hudi

Update / Index / Incremental Processing 是其核心壁垒。

Flink / 实时湖仓

① Paimon

Streaming Lakehouse 的定位非常清晰。

AI / 多模态数据

① Lance / LanceDB

这是完全不同的新赛道。

最后一个非常关键的结论

如果你正在设计企业级 AI Agent 数据基础设施，我不建议把问题理解成：

“Iceberg、Hudi、Paimon、LanceDB 到底选哪个？”

而应该拆成三个层次：

                    Enterprise AI Data Architecture

┌──────────────────────────────────────────────────┐
│              Agent / Application Layer           │
├──────────────────────────────────────────────────┤
│              Knowledge / Retrieval               │
│       RAG / Vector / Full-text / Graph           │
│                    ↑                             │
│              LanceDB / Vector DB                 │
├──────────────────────────────────────────────────┤
│              AI Data Lakehouse                   │
│                                                  │
│     Iceberg / Hudi / Delta / Paimon              │
├──────────────────────────────────────────────────┤
│              Physical Data Files                 │
│                                                  │
│       Parquet / ORC / Avro / Lance               │
├──────────────────────────────────────────────────┤
│          S3 / OSS / HDFS / ADLS / GCS            │
└──────────────────────────────────────────────────┘

这才是这几个技术之间真正的关系。

换句话说：

Parquet 和 Lance 解决“数据怎么物理存”。

Iceberg / Hudi / Delta / Paimon 解决“数据怎么成为可靠、可更新、可版本化的 Lakehouse Table”。

LanceDB 进一步解决“AI 怎么高效地对这些数据做向量、全文、混合检索以及多模态访问”。

而这条演进路线：

Data Lake → Lakehouse → AI Lakehouse → Agent Data Infrastructure

我认为是理解这五项技术未来竞争格局最重要的一条主线。(LanceDB)

Y 推荐文献

X 参考文献

posted @ 2026-09-09 20:55  千千寰宇  阅读(21)  评论(0)    收藏  举报