Colección Externa de Milvus: Indexa y Recupera Datos Residentes en el Lago Sin Moverlos

En muchos pipelines de IA, los embeddings y los metadatos ya se producen y almacenan en un data lake. Un pipeline de productos podría escribir atributos de producto y embeddings multimodales en archivos Parquet en S3. Un corpus de recuperación o entrenamiento podría vivir en una tabla Iceberg o Lance. El lake ya es el lugar donde estos conjuntos de datos se generan, actualizan, versionan y utilizan por el resto del stack de datos.

Las bases de datos vectoriales, sin embargo, se han construido tradicionalmente en torno a una copia de servicio propiedad de la base de datos. Si los equipos querían búsqueda vectorial de baja latencia sobre datos ya ubicados en un lake, generalmente tenían dos opciones:

• Copiar los datos en una base de datos vectorial. Esto proporciona índices ANN y una ruta de servicio de producción, pero crea una segunda copia del conjunto de datos y un pipeline ETL que debe mantenerse sincronizado con la fuente.
• Consultar el lake directamente. Esto evita la duplicación, pero sin una capa de indexación y servicio ANN, la búsqueda vectorial recurre a escaneos que no están diseñados para la latencia de producción.

Milvus 3.0 External Collection introduce una tercera vía. Los datos fuente permanecen en Parquet, Iceberg, Lance, Vortex u otro formato externo compatible, mientras Milvus construye y sirve índices sobre ellos. Mapeas los campos externos en un esquema de Milvus, defines los índices que necesitas, refrescas la colección y usas las API normales de búsqueda y consulta de Milvus, sin copiar primero las filas fuente a una colección gestionada por Milvus.

El cambio arquitectónico es sencillo: los datos pueden permanecer en el lake, mientras Milvus añade la capa de indexación y recuperación.

Eso también convierte a External Collection en un paso importante hacia Vector Lakebase, una arquitectura de datos unificada y nativa del lake para IA que combina el servicio de grado de base de datos vectorial con almacenamiento abierto en lake, índices reutilizables a nivel de lake y una capa semántica compartida. La recuperación en línea ya no tiene que partir de una copia de servicio separada mientras Spark, los pipelines de entrenamiento, los trabajos de evaluación y las herramientas de gobernanza operan sobre otra versión de los datos. Pueden trabajar desde la misma capa de datos residente en el lake.

Qué es una External Collection y qué cambia

Una External Collection es un tipo de colección de Milvus cuyos datos fuente viven fuera del almacenamiento gestionado por Milvus.

Sin una External Collection, poner ese catálogo detrás de la búsqueda vectorial de producción normalmente significa crear otra copia en Milvus:

Cada vez que el catálogo cambia, el modelo de embeddings cambia o un campo se rellena retroactivamente, otro pipeline tiene que mover los datos actualizados a través de ese límite.

Con External Collection, la arquitectura se convierte en:

Milvus no convierte los archivos externos en su propia copia de datos fuente. En cambio, la External Collection contiene la información que Milvus necesita para interpretarlos y buscarlos:

1. Un external_source que identifica los archivos o tabla externos.
2. Un external_spec que describe el formato de la fuente y el acceso al almacenamiento.
3. Mapeos de external_field que conectan campos del esquema de Milvus con columnas del conjunto de datos externo.
4. Los índices, manifiestos y estado de servicio que Milvus crea para la recuperación.

Que los datos fuente tengan cero copias no significa que no haya estado dentro de Milvus. Milvus sigue construyendo índices. Sigue usando cómputo. Sigue almacenando en caché. El cambio es que las filas autoritativas ya no tienen que copiarse en Milvus simplemente porque necesitas que Milvus las busque.

Colección normal de Milvus vs. External Collection

Aspecto	Colección gestionada por Milvus	External Collection
Registros fuente	Almacenados y gestionados por Milvus	Permanecen en los archivos o tabla externos
Cómo entran los datos en Milvus	Insert, upsert, importación o escritura en streaming	Mapeo de fuente externa + Refresh
Mutaciones en línea	Compatible	Solo lectura desde Milvus
Frescura	Sigue la ruta de escritura de Milvus y el modelo de consistencia	Sigue la última publicación de Refresh exitosa
Estado gestionado por Milvus	Datos fuente, metadatos, índices, cachés	Mapeos, manifiestos, índices, cachés
Ruta de consulta	API de búsqueda y consulta de Milvus	API de búsqueda y consulta de Milvus
Mejor ajuste	Datos en línea que cambian continuamente	Datos de lake grandes, producidos por lotes y con mucha lectura

Por tanto, External Collection complementa las colecciones normales de Milvus en lugar de reemplazarlas.

Un sistema puede mantener estado en línea que cambia rápidamente en colecciones normales de Milvus y usar External Collections para corpus grandes, catálogos, conjuntos de datos históricos, características de modelos u otros datos ya producidos y gobernados en el lake.

Por qué es importante eliminar la segunda copia

Puede resultar tentador describir External Collections como una optimización de almacenamiento: no copiar varios terabytes de datos a otra base de datos y así ahorrar almacenamiento. Eso es útil, pero no es el principal problema arquitectónico.

El mayor costo proviene de mantener dos sistemas de datos alineados.

Consideremos de nuevo el catálogo de productos. La plataforma de datos produce el conjunto de datos Parquet autoritativo. La búsqueda lo importa a una base de datos vectorial. Un equipo de recomendación puede leer los mismos datos del lake mediante Spark para análisis fuera de línea. Un nuevo modelo de embeddings genera entonces una columna vectorial de reemplazo. El inventario y los metadatos siguen cambiando simultáneamente.

Una vez que la copia de servicio en línea se independiza del lake, cada cambio tiene que cruzar ese límite:

• los datos deben copiarse;
• la transferencia debe programarse y monitorizarse;
• los trabajos fallidos necesitan reintentos;
• los esquemas y permisos pueden necesitar representarse en múltiples sistemas;
• la frescura depende de la rapidez con que el pipeline de sincronización se ponga al día;
• los equipos tienen que saber qué copia representa la versión que realmente quieren.

El almacenamiento es solo una partida.

Costo	Lake separado + copia de servicio	External Collection
Copias de datos fuente	Copia en el lake más una copia de servicio separada	Las filas fuente permanecen en el lake
Movimiento de datos	Pipeline ETL/importación persistente	Refresh sobre la fuente externa
Frescura	Depende de la cadencia de exportación/importación	Controlada por el momento en que se publica un nuevo Refresh
Gobernanza	La copia fuente y la de servicio deben mantenerse alineadas	La propiedad, el linaje y el versionado de la fuente permanecen en la plataforma de lake
Reutilización fuera de línea	Otros consumidores pueden preparar sus propias copias	Las herramientas existentes del lake pueden seguir leyendo la misma fuente
Recursos de servicio	Dimensionados en torno a la copia de la base de datos y la carga de consultas	La indexación, el cómputo de consultas y las cachés pueden gestionarse por separado de la propiedad de las filas fuente

La diferencia se vuelve especialmente importante a medida que los datos de IA cambian con más frecuencia.

Los equipos deduplican corpus. Agrupan datos para análisis. Generan nuevos embeddings cuando cambia un modelo. Añaden etiquetas, resúmenes, entidades extraídas, puntuaciones de calidad o señales de retroalimentación. Ejecutan trabajos de evaluación y pipelines de limpieza de datos sobre el mismo corpus del que las aplicaciones de producción recuperan.

Si cada sistema es dueño de su propia copia, cada mejora se convierte en otro trabajo de sincronización.

External Collection cambia ese límite: los sistemas fuera de línea pueden seguir trabajando sobre el dataset del lake, mientras Milvus sirve la recuperación sobre la misma base.

Qué fuentes de datos admite External Collection

External Collection está diseñada en torno a datos abiertos y gestionados externamente, no a un diseño de fuente específico de Milvus. Admite múltiples formatos de fuente externa a través de Storage V3:

Formato externo	Valor de format	Lo que Milvus lee
Apache Parquet	parquet	Un directorio o prefijo de almacenamiento de objetos que contiene archivos Parquet y row groups
Vortex	vortex	Archivos Vortex y sus metadatos de layout
Lance	lance-table	Un dataset Lance y sus metadatos de fragmentos
Apache Iceberg	iceberg-table	Metadatos de Iceberg más una instantánea seleccionada
Milvus snapshot	milvus-table	Una instantánea de Milvus compatible expuesta como fuente externa

El mapeo entre la fuente y Milvus es explícito.

Una columna fuente llamada product_id puede convertirse en el campo id de Milvus; image_vec puede convertirse en embedding; y una tabla fuente amplia no necesita exponer todas sus columnas a la colección. Eso significa que la plataforma de datos no tiene que renombrar ni reescribir su fuente solo para satisfacer a la base de datos de servicio.

Los formatos versionados añaden otra propiedad útil. Con una fuente como Iceberg, la colección puede apuntar a una instantánea concreta en lugar de a lo que sea actual cuando se ejecuta la consulta. Una versión fija de la fuente es útil para evaluación repetible, pruebas de regresión, análisis histórico y cargas de trabajo de auditoría.

Los archivos subyacentes también siguen siendo utilizables por el resto del stack de datos. Spark, los frameworks de entrenamiento, los sistemas de gobernanza y otras herramientas compatibles con lake pueden seguir leyendo los mismos datos abiertos.

External Collection añade otro consumidor de esos datos; no convierte a Milvus en su único propietario.

Acceso seguro al almacenamiento externo

Milvus también necesita permiso para leer el almacenamiento externo.

Según el proveedor de almacenamiento, los despliegues pueden usar mecanismos como identidad de carga de trabajo o de instancia, asunción de roles AWS STS, suplantación de cuentas de servicio, acceso basado en SAS o sistemas de roles específicos del proveedor, en lugar de incrustar credenciales de larga duración en la configuración de la aplicación.

Esta identidad de almacenamiento controla cómo llega Milvus a la fuente. La autorización dentro de Milvus sigue siendo un límite de seguridad separado.

Cómo crear, indexar, refrescar y consultar una External Collection

El ciclo de vida de una External Collection tiene cuatro pasos principales:

1. Definir la fuente externa y mapear sus columnas en un esquema de Milvus.
2. Definir los índices que necesita la carga de trabajo.
3. Ejecutar Refresh para que Milvus descubra los datos fuente y prepare una versión consultable.
4. Cargar la colección y usar las API normales de búsqueda y consulta de Milvus.

Aquí está el mismo catálogo de productos representado como una External Collection:

import json
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(
uri=“http://localhost:19530”,
token=“root:Milvus”,
)
schema = client.create_schema(
external_source=“s3://my-lake/datasets/products/”,
external_spec=json.dumps(
{
“format”: “parquet”,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“use_iam”: “true”,
“iam_endpoint”: “https://sts.us-east-1.amazonaws.com”,
},
}
),
)
schema.add_field(
field_name=“id”,
datatype=DataType.INT64,
external_field=“product_id”,
)
schema.add_field(
field_name=“embedding”,
datatype=DataType.FLOAT_VECTOR,
dim=768,
external_field=“image_vec”,
)
schema.add_field(
field_name=“title”,
datatype=DataType.VARCHAR,
max_length=256,
external_field=“product_name”,
)
schema.add_field(
field_name=“stock”,
datatype=DataType.INT64,
external_field=“stock”,
)
schema.add_field(
field_name=“rating”,
datatype=DataType.FLOAT,
external_field=“rating”,
)
client.create_collection(
collection_name=“products_ext”,
schema=schema,
)

Los índices usan la interfaz normal de Milvus:

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
)
index_params.add_index(field_name="stock", index_type="AUTOINDEX")
index_params.add_index(field_name="rating", index_type="AUTOINDEX")
client.create_index(
collection_name=“products_ext”,
index_params=index_params,
)

Luego, refresca la fuente externa:

job_id = client.refresh_external_collection(
    collection_name="products_ext",
)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(2)

Una vez que la versión refrescada esté lista, cárgala y búscala como una colección normal de Milvus:

client.load_collection("products_ext")
results = client.search(
collection_name=“products_ext”,
data=[query_vec],
anns_field=“embedding”,
filter=“stock > 0 and rating >= 4.0”,
limit=10,
output_fields=[“id”, “title”, “stock”, “rating”],
)

La diferencia importante no está en la llamada de búsqueda. Está en dónde comienza el ciclo de vida. Una colección gestionada por Milvus comienza con datos que se escriben o importan en Milvus. Una External Collection comienza con una referencia a datos que ya existen en otro lugar.

Cómo Refresh detecta cambios en los datos externos

External Collection es de solo lectura desde el lado de Milvus, pero el dataset del lake subyacente no tiene que permanecer congelado para siempre.

Supongamos que el pipeline de productos agrega otro lote, actualiza metadatos o escribe embeddings de un nuevo modelo. Milvus no sigue continuamente cada objeto que aparece en la ruta de la fuente. Esos cambios se vuelven visibles a través de Refresh.

Refresh lee los metadatos externos, resuelve los fragmentos de la fuente, actualiza los manifiestos que los conectan con la colección de Milvus y prepara el estado de índice correspondiente.

La clave es que este trabajo puede ser incremental.

Milvus identifica los fragmentos de la fuente que no han cambiado y puede reutilizar el trabajo de segmento e índice existente. Los fragmentos nuevos o modificados son las partes que requieren nuevo procesamiento.

Por lo tanto, un pequeño cambio en un conjunto de datos de varios terabytes no tiene que provocar otra importación completa y otra reconstrucción completa del índice.

Refresh también le da al sistema de servicio un límite de versión claro. Mientras se prepara una nueva versión, las consultas siguen usando el estado publicado anteriormente. Una vez que Refresh se completa, el nuevo estado queda disponible como una versión completa, en lugar de exponer una mezcla de datos antiguos y parcialmente preparados.

Este modelo encaja de forma natural con compilaciones de catálogo por hora, actualizaciones nocturnas de bases de conocimiento, refrescos periódicos de embeddings, pipelines de características generadas por modelos y cargas de trabajo similares orientadas a lotes.

No reemplaza una ruta de escritura en streaming. Si cada inserción o borrado debe volverse buscable a través de Milvus de inmediato, una colección gestionada sigue siendo el mejor modelo.

Cómo Lazy Loading reduce el uso de memoria en conjuntos de datos anchos

Mantener las filas fuente en el almacenamiento de objetos solo ayuda si la capa de servicio no tiene que cargar cada byte localmente antes de poder responder consultas. Con Milvus Tiered Storage habilitado, no es así.

En el momento de cargar la colección, los QueryNodes pueden mantener inicialmente solo metadatos ligeros, como información de esquema, definiciones de índices, mapas de chunks y referencias a objetos remotos. Los datos de los campos se obtienen a nivel de chunk cuando una consulta los necesita; los índices pueden permanecer remotos hasta su primer uso y luego almacenarse en caché localmente. Los datos de uso frecuente permanecen activos, mientras que los datos menos accedidos pueden ser expulsados.

Esto es especialmente útil para conjuntos de datos de IA anchos.

Una fila de producto puede contener varios embeddings, una descripción larga, JSON sin procesar, metadatos de imagen, resúmenes generados, inventario, precios, calificaciones y muchos otros atributos. Una búsqueda de similitud típica puede tocar solo un vector más inventario, precio y calificación. No hay razón para que todos los demás campos ocupen permanentemente memoria de servicio solo porque pertenecen al mismo registro.

External Collection puede reducir la huella de servicio en dos niveles:

• Primero, proyección a nivel de esquema. Mediante external_field, la External Collection puede exponer solo las columnas fuente que la aplicación necesita. Las demás columnas permanecen en el dataset del lake y no se incluyen en este esquema de servicio.
• Segundo, proyección en tiempo de ejecución. Bajo el modelo de servicio en niveles, los QueryNodes obtienen y almacenan en caché los campos e índices que la carga de trabajo realmente necesita, en lugar de cargar todo el dataset mapeado por adelantado.

En otras palabras, el dataset puede permanecer ancho en el lake sin obligar a que la huella de servicio sea igualmente ancha.

Hay una compensación obvia. Una consulta que alcanza un campo o índice frío puede pagar un costo de lectura remota en el primer acceso. Las políticas de calentamiento pueden precargar campos o índices críticos para la latencia, mientras que las políticas de caché y expulsión evitan que el estado menos accedido ocupe recursos locales indefinidamente.

El punto no es que el almacenamiento de objetos se comporte como RAM. Es que la memoria y el disco local pueden seguir el conjunto de trabajo de la carga de recuperación, en lugar del tamaño total y la anchura del dataset fuente.

El formato fuente también importa aquí. Los formatos diseñados para escaneos analíticos amplios y los formatos optimizados para lecturas más estrechas o aleatorias pueden producir un comportamiento de E/S diferente bajo acceso bajo demanda. External Collection no borra esas compensaciones a nivel de almacenamiento; permite que Milvus construya una capa de recuperación sobre ellas.

Qué capacidades de búsqueda e indexación admite External Collection

External Collection no se limita a apuntar a Milvus a un directorio de embeddings y escanear los archivos. Milvus construye estructuras de recuperación sobre datos externos y ejecuta consultas a través de su motor de recuperación estándar.

Índices de Milvus construidos sobre datos externos

Según los campos y la carga de trabajo, Milvus puede construir:

• índices vectoriales para búsqueda ANN;
• índices escalares para filtrado de metadatos;
• índices JSON para atributos semiestructurados;
• índices BM25 y de texto completo para recuperación léxica.
• Campos generados por funciones compatibles con el modelo de datos de Milvus.

La búsqueda ANN usa esos índices para reducir el conjunto de candidatos en lugar de leer cada vector fuente.

Esa distinción importa porque almacenar un embedding en un lake no es lo mismo que operar una base de datos vectorial sobre él. La persistencia te da bytes. La recuperación en producción también necesita índices, planificación de consultas, filtrado, ranking, caché y una ruta de servicio de baja latencia.

Más allá del top-K vectorial

Otro error común es leer «External Collection» como «búsqueda vectorial sobre Parquet». Eso no hace justicia a lo que la recuperación en producción realmente requiere.

Un resultado de búsqueda en producción rara vez depende solo de la similitud vectorial. También puede depender de términos exactos, política de acceso, inventario, timestamp, categoría, precio, calidad de la fuente o señales de ranking de negocio.

Considere una consulta como:

vestido floral rojo para verano, en stock, mejor calificado primero

Una ruta de recuperación en producción puede necesitar varias señales:

• Similitud vectorial para el significado semántico de «vestido floral de verano».
• Búsqueda léxica o de texto completo para un término exacto como «rojo».
• Filtros escalares para eliminar productos agotados o por debajo de un umbral de calificación.
• Recuperación híbrida y ranking para combinar múltiples señales de recuperación.

Milvus 3.0 también expande el motor de consultas más allá de la recuperación inicial de vecinos más cercanos con capacidades como ordenamiento, agregación y facetado en el servidor.

El punto más amplio es que External Collection da a los datos residentes en el lake una ruta de recuperación de nivel de base de datos, no solo una forma de leer vectores desde archivos.

Cómo los mismos datos del lake admiten servicio en línea y procesamiento fuera de línea

La razón arquitectónica más fuerte para mantener la fuente en un formato de lake abierto no es simplemente que una segunda copia cueste dinero. Es que el mismo dataset puede seguir disponible para los sistemas que lo mejoran continuamente.

Volvamos al catálogo de productos.

Durante el día, Milvus puede servir una External Collection para búsqueda de productos, recomendaciones o recuperación para agentes.

Al mismo tiempo, otros sistemas pueden trabajar directamente sobre el dataset del lake:

• Spark puede identificar productos duplicados.
• Un pipeline de entrenamiento puede generar embeddings con un nuevo modelo.
• Un trabajo de calidad de datos puede detectar registros malformados o anómalos.
• Un pipeline de evaluación puede comparar la calidad de recuperación entre versiones de modelos.
• Un proceso por lotes puede generar resúmenes, etiquetas o metadatos adicionales.

External Collection no ejecuta esos trabajos por sí misma. Spark sigue siendo Spark; el entrenamiento sigue siendo entrenamiento. Su rol es eliminar el límite adicional de datos de servicio entre ellos.

El trabajo fuera de línea puede escribir datos mejorados o nuevos campos de vuelta al lake. Un Refresh posterior hace que la fuente actualizada esté disponible para la ruta de recuperación de Milvus.

No hay un bucle separado de exportación e importación cuyo único propósito sea reconstruir otra copia autoritativa para el servicio.

La gobernanza también se mantiene claramente dividida. Las versiones de la fuente, el linaje y la propiedad de la fuente permanecen en la plataforma de lake. Milvus mantiene su propia autorización a nivel de colección y las credenciales necesarias para leer la fuente. Compartir una única capa de datos no significa colapsar todos los dominios de seguridad en un solo sistema.

Esta es la conexión con Vector Lakebase: el lake sigue siendo la capa de datos compartida, mientras Milvus proporciona una capa de recuperación de baja latencia sobre él. External Collection es una parte de esa arquitectura, junto con Storage V3, Snapshots, integración con Spark, evolución de esquemas y backfill.

Dónde encaja External Collection, y dónde no

External Collection es una opción muy adecuada cuando:

• Tus datos autoritativos ya viven en Parquet, Vortex, Lance, Iceberg u otra fuente externa compatible.
• El dataset se produce principalmente por lotes, no mediante escrituras transaccionales de alta frecuencia.
• Mantener una segunda copia de servicio genera una sobrecarga significativa de ETL, frescura o gobernanza.
• Múltiples sistemas necesitan trabajar con el mismo dataset abierto.
• Un límite de Refresh explícito es aceptable para la frescura del servicio.
• Quieres recuperación de producción con Milvus sin convertir a Milvus en el propietario de las filas fuente.

Una colección normal de Milvus sigue siendo la mejor opción cuando:

• la aplicación inserta o actualiza (upsert) registros continuamente;
• los borrados deben hacerse visibles a través de la ruta de escritura en línea;
• la carga de trabajo depende de características de colección no disponibles para esquemas externos;
• el diseño de servicio mantiene intencionalmente todos los datos requeridos en memoria, evitando fallos de caché remotos.

Vale la pena tener en cuenta varios límites.

• Las External Collections son de solo lectura. Los cambios en la fuente ocurren fuera de Milvus.
• El cero copias se aplica a las filas fuente. Los índices, manifiestos, cachés y cómputo siguen costando recursos.
• Refresh es explícito. No es un mecanismo de sincronización en streaming.
• La fuente debe permanecer accesible. El comportamiento de búsqueda, indexación y refresh sigue dependiendo del acceso al almacenamiento y las credenciales.
• Storage V3 es obligatorio. En Milvus 3.0 de código abierto, debe estar habilitado antes de usar External Collection.
• External Collection no reemplaza el procesamiento upstream. La generación de embeddings, el clustering, la deduplicación y la limpieza de datos siguen ocurriendo en los sistemas upstream apropiados.

La elección es, por tanto, complementaria más que binaria. Un sistema puede usar colecciones normales de Milvus para el estado en línea que cambia rápidamente y External Collections para conjuntos de datos grandes y producidos por lotes cuyo hogar natural es el lake.

Prueba External Collection en Milvus 3.0

External Collection está disponible en Milvus 3.0. Comienza con un dataset de lake representativo y evalúa los aspectos que importan para tu carga de trabajo: refresh inicial e incremental, costo de construcción de índices, comportamiento de consultas en caliente y en frío, y el intervalo de frescura que tu aplicación requiere.

Para detalles de implementación, consulta:

• Crear una External Collection
• Notas de la versión de Milvus 3.0
• Blog de lanzamiento de Milvus 3.0

Si prefieres una ruta gestionada, External Collection también está disponible como parte de Zilliz Vector Lakebase en Zilliz Cloud. Consulta:

• External Collection en Zilliz Cloud
• De base de datos vectorial a Vector Lakebase
• Por qué construimos Vector Lakebase: repensando la arquitectura de datos no estructurados para la IA

También puedes llevar preguntas de implementación o comentarios al repositorio de Milvus en GitHub o a la comunidad de Milvus en Discord.