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
- startree.aifonte original
- Categoria
- CEVIU Dados
- Publicado
- 02 de novembro de 2026
- Editoria
- CEVIU Dados
