Cuando algo falla

El pipeline terminó con éxito y el datalake está vacío

El síntoma más común, y casi siempre configuración — no un error.

El pipeline no falla por falta de configuración. Sin base marcada, el snapshot se exporta, los Parquet llegan a S3, y el job de copia los ignora en silencio.

En orden de probabilidad:

Causa	Cómo confirmar
Ninguna base marcada	La vista general de la consola muestra la alerta
Apareció una base nueva en el clúster	Ídem, con el nombre de la base
Eventos de snapshot desactivados	Ídem — en ese caso ni la exportación se ejecuta
El filtro de tablas excluyó todo	En Bancos (Bases), mira cuántas tablas están marcadas

El log del job de copia también registra lo que fue ignorado:

IGNORADO: 56 arquivos do banco "pagila" -- ele nao esta marcado
para ingestao, entao nada dele chega ao datalake.

Una tabla desapareció del datalake

Si la tabla existía y dejó de aparecer, verifica en Partições (Particiones) si hay una configuración para ella con sustituir la copia directa activado y la partición deshabilitada. En esa combinación, la copia salta la tabla y el particionador no se ejecuta — nadie la escribe.

Volver a activar la partición, o desactivar “sustituir la copia directa”, lo resuelve.

Una ejecución falló

En Execuções (Ejecuciones), abre la ejecución para ver las etapas en orden. La etapa que falló trae el mensaje de error y el log.

Las causas más comunes:

• Memoria en el particionamiento — una tabla con muchos valores distintos en la columna de partición. Mira cuántos niveles usar.
• Permiso en el cross-account — si el paso 3 de la instalación cross-account no se hizo, la exportación falla al escribir en el bucket.
• Timeout — cada job tiene una hora. Una tabla muy grande con ordenación configurada es el sospechoso más probable.

Una tabla que falla no tumba a las demás: el pipeline tolera fallas aisladas en el particionamiento y el crawler cataloga lo que fue escrito.

Una columna extraña en el schema

Si aparece una columna partition_0 con valores 1, 2, 3, la instalación está en una versión anterior a la que aplana el directorio de partes de RDS. Actualiza el paquete y reprocesa.

Las mismas filas aparecen dos veces

Dos causas posibles:

Tabla particionada en Postgres. RDS exporta la tabla madre y cada partición hija. Las versiones actuales detectan e ignoran las hijas; si ves tablas como payment_p2024_01 junto a payment, actualiza el paquete.

Partición sin “sustituir la copia directa”. Por defecto, una tabla particionada aparece dos veces a propósito — la copia entera y la particionada. Activa la opción si quieres solo la particionada.

El login no funciona

Cognito rechaza URLs de callback en http, excepto localhost. Si la consola atiende en http, el login falla antes de empezar. Ejecuta setup-https.sh.

Si el navegador avisa que el certificado no es confiable, es el certificado autofirmado — funciona, pero para eliminar el aviso usa un certificado propio vía CERTIFICATE_ARN.

No consigo alcanzar la consola

El load balancer es interno, a propósito: la consola no está expuesta a internet. La alcanzas desde dentro de la VPC, por VPN, o por un túnel de Session Manager.

Saber qué versión produjo un resultado

Cada job registra su propia versión al iniciar, y la ejecución guarda eso. En Execuções (Ejecuciones), la versión de cada componente aparece en los detalles — útil cuando el comportamiento cambió entre actualizaciones.