Partições

Particionar uma tabela faz duas coisas: reduz o que o Athena precisa ler, e permite manter no datalake um histórico que já não existe mais no banco.

Sem configuração aqui, todas as tabelas são copiadas direto — o que funciona bem até a tabela crescer.

Por que particionar

Uma tabela particionada por ano e mês vira diretórios no S3:

catalog/{cluster}/vendas.pagamentos/ano=2024/mes=03/*.parquet

Quando a query diz WHERE ano = 2024 AND mes = 3, o Athena lê só aquele diretório. Sem partição, ele lê a tabela inteira e você paga por isso.

Configurar

Em Partições, crie uma configuração escolhendo o cluster, o banco e a tabela. Depois defina as colunas de partição: uma expressão que calcula o valor e o nome da coluna resultante.

year(CAST(payment_date AS TIMESTAMP))   como   ano
month(CAST(payment_date AS TIMESTAMP))  como   mes

Datas vêm como texto

O export do RDS entrega colunas de data como texto. Toda expressão de data precisa de CAST explícito, como no exemplo.

A ordem importa: do mais amplo para o mais estreito. Ano antes de mês, mês antes de dia.

Quantos níveis usar

Cada combinação distinta de valores vira um diretório, e diretórios demais tornam a gravação mais lenta e podem esgotar a memória do job.

O Data Pump calcula sozinho quantos cabem, a partir da memória disponível e da largura da tabela — uma tabela de 40 colunas suporta muito menos diretórios que uma de 3. Quando passa do limite, ele grava em lotes em vez de falhar.

Ainda assim, vale escolher com intenção: particionar por dia em uma tabela com anos de histórico gera milhares de diretórios, e raramente a consulta precisa dessa granularidade. Ano e mês costumam bastar.

Ordenação

O campo de ordenação existe, mas é caro: a tabela inteira precisa ser ordenada antes da primeira linha ser gravada. O Parquet já guarda o mínimo e o máximo de cada bloco, então o Athena filtra bem sem isso. Use apenas se souber por quê.

Substituir a cópia direta

Por padrão, uma tabela particionada aparece duas vezes no datalake: a cópia inteira e a versão particionada, lado a lado. Isso é proposital — permite comparar as duas durante uma migração.

Quando quiser só a particionada, ligue substituir a cópia direta.

Uma combinação que faz a tabela sumir

Com “substituir a cópia direta” ligado e a partição desabilitada, a tabela deixa de ser gravada por completo: a cópia a pula e o particionador não roda. O console avisa antes de salvar, mas vale conhecer o caso.

Histórico de longo prazo

Ligue manter histórico de longo prazo e a tabela passa a ser gravada em uma área que não é apagada a cada execução.

É o que permite expurgar dados antigos do Postgres sem perdê-los: o mês que sai do banco continua consultável no datalake. O catalog/ reflete o banco hoje; o longterm/ acumula.

A cada execução, só as partições presentes naquele export são regravadas. As que já não vêm do banco ficam intactas.

Atualizar linhas que mudaram

O histórico sozinho serve bem para tabela transacional, onde a linha nasce e não muda mais. Mas se uma linha já ingerida for corrigida no banco, a versão antiga continua no datalake — e ela pode estar em uma partição que nem vem mais no export.

Ligue atualizar linhas que mudaram e informe:

• Coluna chave — identifica a linha, para saber qual substituir
• Como reconhecer o que mudou — uma condição que seleciona, no export, as linhas alteradas desde a última ingestão (ex.: updated_at > current_date - 7)

O Data Pump localiza os arquivos que contêm aquelas linhas e troca a versão antiga pela nova.

Antes de cada substituição, o estado anterior é salvo em longterm/overrides/{export}/. É o único registro do que foi trocado: se uma substituição sair errada, é de lá que se reconstrói. Reprocessar o mesmo export não sobrescreve esse registro.

Repetir a mesma ingestão

Rodar duas vezes o mesmo export é seguro. A gravação apaga a partição antes de regravar, e a substituição casa por coluna chave — o resultado é o mesmo de rodar uma vez só.