Lance：面向多模态 AI 的开放 Lakehouse 数据格式

当 Parquet 遇上向量搜索：一个数据工程师的"最后一公里"困境

2023年，张明（化名）所在的公司完成了 AI 中台建设：大模型训练平台、特征工程流水线、向量数据库都已就位。然而，当团队试图用真实的业务数据构建检索增强生成（RAG）系统时，一个意想不到的瓶颈出现了——数据加载。

Parquet 文件无法高效支持随机读取，每次查询都要完整扫描数 GB 的数据集；向量数据库里的 embedding 与原始图片、文本分别存储，跨模态联合查询形同噩梦；数据版本管理靠手动快照，新版本上线如履薄冰。

这不只是张明一个人的困境。随着 AI 应用从实验走向生产，数据基础设施正在经历一场范式转移：Lakehouse 不再只是"存储层"，它必须成为 AI 工作流的"第一等公民"。正是在这样的背景下，Lance 诞生了。

开源新星：Rust 写的 Lakehouse 格式，凭什么出圈？

Lance 由 lance-format 组织开发和维护，是一个用 Rust 编写的开放湖仓格式，专为多模态 AI 工作负载设计。它不只是一个文件格式，更是一套包含文件格式、表格式和目录规范的完整解决方案。

项目于 2022 年底正式开源，短短两年时间已在 GitHub 积累近 7000 颗星，Python SDK（pylance）发布 PyPI 后迅速获得数千日均下载量。核心贡献者来自数据基础设施领域，项目采用 Apache-2.0 许可证，企业友好。

核心技术亮点

1. 混合检索：向量 + 全文 + SQL，一套数据三种玩法

Lance 内置了向量相似度搜索（IVF_PQ、HNSW、DiskANN 等 ANN 算法）、BM25 全文检索和 SQL 联表查询能力。不同于传统方案需要维护独立的向量数据库，Lance 让用户在同一份数据集上自由组合检索策略：

# 向量最近邻查询
results = dataset.to_table(nearest={
    "column": "vector",
    "k": 10,
    "q": query_embedding
})

# SQL 条件过滤
import duckdb
filtered = duckdb.query(
    "SELECT * FROM dataset WHERE category = 'electronics' LIMIT 100"
).to_df()

2. 随机读取快 100 倍：告别全表扫描

传统列式存储（Parquet/Iceberg）为顺序扫描优化，随机读取性能糟糕。Lance 通过列式索引和优化数据布局，在 SIFT-1M 数据集上实现平均查询延迟 <1ms（M2 MacBook Air，实测数据）。对于需要频繁采样、筛选的 ML 训练流程，这是质的飞跃。

图：SIFT-1M 数据集上向量搜索平均延迟，均值 <1ms

3. 原生多模态：图片、视频、音频、embedding 一体存储

Lance 的数据模式支持将原始二进制数据（图片、视频）与向量 embedding 放在同一张表中，通过 blob 编码高效存储，访问时按需懒加载。这意味着构建多模态 RAG 系统不再需要 ETL 流水线——原始数据和向量索引天然共存。

4. ACID 版本控制：零基础设施的数据"时光机"

内置数据版本管理，支持时间旅行、分支和标签。与 Delta Lake/Iceberg 不同，Lance 的版本控制是零拷贝的，数据以追加方式存储，历史版本共享底层数据块，大幅降低存储成本。ML 训练需要回滚到特定数据版本时，无需重建快照。

5. 生态集成：Arrow 生态全覆盖

Apache Arrow → Pandas → Polars → DuckDB → Spark → Ray → Trino → Apache Flink，几乎覆盖了数据科学生态中所有主流工具链。Python 用户只需 pip install pylance 即可接入：

import lance

# 2行代码从 Parquet 转换
parquet_ds = pa.dataset.dataset("/data/sales.parquet")
lance.write_dataset(parquet_ds, "/data/sales.lance")

# 之后直接读取
ds = lance.dataset("/data/sales.lance")
df = ds.to_table().to_pandas()

技术架构：Rust monorepo + 多语言绑定

项目采用 Rust workspace monorepo 结构：

模块	职责
lance-encoding	列式数据编码与压缩
lance-index	向量索引（ANN 算法实现）
lance-io	对象存储（S3/Azure/GCS）IO
lance-linalg	线性代数运算（向量距离等）
lance-file	Lance 文件格式读写
lance-datagen	测试数据生成器
python/	PyO3 实现的 Python bindings
java/	JNI 实现的 Java bindings

Rust 核心保证了底层性能，PyO3/JNI bindings 让各语言用户零门槛使用。多语言 SDK 的维护是一个挑战，但项目通过清晰的 AGENTS.md/CLAUDE.md 规范保持了较高的协作效率。

上手体验：门槛低，但深度学习有挑战

安装部署：⭐⭐⭐⭐⭐（极简）

pip install pylance

一行命令完成安装，PyPI 分发，无额外依赖。对比 Milvus、Pinecone 等向量数据库需要启动独立服务，Lance 的"嵌入式"设计让本地开发和生产部署都极其轻量。

文档质量：⭐⭐⭐⭐⭐（优秀）

官方网站 lance.org 提供完整的文档、迁移指南、格式规范和 API 参考。benchmark 数据透明可复现（使用 SIFT/DBpedia 等公开数据集）。项目维护者响应积极，Discord 社区活跃。

二次开发：⭐⭐⭐⭐（较好）

Rust monorepo 结构清晰，模块边界明确，lance-encoding/lance-index 等核心模块独立可测试。但 Rust 类型系统陡峭，ANN 算法实现涉及较多领域知识（如 Product Quantization 的 codebook 训练），深度定制需要投入时间。

性能调优：⭐⭐⭐⭐（良好）

create_index 的 num_partitions（IVF）和 num_sub_vectors（PQ）是关键参数，项目在 benchmark 目录提供了 sift/dbpedia/bigann 等场景的参考配置。但参数自动调优功能尚未成熟。

局限与挑战：不能做什么？

1. 不适合超大规模纯 OLAP 场景

Lance 的随机读取优化针对 AI/ML 工作流设计，对于 TB 级别的纯 SQL analytics（无向量检索需求），Parquet on Spark 或 ClickHouse 仍是更成熟的选择。

2. ANN 的精度-性能 trade-off 是固有局限

所有向量索引均为近似最近邻（ANN），在极端 recall 要求场景下，暴力全量扫描仍是金标准。Lance 提供了 IVF_PQ / HNSW / DiskANN 等多种算法选择，但"最佳参数"因数据分布而异。

3. 生态仍在快速演进

项目活跃度高是好消息，但也意味着 API 尚未完全稳定。虽然文件格式有长期兼容性保障，SDK API 仍遵循 semver 迁移规则，大版本升级需要关注迁移文档。

4. 缺少官方托管服务

对比 Weaviate、Qdrant 等有云托管版本的向量数据库，Lance 目前是纯开源方案，企业级运维工具链（如监控、备份策略、多租户隔离）需要自建。

行业意义：Lakehouse 的 AI 原生化

Lance 的出现折射出一个更大的趋势：AI 应用正在反向塑造数据基础设施。

传统数仓 → Lakehouse（Delta Lake/Iceberg）→ AI-native Lakehouse 的演进路径已清晰可见。Lance 所代表的"嵌入式向量能力"路线，与 Qdrant/Milvus 等独立向量数据库路线，是两条互补的技术选择——前者适合已有成熟数据湖的团队，后者适合从零构建检索能力的场景。

截至 2025 年，Lance 已与 Apache Polaris、Unity Catalog、Apache Gravitino 等开放目录系统集成，数据治理能力逐步完善。随着多模态 AI 应用持续爆发，能原生支持图文音视混合存储与检索的 Lakehouse 格式，将在未来 AI 数据栈中占据关键位置。