Início
Blog
Coleção Externa do Milvus: Indexe e Recupere Dados do Data Lake Sem Movê-los

Coleção Externa do Milvus: Indexe e Recupere Dados do Data Lake Sem Movê-los

Engineering

August 24, 2026

Leo Liu

Em muitos pipelines de IA, embeddings e metadados já são produzidos e armazenados em um data lake. Um pipeline de produtos pode gravar atributos de produtos e embeddings multimodais em arquivos Parquet no S3. Um corpus de recuperação ou treinamento pode viver em uma tabela Iceberg ou Lance. O lake já é onde esses conjuntos de dados são gerados, atualizados, versionados e usados pelo restante da stack de dados.

Bancos de dados vetoriais, no entanto, tradicionalmente foram construídos em torno de uma cópia de serviço de propriedade do banco de dados. Se as equipes quisessem busca vetorial de baixa latência sobre dados já presentes em um lake, geralmente tinham duas opções:

Copiar os dados para um banco de dados vetorial. Isso fornece índices ANN e um caminho de serviço de produção, mas cria uma segunda cópia do conjunto de dados e um pipeline de ETL que precisa permanecer sincronizado com a origem.
Consultar o lake diretamente. Isso evita duplicação, mas sem uma camada de indexação e serviço ANN, a busca vetorial recorre a varreduras que não são projetadas para latência de produção.

O External Collection do Milvus 3.0 introduz um terceiro caminho. Os dados de origem permanecem em Parquet, Iceberg, Lance, Vortex ou outro formato externo suportado, enquanto o Milvus constrói e serve índices sobre eles. Você mapeia os campos externos para um schema do Milvus, define os índices necessários, atualiza (refresh) a coleção e usa as APIs normais de busca e consulta do Milvus—sem primeiro copiar as linhas de origem para uma coleção gerenciada pelo Milvus.

A mudança arquitetural é direta: os dados podem permanecer no lake, enquanto o Milvus adiciona a camada de indexação e recuperação.

Isso também torna o External Collection um passo importante em direção ao Vector Lakebase, uma arquitetura de dados unificada e nativa de lake para IA que combina serviço no nível de banco de dados vetorial com armazenamento aberto em lake, índices reutilizáveis no nível do lake e uma camada semântica compartilhada. A recuperação online não precisa mais partir de uma cópia de serviço separada enquanto Spark, pipelines de treinamento, jobs de avaliação e ferramentas de governança operam em outra versão dos dados. Esses sistemas podem trabalhar a partir da mesma fundação de dados residente no lake.

O que é um External Collection, e o que ele muda

Um External Collection é um tipo de coleção do Milvus cujos dados de origem vivem fora do armazenamento gerenciado pelo Milvus.

Sem um External Collection, colocar esse catálogo atrás de uma busca vetorial de produção normalmente significa criar outra cópia no Milvus:

Toda vez que o catálogo muda, o modelo de embedding muda ou um campo é preenchido retroativamente (backfill), outro pipeline precisa mover os dados atualizados através dessa fronteira.

Com o External Collection, a arquitetura se torna:

O Milvus não transforma os arquivos externos em uma cópia própria dos dados de origem. Em vez disso, o External Collection contém as informações que o Milvus precisa para interpretá-los e pesquisá-los:

Um external_source que identifica os arquivos ou tabela externos.
Um external_spec que descreve o formato da origem e o acesso ao armazenamento.
Mapeamentos external_field que conectam campos no schema do Milvus a colunas no conjunto de dados externo.
Os índices, manifests e o estado de serviço que o Milvus cria para recuperação.

Dados de origem com zero-cópia não significam zero estado dentro do Milvus. O Milvus ainda constrói índices. Ainda usa computação. Ainda armazena dados em cache. A mudança é que as linhas autoritativas não precisam mais ser copiadas para o Milvus simplesmente porque você precisa que o Milvus as pesquise.

Coleção Milvus normal vs. External Collection

Aspecto	Coleção gerenciada pelo Milvus	External Collection
Registros de origem	Armazenados e gerenciados pelo Milvus	Permanecem nos arquivos ou tabela externos
Como os dados entram no Milvus	Insert, upsert, import ou escrita em streaming	Mapeamento da origem externa + Refresh
Mutações online	Suportadas	Somente leitura pelo Milvus
Atualidade	Segue o caminho de escrita e o modelo de consistência do Milvus	Segue o último Refresh publicado com sucesso
Estado gerenciado pelo Milvus	Dados de origem, metadados, índices, caches	Mapeamentos, manifests, índices, caches
Caminho de consulta	APIs de busca e consulta do Milvus	APIs de busca e consulta do Milvus
Mais adequado para	Dados online em mudança contínua	Dados de lake grandes, produzidos em lote e com muitas leituras

O External Collection, portanto, complementa as coleções normais do Milvus em vez de substituí-las.

Um sistema pode manter estado online em rápida mudança em coleções normais do Milvus enquanto usa External Collections para corpora grandes, catálogos, conjuntos de dados históricos, features de modelos ou outros dados já produzidos e governados no lake.

Por que remover a segunda cópia é importante

É tentador descrever External Collections como uma otimização de armazenamento: não copie vários terabytes de dados para outro banco de dados e você economiza armazenamento. Isso é útil, mas não é o principal problema arquitetural.

O custo maior vem de manter dois sistemas de dados alinhados.

Considere novamente o catálogo de produtos. A plataforma de dados produz o conjunto de dados Parquet autoritativo. A busca o importa para um banco de dados vetorial. Uma equipe de recomendação pode ler os mesmos dados do lake por meio do Spark para análise offline. Um novo modelo de embedding então gera uma coluna vetorial substituta. Inventário e metadados continuam mudando simultaneamente.

Uma vez que a cópia de serviço online se torna independente do lake, toda mudança precisa cruzar essa fronteira:

os dados precisam ser copiados;
a transferência precisa ser agendada e monitorada;
jobs com falha precisam de novas tentativas;
schemas e permissões podem precisar ser representados em vários sistemas;
a atualidade depende da rapidez com que o pipeline de sincronização acompanha as mudanças;
as equipes precisam saber qual cópia representa a versão que realmente desejam.

O armazenamento é apenas um item de linha.

Custo	Lake separado + cópia de serviço	External Collection
Cópias dos dados de origem	Cópia no lake mais uma cópia de serviço separada	As linhas de origem permanecem no lake
Movimentação de dados	Pipeline persistente de ETL/importação	Refresh sobre a origem externa
Atualidade	Depende da cadência de exportação/importação	Controlada pelo momento em que um novo Refresh é publicado
Governança	As cópias de origem e de serviço devem permanecer alinhadas	A propriedade da origem, a linhagem e o versionamento permanecem com a plataforma de lake
Reuso offline	Outros consumidores podem preparar suas próprias cópias	As ferramentas de lake existentes podem continuar lendo a mesma origem
Recursos de serviço	Dimensionados em torno da cópia do banco de dados e da carga de consultas	Indexação, computação de consultas e caches podem ser gerenciados separadamente da propriedade das linhas de origem

A diferença se torna especialmente importante à medida que os dados de IA mudam com mais frequência.

As equipes deduplicam corpora. Elas agrupam dados em clusters para análise. Elas geram novos embeddings quando um modelo muda. Elas adicionam rótulos, resumos, entidades extraídas, pontuações de qualidade ou sinais de feedback. Elas executam jobs de avaliação e pipelines de limpeza de dados sobre o mesmo corpus do qual os aplicativos de produção recuperam informações.

Se cada sistema possui sua própria cópia, cada melhoria se torna outro job de sincronização.

O External Collection muda essa fronteira: sistemas offline podem continuar trabalhando no conjunto de dados do lake, enquanto o Milvus atende à recuperação sobre a mesma fundação.

Quais fontes de dados o External Collection suporta

O External Collection é projetado em torno de dados abertos e gerenciados externamente, em vez de um layout de origem específico do Milvus. Ele suporta vários formatos de origem externa por meio do Storage V3:

Formato externo	Valor do formato	O que o Milvus lê
Apache Parquet	parquet	Um diretório ou prefixo de object storage contendo arquivos Parquet e row groups
Vortex	vortex	Arquivos Vortex e seus metadados de layout
Lance	lance-table	Um dataset Lance e seus metadados de fragmento
Apache Iceberg	iceberg-table	Metadados do Iceberg mais um snapshot selecionado
Milvus snapshot	milvus-table	Um snapshot do Milvus suportado exposto como origem externa

O mapeamento entre a origem e o Milvus é explícito.

Uma coluna de origem chamada product_id pode se tornar o campo id do Milvus; image_vec pode se tornar embedding; e uma tabela de origem larga não precisa expor todas as colunas à coleção. Isso significa que a plataforma de dados não precisa renomear ou reescrever sua origem apenas para satisfazer o banco de dados de serviço.

Formatos versionados adicionam outra propriedade útil. Com uma origem como o Iceberg, a coleção pode apontar para um snapshot específico em vez do que estiver atual no momento em que a consulta é executada. Uma versão fixa da origem é útil para avaliação reproduzível, testes de regressão, análise histórica e cargas de trabalho de auditoria.

Os arquivos subjacentes também permanecem utilizáveis pelo restante da stack de dados. Spark, frameworks de treinamento, sistemas de governança e outras ferramentas compatíveis com lake podem continuar lendo os mesmos dados abertos.

O External Collection adiciona outro consumidor desses dados; ele não transforma o Milvus em seu único proprietário.

Acessando o armazenamento externo com segurança

O Milvus também precisa de permissão para ler o armazenamento externo.

Dependendo do provedor de armazenamento, as implantações podem usar mecanismos como workload ou instance identity, assunção de role do AWS STS, impersonação de service account, acesso baseado em SAS ou sistemas de role específicos do provedor, em vez de embutir credenciais de longa duração na configuração do aplicativo.

Essa identidade de armazenamento controla como o Milvus acessa a origem. A autorização dentro do Milvus permanece como uma fronteira de segurança separada.

Como criar, indexar, atualizar (refresh) e consultar um External Collection

O ciclo de vida do External Collection tem quatro etapas principais:

Defina a origem externa e mapeie suas colunas para um schema do Milvus.
Defina os índices que a carga de trabalho precisa.
Execute o Refresh para que o Milvus descubra os dados de origem e prepare uma versão consultável.
Carregue a coleção e use as APIs normais de busca e consulta do Milvus.

Aqui está o mesmo catálogo de produtos representado como um 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,
)

Os índices usam a interface normal do 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,
)

Em seguida, faça o refresh da origem 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)

Quando a versão atualizada estiver pronta, carregue e pesquise como uma coleção normal do 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”],
)

A diferença importante não é a chamada de busca. É onde o ciclo de vida começa. Uma coleção gerenciada pelo Milvus começa com dados sendo gravados ou importados para o Milvus. Um External Collection começa com uma referência a dados que já existem em outro lugar.

Como o Refresh capta mudanças nos dados externos

O External Collection é somente leitura do lado do Milvus, mas o conjunto de dados subjacente do lake não precisa permanecer congelado para sempre.

Suponha que o pipeline de produtos adicione outro lote, atualize metadados ou grave embeddings de um novo modelo. O Milvus não acompanha continuamente todos os objetos que aparecem no caminho da origem. Essas mudanças se tornam visíveis por meio do Refresh.

O Refresh lê os metadados externos, resolve os fragmentos da origem, atualiza os manifests que os conectam à coleção do Milvus e prepara o estado de índice correspondente.

O ponto-chave é que esse trabalho pode ser incremental.

O Milvus identifica fragmentos de origem que não mudaram e pode reutilizar o trabalho existente de segmento e índice. Fragmentos novos ou alterados são as partes que exigem novo processamento.

Uma pequena mudança em um conjunto de dados de vários terabytes, portanto, não precisa acionar outra importação completa e reconstrução total de índice.

O Refresh também dá ao sistema de serviço uma fronteira de versão clara. Enquanto uma nova versão está sendo preparada, as consultas continuam usando o estado publicado anteriormente. Quando o Refresh é concluído, o novo estado fica disponível como uma versão completa, em vez de expor uma mistura de dados antigos e parcialmente preparados.

Esse modelo se encaixa naturalmente com builds horários de catálogo, atualizações noturnas de base de conhecimento, atualizações periódicas de embeddings, pipelines de features gerados por modelos e cargas de trabalho semelhantes orientadas a lote.

Ele não substitui um caminho de escrita em streaming. Se todo insert ou delete precisar se tornar pesquisável pelo Milvus imediatamente, uma coleção gerenciada continua sendo o melhor modelo.

Como o Lazy Loading reduz o uso de memória para conjuntos de dados largos

Manter as linhas de origem no object storage só ajuda se a camada de serviço não precisar carregar todos os bytes localmente antes de responder às consultas. Com o Milvus Tiered Storage habilitado, ela não precisa.

No momento do carregamento da coleção, os QueryNodes podem manter inicialmente apenas metadados leves, como informações de schema, definições de índice, mapas de chunks e referências a objetos remotos. Os dados dos campos são buscados no nível de chunk quando uma consulta precisa deles; os índices podem permanecer remotos até o primeiro uso e depois ser armazenados em cache localmente. Dados usados com frequência permanecem quentes, enquanto dados acessados com menos frequência podem ser removidos.

Isso é especialmente útil para conjuntos de dados de IA largos.

Uma linha de produto pode conter vários embeddings, uma descrição longa, JSON bruto, metadados de imagem, resumos gerados, inventário, preços, avaliações e muitos outros atributos. Uma busca por similaridade típica pode tocar apenas um vetor, além de inventário, preço e avaliação. Não há razão para que todos os outros campos ocupem permanentemente a memória de serviço apenas porque pertencem ao mesmo registro.

O External Collection pode reduzir a pegada de serviço em dois níveis:

Primeiro, projeção no nível de schema. Por meio de external_field, o External Collection pode expor apenas as colunas de origem que o aplicativo precisa. As outras colunas permanecem no conjunto de dados do lake e não são incluídas nesse schema de serviço.
Segundo, projeção em tempo de execução. Sob o modelo de serviço em camadas, os QueryNodes buscam e armazenam em cache os campos e índices realmente necessários para a carga de trabalho, em vez de carregar todo o conjunto de dados mapeado antecipadamente.

Em outras palavras, o conjunto de dados pode permanecer largo no lake sem forçar a pegada de serviço a ser igualmente larga.

Há um tradeoff óbvio. Uma consulta que atinge um campo ou índice frio pode pagar um custo de leitura remota no primeiro acesso. Políticas de aquecimento podem pré-carregar campos ou índices críticos para a latência, enquanto políticas de cache e remoção impedem que estados acessados com menos frequência ocupem recursos locais indefinidamente.

O ponto não é que o object storage se comporte como RAM. É que a memória e o disco local podem acompanhar o working set da carga de trabalho de recuperação, em vez do tamanho total e da largura do conjunto de dados de origem.

O formato da origem também importa aqui. Formatos projetados para varreduras analíticas amplas e formatos otimizados para leituras mais estreitas ou aleatórias podem produzir comportamentos de I/O diferentes sob acesso sob demanda. O External Collection não apaga essas trocas no nível de armazenamento; ele permite que o Milvus construa uma camada de recuperação sobre elas.

Quais recursos de busca e indexação o External Collection suporta

O External Collection não apenas aponta o Milvus para um diretório de embeddings e varre os arquivos. O Milvus constrói estruturas de recuperação sobre dados externos e executa consultas por meio de seu mecanismo de recuperação padrão.

Índices do Milvus construídos sobre dados externos

Dependendo dos campos e da carga de trabalho, o Milvus pode construir:

índices vetoriais para busca ANN;
índices escalares para filtragem de metadados;
índices JSON para atributos semiestruturados;
índices BM25 e full-text para recuperação lexical;
Campos gerados por funções suportados pelo modelo de dados do Milvus.

A busca ANN usa esses índices para reduzir o conjunto de candidatos em vez de ler cada vetor de origem.

Essa distinção importa porque armazenar um embedding em um lake não é o mesmo que operar um banco de dados vetorial sobre ele. A persistência fornece bytes. A recuperação em produção também precisa de índices, planejamento de consultas, filtragem, ranqueamento, cache e um caminho de serviço de baixa latência.

Além do top-K vetorial

Outro erro comum é interpretar "External Collection" como "busca vetorial sobre Parquet". Isso subestima o que a recuperação em produção realmente exige.

Um resultado de busca em produção raramente depende apenas da similaridade vetorial. Ele também pode depender de termos exatos, política de acesso, inventário, timestamp, categoria, preço, qualidade da origem ou sinais de ranqueamento de negócio.

Considere uma consulta como:

vestido floral vermelho para o verão, em estoque, melhor avaliado primeiro

Um caminho de recuperação em produção pode precisar de vários sinais:

Similaridade vetorial para o significado semântico de "vestido floral de verão".
Busca lexical ou full-text para um termo exato como "vermelho".
Filtros escalares para remover produtos fora de estoque ou abaixo de um limite de avaliação.
Recuperação híbrida e ranqueamento para combinar múltiplos sinais de recuperação.

O Milvus 3.0 também expande o mecanismo de consulta além da recuperação inicial de vizinhos mais próximos, com recursos como ordenação no lado do servidor, agregação e facetagem.

O ponto mais amplo é que o External Collection dá aos dados residentes no lake um caminho de recuperação de banco de dados—não apenas uma maneira de ler vetores de arquivos.

Como os mesmos dados do lake suportam serviço online e processamento offline

A razão arquitetural mais forte para manter a origem em um formato de lake aberto não é simplesmente que uma segunda cópia custa dinheiro. É que o mesmo conjunto de dados pode permanecer disponível para os sistemas que o melhoram continuamente.

Volte ao catálogo de produtos.

Durante o dia, o Milvus pode servir um External Collection para busca de produtos, recomendações ou recuperação para agentes.

Ao mesmo tempo, outros sistemas podem trabalhar diretamente no conjunto de dados do lake:

O Spark pode identificar produtos duplicados.
Um pipeline de treinamento pode gerar embeddings a partir de um novo modelo.
Um job de qualidade de dados pode detectar registros malformados ou anômalos.
Um pipeline de avaliação pode comparar a qualidade da recuperação entre versões de modelo.
Um processo em lote pode gerar resumos, rótulos ou metadados adicionais.

O External Collection não executa esses jobs por conta própria. Spark continua sendo Spark; treinamento continua sendo treinamento. Seu papel é remover a fronteira extra entre serviço e dados entre eles.

O trabalho offline pode gravar dados melhorados ou novos campos de volta no lake. Um Refresh subsequente disponibiliza a origem atualizada para o caminho de recuperação do Milvus.

Não há um ciclo separado de exportação e importação cujo único propósito seja reconstruir outra cópia autoritativa para o serviço.

A governança também permanece claramente dividida. Versões da origem, linhagem e propriedade da origem permanecem com a plataforma de lake. O Milvus mantém sua própria autorização no nível de coleção e as credenciais necessárias para ler a origem. Compartilhar uma única fundação de dados não significa colapsar todos os domínios de segurança em um único sistema.

Essa é a conexão com o Vector Lakebase: o lake permanece como a fundação de dados compartilhada, enquanto o Milvus fornece uma camada de recuperação de baixa latência sobre ele. O External Collection é uma parte dessa arquitetura, ao lado de Storage V3, Snapshots, integração com Spark, evolução de schema e backfill.

Onde o External Collection se encaixa—e onde não se encaixa

O External Collection é uma ótima opção quando:

Seus dados autoritativos já vivem em Parquet, Vortex, Lance, Iceberg ou outra origem externa suportada.
O conjunto de dados é produzido principalmente em lotes, em vez de por meio de gravações transacionais de alta frequência.
Manter uma segunda cópia de serviço cria sobrecarga significativa de ETL, atualidade ou governança.
Vários sistemas precisam trabalhar com o mesmo conjunto de dados aberto.
Uma fronteira explícita de Refresh é aceitável para a atualidade do serviço.
Você quer recuperação em produção com o Milvus sem tornar o Milvus o proprietário das linhas de origem.

Uma coleção normal do Milvus ainda é a melhor escolha quando:

o aplicativo insere ou faz upsert de registros continuamente;
exclusões precisam se tornar visíveis pelo caminho de escrita online;
a carga de trabalho depende de recursos de coleção indisponíveis para schemas externos;
o design de serviço mantém intencionalmente todos os dados necessários em memória, evitando cache misses remotos.

Vale a pena ter em mente algumas fronteiras.

External Collections são somente leitura. Mudanças na origem acontecem fora do Milvus.
Zero-cópia se aplica às linhas de origem. Índices, manifests, caches e computação ainda custam recursos.
O Refresh é explícito. Não é um mecanismo de sincronização em streaming.
A origem deve permanecer acessível. O comportamento de busca, indexação e refresh ainda depende do acesso ao armazenamento e das credenciais.
O Storage V3 é obrigatório. No Milvus 3.0 de código aberto, ele deve ser habilitado antes de usar o External Collection.
O External Collection não substitui o processamento a montante (upstream). Geração de embeddings, clustering, deduplicação e limpeza de dados continuam acontecendo nos sistemas upstream apropriados.

A escolha, portanto, é complementar em vez de binária. Um sistema pode usar coleções normais do Milvus para estado online em rápida mudança e External Collections para conjuntos de dados grandes, produzidos em lote, cujo lar natural é o lake.

Experimente o External Collection no Milvus 3.0

O External Collection está disponível no Milvus 3.0. Comece com um conjunto de dados de lake representativo e avalie os aspectos que importam para sua carga de trabalho: refresh inicial e incremental, custo de construção de índices, comportamento de consultas quentes e frias e o intervalo de atualidade que seu aplicativo exige.

Para detalhes de implementação, consulte:

Se você preferir um caminho gerenciado, o External Collection também está disponível como parte do Zilliz Vector Lakebase no Zilliz Cloud. Consulte:

Você também pode levar dúvidas de implementação ou feedback para o repositório do Milvus no GitHub ou para a comunidade do Milvus no Discord.