Vector Lakebase专业评测：340GB索引压至13GB成本仅1/15

信息图封面：Vector Lakebase 核心要点

有个做自动驾驶的客户，数据湖里存了10亿条768维向量——摄像头帧、驾驶场景、天气、位置等元数据。每天真正需要在线查询的时间，其实只有大约20分钟。但为了这20分钟，他得养一组Long-running集群，每月烧掉将近7,000美元。

这可不是孤例。AI数据架构里藏着一个挺普遍的结构性矛盾：在线检索和离线分析，活像两个世界里的生物。向量数据库擅长低延迟查询，但数据进去就出不来；数据湖批量分析一把好手，却连个像样的向量索引都没有。

Zilliz的Vector Lakebase就是冲着这个矛盾来的。它不是简单的“向量数据库 + 数据湖”拼凑，而是一套统一的、湖原生的AI数据基础架构，试图让在线服务和离线发现围绕同一份数据转起来。

截至2026年6月，Vector Lakebase仍处于Public Preview阶段（官方未公布GA日期）。这篇文章基于Zilliz官方博客、CTO栾小凡和VP Product郭人通的公开文章，以及Milvus社区公开资料整理，来拆解它的技术思路。

1. 从向量数据库到Vector Lakebase：一条怎样的演进路径？

要理解Vector Lakebase，不妨先看Zilliz CTO栾小凡画的一条历史类比线：

移动互联网时代，数据基础设施经历了三代演进——MongoDB解决半结构化数据存储，Snowflake/Redshift解决分析需求，Lakehouse（Databricks/Iceberg/Hudi）把OLTP和OLAP统一到同一架构下。

AI时代正在经历类似的演进。向量数据库（如Milvus、Pinecone）解决的是AI的语义检索问题，相当于当年的MongoDB。但AI系统正在从静态助手演变为持续运行的Agent，企业需要的不仅是检索，还有聚类、去重、重嵌入、离线评估、模型微调数据准备等发现能力。

Vector Lakebase想做的，就是AI时代的Lakehouse——把在线服务（Serving）和离线发现（Discovery）统一起来。

这里有个关键点：向量数据库不会消失。正如OLTP数据库在Lakehouse时代没有被替代，而是成为架构栈中的一层，向量数据库在Vector Lakebase中会成为内部的服务引擎（serving engine）。Milvus 3.0 beta已经包含了新的Loon存储引擎，就是这条路线在开源侧的落地。

向量搜索架构三代演进

图：从向量数据库到Vector Lakebase的架构演进

2. CS/CD飞轮：不只是检索，而是持续改进数据

Vector Lakebase的核心理念叫CS/CD（Continuous Serving / Continuous Discovery），这个缩写明显是借用了CI/CD的概念。

Serving层做的是我们熟悉的事：高吞吐写入、低延迟检索，支撑在线RAG、推荐、个性化、AI记忆、实时Agent。这部分是向量数据库的老本行。

Discovery层做的事情就不一样了：聚类、去重、重嵌入、离线评估、质量分析、模型微调准备、Agent轨迹分析。这些操作在传统向量数据库里基本做不到，或者得把数据导出来到Spark/Ray里跑。

关键在于，两者形成了一个飞轮：Serving产生反馈和新数据 → Discovery分析和改进数据 → 改进后的数据回流到Serving。这个循环如果跑不起来，AI系统就永远是个查询工具，而不是持续改进的系统。

说实话，这个理念本身不算新鲜——数据飞轮的概念很多公司都在讲。但Vector Lakebase的意思是：如果你得在向量数据库和数据湖之间来回搬数据，这个飞轮根本转不起来。所以核心问题回到了架构层面。

3. 一份数据，三种计算：架构拆解

Vector Lakebase的架构可以简化为三个层次：

存储层：基于Loon存储引擎和Vortex开放格式的统一湖存储。所有数据（向量、标量、文本、JSON、地理空间）存在一张湖表里，底层是S3对象存储。

索引层：索引不再是某个引擎的内部资产，而是湖级资产（lake-level asset）。向量索引、倒排索引、JSON索引都可以独立构建、版本化、跨不同计算模式复用。

计算层：三种计算模式按需激活：

这种设计的直接好处是资源跟着数据走，而不是跟着租户走。传统架构里，100万个租户就需要100万组计算资源。Vector Lakebase的控制平面通过共享Coordinator、Catalog替代etcd、WAL直写S3（官方数据：750 MB/s，5.8倍于Kafka），把控制平面的复杂度从O(N)降到O(1)。官方给出的数据是：100万租户中通常只有1%同时活跃，意味着99%的数据零计算成本。

Vector Lakebase五层架构图

图1：Vector Lakebase分层架构：控制平面 → 计算层（三种模式） → 索引层 → 存储层 → S3

4. Loon存储引擎：混合格式 + 行ID对齐

Loon是Milvus和Vector Lakebase的新存储引擎，Principal Engineer Ted Xu在官方博客里详细讲了设计思路。它面对的是三个绕不开的问题：

问题一：长列导致写放大

AI数据的列比传统分析表大得多。TPC-H lineitem行约150字节，但768维fp16向量行就有1.5 KB，3072维fp32向量（如text-embedding-3-large）光向量就约12 KB。如果要给1亿行数据加一个1024维fp32嵌入列，光原始向量数据就有约400 GB。用传统方式重写整行？太慢了。

问题二：同一数据需要扫描和点查

分析负载需要宽的、压缩的扫描（Parquet擅长），ANN结果需要窄的、行级查找（Parquet不擅长）。混合搜索一次查询可能同时需要两种模式。

问题三：数据集不只存在于一个引擎

AI数据管道横跨Spark、Ray、GPU服务、LLM推理管道。私有存储格式意味着真相的多份拷贝。

Loon的三个设计决策

混合文件格式：标量字段用Parquet（扫描/过滤/生态兼容），密集向量和稀疏向量用Vortex（低延迟随机访问），原始对象（视频/PDF/图片）留在对象存储，数据库只存引用。

行ID对齐：每个物理ColumnGroupFile记录路径和行ID范围（start_index / end_index），不同ColumnGroup可以覆盖同一行ID空间，即使在不同文件和不同格式中。这意味着添加新的embedding_v2不需要重写原有的caption、元数据或embedding_v1。

Manifest版本化：用Apache A vro编码的Manifest包含ColumnGroups / DeltaLogs / Stats / Indexes四个板块，支持乐观并发提交。外部引擎（Spark/Ray）可以生成新的ColumnGroup并提交Manifest。这个思路和Iceberg/Delta Lake类似，但对象模型更广泛。

官方给出的基准测试数据（8 vCPU，本地文件系统，4万行128维向量）：

有意思的是Vortex在压缩比上也没吃亏——反而比Parquet小7%，点查还快25倍。原因是它不强制行组结构，布局完全可配置，支持Delta → RLE → BitPacking嵌套编码，压缩数据上就能直接做点查。

5. 两项关键优化：Vortex读取和RaBitQ量化

Vortex：135倍减少S3读取

Parquet的64 MB row group在S3场景下是个大问题。如果你只需要读一条3 KB的记录，得先把64 MB的row group整个拉下来——大约20000倍的I/O浪费。

Vortex的做法是把每次S3读取量从Parquet的9.44 MB压到0.07 MB，减少135倍下载流量，而且没有IOPS惩罚。官方基准测试（3M行128维向量，S3存储，256并发）的关键数据：

全扫描吞吐是Parquet的2.4倍。Vortex是Linux Foundation托管的开放格式，不是Zilliz的私有格式——这一点对避免厂商锁定很关键。

RaBitQ：340 GB压到13 GB，冷启动5秒

RaBitQ来自SIGMOD 2024论文（Gao & Long），核心是1 + 3 bit嵌套量化——类似俄罗斯套娃的结构。1-bit层提供可证明的误差边界，用于粗过滤；3-bit层后台下载，用于精排，召回率可达95%以上。

在Zilliz的实际应用中：340 GB的HNSW索引经1-bit压缩后仅13 GB，冷启动时间从4分钟以上降到5-10秒。再配合IVF聚类剪枝，每个查询只扫描约3%的数据，最终每次查询只需约400 MB。

RaBitQ不是只有Zilliz在用。faiss v1.11.0已经集成了RaBitQ；Elastic/Lucene正在实验它作为更高量化级别的方案（GitHub issue #13650）；阿里云RDS PostgreSQL中的pgvector也引入了RaBitQ量化。Elastic团队的实验还发现：在相同压缩比下，RaBitQ的召回率等于或优于Product Quantization，量化速度快20-30倍。

Vortex vs Parquet vs Lance基准测试对比

图2：Vortex vs Parquet vs Lance基准测试对比——点查吞吐、S3读取量、全扫描吞吐

6. 分层服务与成本优化

Vector Lakebase提供三种服务层级：

三个层级共享同一份数据，区别在于缓存命中率和计算资源配比。分层存储层官方给出的缓存命中率>95%，这意味着大部分请求不会穿透到S3。

但更值得关注的是On-Demand Search。这是为大规模、低频查询场景设计的计算模式，按分钟计费，空闲时零成本。

回到开头那个自动驾驶客户的例子：10亿条768维向量，每天只需约20分钟在线查询。

Long-running模式：约$7,000/月
On-Demand模式：约$500/月

省了93%。

另一个对比数据更有说服力：同样是10亿向量768维、月累计10小时活跃计算的场景，Serverless模式要$4,937/月，On-Demand只要$318/月——大约是Serverless的1/15。差距的核心在于Serverless按数据量和空闲计算收费，On-Demand只按实际计算时间收费。

你的场景是低频查询还是高频常驻？这个选择对成本影响巨大。

10亿向量场景成本对比

图3：10亿向量场景成本对比——Long-running $7,000 → On-Demand $500（省93%）、Serverless $4,937 → On-Demand $318（1/15）

7. External Collection：不搬数据，直接搜

External Collection解决的是一个很实际的问题：很多公司的数据已经存在Iceberg/Lance/Parquet格式的数据湖里，搬不搬？

传统做法是把数据ETL到向量数据库里。问题是：数据冗余、同步延迟、还需要维护两套系统。

Vector Collection的做法是零拷贝逻辑映射。它在外部数据之上构建独立的索引层（向量索引、倒排索引、JSON索引），原始数据留在客户现有平台。支持增量同步。

官方的原则是One Data. One Index.——数据不搬家，索引跟着数据走。支持的湖表格式包括Lance和Iceberg，开放数据格式包括Parquet和Vortex。

不过，当前资料中未发现External Collection的具体性能数据和增量同步延迟数据，因此不做推断。如果同步延迟对你的场景很敏感，建议直接向Zilliz确认。

8. Full-Spectrum Search：不只是向量检索

Vector Lakebase把自己定位为全谱检索（Full-Spectrum Search）平台，不仅限于向量相似度搜索。它支持：

向量检索（稠密 + 稀疏向量）
全文搜索（BM25索引，支持短语查询、前缀匹配、模糊匹配、多种分词器）
JSON查询（JSON shredding索引）
地理空间搜索
多向量搜索
多路径检索和重排序

重排序器支持Cohere、Voyage AI、Boost、Decay、RRF、Weighted等方案。宽表建模让每个application-level entity映射为单行，支持稠密/稀疏向量、文本、JSON、地理空间数据混合存储。

默认召回率在95%-98%之间，可调优至90%-99%。Schema evolution支持1亿行数据回填在个位数分钟内完成（由平台侧共享计算资源处理）。Global Cluster提供99.99% uptime SLA。

这些指标看着漂亮，但要泼一盆冷水：这些都来自官方数据，Vector Lakebase目前仍处于Public Preview，还没有生产环境的大规模验证案例。

9. 和现有架构比，差异在哪？

Zilliz官方把向量搜索架构分为三代：

一个制药客户的实际数据能说明问题：分子相似性搜索中，Spark暴力扫描比IVF索引检索慢约1000倍。还有一组去重性能数据：10亿向量的近重复检测，用ANN逐条搜索需要70小时，用Offline Batch Job只需10小时。

那Vector Lakebase和Databricks Lakebase是什么关系？Zilliz官方明确说是互补而非竞争：

Databricks Lakebase解决的是结构化数据的OLTP/OLAP统一，Vector Lakebase解决的是非结构化数据的在线服务/离线发现统一。两者面对的是不同的问题域。

不过有一个信息缺口：当前资料中没有Vector Lakebase与其他向量数据库（Pinecone、Wea viate、Qdrant）的直接性能对比数据，也没有Vortex格式的独立第三方基准测试。如果这些数据对你的选型很关键，建议关注后续社区评测。

向量搜索架构三代演进对比

图4：向量搜索架构三代演进——Gen 1向量数据库 → Gen 2向量湖 → Gen 3 Vector Lakebase

10. 什么场景该考虑Vector Lakebase？

根据官方给出的使用场景和案例，以下几类团队可能值得关注：

适合的场景：

数据规模达到十亿级，既有在线检索又有离线分析需求（如自动驾驶、基础模型训练、制药）
当前在向量数据库和数据湖之间做ETL，数据同步成为瓶颈
低频查询场景下成本敏感（On-Demand模式的成本优势明显）
需要对向量数据做聚类、去重、重嵌入等批量操作
数据已经存在Iceberg/Lance格式的湖里，不想搬迁

可能还不适合的场景：

数据规模在千万级以下，纯在线检索——这种场景用Milvus或其他向量数据库就够了
需要OLTP事务能力——这是Databricks Lakebase的领域
对生产稳定性要求极高——Vector Lakebase目前还在Public Preview

还有几个当前无法确认的点（官方资料中未给出）：具体定价细节和计费模型、Loon在Milvus 3.0开源版中的功能范围与Zilliz Cloud商业版的差异、External Collection的增量同步延迟。

总结

Vector Lakebase的核心思路很清晰：一份数据，一个索引，多种计算模式。它不试图替代向量数据库，而是把向量数据库变成更大架构栈里的一层服务引擎。

技术栈上有三个亮点值得持续关注：Loon的混合文件格式和行ID对齐解决了存算分离后的写放大问题；Vortex开放格式把S3点查的I/O放大压了两个数量级；RaBitQ量化让冷启动从分钟级降到秒级。

但话说回来，这些数据目前都来自Zilliz官方。Vector Lakebase要证明自己，还得靠生产环境的验证和第三方基准测试。External Collection的实际性能、增量同步的可靠性、大规模多租户下的稳定性——这些都需要时间来回答。

Milvus作为全球42k+ GitHub Stars的开源向量数据库，Zilliz Cloud已服务10,000+组织，这个社区基础是Vector Lakebase的底气。但湖原生AI数据平台这个赛道才刚刚开始，Databricks、Snowflake都不会袖手旁观。

赌这个方向是对的——AI数据架构的下一站，大概率就是湖原生。但谁是最终的赢家，现在下结论还太早。

来源：互联网