Converter Parquet para TSV

É um contêiner binário. O comando head nele imprime os quatro bytes PAR1 e depois uma tela de ruído, o grep não encontra nada confiável porque os valores são comprimidos e codificados por dicionário, e wc -l reporta um número sem relação com a contagem de linhas. O arquivo foi feito para ser lido por um motor de consulta, e sem um instalado na máquina, ele é opaco.

É essa a situação para a qual esta conversão serve: um extrato Parquet num servidor, um notebook sem permissão de administrador, um contêiner sem nada instalado, ou um arquivo que alguém mandou com uma pergunta que precisa de resposta nos próximos dois minutos. Transformar em linhas é o caminho mais rápido para conseguir responder qualquer coisa sobre ele.

Valores num extrato de dados estão cheios de vírgulas — endereços, nomes de produto, texto livre, números escritos em formato europeu. Um arquivo separado por vírgula precisa envolver tudo isso em aspas, e todo consumidor do arquivo precisa implementar aspas, aspas escapadas e quebras de linha embutidas corretamente antes de conseguir achar uma fronteira de coluna.

Tabulações são quase ausentes desse tipo de dado, então o separador deixa de competir com o conteúdo. Depois desta conversão, cut -f3 acha a terceira coluna, awk -F"\t" acha, e sort -t$'\t' -k2 ordena pela segunda. Nada precisa ser interpretado; as coisas só precisam ser divididas.

Uma tabulação dentro de um valor é a exceção. É mais rara em dados vindos de um Parquet que em dados vindos de uma planilha, mas acontece — campos de texto livre carregam o que quer que tenha sido colado ali originalmente. Quando isso acontece, o conversor escreve esse campo entre aspas duplas, porque a alternativa seria uma linha que silenciosamente ganha uma coluna a mais.

Essa saída está correta e um interpretador de verdade lida com ela. O cut -f não lida: conta caracteres de tabulação e nunca ouviu falar de aspas, então a partir dessa linha ele vê um campo a mais e tudo depois fica deslocado. Se um pipeline produz resultados desalinhados numa fração das linhas, grep -c '"' output.tsv mostra em um segundo se é esse o motivo.

Uma coluna de carimbo de tempo é escrita como string ISO 8601 — 2024-03-11T09:30:00.000Z — a única resposta sensata num formato sem tipo de data. Ela tem uma propriedade que importa muito num shell: ordena cronologicamente sob uma ordenação léxica comum, porque os campos vão do mais significativo ao menos significativo.

sort -k4 numa coluna de data, portanto, faz o que você queria, uniq -c nos primeiros dez caracteres conta linhas por dia, e um filtro de intervalo é uma comparação de string. Nada disso funciona numa data formatada por região, e nada funciona num número de época sem aritmética.

Parquet guarda listas, structs e mapas nativamente. Uma linha de texto não guarda, então uma coluna aninhada é escrita como JSON dentro do campo: uma lista chega como ["a","b"], um struct como um objeto com os nomes dos membros.

Isso é deliberadamente o formato que outra coisa consegue ler. cut -f5 output.tsv | jq ".[0]" pega o primeiro elemento de cada lista, e o aninhamento sobrevive à viagem em vez de ser achatado em colunas cujos nomes você precisaria descobrir. Colunas binárias sem anotação de texto são escritas em hexadecimal minúsculo por um motivo parecido: é reversível, não contém separador, e ninguém confundirá com prosa.

Um nulo é escrito como campo vazio. Toda linha mantém o mesmo número de tabulações, então o arquivo permanece retangular e ferramentas posicionais continuam alinhadas, que é o comportamento necessário.

Também apaga uma distinção que o arquivo de origem fazia com cuidado. Parquet registra nulidade por coluna e distingue um nulo de uma string vazia; na saída os dois são os mesmos zero caracteres entre duas tabulações. Se você está contando valores ausentes, awk -F"\t" '$3==""' conta os dois juntos e nenhum comando de shell os separa de novo.

Tudo que o arquivo Parquet sabia sobre suas colunas — o tipo de cada uma, a contagem de linhas, as estatísticas por coluna — vive num rodapé, e nada disso sobrevive num arquivo separado por tabulação. A saída tem uma linha de cabeçalho com os nomes e depois são só caracteres.

Se você tem algum jeito de ler o schema, leia antes de converter e anote. DESCRIBE SELECT * FROM "arquivo.parquet" no DuckDB imprime tudo numa instrução. Onde não há nada disponível, o texto em si é a única evidência, e o gesto sensato é conferir alguns valores distintos por coluna com cut -f2 | sort -u | head em vez de presumir que uma coluna de dígitos é uma quantidade.

Parquet é comprimido e codificado por dicionário, então o texto que ele expande costuma ser várias vezes o tamanho do arquivo, e frequentemente bem mais que isso. Uma coluna de códigos de status repetidos custou quase nada na origem e custa uma cópia completa por linha na saída.

Vale estimar isso antes de converter um arquivo que você ainda não olhou, porque a tabela expandida fica na memória durante a conversão. Um extrato de cem megabytes pode produzir bem mais que cem megabytes de texto, e o teto aqui chega antes do que o tamanho do arquivo em disco sugere.

O leitor de Parquet é uma biblioteca carregada sob demanda por esta página, e a escrita é JavaScript comum. Nenhuma requisição carrega o arquivo, então um extrato do meio de uma plataforma de dados — geralmente a versão não agregada e não mascarada — não vira uma cópia no servidor de outra pessoa só para ser lido.

Não há fila nem cadastro, e o teto é 100 MB por arquivo. Para um arquivo grande demais, a resposta é um motor de consulta, não um conversor maior, e é uma resposta melhor de qualquer forma, porque permite pegar só as colunas que interessavam.