来源：LanceDB Blog
作者：Jack Ye & Prashanth Rao
原文链接：https://lancedb.com/blog/from-bi-to-ai-lance-and-iceberg/
“湖仓一体”理念在持续演进，它融合数据湖与数据仓库的优势：一方面具备数据湖的灵活性（基于对象存储，原生支持开放文件格式），另一方面，又兼具数据仓库的分析性能与可靠性。
而Apache Iceberg 等开源项目为这一理念落地提供了核心支撑，不仅实现了大规模场景下的事务一致性保障，更支持数据表结构的灵活演进，无需重构底层存储。
人工智能和机器学习的发展，带来了海量多模态数据（如文本、图像、音频、视频、传感器数据），Lance 等新型格式正推动技术实现跨越式发展。
作为一种高性能列式格式，Lance 专为 PB 级多模态数据和 AI/ML 工作负载，比如模型训练、特征工程等量身打造。
本文将解析 Iceberg 与 Lance 在现代湖仓架构中的定位及核心差异，探讨如何通过这两种格式构建连接数据分析与 AI/ML 的新型数据架构，实现基于同一数据底座的多场景支撑。
一、解读现代湖仓架构
现代湖仓架构由六个独立的技术层构成，每层承担特定功能。以下从底层到上层逐一拆解，明确 Lance 与 Iceberg 的定位及协同方式：
1. 对象存储层
湖仓架构的基础是对象存储 —— 这类存储系统采用简洁的对象化层级结构，通常具备高耐久性，并通过基于 HTTP 的通信协议实现数据传输。
2. 文件格式层
定义单个文件在磁盘上的存储方式，典型代表包括 Lance、Parquet、ORC、Avro 等。文件格式决定了数据文件的内部结构、编码方式和压缩算法。
3. 表格式层
描述多个文件如何协同构成逻辑表，核心需支持事务提交、读隔离等特性，确保多写入者和读取者可安全操作同一数据表。
4. 目录规范层
定义系统如何发现和管理存储中的数据表集合，是连接存储层与计算层（从目录服务开始，下文详述）的关键桥梁。
5. 目录服务层
为上层计算引擎提供便捷的连接能力，实现一种或多种目录规范，负责管理表元数据，并可选择性提供表格式所需的后台维护能力（如数据压缩、优化、索引更新），保障系统性能。
6. 计算引擎层
构建在目录服务之上的核心处理单元，利用对目录规范、表格式和文件格式的深度理解，执行复杂的数据工作流。计算引擎需精心设计以支持多样化工作负载，包括 SQL 查询、分析处理、向量检索、全文检索、机器学习训练等。
二、Lance 与 Iceberg 的核心差异
从上述湖仓架构可知，文件格式、表格式、目录规范层均属于存储规范，而计算能力仅存在于对象存储、目录服务和计算引擎层。
这种清晰的职责分离，使得湖仓存储具备灵活性、可移植性和独立扩展性，同时支持任意目录服务发现数据、兼容计算引擎处理数据。
- Iceberg 覆盖架构中的两个层级：表格式层和目录规范层，通常以 Parquet 作为底层文件格式。
- Lance 则跨越三个层级，同时兼具文件格式、表格式和目录规范的属性。
以下从各层级详细对比两者差异：
1. 表格式层对比
Iceberg 采用三级元数据层级结构：表元数据文件 → 清单列表（manifest list）→ 清单文件（manifest files）。
- 表元数据（JSON 格式）汇总了历史提交记录和 schema 变更，存储分区规范、快照引用和表属性；
- 每个快照指向一个清单列表（Avro 格式），包含清单文件的元数据和分区统计信息（同样为 Avro 格式）；
- 清单文件则记录对象存储中的数据文件列表。
需注意：Iceberg 表格式本身不定义原子提交机制，仅记录最新表元数据的存储位置，实际提交逻辑由目录服务实现。
Lance 采用单级元数据层级结构，每个表版本对应一个清单文件。Lance 表使用 “片段（fragment）” 而非 “分区” 作为组织单元，每次提交都会生成新的清单文件，包含片段（每个片段配有独立的数据文件和删除文件）及索引文件指针（支持全文检索、向量索引等标量索引）。
2. 文件格式层对比
Iceberg 支持多种底层文件格式，其中 Parquet 应用最广泛，同时兼容 Avro 和 ORC 格式。
Lance 则摒弃了行组（row groups）设计（Parquet 高度依赖该结构），实现了高并行度处理，在不牺牲扫描性能的前提下，随机访问性能达到 Parquet 的 100 倍。
Lance 与 Parquet 还有其他多项差异，详见 VLDB 2025 论文《Efficient Random Access in Columnar Storage through Adaptive Structural Encodings》（《基于自适应结构编码的列式存储高效随机访问》）。
论文链接：https://arxiv.org/html/2504.15247v1
3. 目录规范层对比
由于 Iceberg 将原子写入保障委托给任意目录服务实现，各厂商在构建目录服务时开发了多种协议。
Iceberg 的 “REST Catalog 规范” 作为统一封装层，标准化了这些异构协议，采用该规范的目录服务需保证 API 操作的原子性。
Lance 未明确定义目录规范，而是采用 “命名空间（namespaces）” 机制。
Lance 特意将其命名为 “Lance Namespace” 而非 “Lance Catalog”，因其本质是轻量级封装，支持通过任意目录服务存储和管理 Lance 表，并非完整的目录规范。
未来，为提供全面的目录规范能力，Lance 计划以 Arrow Flight gRPC 作为核心标准，契合其 “Arrow 原生湖仓格式” 的设计愿景。
三、Lance 优势场景
以下重点介绍 Lance 相比 Iceberg 的核心优势，尤其适用于 AI/ML 工作负载：
1. 为搜索、ML/AI 场景优化的高速随机访问
Iceberg、Delta Lake、Hudi 等早期开源表格式主要作为 Hive 的替代方案设计，聚焦数据仓库（OLAP）工作负载，适配 “长而窄” 的表结构。
而 Lance 从底层设计就致力于支持机器学习和 AI 工作负载，适配完全不同的数据访问模式，兼容 “长而宽” 的表结构（如包含嵌入向量、二进制大对象（blob）、深度嵌套数据的列）。
- Lance 可在数小时内完成数十亿级向量的索引构建，支持10 PB+ 数据存储；
- 向量检索场景下，基于对象存储可实现 10,000+ QPS 查询性能，延迟低于 50 毫秒；
- ML 训练场景下，通过与 PyTorch、JAX 数据加载器集成，借助分布式缓存集群，从 NVMe SSD 可实现超过 500 万 IOPS 的数据读取性能。
相比传统湖仓中依赖 Iceberg 的扫描式处理方案，Lance 在同一格式中融合高速随机访问与原生索引能力，使其在 ML/AI 场景中具备显著优势。
参考资料
- Lance长且宽的表结构：https://lancedb.com/blog/lance-v2/#very-wide-schemas
- Lance数小时内完成数十亿级向量的索引构建：https://lancedb.com/blog/case-study-netflix/
- 向量场景下，Lance延迟低于 50 毫秒：https://arxiv.org/html/2504.15247v1
2. 原生支持多模态数据
在 AI 时代，多模态数据（图像、视频、音频、深度嵌套点云及其关联嵌入向量）的生成和消费变得愈发便捷，应用日益广泛。
当前多数 Iceberg 部署中，多模态数据被建模为表中的普通列（与其他表格数据一致），通过指针指向对象存储中的实际数据。
这种方式存在明显弊端：
- 数据治理层面，需为不同系统构建独立的访问控制层和额外运维流程；
- 性能层面，获取单个数据项时会产生额外的 I/O 和网络开销。
Lance 的文件格式支持将多模态数据以 blob 形式原生存储在列中，无需外部查找（多模态数据与元数据、嵌入向量共置），大幅简化了多模态数据的治理与管理。
性能方面，Lance 基于片段化设计，可将多个小行打包存储，同时将超大行（如图像、音频 blob）存入独立文件，实现性能与存储效率的平衡。
3. 灵活的零成本数据演进
随着数据集规模扩大，数据演进（即表 schema 变更、列的增删改）成为常见需求，尤其在 ML/AI 应用中，多个开发者并行工作时，经常需要向现有表添加新的特征、预测结果或嵌入向量列。
Iceberg 的数据演进存在显著成本 —— 由于 Parquet 按行组存储数据，新增列需重写整张表。对于超大型表，当多个团队并行添加新特征列时，需通过表锁定保障一致性，这会成为特征工程流程的性能瓶颈。
Lance 新增列本质上是零复制操作。其片段化设计允许每个片段拥有独立的列文件（多个列也可共享一个数据文件），因此添加或更新列仅需追加新的列文件，无需修改现有数据。
正如 Netflix 在构建媒体数据湖时采用 LanceDB 所验证的，这种设计可避免 PB 级数据的冗余复制。
空间节省效果显著：
- 假设现有表大小为 100GB，新增一列（大小 1GB，占原表 1%）——Iceberg 需重写整张表，产生 101GB 写入量；
- 而 LanceDB 仅需写入 1GB。数据集规模越大，这种差异越明显。
Lance 支持持续或增量添加特征，无需复制或重写无关数据，成为 PB 级数据场景下的优选方案。
四、Iceberg 的优势场景
Iceberg 基于分区、以目录为中心的设计，在传统商业智能（BI）或分析工作负载中仍具备显著优势。
以下将阐述其核心价值，以及 Lance 未来版本的优化方向：
1. 适配分析型工作负载
Iceberg 的隐式分区逻辑和三级元数据层级结构，使优化后的分析型计算引擎能高效实现分区剪枝 —— 这类场景下的查询通常会基于分区键进行过滤。
相比之下，Lance 以片段（而非分区）作为数据组织单元，目前其数据组织方式与高度依赖分区扫描的传统 OLAP 计算引擎适配度较低。
Databricks 提出的 “液态聚类（liquid clustering）” 等新技术，未来可充分发挥 Lance 的特性 —— 该技术摒弃固定表结构，采用基于实际查询模式优化的自适应聚类方案。
但分区概念已深度融入当前主流查询引擎，因此在液态聚类获得更广泛生态支持前，Iceberg 在分析型工作负载中仍占据优势。
2. 成熟的生态集成
Iceberg 经过多年生产环境验证，生态系统成熟，已与多款计算引擎和目录服务实现深度集成。
而 Lance 的计算引擎集成仍在发展阶段（目前主要支持 Spark 和 Ray），更多集成功能尚处于初期阶段。
开源社区对将 Lance 支持扩展至 Iceberg 生态中的主流计算引擎（如 Flink、StarRocks、Trino）抱有浓厚兴趣，相关生态将持续演进。
3. 集中式可观测性
Iceberg 依赖目录的设计，使得目录能够感知所有表操作，从而支持集中式监控和强大的自动化优化触发机制，同时便于维护全表统一审计日志，实现协同数据血缘追踪。
与 Delta Lake 类似，Lance 表可直接在存储层修改，无需目录感知。
这种 “存储优先” 的设计赋予 Lance 更好的可移植性，但增加了活动追踪难度 —— 下游操作需依赖拉取式轮询或存储事件通知（如 S3 Events、GCS Pub/Sub），而非语义化目录事件。
Lance 目前通过商业版产品 LanceDB Enterprise（可监控所有读写流量）解决这一问题，未来计划将所有操作接入 OpenTelemetry 等开源可观测性框架，支持任意兼容工具的追踪能力。
五、核心差异总结表
Parquet 与 Iceberg 在各自发展周期中，推动了湖仓架构各层级的连接器、集成工具和创新技术爆发。
但这些技术大多诞生于 AI 时代之前，难以适配当前快速变化的工作负载和用户需求。
Lance 作为较新的技术方案，能够在借鉴 Iceberg/Parquet 成功经验的基础上，针对现有痛点快速迭代优化。
如表格所示，Lance 的设计融合了多项经实践验证的模式，同时引入新范式以满足 AI/ML 工作负载的独特需求。Lance 用户可无缝对接各类 ML 和数据处理框架，从 Pandas、Polars 到 PyTorch 等。
六、基于 Lance 与 Iceberg 的统一数据平台
综合 Lance 与 Iceberg 的技术取舍（尤其分析型 vs ML/AI 工作负载），大型企业正逐步采用 “双格式策略”。例如 Netflix 已将 LanceDB 用于 AI 和多模态工作负载，同时保留 Iceberg 作为 BI 和分析场景的主力表格式。
下图展示了基于 Lance 与 Iceberg 构建的统一湖仓平台架构 —— 存储格式之上（目录服务、计算引擎）和之下（对象存储）的计算层实现了统一协同：
现有目录规范和元数据服务（如 Glue、Hive 元数据存储（HMS）、Unity REST Catalog、Polaris）已通过 lance-namespace 与 Lance 集成 —— 这是一个基于 Lance 的开放规范，标准化了多 Lance 表的访问方式。
计算引擎层面，Lance 生态已推出多款集成工具（如 lance-ray、lance-spark），并在开源社区获得广泛应用。
核心结论：无需维护多个目录服务的开发者，可基于 Lance 及其计算生态构建系统；已使用 Iceberg 的开发者，可在适合的场景中集成 Lance，充分发挥其技术优势。
这些新兴架构模式和开源项目反映了行业趋势：通过两种独立且互操作的格式，分别满足分析型和 AI 工作负载的需求 ——Iceberg 面向 BI，Lance 面向 AI 和多模态数据，实现两者优势的有机融合。
点击阅读原文，跳转LanceDB GitHub