LanceDB：AI 时代的多模态数据湖

资料来源：火山引擎-开发者社区

LanceDB 是一款专为 AI 时代设计的开源数据湖解决方案，致力于解决多模态数据管理的核心痛点。

传统数据架构难以应对图像、视频等复杂数据类型，导致企业不得不维护多套独立系统，造成资源浪费和效率低下。LanceDB 通过创新的 Lance 格式，将数据存储、实时处理和模型训练整合到统一平台，其"Zero-cost Data Evolution"等特性提升了 AI 研发效率。目前已被多个头部 AI 公司采用，支撑数 10 PB 级数据处理。

LanceDB 与火山引擎建立了深度合作关系，自 2024 年起，多位火山引擎工程师成为项目核心贡献者，双方共同优化了 Java/Spark 技术栈性能，开发了 Catalog Service 等关键组件，将 LanceDB 深度集成到传统大数据生态中，推出了火山引擎 AI 数据湖服务 LAS。

近期在 北京举行的火山引擎 FORCE 原动力大会上， LanceDB CTO 徐磊进行了《LanceDB：AI 时代的多模态数据湖》专题分享，展示这一合作如何帮助企业简化 AI 数据架构，让研究人员专注于模型创新而非底层工程。

以下为演讲全文：

大家好，我是徐磊，LanceDB 的联合创始人兼 CTO。

自 2022 年 LanceDB 启动开发以来，我们在美国市场获得了广泛关注。目前，我们的产品已被多家顶级 AI 公司采用，其中包括李飞飞博士创立的 World Labs、知名图像生成平台 Midjourney、视频生成领域的 Runway，以及 Luma AI 等头部企业。在这些公司的实际部署中，我们的解决方案已经支撑了超过 10PB 规模的数据处理。

除了 AI 领域的合作伙伴，我们还与众多传统数据公司、云服务提供商展开了深度合作。其中包括像 Databricks 和 Netflix 这样从中型到大型的行业领先企业。

LanceDB 的核心目标，是重新思考并设计面向 AI 时代的数据基础设施——特别是针对多模态数据的存储与管理。

我们发现，AI 基础设施所需支持的工作负载，与传统 OLAP（在线分析处理）系统有着本质区别。越来越多的用户需要一种全新的数据架构，来高效支持 AI 计算、模型训练、Agent 开发等多样化需求。

自 2024 年年中以来，我们与火山引擎展开了紧密合作。火山引擎不仅贡献了两位优秀的工程师成为 LanceDB 项目的核心贡献者（Committer），还与我们共同聚焦一个关键方向：将 LanceDB 深度集成到传统大数据生态中。

具体来说，我们重点优化了 Lance 在 Java/Spark 技术栈中的性能表现，并联合开发了火山引擎的 Catalog Service 和 Hive Catalog Service。这使得 LanceDB 能够无缝兼容现有数据湖环境（如 Iceberg、Hudi 等），让企业无需重构架构即可享受 Lance 的高性能优势。

在技术集成方面，我们不仅完成了 Java SDK 和 Spark 的深度适配，还重点投入了 Python 工具链的优化——这是 AI 团队最常用的开发环境之一。

更令人振奋的是，通过与火山引擎的合作，我们成功将 LanceDB 集成到上游开源生态（如 Ray），并使其成为官方支持的数据源（Data Source）。这意味着开发者现在可以更便捷地在主流大数据框架中调用 Lance 的高性能能力。

同时，我们持续优化训练数据路径，显著提升了 AI 工作流的效率。今天，我非常激动能与火山引擎的同事们共同见证这一里程碑式的发布。

自 2022 年推出以来，LanceDB 得到了开源社区的广泛支持。我们的数据格式（Lance Format）和表格式（Table Format）已成为发展最快的数据湖格式之一。

这一增长背后的核心动力，是 LanceDB 精准填补了市场空白：专为 AI 数据设计的基础设施。从社区反馈来看，这正是开发者和企业急需的解决方案。

LanceDB 解决的核心问题是什么？

从产品角度来看，在 AI 研发的生命周期中，理想情况下，团队应该将全部资源集中在提升数据质量和模型训练上。

然而现实是，许多客户不得不反复构建相似的数据基础设施，这不仅造成了行业级的资源浪费，还导致项目周期大幅延长。

我们观察到，许多新兴 AI 公司招募了大量顶尖院校的 PhD，他们本应专注于模型创新和数据洞察，却不得不耗费大量时间管理数据底层架构。

这正是 LanceDB 诞生的初衷——让 AI 团队从繁琐的数据架构中解放出来，回归本质：More time on AI, but much less on data infrastructure。

合作案例一

Runway ML 是一家专注于视频生成的 AI 公司，他们面临的挑战非常具有代表性。在采用 LanceDB 之前，Runway ML 的技术团队需要处理数十 PB 规模的视频训练数据，这些数据以 Web Dataset 格式存储。

这个由 20 多名 AI 工程师组成的团队，其中包括许多顶尖院校的 PhD 研究员，不得不将大量时间花费在重复性的特征工程和数据采样工作上，通过传统的数据分析手段来理解训练数据分布对模型性能的影响。

问题的根源在于，Web Dataset 缺乏行业标准的分布式工具流支持。这就导致了一个现象：本该专注于模型创新和算法突破的高级研究人员，却不得不耗费大量精力开发底层数据操作功能。

更复杂的是，像 Runway ML 这样规模在 100-300 人的中型 AI 公司，通常没有配备完整的大数据工程团队。这种组织架构特点使得他们很难建立高效、统一的数据实践标准。缺乏专业的数据基础设施支持，导致各个团队都在重复造轮子，整体效率低下。

在与 LanceDB 合作后，Runway ML 将数十 PB 的视频训练数据迁移至 Lance 格式，通过支持 SQL 查询和简洁的 Python DataFrame API 访问和分析海量数据。

然后在整个公司中他们维护了"单一数据源"（Single Source of Truth）系统，将所有关键数据集整合到统一的大表中。其中最具突破性的是"零成本数据演进"（Zero-cost Data Evolution）功能，它允许工程师们动态地增减数据列，进行特征工程实验。

多位 AI 工程师可以在这张共享表上并行开展不同的特征迭代工作，而每个工程师的创新都能实时被整个团队共享利用。

这种架构带来了多重优势：

1.消除了数据副本的冗余存储

2.解决了数据一致性问题

3.降低了存储和计算成本

得益于 Lance 底层采用的 Arrow 内存格式，这套系统能够无缝对接各类标准数据库工具。无论是通过 LanceDB 企业版、Spark 还是 Daft，团队都能使用行业标准方法进行数据可视化和分析。

在性能优化方面，我们与 Runway 团队深度合作，对开源的 PyTorch 数据加载器进行了针对性增强。新增的物化视图（Materialized View）和非物化视图功能，使研究人员能够基于同一数据集快速创建不同的训练子集。这些改进共同构成了一个完整的高效研发闭环，为 Runway ML 的模型迭代速度带来了极大的提升。

合作案例二

让我为大家介绍另一个典型案例——Rerun.io，这是一家专注于机器人和自动驾驶领域的可视化开发平台。

事实上，在自动驾驶行业，包括我们之前合作过的 Cruise 在内，许多公司都开发过类似的系统，主要用于模型调试的可视化分析。

在使用 LanceDB 之前，Rerun.io 采用的是专为 Rust 系统优化的数据格式，比如 ROS2 的 rust bag 和 MCAP 格式。这些基于时间序列的流式数据格式虽然非常适合实时数据采集，但在实际使用中遇到了明显的瓶颈：

首先，这类时序格式在设计上主要面向流计算场景，难以支持高效的数据搜索查询和全局数据分布分析。为了解决这个问题，团队曾经考虑过将数据额外存储一份为 Parquet 格式，试图通过这种方式来实现多模态数据分析。

但这样做又带来了新的问题：Parquet 格式本身并不擅长处理多模态数据，每个部署节点都需要维护多份数据副本，系统复杂度和管理成本大幅增加。正是这些挑战促使 Rerun.io 开始与我们合作。最终，他们选择 LanceDB 作为底层数据格式，完美实现了"一箭双雕"的效果。

LanceDB 的方案能够像 MCAP 格式一样高效地存储激光雷达点云、各类传感器数据流以及图像视频等多模态数据，同时保持了极高的数据保真度。

在性能方面，LanceDB 的数据读取速度非常快速，这使得实时数据流式传输和可视化展示变得异常流畅。

LanceDB 创造性地将实时数据处理与离线分析功能融合在同一个平台中。研发团队现在可以在一个统一的系统里完成从数据注入、存储管理到训练数据探索的全流程工作。

从这些实际案例中我们可以清晰地看到，多模态数据管理面临着双重挑战：首先是数据类型的复杂性，无论是图像、视频还是长文本数据，这些都不是传统 OLAP 系统设计时考虑和优化的典型工作负载。

更深层次的挑战在于数据访问模式的根本性差异。多模态数据的查询和使用方式与传统的 OLAP 分析或时序数据库有着本质区别。

当前行业的一个普遍困境是：由于缺乏统一的数据架构解决方案，各家公司不得不投入大量资源重复构建单一用途的系统。

这种现状催生了一个典型的反模式架构：企业通常会建立一个中心数据湖作为原始数据源，然后针对不同的工作负载需求，开发各种专用的 ETL 流程，将数据推送到多个独立的专业系统中进行处理。

比如说一个很经典的场景，企业用 ElasticSearch 和向量数据库处理数据挖掘，依赖 WebDataset 等格式进行模型训练，再借助传统数据仓库完成模型评估，这样带来了巨大的开发和维护负担。

企业需要组建庞大的数据工程团队来维护多条独立的 Pipeline，每增加一个业务场景就意味着要新建一套 ETL 流程。

更严重的是，由于数据需要在多个系统间流转，各环节之间存在不可避免的同步延迟。当不同团队对数据状态的理解出现分歧时（比如有的团队使用版本 A 的数据，有的团队却在使用版本 B），就会引发一系列数据一致性问题。

LanceDB 希望能打破上一代数据湖的传统思维，能够在单一的存储介质中，同时满足数据存储、实时处理和模型训练三大需求，LanceDB 期望将这些功能整合到一个统一的体系结构中，同时保持了高度的架构开放性，能够与 Spark、Presto、Trino 等主流计算引擎无缝对接，从而大幅简化了 AI 原生的数据基础设施架构。

Lance 全新开源的数据湖是基于全新开发的 Lance format 格式。这个创新的文件格式兼具数据格式（Data Format）和表格式（Table Format）的双重特性，这与传统的 Parquet 或 Iceberg/Hudi 有着本质区别。

从数据格式的角度来看，Lance 在保持与 Parquet、ORC 等格式相当的高效存储能力的同时，还实现了更快速的数据点查能力。

而在表格式层面，最具突破性的就是 Zero-cost Data Evolution 特性，这使得在添加新列时完全不需要复制历史数据包，解决了传统方案中常见的数据迁移难题。

这些核心特性带来了诸多延伸优势。

得益于快速的数据点查能力，构建全局索引变得异常简单。在实际生产环境中，我们已经实现了每秒数千次查询（QPS）下对十亿级向量的毫秒级响应。

同时，由于采用了业界标准的 Arrow 交换格式，LanceDB 能够轻松与现有系统集成。目前我们已经完成了与 DuckDB、Daft、Spark 等系统的对接，并将持续扩展更多的生态集成。

这个创新的架构不仅解决了当前 AI 数据管理中的核心痛点，更为下一代数据基础设施的发展指明了方向。

通过将原本分散在多套系统中的功能整合到统一平台，LanceDB 在简化架构复杂度的同时，提升了整体效率，为 AI 研发提供了更加强大、灵活的数据支撑。

在接下来的 6 个月里，我们将与火山引擎团队重点推进三个方向的合作，持续增强 LanceDB 的能力。

首先在数据格式层面，我们将着重优化 Lance 格式的基础性能。这包括引入更高效的压缩算法来降低存储成本，提升写入和更新操作的性能表现。

同时，我们正在改进 Data evolution 机制，通过支持 partial schema evolution 来提供更灵活的数据结构演进能力。这些升级将推动 Lance 格式演进到 Table Format V3 版本。

其次，针对 AI 训练场景，我们将深化 PyTorch 生态的集成优化。LanceDB 与其他数据湖格式最大的差异化优势在于其卓越的数据检索性能，我们将进一步强化这一核心竞争力。

重点投入方向包括：加速索引构建过程、提升查询响应速度，以及扩展多语言支持来满足全球化市场需求。这些改进将让 LanceDB 能够更好地服务于更广泛的 AI 应用场景。

最后，我们非常重视开发者及社区生态建设，后续与火山引擎的合作也将重点推进 Catalog Service 的深度集成，包括原生支持 Iceberg Catalog 等业界标准。同时，我们计划扩展与更多计算引擎的对接，持续丰富 LanceDB 的生态系统。