从向量数据库到向量数据湖-Introduction to Vector Lake

摘要：导读本次分享围绕“Vector Lake”展开，介绍了 Vector Lake 的背景、与传统 Data Lake 的关系及其专注的向量和 AI 数据类型，详细阐述了其统一存储计算架构下对海量非结构化数据的高效管理和智能分析能力。

导读本次分享围绕“Vector Lake”展开，介绍了 Vector Lake 的背景、与传统 Data Lake 的关系及其专注的向量和 AI 数据类型，详细阐述了其统一存储计算架构下对海量非结构化数据的高效管理和智能分析能力。

主要介绍以下部分：

1. Zilliz 和 Vector Lake

2. 解决方案

分享嘉宾｜郭人通博士 Zilliz 产品总监

编辑整理｜neil

内容校对｜郭慧敏

出品社区｜DataFun

Zilliz 和 Vector Lake

当前的 AI 应用场景，绝大多数是基于非结构化数据构建的。统计显示，超过 90% 的新增数据与存量数据均为非结构化数据，涵盖文本、图像、音频、视频等多种形式。这类数据已成为现代企业数字化转型与智能化升级中的核心资产。

如何更好的存储以及管理这些非结构化数据，向量数据库是目前业内的主流选择。

自 2018 年以来，Zilliz 一直专注于向量数据库的研发，深耕向量领域已有八年时间。其最早的核心项目是全球首款开源的向量数据库 —— Milvus。目前 Milvus 在 GitHub 上的 Star 数已超过 37K，长期稳居全球开源向量数据库项目的首位。截至目前，Milvus 在全球的部署规模（以 Pod 数量计算）已超过 1 亿。

在中国市场，Zilliz 也实现了广泛的覆盖——目前涉及向量数据库的应用场景，约九成以上的企业用户在使用 Zilliz 的开源或商业版本解决方案。

通常来说，在多数中小型 AI 应用场景中，向量数据库已经足够满足存储和检索需求。但近几年，随着大模型厂商、自动驾驶企业、机器人企业以及搜索推荐系统等行业场景的快速发展，其数据规模正呈指数级增长。Zilliz 与众多头部企业客户在项目合作中不断深入，逐渐发现这些企业在业务实践中积累的数据规模已达到“数据湖”的级别。

以实际业务为例，在 2020 年至 2021 年期间，较大的业务系统单一模块所产生的数据量约为千万级别。然而到了当前，单一业务的数据规模已普遍跃升至亿级，甚至更高。业务扩张的速度远超传统数据库的承载能力。

这一趋势在多个客户案例中得到了验证。例如，某国际领先的代码类平台，其 CTO 在近期一次公开访谈中提到，企业在早期阶段曾尝试使用传统数据库级别的方案来处理底层的结构化与非结构化数据。但随着业务增长迅猛，数据库系统屡次面临扩展瓶颈，导致频繁更换底层架构。最终，在经历了三到四次数据库架构替换之后，团队意识到现有数据库体系已无法支撑当前与未来的数据增长趋势。

为应对这一挑战，多数团队最终会选择基于 S3（对象存储）构建统一的数据湖架构，将结构化、非结构化、向量化数据全部纳入统一的数据底座之上。通过这样的架构，可以更灵活地应对大规模数据存储、索引与智能检索的需求。

基于这一背景，Zilliz 在与客户的深入合作与需求打磨过程中，推出了 Vector Lake （向量数据湖）这一解决方案。我们可以视其为传统数据湖在 AI 时代的演进，新增的针对海量非结构化数据、向量数据库的管理、分析、存储、检索等功能，是其能力核心。

需要明确的是，向量数据湖并非对向量数据库的替代，而是一种针对超级客户的海量数据场景所推出的更高阶、更具扩展能力的解决方案。

1. Data lake 和 Vector lake 之间的关系

在现代数据基础设施体系中，Data Lake 与 Vector Lake 并非相互替代的关系，而是协同互补的关系。两者共同构成了支持 AI 应用和大规模非结构化数据管理的关键组件。

通常，企业业务系统在运行过程中会沉淀大量非结构化数据，包括文本、图像、视频、音频等，这些原始数据大多首先存储在 Data Lake 中。Data Lake 的主要职能是作为原始数据的存储仓库，提供高可用、高扩展、低成本的存储能力。

而 Vector Lake 并不直接面向原始数据的初级处理，其核心价值在于支持 AI 应用的数据理解与提取。也就是说，Vector Lake 主要存储的是从对 Data Lake 中的原始数据经过 AI 处理后派生出的、更具信息密度与语义聚焦的数据，然后对其做高效索引。这些数据包括但不限于：

Embedding 向量（Embedding Vectors）大模型生成的摘要（如文本总结）视频中提取的行为标签或语义描述AI 模型生成的元信息与特征信息

对这些语义层的数据做管理，构成了 Vector Lake 的核心能力。相较于直接在 Data Lake 中处理原始数据，Vector Lake 提供了更高效、更具针对性的操作方式，尤其适用于需要低延迟与高语义理解的 AI 应用场景。

以视频数据为例，直接对海量视频进行原始处理不仅在时效性上难以满足业务需求，在成本上也极为高昂。大多数企业难以承担如此高的基础设施开销。相比之下，若将视频中关键语义信息提取出来并以结构化或向量化形式存储在 Vector Lake 中进行检索，则可以大大提升数据处理效率与 AI 推理能力。

例如，在同一段视频数据中，针对不同的业务场景所需关注的信息不同。自动驾驶系统可能只关心道路元素、车辆动态与行人行为等相关信息。Vector Lake 可以针对该需求，从原始视频中管理并检索与自动驾驶相关的向量、标签与行为描述，从而构建更贴合业务目标的数据视角。

因此，Vector Lake 是对 Data Lake 数据语义层的提炼与增强，两者共同支撑起完整的 AI 数据生态，从底层数据存储到上层智能分析，实现高效联动。

在实际业务应用中，Data Lake 与 Vector Lake 的协同能力可以通过自动驾驶这一典型场景加以说明。

在自动驾驶领域，车辆在行驶过程中会产生大量多模态原始数据，包括车载摄像头采集的视频、定位传感器数据、制动与加速等控制信号。这些原始数据首先被沉淀至 Data Lake 中，完成海量信息的初步存储。此类数据来自于部署在公共道路上持续运行的大量车辆，它们会实时将数据上传至企业数据中心，形成一个规模庞大的数据矿。

而自动驾驶业务的核心挑战并非是如何处理所有正常行驶数据，而是如何从中挖掘出极其稀有的“长尾场景”，如万分之一甚至十万分之一概率的特殊情况。企业需要识别这些罕见事件，验证模型是否能在这些极端情况下做出正确响应，并基于此优化模型表现。

在此过程中，Vector Lake 的价值被显著体现。企业通常会对视频数据进行语义层面的提取，分为静态帧和动态行为两类处理方式：

动态行为分析：通过大模型（随着模型成本的下降，这类处理变得更加可行），自动对视频行为进行识别与抽象。例如，一段视频中记录了车辆先在昏暗隧道中行驶，突然驶出后遇到强烈光线变化，前方出现缓慢行驶的洒水车或工程车辆。系统需要判断车辆是否及时制动或变道超车等。这类行为信息通过大模型提取为结构化描述，并生成相应的文本、标签和 embedding 向量，统一被 Vector Lake 所管理。

静态图像帧分析：视频会被切分为静态帧，系统识别每一帧中的目标对象，并为每个对象赋予标签、向量等语义信息，构建面向业务语义的描述层。

所有这些经过提取的信息，都是业务所关注的内容。在海量原始数据中，用户希望挖掘的是模型表现尚未充分覆盖的长尾区域。基于 Vector Lake 的索引与分析能力，可以以显著更低的成本与更高的效率，定位这些关键数据场景，从而支撑后续模型训练与迭代优化。

相较直接在 Data Lake 的原始视频数据层面进行处理，Vector Lake 通过聚焦语义数据层显著提升了处理效率，成为自动驾驶数据基础设施中的关键组成部分。

2. 数据流

首先数据遵循传统的数据处理流程，包括数据清理、去重、预处理等基础工作。这一阶段主要负责保证原始数据的完整性和质量，为后续深度分析打下基础。

随后，数据从 Data Lake 进入到语义提取环节，在此过程中，基于 AI 技术对原始数据进行理解和加工，将海量的非结构化数据转换为语义聚焦的结构化信息。

经过语义提取后，数据进入 Vector Lake，这里聚焦于管理 AI 应用的特定数据类型，如向量（vectors）、标签（tags）、文本的关键描述（key textual descriptions）、元信息（metadata）等。这些数据构成了业务迭代和智能分析的核心基础。

解决方案

Data Lake 和 Vector Lake 并不是两套完全独立的系统。从存储和计算的基础设施角度来看，它们共享同一套架构。在存储方面，主要有三类数据：

原始的非结构化数据面向 AI 的向量及相关数据类型索引数据

这些数据都统一组织在类似 Iceberg、S3 这样的对象存储系统中，形成统一的数据管理体系。

在计算层面，目前主流的框架如 Spark 和 Ray 等被广泛采用，用来支持对向量数据的处理。向量索引通常会进行分片管理，查询时则采用类似 MapReduce 的方式，分别在各个索引分片上并行执行用户查询，最终将结果汇总返回。随后，系统会基于这些召回的数据执行更复杂的业务逻辑处理。

整个技术框架主要解决两个核心问题：一是大规模数据的处理，二是复杂任务的处理能力。针对大规模问题，系统通过分片和多路召回的机制，将数百亿规模的数据快速过滤到几万甚至几十万条的候选集。这样，后续在较小规模数据集上进行复杂的重排序和筛选操作，成本和效率都处于可控范围内。

通过这种设计，既保证了面对海量数据时的检索效率，也支持了针对复杂业务需求的深度分析和处理，充分满足 AI 应用对数据处理的双重需求。

向量数据湖并不仅仅局限于处理向量数据。如今的趋势是，许多传统数据库或数据湖解决方案都开始融合新的 AI 数据类型，而向量数据库或数据湖在此基础上，也会继续支持传统的数据类型，比如数值型数据和 JSON 格式的数据。这些不同类型的数据混合存在，主要是为了帮助用户构建更加复杂和多样化的查询能力。因为在实际应用中，查询往往不仅仅依赖于向量数据，而是需要结合各种数据类型综合分析，才能满足业务需求。