Fundamentos do armazenamento colunar: como um arquivo Parquet é organizado e por que leituras analíticas acessam menos dados

O que é

O glossário do Parquet (citado) define a hierarquia: um arquivo é composto por um ou mais row groups; um row group é uma partição horizontal das linhas e contém um column chunk para cada coluna; os column chunks são contíguos no arquivo e divididos em páginas; uma página é a unidade indivisível de codificação e compressão. A página do formato de arquivo (citada) afirma que os metadados do arquivo são gravados depois dos dados, para permitir a escrita em uma única passada, e que se espera que os leitores leiam primeiro os metadados para localizar os column chunks de seu interesse. Como todos os valores de uma coluna dentro de um row group ficam armazenados juntos, as codificações conseguem explorar a semelhança entre eles: a página de codificações (citada) descreve a codificação por dicionário, que constrói um dicionário com os valores encontrados em um column chunk, o guarda em uma página de dicionário e grava os valores como índices inteiros usando um híbrido de run-length e bit-packing, recorrendo à codificação plain se o dicionário crescer demais. O page index (citado) acrescenta valores mínimo e máximo por página, de modo que varreduras por intervalo e buscas pontuais possam ler apenas as páginas que podem conter linhas correspondentes.

Por que importa

Uma consulta analítica costuma ler poucas colunas de muitas linhas. Um arquivo orientado a linhas (CSV, JSON lines) obriga o leitor a processar cada byte de cada linha; um arquivo colunar permite ler apenas os chunks das colunas projetadas, pular row groups inteiros cujas estatísticas excluem o predicado e decodificar índices inteiros compactos em vez de strings repetidas. Esse mesmo layout é pouco adequado para ler um registro completo ou para atualizar linhas no local: um arquivo Parquet é gravado uma vez e substituído, não editado.

Como aplicar

• Ordene ou agrupe as linhas pelas colunas mais usadas em filtros antes de gravar; a poda por mín./máx. só ajuda quando os valores dentro de uma página são próximos entre si.
• Particione os conjuntos de dados em diretórios por uma chave de granularidade grossa (data, região) e mantenha os arquivos grandes o bastante para que o custo do rodapé e dos dicionários seja diluído; milhares de arquivos minúsculos custam mais em leituras de metadados do que economizam.
• Use os tipos e tipos lógicos mais restritos que sejam corretos (datas, decimais, timestamps com unidade declarada), para que estatísticas e codificações funcionem e os leitores concordem sobre o significado.
• Confira na saída de explain do mecanismo de consultas se a projeção de colunas e o predicate pushdown realmente chegam ao leitor; um filtro aplicado depois de uma varredura completa não traz ganho algum.

Armadilhas

Colunas de string com alta cardinalidade inviabilizam a codificação por dicionário e recorrem à codificação plain, o que incha os arquivos. Campos aninhados e repetidos usam definition levels e repetition levels, que algumas ferramentas tratam de forma inconsistente. A escolha do codec de compressão é feita por column chunk; se o leitor não tiver o codec usado, o arquivo fica ilegível para ele.