O que é Parquet? Armazenamento Colunar, Esquema e Casos de Uso

A API de Scraping sem Scrap retorna dados estruturados da web em JSON ou CSV que pipelines analíticos podem validar e converter para Apache Parquet para consultas repetidas orientadas a colunas.

O que é Apache Parquet?

Apache Parquet é um formato de arquivo de dados orientado a colunas, de código aberto, para armazenamento e recuperação eficientes. Em vez de escrever cada campo de um registro juntos, o Parquet organiza valores por coluna dentro de grupos limitados de linhas. Motores analíticos podem ler apenas as colunas necessárias por uma consulta em vez de escanear cada campo em cada registro.

O documento do Apache Parquet liga a especificação do formato, conceitos, detalhes do formato do arquivo e recursos de implementação. O formato é suportado em motores de processamento de dados e linguagens, o que o torna uma fronteira de armazenamento comum para lagos de dados, armazéns, pipelines de recursos e conjuntos de dados analíticos arquivais.

Parquet é binário. Não é destinado a ser aberto e editado em um editor de texto. Uma biblioteca de leitura usa metadados armazenados no arquivo para localizar fragmentos de coluna, decodificar páginas, aplicar codecs de compressão e reconstruir linhas ou vetores de coluna.

Por que o Armazenamento Colunar é Importante

Considere um conjunto de dados com ID do cliente, país, categoria, descrição, preço e hora do evento. Uma consulta que calcula o preço médio por país precisa apenas de três colunas. Em um arquivo de texto orientado a linhas, o motor ainda lê descrições e outros campos não utilizados. No Parquet, o motor pode selecionar os fragmentos de coluna necessários.

Os valores de coluna também tendem a se assemelhar aos seus vizinhos. Uma coluna de país pode repetir um pequeno conjunto de códigos, uma coluna booleana tem uma cardinalidade muito baixa, e timestamps ordenados podem ter deltas pequenos. Codificações e compressão podem aproveitar esses padrões de maneira mais eficaz do que um layout onde tipos de campos não relacionados alternam em cada linha.

O armazenamento colunar não torna toda operação mais rápida. Reconstruir um registro individual completo pode tocar em muitos fragmentos de coluna. Atualizar um registro geralmente significa reescrever dados do arquivo em vez de alterar uma linha no local. Parquet favorece leituras, agregações, filtragem e projeções seletivas sobre atualizações transacionais de linhas.

Como um Arquivo Parquet é Organizado

Um arquivo Parquet contém metadados e dados codificados organizados em várias camadas:

• Metadados do arquivo. O rodapé registra o esquema, grupos de linhas, locais de coluna, codificações, informações de compressão e metadados de chave-valor opcionais.
• Grupos de linhas. Um grupo de linhas é uma partição horizontal de linhas. Cada coluna nesse intervalo de linhas é armazenada como um fragmento de coluna.
• Fragmentos de coluna. Um fragmento contém os valores de uma coluna dentro de um grupo de linhas e é dividido em páginas.
• Páginas. Páginas são a unidade onde codificações, compressão e algumas estatísticas são aplicadas e lidas.
• Rodapé. Metadados no final do arquivo permitem que um leitor descubra o layout antes de selecionar quais intervalos de dados buscar.

As estruturas e codificações detalhadas vivem no repositório de especificação do formato Apache Parquet. Implementações podem suportar subconjuntos diferentes ou recursos opcionais, portanto, um pipeline deve testar a compatibilidade entre seus escritores e leitores.

Tipos Físicos e Lógicos

Parquet define tipos físicos que controlam o armazenamento de baixo nível, incluindo inteiros, valores de ponto flutuante, arrays de bytes e arrays de bytes de comprimento fixo. Anotações de tipos lógicos adicionam significado de domínio, como string, decimal, data, hora, timestamp, UUID, lista, mapa e larguras de inteiro.

Um valor decimal ilustra por que a distinção é importante. Seus bytes físicos podem ser armazenados como um inteiro ou array de bytes, enquanto a anotação lógica fornece precisão e escala. Leitores precisam de ambas as camadas para reconstruir o valor pretendido corretamente.

O design do esquema deve preservar a semântica dos negócios. Timestamps precisam de uma interpretação de fuso horário documentada. A precisão decimal deve cobrir valores esperados. Identificadores que parecem numéricos podem pertencer a um tipo de string. Um escritor não deve inferir um tipo estreito a partir de uma amostra pequena se arquivos posteriores puderem conter valores maiores.

Dados Aninhados em Parquet

Parquet pode representar registros aninhados, listas e mapas em vez de forçar cada conjunto de dados em uma tabela plana. Ele usa níveis de definição e repetição para codificar se campos aninhados estão presentes e onde valores repetidos pertencem na estrutura reconstruída.

Essa capacidade torna o Parquet um destino natural para registros JSON validados que contêm arrays ou objetos filhos. A conversão ainda precisa de um esquema estável. Se um registro armazena um campo como uma string e outro armazena um objeto com o mesmo nome, o escritor deve resolver esse conflito antes de produzir um conjunto de dados confiável.

Colunas aninhadas podem reduzir dados parentais repetidos em comparação com achatamento de cada filho em uma linha. Elas também podem complicar consultas e interoperabilidade quando motores expõem estruturas aninhadas de forma diferente. Teste as formas exatas de lista e mapa usadas pelo pipeline.

Parquet vs CSV e JSON

Compressão, Codificação e Estatísticas

Parquet separa a codificação da compressão. A codificação representa os valores de forma eficiente antes que um codec de compressão processe os bytes da página. As implementações podem escolher codificação de dicionário, técnicas de run-length, empacotamento de bits, codificações delta ou representação simples com base no tipo e nos dados.

Estatísticas de metadados podem incluir valores mínimos e máximos, contagens de nulos e outros índices. Um mecanismo de consulta pode usá-los para ignorar um grupo de linhas cujo intervalo de valores não pode satisfazer um filtro. Isso é chamada de pushdown de predicado ou poda na camada de armazenamento. Reduz I/O quando a organização dos dados e as estatísticas estão alinhadas com os predicados da consulta.

Estatísticas não são um substituto para controle de acesso e podem revelar intervalos de valores ou contagens para qualquer um que possa ler os metadados do arquivo. Conjuntos de dados sensíveis precisam de permissões de armazenamento, controles de criptografia e governança nas camadas de objeto e catálogo.

Partições, Arquivos e o Problema de Arquivos Pequenos

Conjuntos de dados frequentemente colocam arquivos Parquet em diretórios particionados por um valor frequentemente filtrado, como data ou região. Um mecanismo de consulta pode ignorar caminhos inteiros antes de abrir os metadados do arquivo. Campos de partição devem ter cardinalidade controlada; criar um diretório por usuário ou solicitação pode gerar um número inadministrável de pequenas partições.

Muitos arquivos pequenos adicionam planejamento, listagem, conexão e sobrecarga de metadados. Eles também reduzem a quantidade de dados disponíveis para uma compressão eficaz dentro de cada arquivo. Os pipelines geralmente compactam pequenas saídas em arquivos dimensionados para seu mecanismo de consulta e armazenamento de objetos, enquanto preservam limites de partição que suportam poda.

Não existe um tamanho de arquivo universal que se adapte a todos os sistemas. Escolha com base no comportamento do armazenamento de objetos, concorrência de consulta, largura de linha, limites de memória, cadência de escrita e orientação do mecanismo. Meça o tempo de planejamento e também a taxa de transferência de análise.

Parquet Não é um Formato de Tabela

Um arquivo Parquet descreve dados dentro desse arquivo. Ele não fornece por si só um log de transações em milhares de arquivos, isolamento de snapshot, commits atômicos em múltiplos arquivos, alterações em nível de linha, ou um catálogo de quais arquivos pertencem ao estado atual da tabela.

Uma plataforma de dados pode gerenciar essas preocupações através de seu catálogo e camada de tabela. Essa distinção é importante durante atualizações e mudanças de esquema. Listar cada objeto em um diretório e tratá-lo como dados atuais pode incluir arquivos obsoletos ou parcialmente escritos, a menos que o sistema circundante defina a semântica de commit.

Evolução do Esquema

Adicionar uma coluna opcional é frequentemente gerenciável porque arquivos mais antigos simplesmente a carecem e leitores podem fornecer nulo. Renomear uma coluna é mais difícil porque um leitor baseado em nome pode enxergar dois campos diferentes. Alguns ecossistemas rastreiam identificadores de campo estáveis, mas o suporte deve ser consistente entre escritores, leitores e a camada de tabela.

Mudanças em um tipo físico ou lógico requerem um plano de compatibilidade. Ampliar um inteiro pode funcionar em alguns leitores; mudar uma string para um registro aninhado é uma quebra semântica. Armazene versões de esquema, valide novos arquivos antes da publicação e teste leituras de versões mistas.

Não confie no esquema de um único arquivo como o contrato do conjunto de dados inteiro. Um diretório pode conter arquivos escritos por diferentes trabalhos ou em diferentes momentos. O esquema do catálogo e a validação da ingestão devem definir o que é aceito.

Casos de Uso Comuns do Parquet

Quando Não Usar Parquet

Parquet é uma má escolha para um documento que as pessoas precisam editar manualmente, uma resposta de API pública, ou um fluxo de pequenas mensagens independentes. Também é desconfortável para atualizações frequentes de uma única linha e consultas diretas de chave-valor sem um índice ou mecanismo de tabela.

CSV pode ser melhor para uma passagem simples entre analistas. JSON ou NDJSON pode ser melhor para serviços e processamento de eventos. Um banco de dados transacional pode ser melhor para estado operacional mutável. O mesmo pipeline pode receber entradas brutas em um formato e publicar uma camada analítica organizada em Parquet.

Como Criar Dados Parquet Confiáveis

1. Defina o esquema canônico. Especifique nulidade, tipos lógicos, semântica de timestamp, precisão decimal e estruturas aninhadas.
2. Valide os registros de entrada. Resolva conflitos de tipo e valores malformados antes de escrever arquivos.
3. Escolha grupos de linhas e alvos de arquivos por medição. Equilibre memória, compressão, paralelismo e sobrecarga de metadados.
4. Particione para filtros reais. Evite caminhos de alta cardinalidade e partições vazias.
5. Teste todo leitor. Confirme tipos aninhados, anotações lógicas, codecs de compressão e evolução de esquema através do conjunto de mecanismos implantados.
6. Publique atomicamente através da camada de conjunto de dados. Torne arquivos incompletos invisíveis até que a validação e as atualizações do catálogo sejam bem-sucedidas.

Conclusão

Apache Parquet transforma registros tipados em um arquivo orientado a colunas que sistemas analíticos podem ler seletivamente. Seu esquema, codificações, compressão, estatísticas e suporte a dados aninhados reduzem I/O desnecessários para muitas cargas de trabalho pesadas em escaneamento. Esses benefícios dependem de um design sólido de conjunto de dados: esquemas controlados, arquivos e grupos de linhas sensatos, partições úteis, leitores compatíveis e uma camada de tabela quando transações ou instantâneas importam. Parquet é mais forte como o destino analítico organizado, não como um substituto universal para JSON, CSV, bancos de dados ou formatos de evento.