Cómo construir un pipeline de datos que no se rompa cada lunes por la mañana

El pánico del lunes por la mañana

Conoces la sensación. Llegas a tu escritorio el lunes, abres tu dashboard, y los datos no se han actualizado desde el viernes por la tarde. El scraper se cayó porque el sitio objetivo cambió un nombre de clase. El script de transformación encontró un valor null que nadie anticipó. El pool de conexiones a la base de datos estaba agotado porque tres jobs corrieron simultáneamente.

Nadie lo notó hasta ahora porque las alertas — si es que existen — envían emails a una bandeja compartida que nadie revisa los fines de semana.

Este es el estado por defecto de la mayoría de pipelines de datos. Funcionan bien el 95 % del tiempo, y el otro 5 % consume el 80 % de tu tiempo de ingeniería.

No tiene que ser así.

Las tres capas que se rompen independientemente

Cada pipeline de datos tiene tres capas, y entenderlas por separado es la clave de la fiabilidad:

Recopilación — obtener datos de fuentes externas (APIs, sitios web, bases de datos, archivos). Aquí es donde se originan la mayoría de fallos porque interactúas con sistemas que no controlas.

Transformación — limpiar, normalizar, enriquecer y estructurar los datos brutos. Aquí es donde los casos límite en los datos crean bugs en tu lógica.

Entrega — cargar los datos procesados en su destino (base de datos, data warehouse, dashboard, API). Aquí es donde los problemas de infraestructura y las incompatibilidades de esquema causan fallos.

Cada capa necesita su propia estrategia de manejo de errores porque los modos de fallo son completamente diferentes.

Hacer la recopilación resiliente

Los fallos de recopilación son los más comunes porque las fuentes externas son impredecibles. Los sitios cambian layouts (como cualquier practicante de scraping con navegador headless sabe). Las APIs devuelven respuestas inesperadas. Los límites de tasa se activan. Los servidores se caen.

Reintentar con backoff, pero no para siempre. Cuando una petición falla, reinténtala — pero con backoff exponencial (espera 1 segundo, luego 2, luego 4, luego 8). Establece un número máximo de reintentos. Si una fuente lleva fallando 30 minutos, algo va realmente mal, y reintentar cada pocos segundos solo está martilleando un servidor que ya tiene problemas.

Guarda tu progreso. Si estás scrapeando 10.000 páginas y falla en la página 7.342, deberías poder retomar desde la página 7.342 — no reiniciar desde el principio. Almacena checkpoints (el último elemento procesado con éxito) para que la recuperación no signifique rehacer todo.

Separa la recopilación de la transformación. Almacena los datos brutos recopilados antes de procesarlos. Si tu scraper obtiene HTML e inmediatamente intenta parsearlo, un bug de parsing significa que pierdes los datos brutos y tienes que volver a scrapear. Si almacenas primero el HTML bruto, puedes arreglar el parser y reprocesar sin re-recopilar.

Monitorea la frescura, no solo el éxito. Un scraper que “tiene éxito” pero devuelve cero resultados porque la estructura del sitio cambió es peor que uno que falla ruidosamente. Rastrea el número de elementos recopilados por ejecución y alerta cuando se desvía significativamente de la línea base.

Patrones de transformación que sobreviven a los casos límite

La capa de transformación es donde “funcionaba en testing” se encuentra con “los datos de producción son el caos.”

Valida las entradas antes de procesar. Antes de transformar un registro, verifica que los campos requeridos existen y tienen los tipos esperados. Un campo de precio que de repente es un string (“Contáctenos para precio”) en vez de un número propagará errores por todo tu pipeline si no lo atrapas temprano.

Maneja los nulls explícitamente. Cada campo de una fuente externa puede ser null. Cada uno. Diseña tu lógica de transformación para manejar datos faltantes con gracia — ya sea con valores por defecto sensatos, marcando el registro para revisión, o saltándolo con una entrada de log. Nunca dejes que un null produzca un resultado silenciosamente incorrecto.

Validación de esquema en las fronteras. Define esquemas explícitos para tus datos de entrada y salida. Herramientas como Zod (TypeScript), Pydantic (Python) o JSON Schema funcionan perfectamente para esto. Valida cada registro en el punto de entrada y salida de tu transformación. Los registros que no coinciden con el esquema van a una cola “dead letter” para investigación, no a tu base de datos de producción.

Haz las transformaciones idempotentes. Ejecutar la misma transformación dos veces sobre la misma entrada debería producir la misma salida sin efectos secundarios. Esto parece obvio, pero es sorprendentemente fácil de violar — especialmente con operaciones que incrementan contadores, agregan a listas o generan timestamps. La idempotencia significa que puedes re-ejecutar cualquier paso con seguridad sin miedo a duplicar o corromper datos.

Entrega que no corrompe tu base de datos

La capa de entrega parece simple — solo escribir datos en el destino. Pero aquí es donde la integridad de datos vive o muere.

Usa upserts, no inserts. Si estás cargando datos de producto diariamente y un producto ya existe, quieres actualizarlo — no crear un duplicado. Las operaciones upsert (insertar si es nuevo, actualizar si existe) basadas en una clave única previenen la acumulación lenta de registros duplicados que afecta a la mayoría de pipelines de datos.

Escrituras por lotes con transacciones. No escribas registros de uno en uno. Agrúpalos en transacciones de 100-1.000 registros. Esto es más rápido (menos viajes ida y vuelta a la base de datos) y más seguro (si el lote falla, la transacción hace rollback limpiamente en lugar de dejar tu base en un estado medio actualizado).

Las migraciones de esquema no son opcionales. Cuando tu modelo de datos cambia — un nuevo campo, un tipo cambiado, una columna renombrada — manéjalo con migraciones explícitas, no con sentencias ALTER TABLE ad hoc ejecutadas en producción. Herramientas como Prisma Migrate, Alembic o Flyway rastrean cambios de esquema como archivos versionados que pueden aplicarse consistentemente entre entornos.

Orquestación: el pegamento que mantiene todo unido

Los pasos individuales del pipeline pueden ser fiables, pero la orquestación — cuándo corren las cosas, en qué orden y qué pasa cuando algo falla — determina la fiabilidad general del sistema.

No uses cron jobs para nada complejo. Cron está bien para “ejecutar este script cada hora.” Es terrible para “ejecutar paso A, luego paso B si A tuvo éxito, luego paso C, pero reintentar paso B hasta 3 veces si falla, y enviar una alerta si el pipeline completo no ha terminado en 2 horas.” Para cualquier cosa más allá de la programación simple, usa un orquestador de workflows real.

En 2026, las opciones prácticas son:

• Temporal para workflows complejos y de larga duración con lógica sofisticada de reintento y compensación
• Dagster o Prefect para pipelines específicos de datos con controles de calidad integrados
• Sistemas simples basados en colas (BullMQ, SQS) para procesamiento paso a paso directo

La mayoría de pipelines no necesitan Airflow. A pesar de su popularidad, la complejidad de Airflow es excesiva para el 90 % de los casos de uso de recopilación de datos. Un sistema basado en colas bien diseñado con manejo de errores adecuado es más simple y más fiable.

Alertas a las que la gente realmente responde

El mejor manejo de errores del mundo es inútil si nadie ve las alertas.

Alerta por anomalías, no solo errores. Un pipeline que ejecuta exitosamente pero recopila 50 registros en vez de los 5.000 habituales probablemente está roto. Rastrea métricas de referencia y alerta cuando los valores se desvían más allá de un umbral razonable.

Un canal, señal alta. Si tus alertas envían 20 mensajes al día, la gente deja de leerlos. Reduce el ruido deduplicando alertas, agrupando notificaciones no críticas, y teniendo niveles de severidad claros. Las alertas críticas (pipeline de datos completamente detenido) deberían ir a Slack o PagerDuty. Los avisos (más lento de lo usual, algunos registros saltados) pueden ir en un email resumen diario.

Incluye contexto en las alertas. “Pipeline falló” es inútil. “El paso de recopilación falló para la fuente X: HTTP 403 en página 234/10000, última ejecución exitosa hace 2 horas, 233 páginas ya recopiladas y guardadas” — eso es accionable. Incluye qué falló, por qué, qué ya se completó, e idealmente un enlace a los logs relevantes.

Juntando todo

En SilentFlow, hemos construido pipelines de datos que procesan millones de registros diariamente desde cientos de fuentes. Los que funcionan de manera fiable comparten todos el mismo ADN: separación de responsabilidades entre recopilación, transformación y entrega. Datos brutos almacenados antes de procesar. Validación de esquema en cada frontera. Operaciones idempotentes de principio a fin. Alertas significativas con contexto.

Nada de esto es ciencia espacial. Es solo disciplina — aplicar patrones conocidos consistentemente en lugar de tomar atajos que ahorran tiempo hoy y cuestan fines de semana después. El pánico del lunes por la mañana es opcional. Solo tienes que construir el pipeline que lo haga innecesario.