Particiones

Particionar una tabla hace dos cosas: reduce lo que Athena necesita leer, y permite mantener en el datalake un histórico que ya no existe en la base.

Sin configuración aquí, todas las tablas se copian directo — lo que funciona bien hasta que la tabla crece.

Por qué particionar

Una tabla particionada por año y mes se convierte en directorios en S3:

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

Cuando la consulta dice WHERE ano = 2024 AND mes = 3, Athena lee solo ese directorio. Sin partición, lee la tabla entera y tú lo pagas.

Configurar

En Partições (Particiones), crea una configuración eligiendo el clúster, la base y la tabla. Después define las columnas de partición: una expresión que calcula el valor y el nombre de la columna resultante.

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

Las fechas llegan como texto

El export de RDS entrega las columnas de fecha como texto. Toda expresión de fecha necesita un CAST explícito, como en el ejemplo.

El orden importa: de lo más amplio a lo más estrecho. Año antes que mes, mes antes que día.

Cuántos niveles usar

Cada combinación distinta de valores se convierte en un directorio, y demasiados directorios hacen la escritura más lenta y pueden agotar la memoria del job.

Data Pump calcula solo cuántos caben, a partir de la memoria disponible y del ancho de la tabla — una tabla de 40 columnas soporta muchos menos directorios que una de 3. Cuando pasa del límite, escribe en lotes en vez de fallar.

Aun así, vale elegir con intención: particionar por día en una tabla con años de histórico genera miles de directorios, y rara vez la consulta necesita esa granularidad. Año y mes suelen bastar.

Ordenación

El campo de ordenación existe, pero es caro: la tabla entera debe ordenarse antes de escribir la primera fila. Parquet ya guarda el mínimo y el máximo de cada bloque, así que Athena filtra bien sin eso. Úsalo solo si sabes por qué.

Sustituir la copia directa

Por defecto, una tabla particionada aparece dos veces en el datalake: la copia entera y la versión particionada, lado a lado. Es intencional — permite comparar las dos durante una migración.

Cuando quieras solo la particionada, activa substituir a cópia direta (sustituir la copia directa).

Una combinación que hace desaparecer la tabla

Con “sustituir la copia directa” activado y la partición deshabilitada, la tabla deja de escribirse por completo: la copia la salta y el particionador no se ejecuta. La consola avisa antes de guardar, pero vale conocer el caso.

Histórico de largo plazo

Activa manter histórico de longo prazo (mantener histórico de largo plazo) y la tabla pasa a escribirse en un área que no se borra en cada ejecución.

Es lo que permite purgar datos antiguos de Postgres sin perderlos: el mes que sale de la base sigue consultable en el datalake. catalog/ refleja la base hoy; longterm/ acumula.

En cada ejecución, solo se reescriben las particiones presentes en ese export. Las que ya no vienen de la base quedan intactas.

Actualizar filas que cambiaron

El histórico por sí solo sirve bien para una tabla transaccional, donde la fila nace y no cambia más. Pero si una fila ya ingerida se corrige en la base, la versión antigua sigue en el datalake — y puede estar en una partición que ya ni viene en el export.

Activa atualizar linhas que mudaram (actualizar filas que cambiaron) e informa:

• Columna clave — identifica la fila, para saber cuál sustituir
• Cómo reconocer lo que cambió — una condición que selecciona, en el export, las filas alteradas desde la última ingesta (ej.: updated_at > current_date - 7)

Data Pump localiza los archivos que contienen esas filas y cambia la versión antigua por la nueva.

Antes de cada sustitución, el estado anterior se guarda en longterm/overrides/{export}/. Es el único registro de lo que se cambió: si una sustitución sale mal, es de ahí que se reconstruye. Reprocesar el mismo export no sobrescribe ese registro.

Repetir la misma ingesta

Ejecutar dos veces el mismo export es seguro. La escritura borra la partición antes de reescribirla, y la sustitución casa por columna clave — el resultado es el mismo que ejecutarlo una sola vez.