Voltar

StarTree leva busca vetorial a tabelas Apache Iceberg sem copiar os dados de origem

Aprofundamento CEVIU

Aprofundamento

A StarTree estendeu o índice vetorial HNSW do Apache Pinot para embeddings que ficam no data lake. O fluxo usa as External Tables da StarTree: os registros continuam em arquivos Parquet de tabelas Iceberg, com os embeddings numa coluna float[] gerada pelo pipeline do próprio usuário. O Pinot constrói o índice sobre essa coluna sem copiar os dados para segmentos nativos. A consulta é SQL: a função VECTOR_SIMILARITY faz a busca aproximada (ANN) e atua como predicado de filtro, e a cosineDistance calcula as distâncias dos candidatos para ordenar o resultado.

O problema técnico era que o HNSW pressupõe acesso aleatório barato, e o Lucene (base da implementação do Pinot) usa arquivos .vec, .vex e .vem com semântica de disco local. A StarTree consolidou esses arquivos no arquivo combinado columns.psf, passou a ler o índice por um PinotDataBuffer e reaproveitou a infraestrutura de tiered storage nas External Tables. Para isso, a configuração exige a propriedade storeInSegmentFile. O índice vive no object storage, cada segmento tem o seu, e as consultas rodam em paralelo nos servidores, então computação e armazenamento escalam separados. Num teste inicial com 100 mil documentos e S3, a StarTree mediu cerca de 50 ms de latência mediana em consultas quentes, e o próprio texto avisa que isso não é garantia para produção. O custo: o índice tem tamanho próximo ao dos embeddings brutos (o grafo HNSW soma poucos pontos percentuais) e precisa ser mantido conforme a origem muda. Detalhes na documentação de StarTree.

Por que isso importa

Para quem opera um lakehouse com Iceberg como fonte da verdade, a proposta corta um pipeline: não há segunda base vetorial para sincronizar. Em contrapartida, vale planejar o armazenamento extra do índice e aceitar que a atualização acompanha os snapshots do Iceberg, não a ingestão em tempo real. Para cargas que exigem frescor de segundos, isso pode pesar. Os números ainda vêm de uma prova de conceito pequena, então vale testar com o seu volume antes de decidir.

Perguntas frequentes

A StarTree copia os dados do Iceberg para fazer a busca vetorial?

Não. Os registros continuam nos arquivos Parquet do data lake, com os embeddings numa coluna float[]. O Pinot constrói um índice HNSW derivado sobre essa coluna e o armazena no object storage, ao lado do segmento.

Como é feita uma consulta híbrida?

Em uma única instrução SQL no Pinot. VECTOR_SIMILARITY faz a busca aproximada e vale como predicado de filtro, e cosineDistance ordena os candidatos. Filtros estruturados, como cliente, categoria ou janela de tempo, entram na mesma consulta.

Qual é o custo dessa abordagem?

O índice ocupa espaço aproximadamente igual ao dos embeddings brutos, com o grafo HNSW somando poucos pontos percentuais. Ele também precisa ser construído e mantido conforme a origem muda. A atualização segue a sincronização de snapshots do Iceberg, não a ingestão em tempo real.

Qual a latência medida pela StarTree?

Em uma prova de conceito com 100 mil documentos e armazenamento em S3, a mediana foi de cerca de 50 ms em consultas quentes, inclusive com filtros SQL. A própria StarTree diz que não é garantia de desempenho em escala de produção.

Fontes

Avalie este artigo:
Categoria
CEVIU Dados
Publicado
02 de novembro de 2026
Editoria
CEVIU Dados

Quer receber mais sobre CEVIU Dados?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser