当“数据湖仓”概念在2020年首次被提出时，其目标是在单一架构中统一数据仓库和数据湖：在廉价的对象存储上使用开放格式，内置ACID事务、模式强制、治理、BI支持和流处理。其承诺很简单：用一个系统支持SQL分析、数据科学和机器学习，而不是在数据湖、数据仓库和专门存储之间来回迁移数据。该设计假设大多数工作负载从根本上仍是表格化的，即使处理日志或半结构化JSON时也是如此，并且主要消费者是分析业务，而非AI模型服务。
多模态AI挑战了这些假设。现代系统融合了文本、图像、视频、音频、传感器流和非常大的嵌入向量。数据行不再是千字节级；它们可能达到兆字节或更多。访问模式不再是“每天扫描一次表”，而是“每秒获取数千个随机片段或向量，持续更新标签，并且在为GPU供给数据时绝不使其空闲”。Parquet等传统格式和Iceberg等表层在这些条件下举步维艰：它们为批处理分析而构建，而非为低延迟、可变更、向量密集型的工作负载设计。为了防止回归到孤岛式架构——团队需要维护独立的向量数据库、搜索引擎和对象存储——各团队正在重新审视湖仓概念。
从批处理分析到随机访问：Lance格式内幕
Lance是一种专门为AI工作负载而非传统商业智能设计的列式数据格式。虽然Apache Parquet等传统格式针对顺序扫描（如聚合销售数据）进行了优化，但它们在现代机器学习管道中造成了显著的I/O瓶颈。深度学习任务，如训练数据混洗或检索增强生成（RAG），需要对特定行进行高性能的随机访问，而传统格式难以高效支持这种模式。
Lance通过将嵌入向量、媒体引用（指向视频、音频或图像的指针）和结构化元数据统一在一个单一模式中来解决这个问题。它将搜索功能直接集成到存储层，以最大限度地减少数据传输。通过首先对轻量级属性进行过滤，确保仅在绝对必要时才检索大文件（如图像或视频）。这种架构带来了显著的性能提升；基准测试表明，与Parquet相比，Lance实现了3到35倍的随机读取速度提升和高达10倍的向量查询速度提升，通常消除了对外部索引服务的需求。
“从BI到AI：使用Lance和Iceberg的现代湖仓栈”
这种统一性也体现在存储栈中。在传统的湖仓设置中，团队通常组合三个独立的组件：列式文件格式（如Parquet）、表格式（如Iceberg或Delta Lake），以及用于跟踪表的外部目录定义。Lance同时涵盖了这三个规范层：它定义了数据如何在单个文件中存储，这些文件如何组织成逻辑表，以及一个用于定位表的轻量级命名空间机制。由于该结构被捕获在一个单一、连贯的格式中，相同的Lance表可以注册到不同的目录服务，并由多个计算引擎访问，而无需更改底层数据。
至关重要的是，Lance解决了数据可变性的操作挑战。修改Parquet数据集通常需要昂贵的重写，而Lance则利用Delta风格的日志和分层的磁盘布局。这支持流式插入、列追加和删除，并具有自动压缩功能，确保了高读取性能，同时支持基于快照的版本控制和对于模型可复现性至关重要的“时间旅行”查询。
多模态数据湖仓的崛起
LanceDB将Lance格式提升为多模态数据湖仓，这是一个旨在整合复杂数据类型（包括视频、音频、3D模型和嵌入向量）以及传统表格记录的架构范式。这种方法与标准数据湖模型不同，它将媒体和向量嵌入视为核心组件，而非辅助附件。通过将向量搜索与存储引擎紧密耦合，该系统消除了对外部索引服务的需求，实现了高效的混合查询，例如通过元数据约束过滤语义结果（例如，“检索在过去一小时内创建的相似视频片段”）。
在保留传统湖仓可扩展性和对象存储经济性的同时，该系统针对AI原生工作流（如RAG和模型训练）进行了重新设计。关键区别包括：原始资产和嵌入向量的共置以最小化延迟；允许训练和服务访问同一存储而无需复制的“零拷贝”管道；以及对流式更新的支持——这是动态生产环境的必要条件。
多模态数据湖仓已在生产中使用，其采用凸显了两个主要驱动因素：性能优化和基础设施整合。
- 性能优化： 某中心从Parquet迁移到LanceDB，以统一视频帧和元数据，解决了媒体分析所需的高频访问模式中的瓶颈。同样，生成式视频初创公司Runway采用该平台，以防止训练期间GPU空闲；该格式的随机访问能力允许高效的流式处理和实时数据增强，而无需重写海量数据集。
- 基础设施整合： 对于AI代码审查工具CodeRabbit而言，迁移是出于操作考量。他们用单个LanceDB实例取代了由Pinecone（用于向量）和PostgreSQL（用于元数据）组成的碎片化技术栈，在降低复杂性的同时，实现了对代码片段的混合搜索。同样，某中心和TwelveLabs利用该平台聚合来自不同模态的嵌入向量，创建了用于音频和视频内容的统一语义搜索引擎。
多模态AI打破了传统数据湖的假设：数据行变得庞大，访问是随机的，而GPU无法等待批处理时代的存储。
其他多模态数据管理系统
LanceDB并非孤立存在。为多模态AI定义数据基础设施的竞赛催生了其他架构，每种架构都针对延迟、吞吐量或工作流编排中的特定瓶颈。
- Magnus（字节跳动）： 为大型推荐模型所需的艾字节级规模设计，Magnus将向量索引和倒排索引直接集成到数据湖中。它引入了专门的“Blob格式”来处理媒体文件，并针对机器学习中常见的“宽表”进行了优化，允许通过SQL进行复杂检索，而无需依赖外部向量数据库。
- Deep Lake 4.0（Activeloop）： 该平台旨在解决存储和训练框架之间的摩擦。通过为PyTorch和TensorFlow提供零拷贝数据加载器，Deep Lake允许模型直接在远程数据集上进行训练。其理念是将“数据视为代码”，结合版本控制和CI/CD集成，以确保端到端管道的可复现性。
- Pixeltable： Pixeltable将AI管道重新构想为一个数据库问题。它采用声明式界面，将转换（如视频转录或嵌入向量生成）定义为模式内的“计算列”。基于PostgreSQL和pgvector构建，它自动化了依赖关系跟踪和增量更新，显著减少了对定制编排代码的需求。
- Daft + Unity Catalog： Daft是一个基于Rust的分布式查询引擎，专为多模态工作负载设计。当与Databricks的Unity Catalog配对时，它通过动态流式执行来防止内存过载，从而应对“数据膨胀”的挑战（例如，从URL解码数百万张图像），同时还管理GPU资源调度。
这些系统与LanceDB方向一致：统一处理多模态内容、向量搜索和表格元数据。区别在于打包方式和侧重点——内部与开源、侧重于训练与服务于服务、或更倾向于编排与存储格式。
与PARK栈的协同
总而言之，Lance（格式）和LanceDB（多模态湖仓）正在成为一个成熟且经过验证的平台，适用于那些希望为多模态AI获得通用数据层的团队。其核心是开源的，通过社区模式管理，并已部署在媒体、开发者工具和生成式AI产品等高要求环境中。对于大多数团队来说，主要的架构问题是“多模态湖仓如何适应我的AI平台的其余部分？”
一个有用的视角是PARK栈：PyTorch、前沿AI模型、Ray和Kubernetes。Lance和LanceDB的作用是作为该计算栈下的多模态存储和检索基础。PyTorch和基础模型负责学习和推理。Ray编排异构工作负载——CPU用于元数据转换，GPU用于嵌入向量计算或视频解码——而Kubernetes提供集群级资源管理。LanceDB位于下方，作为存储原始媒体、嵌入向量和特征的地方，Ray Data或类似库在训练和服务管道中读取和写入Lance表。这已经在实践中得到体现：LanceDB与Ray有原生集成，可在集群中分发查询和向量工作负载，并且其设计假设了对象存储和计算分离。
对于AI团队来说，实际的启示是，您可以将开源计算（PARK）与开放的多模态存储层（Lance + LanceDB）以及在必要时使用专门的引擎相结合。正如某中心最近展示的那样，这种模块化方法允许团队利用Ray进行弹性批处理推理，利用LanceDB进行零拷贝数据演进，从而能够高效地管理和查询PB级的多模态数据集，而无需传统数据湖的开销。
