Spotify lançou Random Access Parquet (RAP), uma camada de indexação externa que permite consultas de ponto em sub-segundo diretamente contra arquivos Parquet em seu data lake baseado em GCS, sem copiar dados para Bigtable, DynamoDB ou outras lojas de atendimento. O sistema fecha uma lacuna que forçou equipes de dados em larga escala a escolher entre custo de armazenamento e latência de consulta.
O problema é concreto em escala. Spotify armazena petabytes no Bigtable para atendimento de baixa latência, mas exabytes vivem no GCS. Replicar até mesmo uma fração para uma loja chave-valor para torná-la consultável é economicamente insustentável. O armazenamento em nuvem agora oferece 30–100ms por requisição; GCS Rapid Storage e S3 Express One Zone caem para milissegundos de um dígito. O gargalo real é a sobrecarga de planejamento de consultas. Trino e BigQuery adicionam segundos de trabalho de agendamento até mesmo para consultas de linha única.
A leitura em cadeia de dependências é o problema central do RAP. Uma consulta de ponto para o histórico de audição de um usuário em 90 dias com 1.000 arquivos Parquet por dia começa com 90.000 arquivos candidatos. Particionamento baseado em chave mais filtros Bloom reduzem para aproximadamente 12 arquivos. Cada um ainda requer viagens de ida e volta sequenciais: buscar rodapé, analisar metadados de grupo de linhas, verificar a coluna de chave, resolver deslocamentos de página para cada coluna de valor. No armazenamento em nuvem cada um custa dezenas de milissegundos. Encadeados, isso é centenas de milissegundos antes de um único byte de dados do usuário chegar.
RAP reduz a cadeia para uma única consulta O(1). Um índice externo mapeia cada chave diretamente para arquivo e números de linha. O leitor acessa o índice, resolve números de linha para intervalos de bytes usando metadados de arquivo em cache, e emite leituras paralelas de intervalo. Nenhuma viagem de ida e volta dependente. Entradas de índice são compactas: chave, arquivo (ordinal codificado em dicionário), números de linha e contagem de valor opcional para paginação. Regra prática: indexar um petabyte produz um terabyte de índice; terabytes produzem gigabytes.
Mudanças de layout do lado da escrita eliminam amplificação remanescente. Mesmo com um índice perfeito, leitores buscam uma página completa de 4MB para extrair talvez 100 bytes de dados úteis. Spotify classifica a saída Parquet por chave de consulta, alinha limites de página para transições de chave e usa layout de coluna intercalada colocando colunas de valor relacionadas. Índices de cobertura fazem cache de dados de valor suficientes dentro do próprio índice para satisfazer algumas consultas sem abrir nenhum arquivo Parquet. A compensação é crescimento modesto do índice e tamanho de arquivo para consultas resolvidas em quilobytes.
Índices secundários estendem o modelo sem mudanças de pipeline. Índices baseados em hash servem consultas exatas em dimensões; índices ordenados lidam com consultas de intervalo. Ambos são gerenciados na camada de atendimento, permitindo que equipes adicionem caminhos de acesso—ID do comprador, ID do vendedor, ID de sessão—sem tocar em trabalhos upstream ou reescrever dados.
A função de forçamento prático é agentes de IA. Agentes respondendo perguntas temporais como "o que eu estava ouvindo no verão passado?" precisam paginar através de meses de histórico por usuário em velocidades interativas. Esse volume de dados sempre excedeu o que as lojas chave-valor podem economicamente conter. RAP permite que os mesmos datasets Parquet alimentem análise em lote, treinamento de ML, notebooks e contexto de agente a partir de uma única cópia.
Ponto de avaliação: se sua equipe mantém uma réplica de dados de lake em uma loja KV puramente para latência de consulta de ponto, RAP merece avaliação direta. Sobrecarga de indexação é limitada, arquivos Parquet permanecem imutáveis, e mudanças de layout do lado da escrita são incrementais o suficiente para aplicar por tabela sem reescritas de pipeline.