Como funciona

Duas coisas precisam acontecer para o datalake receber dados: configurar e executar. A configuração é feita uma vez, no console. A execução acontece a cada snapshot, sozinha.

A distinção importa porque o pipeline conclui com sucesso mesmo sem configuração completa. Sem nenhum banco marcado para ingestão, o snapshot é exportado, os arquivos Parquet chegam ao S3, e o job de cópia os ignora em silêncio. Não há erro em lugar nenhum — por isso a visão geral do console lista o que ainda falta.

O caminho de uma tabela

1. A AWS tira o snapshot
   automático (janela de backup) ou manual

2. O RDS exporta em Parquet
   exported/{cluster}/{export}/pagila/public.payment/1/*.parquet

3. O Data Pump copia o que você marcou, com o nome que você deu
   catalog/{cluster}/pagila.pagamentos/*.parquet

4. Reparticiona as tabelas configuradas
   catalog/{cluster}/pagila.pagamentos/ano=2024/mes=03/*.parquet

5. O Glue cataloga
   SELECT * FROM datalake.pagila_pagamentos WHERE ano = 2024

Os passos 3 e 4 são onde suas decisões entram: quais bancos e tabelas (configurar a ingestão) e como reparticionar (partições).

O gatilho

Quando um snapshot fica pronto, o RDS publica um evento. Uma função Lambda recebe, verifica se aquele cluster está inscrito e, se estiver, inicia a exportação. Quando a exportação termina, o mesmo caminho dispara o pipeline de processamento.

A lambda é a mesma nos dois momentos — ela distingue pelo tipo do evento. Eventos que não interessam (criação iniciada, cópia, exclusão) são registrados e ignorados.

O pipeline

Quatro jobs em sequência, todos como tasks Fargate a partir da mesma imagem:

1. Limpa o catálogo anterior — catalog/{cluster}/ é reconstruído a cada execução, então reflete sempre o estado atual do banco.
2. Copia os arquivos — só dos bancos marcados, aplicando filtros de tabela e apelidos.
3. Reparticiona — uma task por tabela configurada, em paralelo.
4. Limpa o export bruto — opcional.

Ao final, o crawler do Glue cataloga o resultado e uma notificação é publicada em um tópico SNS, para quem quiser encadear algo depois.

Onde o dado fica no S3

exported/{cluster}/{export}/{banco}/{schema}.{tabela}/{parte}/*.parquet
   └── o que o RDS produz: tudo que o snapshot contém

catalog/{cluster}/{alias}.{tabela}/*.parquet
   └── o que o Glue cataloga: só o que você marcou

longterm/{cluster}/{alias}/{tabela}/
   └── histórico que sobrevive ao expurgo no banco de origem

A diferença entre catalog/ e longterm/ é o que permite manter histórico depois de expurgar dados antigos do Postgres: catalog/ é recriado a cada execução; longterm/ acumula.

Tabelas já particionadas no Postgres

Se uma tabela é particionada nativamente no Postgres, o RDS exporta a tabela-mãe e cada partição filha como tabelas separadas. A mãe já contém todas as linhas, então copiar as duas duplicaria cada linha no datalake.

O Data Pump detecta e ignora as filhas, usando os metadados do próprio export — não o padrão do nome. Partições novas criadas no banco são reconhecidas sozinhas; não há lista para manter.