Formatos de Dados e Compressão: CSV, JSON, Avro, Parquet e ORC

O Amazon Athena precifica uma única coisa: "Consultar dados comprimidos é mais rápido e também mais barato porque você paga pelo número de bytes varridos antes da descompressão" (Amazon Athena User Guide, Compression formats, acesso em 2026-10-11). Todo o resto de um design de lakehouse, partições, workgroups, tamanhos de cluster, regras de ciclo de vida, fica a montante de uma decisão que você toma na primeira semana e depois convive por anos: qual formato de arquivo, qual codec de compressão e de que tamanho deve ser cada objeto.

A AWS publica a mesma decisão como uma história de custos em três passos na própria página de preços: uma tabela de 3 TB com quatro colunas, uma única query de uma coluna, cobrada a $5.00 por TB varrido em outubro de 2026. Texto sem compressão = $15.00. Gzip no texto a 3:1 = $5.00. Gzip e conversão para Parquet, de modo que só uma das quatro colunas seja lida = $1.25. Mesma query, mesma resposta, mesmos dados: um spread de 12× criado inteiramente por escolhas de formato e compressão.

É por isso que esta lição vem antes dos formatos de tabela, antes do ETL, antes da camada de consulta. Se os bytes estiverem errados, nenhum tuning de motor devolve esse dinheiro.

Nesta lição você vai:

• ler corretamente a anatomia linha versus colunar, row groups, column chunks, data pages, footers, estatísticas min/max, o page index opcional, e ver exatamente onde acontece o predicate pushdown;
• usar a matriz de formatos para CSV, JSON, Avro, Parquet, ORC e Protobuf: orientação, schema in-file, splittability, tipos aninhados e qual motor AWS realmente vai ler cada um;
• aplicar a matriz de evolução de schema por formato, incluindo por que o Parquet lê por nome enquanto o ORC lê por índice e o que isso te custa;
• explicar encodings, dictionary + RLE, run-length encoding, a família delta, BYTE_STREAM_SPLIT, e por que eles rodam antes da compressão;
• escolher entre Snappy, Gzip, Zstd e LZ4 com números de benchmark de terceiros datados na mão, em vez de folclore;
• dimensionar arquivos na faixa de 128 MB: 1 GB e diagnosticar (e depois corrigir) o problema dos arquivos pequenos;
• percorrer um fluxo de decisão de quando usar qual da zona de aterrissagem crua até o gold;
• resolver sete exemplos resolvidos com números reais em outubro de 2026: a aritmética do Athena, as razões de codec, o desastre de contagem de arquivos do micro-batch, um CTAS de 420 GB de CSV → Parquet, o fator de expansão do JSON, a recomendação Iceberg + ZSTD e a decisão de codec para uma tabela quente;
• estudar casos reais nomeados de clientes da AWS, o "data swamp" de arquivos Parquet da Vanguard e o lake colunar da Nasdaq, além da Woot.com e da ZS;
• ler a caixa de atualizações de outubro de 2026 (Glue 6.0 Iceberg v3, S3 Metadata, compactação do S3 Tables) e responder doze questões no estilo de exame com quatro verificações interativas.

---

1. Linha versus colunar: a anatomia que define sua conta

1.1 Um formato de linha armazena registros, inteiros e repetidos

CSV, TSV, NDJSON, Avro e Protobuf são formatos de linha: os campos de um registro ficam juntos. A vantagem é exatamente o que um produtor precisa: escrever o registro inteiro, ler o registro inteiro, anexar o próximo registro. A desvantagem aparece no momento em que uma query toca um campo só, dos quarenta.

SELECT amount FROM events WHERE date >= '2026-01-01' contra texto orientado a linha tem que percorrer cada byte de cada linha e pular os trinta e nove campos de que não precisa. Não existe como pular direto para a coluna amount, porque a coluna amount não existe como região contígua em lugar nenhum do arquivo.

O JSON acrescenta um segundo custo, mais silencioso: as chaves se repetem em cada registro. A matriz de formatos do digest diz isso sem rodeios: JSON tem "no in-file schema (keys repeat per record)". O Avro resolve essa metade do problema ao embutir um JSON schema no arquivo (e manter o schema do writer ao lado dos dados para a schema resolution), mas continua orientado a linha.

1.2 Um formato colunar armazena campos, inteiros e repetidos

Parquet e ORC são colunares: os valores de uma coluna ficam juntos, então uma query de 2 das 40 colunas lida algo como 2/40 dos dados mais os metadados. Isso não é uma razão de marketing: é o mecanismo pelo qual o Athena cobra. A própria página de armazenamento colunar do Athena diz que o predicate pushdown "enables Athena queries to fetch only the blocks it needs … it uses statistics from data block predicates, such as max/min values, to determine whether to read or skip the block" (acesso em 2026-10-11).

1.3 …e ambos são, na verdade, híbridos (PAX)

A descrição honesta não é "linha" nem "colunar", e sim PAX: um híbrido que particiona linhas horizontalmente primeiro e depois armazena as colunas de cada partição separadamente. Como diz o survey acadêmico de 2023: "both Parquet and ORC employ the PAX format. The DBMS first partitions a table horizontally into row groups. It then stores tuples column-by-column within each row group" (arXiv 2304.05028, 2023-11-07: fonte acadêmica de terceiros).

Daí seguem duas consequências, e as duas caem em prova:

1. "Linha versus colunar" é um espectro, não um interruptor. Reconstituir uma linha completa ainda toca uma unidade de localidade (um row group, um stripe): só que uma muito menor do que um arquivo de texto inteiro.
2. O tamanho da unidade é um knob de tuning, não uma constante. O Athena documenta os padrões: "O tamanho padrão dos row groups é 128 MB e o dos stripes, 64 MB … Diminuir o tamanho do row group ou do stripe … não é recomendado" (acesso em 2026-10-11).

1.4 Anatomia de um arquivo Parquet, ponta a ponta

A própria documentação de formato do Parquet descreve um arquivo que começa e termina com um magic number de 4 bytes PAR1, guarda um ou mais row groups e grava os metadados do arquivo por último, de modo que o writer faz uma única passagem. O contrato do leitor é o espelho: "Os leitores devem primeiro ler os metadados do arquivo para encontrar todos os column chunks de que precisam" (parquet.apache.org/docs/file-format/, acesso em 2026-10-11).

O README do parquet-format acrescenta dois fatos que valem decorar: "A file consists of one or more row groups. A row group contains exactly one column chunk per column. Column chunks contain one or more pages", e dados aninhados usam "a codificação Dremel com níveis de definição e repetição".

A orientação de tamanho varia por workload, e os dois números são oficiais:

1.5 Estatísticas, page index e predicate pushdown

O footer carrega Statistics {min_value, max_value, null_count, distinct_count} por column chunk (parquet.thrift, acesso em 2026-10-11). Um predicado de query é avaliado contra esses intervalos antes que qualquer data page seja lida:

A documentação de page index do Parquet descreve o payoff com precisão: "a page index is optional metadata for a ColumnChunk, containing statistics for DataPages that can be used to skip those pages", e "A single-row lookup in a row group … will only read one data page per retrieved column" (acesso em 2026-10-11).

O equivalente no ORC não é opcional e é mais fino por padrão. O ORC fornece "three level of indexes within each file: file level … stripe level … row level: statistics … for each set of 10,000 rows within a stripe" (orc.apache.org/docs/indexes.html, acesso em 2026-10-11), e "As of Hive 1.2, the indexes can include bloom filters". O passo de 10,000 linhas é o orc.row.index.stride=10,000 do Hive. O ORC também dimensiona seus blocos de compressão em 256 KiB (orc.compress.size=262,144), de modo que um bloco de que não se precisa nunca chega a ser descomprimido.

• 📚 Você sabia? Os crawlers do Glue descobrem o schema de um arquivo lendo partes diferentes de formatos diferentes: Avro "Lê o schema no começo do arquivo", Parquet "Lê o schema no fim do arquivo", ORC "Reads the file metadata", e o JSON lê o começo (AWS Glue classifiers, acesso em 2026-10-11). É por isso que um objeto Parquet truncado, com o footer faltando, é indecifrável para um crawler, enquanto um objeto Avro truncado não é.

1.6 Exemplo resolvido E1: a aritmética de $15 →$5 → $1.25 (em out 2026)

O exemplo publicado pela própria AWS (aws.amazon.com/athena/pricing/, acesso em 2026-10-11): uma tabela de 3 TB com quatro colunas, uma query que lê uma única coluna, Athena sob demanda a $5.00 por TB varrido.

Escale: a 600 queries por mês isso dá $9,000.00 contra $3,000.00 contra $750.00: um delta mensal de $8,250.00 entre o pior e o melhor design sobre dados idênticos. A compressão comprou os primeiros 3×; o layout colunar mais o predicate pushdown comprou os próximos 4×.

Note a ordem. A compressão ajuda na proporção dos bytes varridos; a poda de colunas multiplica isso. Você não chega aos $1.25 com CSV só com gzip, e não chega neles com Parquet se toda query selecionar as quatro colunas.

2. A matriz de formatos: CSV, JSON, Avro, Parquet, ORC e Protobuf

2.1 A matriz central

Seis formatos, quatro eixos. Tudo na tabela vem da documentação da AWS e da Apache citada no digest (todos com acesso em 2026-10-11).

Três linhas merecem comentário.

Protobuf não é um formato de lakehouse consultável no Athena. A tabela de SerDes suportados do Athena lista Ion, Avro, Parquet, CSV, JSON, ORC, TSV e formatos de log, o Protobuf está ausente. O que o Protobuf tem são duas posições legítimas na AWS: como entrada do Glue Schema Registry ("Protocol Buffers (Protobuf) versions proto2 and proto3 without support for extensions or groups", acesso em 2026-10-11), e como entrada do conector MSK do Athena ao lado de JSON, CSV e AVRO. Aterrisse, converta, consulte, nessa ordem.

O Firehose converte JSON e nada mais. "Amazon Data Firehose can convert the format of your input data from JSON to Apache Parquet or Apache ORC before storing the data in Amazon S3 … If you want to convert an input format other than JSON, such as comma-separated values (CSV) … use AWS Lambda to transform it to JSON first" (docs do Firehose, acesso em 2026-10-11). Com a conversão habilitada, o Amazon S3 é o único destino, a compressão do lado do S3 fica desabilitada e "Snappy compression happens automatically" usando framing compatível com Hadoop.

NDJSON é o único formato de JSON que o Athena aceita bem. O JSON SerDe do Athena é orientado a linha, então um objeto JSON por linha (JSON Lines) funciona e JSON pretty-printed ou embrulhado em array não funciona. Aterrisse NDJSON, não JSON bonitinho.

2.2 Splittability: a propriedade que todo mundo entende ao contrário

A concepção mais comum desta lição: "Parquet é comprimido, então não é divisível." Errado. O próprio blog Top-10 de tuning do Athena da AWS (2017-03-24) afirma: "Os arquivos Parquet e ORC são sempre divisíveis porque esses formatos comprimem seções dos arquivos separadamente e têm metadados que contêm as posições dentro dos arquivos."

O que não é divisível é texto comprimido:

• "a maioria dos arquivos de texto comprimidos não é divisível": um gzip.csv de 2 GB é um split e portanto um worker;
• bzip2 e LZO são as exceções divisíveis entre os codecs de texto, mas "não recomendado se você quer desempenho e compatibilidade";
• a própria regra de tamanho do blog: "mire em splits de cerca de 128 MB".

O Athena reforça o teto de paralelismo para dados comprimidos: o número de arquivos é o teto de workers. Um arquivo gigante significa um worker, independentemente do tamanho do cluster.

2.3 Evolução de schema: a matriz que ninguém ensina até quebrar

O Athena publica uma matriz por formato do que sobrevive a qual mudança de schema (handling-schema-updates-chapter.md, acesso em 2026-10-11). A razão mecânica por trás da tabela cabe em uma linha: "By default, Parquet will access columns by name and ORC by index (ordinal value)".

Leia a tabela como designer, não a decore:

• Parquet com leitura por nome te compra add / remove / reorder e te custa o rename. Vire parquet.column.index.access=true e você ganha rename ao preço de add/remove/reorder. Isso é uma decisão de design de schema, não uma configuração de performance.
• ORC é o espelho: rename funciona, mudança estrutural não funciona, até você virar orc.column.index.access=false.
• Avro vai mais longe porque sua spec define uma Schema Resolution formal: schema do writer mais schema do reader, promotions como "int … long, float, double", "string is promotable to bytes", e defaults para campos que o writer não tem: com a regra de que "files or systems that store Avro data should always include the writer's schema."
• O Iceberg escapa em grande parte dessa tabela, porque armazena field IDs e seus próprios metadados de schema (lição 04). Arquivos crus no S3 ainda obedecem a cada linha da matriz acima.

2.4 Interativo: correlacione o formato com suas características

• 📚 Você sabia? O Athena vai ler silenciosamente alguns arquivos comprimidos de forma errada porque usa a extensão do arquivo como chave: "extensões de arquivo em maiúsculas como .GZ … não são reconhecidas pelo Athena" (acesso em 2026-10-11). Um script de CLI que grava part-00000.csv.GZ em vez de .gz produz uma tabela que lista arquivos mas não varre nada. Mantenha todas as extensões em minúsculas.

3. Encodings: o que acontece antes da compressão

A compressão é a segunda passagem. A primeira é o encoding: converter valores tipados em uma representação de bytes que explora a forma da coluna. Tanto o Parquet quanto o ORC aplicam essa camada, e é dela que vem a maior parte do ganho de tamanho de verdade.

3.1 Dictionary encoding + RLE, o cavalo de batalha de baixa cardinalidade

Para uma coluna com poucos valores distintos (códigos de país, flags de status, nomes de eventos), o writer monta um dicionário de valores únicos e substitui cada ocorrência por um ID inteiro pequeno. Esses IDs depois passam por run-length encoding. O registro de encodings do Parquet chama essa combinação de RLE_DICTIONARY (valor de enum 8).

A regra de fallback importa mais que o caminho feliz: "Se o dicionário crescer grande demais … a codificação recua para a codificação plain" (parquet.apache.org, modificado em 2026-02-24). Colunas de alta cardinalidade, IDs de usuário, UUIDs, timestamps com precisão de microssegundo, estouram o orçamento do dicionário e caem silenciosamente para PLAIN, que aí é comprimido só pelo codec.

Um exemplo medido dessa falésia: desligar o dictionary encoding em uma única coluna de um arquivo Parquet de 10 M de linhas acrescentou 18.79 MiB (aicodeinvest.com, 2026-07-19: benchmark de terceiros). O orçamento padrão de dicionário do Iceberg é write.parquet.dict-size-bytes = 2097152 (2 MB).

3.2 Run-length encoding e bit packing

RLE só compensa quando os valores realmente se repetem: booleanos, colunas de status ordenadas e os níveis de definição/repetição que o Dremel usa para dados aninhados. Bit packing guarda inteiros pequenos no número mínimo de bits e é amigável a SIMD.

O survey acadêmico de 2023 traça a linha prática: o Parquet só muda para RLE quando o run length ≥ 8, enquanto o ORC entrega quatro encodings de inteiros separados. Nos testes deles, isso ajudou o Parquet a varrer mais rápido, enquanto os zone maps mais finos do ORC ajudaram point lookups seletivos (arXiv 2304.05028, 2023-11-07: terceiros).

3.3 A família delta e os encodings de float

• DELTA_BINARY_PACKED (enum 5): deltas entre inteiros ordenados, muito eficaz em timestamps e números de sequência ordenados.
• DELTA_LENGTH_BYTE_ARRAY (enum 6) e DELTA_BYTE_ARRAY (enum 7): para strings com prefixos e comprimentos parecidos.
• BYTE_STREAM_SPLIT (enum 9) e ALP (enum 10): para colunas de ponto flutuante.

O kit equivalente do ORC, na própria especificação: "type specific readers and writers that provide light weight compression techniques such as dictionary encoding, bit packing, delta encoding, and run length encoding … Additionally, ORC can apply generic compression using zlib, or Snappy on top of the lightweight compression."

O registro completo de encodings do Parquet em out 2026: PLAIN=0, PLAIN_DICTIONARY=2 (descontinuado), RLE=3, BIT_PACKED=4, DELTA_BINARY_PACKED=5, DELTA_LENGTH_BYTE_ARRAY=6, DELTA_BYTE_ARRAY=7, RLE_DICTIONARY=8, BYTE_STREAM_SPLIT=9, ALP=10.

---

4. Codecs de compressão: Snappy, Gzip, Zstd, LZ4

4.1 O trade em um único eixo

A própria página de compressão do Parquet enquadra isso como um espectro: "The Parquet format supports several compression codecs covering different areas in the compression ratio / processing cost spectrum": SNAPPY, GZIP, LZO, BROTLI, LZ4 (framing Hadoop descontinuado), ZSTD, LZ4_RAW (acesso em 2026-10-11).

4.2 O que a AWS recomenda, com as palavras da própria AWS

• Zstd para Iceberg. "Recomendamos usar o codec de compressão ZSTD porque ele equilibra GZIP e Snappy … o Snappy pode oferecer o melhor desempenho geral de leitura e escrita, mas tem uma taxa de compressão menor que GZIP e ZSTD" (AWS Prescriptive Guidance, Apache Iceberg on AWS: general best practices, acesso em 2026-10-11).
• Níveis do Zstd. "níveis de 1 a 22 … o Athena usa o nível de compressão ZSTD 3 por padrão … recomendamos usar o nível padrão 3 ou um nível na faixa de 6 a 9 … use níveis maiores que 19 com cautela." A propriedade compression_level é suportada apenas no Athena engine version 3 (acesso em 2026-10-11).
• Gzip é amplo e confiável. "GZIP … is the default write compression format for files in the Parquet and text file storage formats" para tabelas Hive com engine v2/v3, e "provides good compression ratios and has wide range support" (acesso em 2026-10-11).
• Zstd é o mais novo e o equilibrado. "a newer compression format with a good balance between performance and compression ratio" (acesso em 2026-10-11).

4.3 Benchmarks de terceiros datados (rotulados como tal)

Nenhum dos números abaixo é publicado pela AWS; todos são datados e, em princípio, reproduzíveis.

Benchmark de codecs em Parquet de 10 M de linhas (aicodeinvest.com, 2026-07-19):

Duas leituras dessa tabela: o gzip foi ~47× mais lento para escrever que o zstd nível 3 (44.363 ÷ 0.942) e ainda produziu um arquivo maior, e o zstd nível 9 comprou 0.09 MiB por 2.5× o tempo de escrita do nível 3. A escolha de nível não é de graça: é exatamente por isso que o Athena recomenda 3 ou 6 to 9 e alerta acima de 19.

Dois datasets públicos, Parquet com e sem codecs (jeronimo.dev, 2025-01-16, terceiros): os CSVs de origem de 1,761 MB e 2,983 MB viraram: Parquet sem compressão 564 / 760 MB; snappy 220 / 542; gzip 146 / 448; zstd 148 / 430; lz4_raw 209 / 547; lzo 215 / 518. Segundos de escrita nos mesmos dois datasets: nenhum 25.0 / 57.9; snappy 25.2 / 56.4; gzip 39.3 / 91.1 (algo como +50%); zstd 27.3 / 64.1; lz4_raw 24.9 / 56.5; lzo 26.0 / 56.1. O overhead de descompressão medido foi de 10 to 20%.

Micro-benchmark de codecs (mamonas.dev, 2025-08-18, terceiros): Snappy e LZ4 descomprimem a ">3.5 GB/s"; o Zstd mantém algo como 1 GB/s entre os níveis; o gzip é o mais lento; o Zstd no nível 19 escreve extremamente devagar.

Migração de produção da Uber (blog de engenharia da Uber, 2022-01-24, terceiros): ao mover suas top-10 tabelas "From GZIP to ZSTD … ~7% drops in storage size, while from SNAPPY to ZSTD, we see ~39% reduction", e "~~79% size reduction" contra o sem compressão. A compute também caiu: 870,472 → 639,184 → 213,914 vCoreSeconds em Snappy → Gzip → Zstd num único trimestre medido: uma redução de 75.4% do Snappy para o Zstd.

4.4 Interativo: os padrões de codec, preencha-os

• 📚 Você sabia? "Snappy" aparece duas vezes nesta lição com dois trabalhos diferentes: é um codec que você escolhe para Parquet ou ORC, e é o que o Firehose aplica automaticamente sempre que a conversão de formato de registro está habilitada ("However, Snappy compression happens automatically … The framing format for Snappy … is compatible with Hadoop"). É por isso que a documentação do Firehose manda você definir CompressionFormat como UNCOMPRESSED quando a conversão está ligada: senão você comprime duas vezes e paga as duas.

4.5 Exemplo resolvido E2: aritmética de codec em uma tabela de staging de 10 GB por hora (em out 2026)

Um pipeline estagina 10 GB por hora e o caminho de escrita é limitado por CPU. Usando o benchmark de terceiros de 10 M de linhas acima (aicodeinvest.com, 2026-07-19) como proxy de escala:

Leitura dos números: o Zstd nível 3 bate o Gzip nos dois eixos nesta execução: arquivo menor e cinquenta vezes mais rápido para escrever. Não existe cenário nesta tabela em que o Gzip vença; ele perde em razão para o Zstd e perde em velocidade para tudo. O Snappy é 2.7 GB/hora maior que o Zstd-3 (≈ 65 GB/dia, ≈ 23.7 TB/ano ao longo de 365 dias de estagiação contínua) por uma economia no caminho de escrita que ninguém consegue medir.

As regras defensáveis:

• estagiação limitada de escrita → Snappy (ou LZ4), porque Firehose e Spark já têm esse padrão e a perda de razão é o preço do throughput;
• tabelas curadas limitadas de armazenamento ou de scan → Zstd nível 3, que é o padrão do Iceberg no Athena e a recomendação do AWS Prescriptive Guidance;
• nunca escolha Gzip para gravação de Parquet por causa da velocidade de escrita, o Gzip existe no mundo porque é o padrão de CTAS do Athena, não porque seja o melhor codec.

5. Dimensionamento de arquivos e o problema dos arquivos pequenos

5.1 A faixa

Abaixo de algo como 128 MB por arquivo, o overhead por objeto domina: custo de GET/LIST do S3, tempo de listagem, setup de footer e dicionário, metadados de partição do Glue, e, o que o Athena declara diretamente, "Para arquivos pequenos, o overhead do formato colunar supera os benefícios." Acima de algo como 1 GB você começa a perder paralelismo de split e a aumentar o custo de retry de uma task que falha.

5.2 Exemplo resolvido E3, o desastre de contagem de arquivos do micro-batch (em out 2026)

Uma equipe grava 1 TB por dia em micro-batches de 5 segundos, acreditando que micro-batches dão frescor.

• Arquivos por dia: 86,400 s ÷ 5 s = 17,280 arquivos/dia
• Bytes por arquivo: 1,000 GB ÷ 17,280 ≈ 58 MB: já abaixo da faixa
• Em um mês: ≈ 518,400 objetos, cada um com seu próprio footer, seu próprio GET no S3, sua própria entrada de listagem

Agora coalesça para a faixa da lição:

• A 1 GB por arquivo: 1,000 GB ÷ 1 GB = 1,000 arquivos/dia (redução de 17×)
• A 128 MB por arquivo: 1,000 ÷ 0.128 = 7,813 arquivos/dia (redução de 2.2×)

O sintoma que você realmente vai ver não é "lento", e sim o tempo de planejamento virando uma parcela relevante do tempo total de execução da query, o Athena enumerando centenas de milhares de objetos, montando um plano e depois varrendo uma quantidade minúscula de dados. O conserto é compactação (lição 04) ou dimensionamento de escrita (lição 08), nunca um retorno ao CSV.

5.3 O funil dos arquivos pequenos, medido

O caso EMR + Iceberg da própria AWS (AWS Big Data Blog, 2023-10-03) é o conjunto de números mais limpo deste curso:

Cada passo desse funil é um conserto de formato e tamanho de arquivo, não de compute: nenhum cluster foi redimensionado, nenhuma query foi reescrita, nenhuma partição foi adicionada. Os objetos simplesmente passaram a ter o formato certo no tamanho certo.

• 📚 Você sabia? Formatos colunares tornam os arquivos pequenos piores, não melhores. A página de performance tuning do Athena diz em voz alta: "Para arquivos pequenos, o overhead do formato colunar supera os benefícios." Um arquivo Parquet de 40 KB ainda carrega um par de magic PAR1, um footer com schema completo, estatísticas e estado do dicionário: overhead que pode exceder os próprios dados. Texto puro de 40 KB ao menos não tem footer para escrever.

---

6. Quando usar qual: o fluxo de decisão

6.1 O fluxo

6.2 A regra camada por camada

6.3 Exemplo resolvido E4: CSV → Parquet com Athena CTAS (em out 2026)

Entrada: 420 GB de CSV delimitado por quebras de linha em s3://lake/raw/ghcn/, 60 colunas.

Passo 0: DDL da tabela crua e baseline.

Passo 1: CTAS. Este é o padrão oficial da AWS (Athena CTAS INSERT INTO ETL, mais o walkthrough do AWS Big Data Blog de 2019-11-27):

Uma única instrução define formato, codec, particionamento e localização, e registra automaticamente a tabela no Glue Data Catalog. (Formatos aceitos pelo CTAS: PARQUET, ORC, AVRO, JSON, TEXTFILE: Parquet se você omitir format.)

Passo 2: incremental. INSERT INTO ghcn_parquet SELECT … WHERE year_col = '2026';

Passo 3, a aritmética. Aplicando o resultado de dois datasets de terceiros (Parquet + codec ≈ 9 to 15% do CSV; jeronimo.dev, 2025-01-16, terceiros, não uma garantia da AWS):

• 420 GB × 0.09 → 420 GB × 0.15 = ≈ 38 GB: 63 GB no S3
• query de uma coluna lê 63 GB ÷ 60 colunas ≈ 1.05 GB
• custo: 1.05 GB a $5.00/TB ≈ $0.005 contra 420 GB a $5.00/TB ≈ $2.10: uma redução de ≈400× por query

Passo 4, verifique. Confira Data Scanned no console do Athena, aws s3 ls --summarize no prefixo prata, e confirme que os objetos caem na faixa de 128 MB, 1 GB, e não em quilobytes.

Passo 5: guardrails. Limite de uso de dados do workgroup, partition projection em year_col e uma política de mudança de schema de crawler do Glue MergeNewColumns.

O walkthrough publicado do CTAS da AWS chegou em "Size of dataset after parquet with snappy compression: 1.2 GB", e a nota dele é a lição: "the file sizes are pretty small. Merging them into larger files … would lead to faster query execution."

6.4 Exemplo resolvido E5, o fator de expansão do JSON (em out 2026)

Pegue um registro de sensor de seis campos e compare as representações. Isto é aritmética trabalhada sobre um registro ilustrativo, não um benchmark publicado, o fato que ele demonstra (o JSON repete chaves por registro) vem da matriz de formatos da §2.1.

CSV (52 bytes):

NDJSON (107 bytes):

• Expansão: 107 ÷ 52 = 2.06×: a mesma informação, 106% maior
• Dos 107 bytes, 45 bytes (42%) são tokens de nome de campo repetidos ("ts":, "device":, "region":, "temp":, "status":, "seq":) mais as chaves: estrutura que nunca muda entre registros
• A 1,000,000 registros/dia: CSV ≈ 52 MB/dia (≈ 19.0 GB/ano), JSON ≈ 107 MB/dia (≈ 39.1 GB/ano): ≈ 20.1 GB/ano de pura repetição, antes de qualquer compressão
• E os codecs de compressão tratam os dois como texto opaco: Gzip e Zstd comprimem a repetição um pouco, mas só um formato colunar a remove estruturalmente ao guardar cada campo uma vez por row group

A consequência de design: a repetição do JSON não é um problema de armazenamento que você resolve com um codec melhor, é um problema de representação que você resolve com uma conversão na fronteira prata: exatamente o que faz a conversão de formato de registro do Firehose ou um CTAS.

6.5 Exemplo resolvido E6: a recomendação Iceberg + ZSTD (em out 2026)

AWS Prescriptive Guidance, Apache Iceberg on AWS: general best practices (acesso em 2026-10-11), declara a recomendação: "recomendamos usar o codec de compressão ZSTD porque ele equilibra GZIP e Snappy … o Snappy pode oferecer o melhor desempenho geral de leitura e escrita, mas tem uma taxa de compressão menor que GZIP e ZSTD." A própria glossa do Athena sobre o mesmo par: Zstd é "a newer compression format with a good balance between performance and compression ratio" (acesso em 2026-10-11).

A configuração do próprio Iceberg a confirma como o padrão entregue (iceberg.apache.org/docs/1.10.2/configuration/, acesso em 2026-10-11):

E o Athena já o grava: "ZSTD is the default compression for Iceberg tables … level 3 by default."

A aritmética. Pegue uma tabela Iceberg de 10 TB e compare codecs usando as medições de produção da Uber (blog de engenharia da Uber, 2022-01-24: terceiros):

À taxa do Athena de $5.00/TB varrido, o ganho do codec é um ganho de scan, porque o Athena cobra os bytes que lê do S3, "você paga pelo número de bytes varridos antes da descompressão" (acesso em 2026-10-11). Então a mesma tabela de 10 TB varrida mensalmente custa cerca de $50.00 sem compressão, cerca de $46.50 se tivesse sido Gzip (−7% para o Zstd implica que o Zstd fica 7% abaixo do Gzip), cerca de $30.50 se tivesse sido Snappy (−39%) e cerca de $10.50 se tivesse sido gravada como Zstd sem compressão (−79%). São razões de armazenamento de terceiros aplicadas à taxa de lista da AWS, rotule-as assim e mantenha os dois efeitos separados: o codec encolhe os bytes que você varre; o layout colunar mais o predicate pushdown encolhe o número de colunas e de row groups que você varre de todo. O $1.25 da E1 veio dos dois; esta tabela só mostra o primeiro.

A disciplina de nível: nível 3 por padrão, 6 to 9 se você mediu o trade, >19 com cautela, e compression_level só no Athena engine version 3. A própria Uber usou o nível 19 para backfills frios e níveis baixos em caminhos de streaming: leitura é constante entre níveis, escrita não (terceiros, 2022-01-24).

6.6 Exemplo resolvido E7: escolhendo um codec para uma tabela de staging quente (em out 2026)

Uma equipe precisa escolher um codec para uma tabela de staging que é gravada continuamente e lida por dashboards a cada cinco minutos. Insumos de decisão a partir dos números do digest:

Veredito: Zstd nível 3. Ele é 33% menor que o Snappy por uma penalidade de 7.5% no tempo de escrita, e o Gzip é eliminado nos dois eixos. Se a tabela fosse um buffer de ingestão write-only de alto volume, sem leituras analíticas, o Snappy seria a resposta correta no lugar, o número de throughput de descompressão é o único argumento a favor do Snappy, e ele aperta só quando leituras dominam a CPU.

---

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

Caso A, Vanguard: um "data swamp" de arquivos Parquet ainda é um data swamp

Vanguard (gestão de investimentos; Financial Advisor Services "FAS 360"). Em um AWS Big Data Blog datado de 2026-03-18, a Vanguard descreve o ponto de partida de sua modernização em uma frase: "migrating from a fragmented 'data swamp' of Parquet files on Amazon Simple Storage Service (Amazon S3) to a structured, unified system." Dois anos depois do trabalho, a AWS reporta 20 TB no Amazon Redshift e outros 150 TB no data lake do S3, 600+ jobs de ETL do AWS Glue (um aumento de 30×), 300+ tabelas, 250+ materialized views do Redshift, 500+ dashboards do Tableau e 500,000+ queries de usuários por mês. A Vanguard agora está "curating data products on the data lake using Apache Iceberg format and leveraging AWS Glue for metrics computation and data lake integration."

O ângulo de desta lição para este caso é desconfortável e importante: os arquivos já eram Parquet. Só o formato não os salvou. Parquet sem disciplina de dimensionamento, sem um formato de tabela que forneça ACID e snapshots, e sem dono transforma um lake em um swamp tão eficaz quanto CSV cru: a matriz de formatos da §2 é um insumo necessário, não suficiente. O conserto da Vanguard foi adicionar a camada que faltava (produtos de dados em Iceberg, com domínios donos), não trocar o formato de arquivo.

Números relatados pelo cliente a partir de um blog da AWS publicado em 2026-03-18; não é um compromisso da AWS.

Caso B, Nasdaq: arquivos de lake colunar sob a carga de uma bolsa

Nasdaq (operadora de bolsa, serviços financeiros). Segundo o estudo de caso da AWS (página com ano 2020, acesso em out 2026), a Nasdaq construiu "the foundation of a new data lake on Amazon Simple Storage Service (Amazon S3)" em 2018 e adotou o Redshift Spectrum para "consultar dados tanto no data warehouse quanto no data lake do Amazon S3", o que a AWS chama de "a lake house architecture". O perfil de ingestão noturno foi de "30 billion to 55 billion records and surpassing 4 terabytes" de milhares de fontes; o lake guardava 15 terabytes de dados no Amazon S3 consultáveis in place; os resultados reportados foram queries do Redshift "32 percent faster" e a marca de 90% do data-load atingida 5 horas mais cedo. Robert Hunt, VP de Software Engineering, é citado: "Amazon S3 gave us a solution that enables zero contention between data loading and querying processes."

Por que ele pertence aqui: 4 TB por noite, consultados na manhã seguinte, é exatamente o workload para o qual a matriz de formatos existe. O layout colunar mais o predicate pushdown é o que permite a uma bolsa varrer uma noite de registros para uma pergunta de vigilância sem ler cada coluna de cada registro, e a própria citação de "zero contention" da Nasdaq é a lição de separação de storage/compute da lição 01 aparecendo no nível do byte.

Números relatados pelo cliente a partir de uma página de estudo de caso da AWS sem data (marca de ano 2020, acesso em out 2026); não é um compromisso da AWS.

Caso C, Woot.com: por que o CSV quebrou e o Parquet não

Woot.com (varejo). Em um AWS Big Data Blog datado de 2019-01-22, a equipe reporta que exportar colunas de texto para CSV "conflicted with the commas present in the text data. We opted to use AWS Glue to export data from RDS to S3 in Parquet format", o Parquet é "unaffected by commas because it encodes columns directly." Duas lições em uma linha: a fragilidade do delimitador do CSV é um risco de correção, não só de performance, e o AWS Glue ETL gravando format="parquet" é a segunda das duas rotas de conversão sancionadas, ao lado do Athena CTAS.

Blog da AWS, 2019-01-22; datado, trate como evidência histórica do padrão, não como pricing ou performance atuais.

---

Perguntas de Prática (Practice Questions)