Quando uma equipa começa a construir um data lake, a conversa costuma girar à volta de ferramentas: que motor de processamento, que orquestrador, que plataforma na cloud. Mas há uma decisão mais discreta que acaba por determinar metade do desempenho e do custo da plataforma — o formato em que os dados ficam guardados no disco. É aqui que entram nomes como Parquet, Avro e ORC.
Estes três formatos abertos resolvem o mesmo problema — guardar grandes volumes de dados de forma eficiente — mas fazem-no de maneiras diferentes, pensadas para cargas de trabalho diferentes. Escolher mal não parte nada de imediato: os dados continuam lá. O que acontece é mais subtil. As consultas ficam mais lentas, a fatura de armazenamento e de compute sobe, e ninguém percebe bem porquê.
Este artigo explica como cada formato funciona, onde brilha e onde tropeça, para que a escolha deixe de ser um detalhe herdado de um tutorial e passe a ser uma decisão consciente.
Linha ou coluna: a decisão que muda tudo
Antes dos nomes, a ideia base. Um ficheiro de dados pode organizar a informação de duas formas: por linha ou por coluna.
Num formato orientado à linha, os valores de um registo ficam juntos: nome, idade, cidade e data de um cliente ficam gravados em sequência, e o cliente seguinte vem a seguir. É ótimo para escrever um registo de cada vez e para ler registos inteiros — como faz uma aplicação transacional.
Num formato orientado à coluna, é o contrário: todos os nomes ficam juntos, depois todas as idades, depois todas as cidades. Ler uma tabela inteira passa a ser mais trabalhoso, mas responder a "qual a idade média dos clientes de Lisboa" fica muito mais rápido, porque o motor só lê as colunas idade e cidade e ignora tudo o resto. Em analítica, onde as consultas tocam poucas colunas mas milhões de linhas, esta diferença é enorme.
Guardar esta distinção na cabeça resolve 80% das dúvidas: Parquet e ORC são colunares; Avro é orientado à linha. O resto são detalhes — importantes, mas detalhes.
Parquet: o formato colunar que domina a analítica
O Apache Parquet tornou-se o formato por omissão de praticamente todo o ecossistema de dados moderno. Se usas Spark, um lakehouse ou um motor de consulta como o Trino, é quase certo que os dados estão em Parquet — e há boas razões para isso.
Ao guardar os dados por coluna, o Parquet permite que o motor leia apenas as colunas necessárias (a chamada projection pushdown). Como valores da mesma coluna são semelhantes entre si — muitas datas parecidas, muitos códigos repetidos — a compressão é muito mais eficaz do que num formato de linha. Além disso, o Parquet guarda estatísticas por bloco (mínimo, máximo, contagem de nulos), o que deixa o motor saltar blocos inteiros que não interessam à consulta (predicate pushdown). Menos dados lidos significa consultas mais rápidas e mais baratas.
O reverso da medalha: escrever um único registo de cada vez em Parquet é ineficiente. O formato foi pensado para escrever muitos registos de uma vez e ler muitas vezes — não para atualizações constantes de linhas soltas.
ORC: o primo colunar do mundo Hive
O Apache ORC (Optimized Row Columnar) nasceu no ecossistema Hive e resolve o mesmo problema que o Parquet, também de forma colunar. Na prática, os dois são mais parecidos do que diferentes: ambos comprimem bem, ambos guardam estatísticas, ambos aceleram consultas analíticas.
As diferenças são de afinação. O ORC tende a conseguir rácios de compressão ligeiramente melhores em alguns cenários e traz índices leves e suporte robusto a transações ACID quando usado dentro do Hive. O Parquet, por seu lado, tem um suporte mais universal fora do mundo Hadoop — bibliotecas, motores e serviços cloud falam Parquet de forma nativa.
A regra prática: se o teu ambiente é fortemente Hive/Hadoop, o ORC sente-se em casa. Se queres o denominador comum que funciona em todo o lado, o Parquet é a aposta segura. Escolher entre os dois raramente é o que decide o sucesso de uma plataforma — usar um formato colunar em vez de linha, esse sim, faz diferença.
Avro: quando a linha e o esquema mandam
O Apache Avro joga noutro campeonato. É orientado à linha, o que o torna mau candidato para consultas analíticas que varrem poucas colunas — mas excelente para outra coisa: mover dados e escrever registos à medida que chegam.
O Avro guarda o esquema junto dos dados, em JSON, e leva a sério a evolução de esquema: podes acrescentar um campo novo, dar-lhe um valor por omissão e continuar a ler ficheiros antigos sem partir nada. Por isso é o formato natural para fluxos de eventos — é omnipresente em pipelines com Kafka — e para a camada onde os dados aterram em bruto antes de serem transformados.
Pensa no Avro como o formato do transporte e da aterragem, e no Parquet/ORC como o formato do armazém analítico. Muitas arquiteturas usam os dois: recebem eventos em Avro e, mais à frente no pipeline, reescrevem-nos em Parquet para consulta.
Compressão, esquema e evolução
Os três formatos suportam compressão, mas com nuances. Nos colunares, como os valores semelhantes ficam lado a lado, algoritmos como Snappy (rápido) ou ZSTD (mais compacto) rendem muito. A escolha do codec é um compromisso clássico: comprimir mais poupa armazenamento mas gasta mais CPU a ler e escrever.
Quanto ao esquema, todos o guardam com os dados — o que evita o pesadelo de ficheiros CSV sem cabeçalho fiável. A diferença está na cultura de evolução: o Avro foi desenhado à volta dela, com regras claras de compatibilidade para a frente e para trás. Parquet e ORC também evoluem esquema, mas a disciplina fica mais do lado da tabela (por exemplo, através de formatos de tabela como Delta Lake ou Iceberg, que gerem metadados por cima dos ficheiros).
O problema dos ficheiros pequenos
Há uma armadilha que apanha quase toda a gente, e não depende do formato: os ficheiros pequenos. Um data lake com milhões de ficheiros minúsculos — resultado, por exemplo, de escritas em streaming a cada poucos segundos — fica lento independentemente de ser Parquet, ORC ou Avro. Cada ficheiro tem um custo fixo de abertura e de leitura de metadados; multiplicado por milhões, esse custo domina tudo.
- Sintoma: consultas simples demoram uma eternidade e o motor passa mais tempo a listar ficheiros do que a ler dados.
- Causa: ingestão frequente que gera muitos ficheiros pequenos, sem consolidação.
- Cura: processos de compaction que juntam ficheiros pequenos em ficheiros maiores (idealmente na ordem das centenas de MB), e particionamento sensato que não fragmente os dados em excesso.
Escolher o formato certo não salva uma plataforma cheia de ficheiros pequenos. Os dois problemas têm de ser resolvidos em conjunto.
Como escolher sem complicar
Reduzindo tudo ao essencial, a decisão cabe em três perguntas:
- Vais consultar poucas colunas de tabelas grandes? Usa um formato colunar — Parquet como escolha por omissão, ORC se vives no mundo Hive.
- Vais mover eventos ou aterrar dados em bruto que mudam de forma? Avro, pela evolução de esquema e pela escrita registo a registo.
- Precisas de transações, time travel ou atualizações? A resposta já não é só o formato de ficheiro, mas um formato de tabela (Delta Lake, Iceberg, Hudi) por cima de Parquet ou ORC.
Na maioria das plataformas, a combinação vencedora é banal: Avro (ou JSON) à entrada, Parquet no armazém analítico. Não é preciso mais exotismo do que isto para acertar.
Mini-caso: uma empresa de retalho a arrumar o data lake
Uma empresa de retalho com loja física e online guardava tudo — vendas, cliques, stock — em ficheiros JSON comprimidos, escritos de hora a hora. Os relatórios diários demoravam cerca de 40 minutos e a fatura de compute não parava de crescer. A equipa achava que precisava de um motor mais potente; na verdade, precisava de arrumar a casa.
Fizeram duas mudanças. Primeiro, passaram a reescrever os dados históricos em Parquet particionado por data, com compressão ZSTD. Segundo, introduziram um passo de compaction noturno que consolidava os milhares de ficheiros pequenos do dia em poucos ficheiros grandes. Mantiveram o Avro apenas na camada de entrada, onde os eventos chegam.
O resultado: os relatórios que demoravam 40 minutos passaram a correr em cerca de 6, o volume de dados lido por consulta caiu para uma fração do anterior e o armazenamento encolheu perto de 60% com a melhor compressão. Nenhum motor novo, nenhuma reescrita da aplicação — apenas o formato certo, no sítio certo, sem ficheiros pequenos a atrapalhar.
Na prática
Formatos de ficheiro não são o tema mais glamoroso de uma plataforma de dados, mas são dos que mais silenciosamente decidem o seu custo e a sua velocidade. A boa notícia é que a decisão é simples quando se percebe a lógica: colunar (Parquet ou ORC) para consultar, linha (Avro) para transportar e aterrar.
Antes de trocar de motor ou de aumentar recursos por causa de consultas lentas, vale a pena olhar para baixo, para o formato e o tamanho dos ficheiros. Muitas vezes, o ganho maior está exatamente aí — e não custa uma licença nova, apenas uma decisão de engenharia bem tomada.
