Errores comunes al diseñar un pipeline de datos

Montar un pipeline de datos que extraiga datos de una fuente, los transforme y los cargue en un destino no es complicado. Cualquier script de Python con un par de queries puede hacerlo. El problema es que ese script que funciona en tu portátil a las tres de la tarde falla a las cuatro de la mañana cuando cambia un campo, llega un null inesperado o la fuente responde con un timeout.

La diferencia entre un pipeline que funciona y uno que es fiable está en los errores que se previeron y se gestionaron durante el diseño. Estos son los que aparecen con más frecuencia.

Error 1: No diseñar para idempotencia

Un pipeline no idempotente genera duplicados cada vez que se reejecuta. Y las reejecuciones pasan: por un fallo de red, un timeout, un reinicio del orquestador o un despliegue que necesita reprocesar un día. Si tu pipeline hace INSERT sin comprobar si el registro ya existe, cada reejecución duplica datos.

La prevención pasa por usar patrones como MERGE/UPSERT, reemplazar particiones completas en cada ejecución (write-replace) o implementar un patrón de staging donde los datos nuevos se escriben en una tabla temporal y se reconcilian con la tabla final. La elección depende del volumen y del motor de destino, pero la regla es clara: el pipeline debe poder ejecutarse dos veces seguidas sin cambiar el resultado.

Error 2: No validar el schema de entrada

Las fuentes de datos cambian sin avisar. Un campo que era entero pasa a ser string, una columna desaparece, un nuevo campo aparece con un nombre parecido pero distinto formato. Si tu pipeline asume que la estructura de entrada es fija, cualquiera de estos cambios lo rompe en silencio o produce datos corruptos.

Valida el schema al inicio de cada ejecución. Comprueba que las columnas esperadas existen, que los tipos son correctos y que los valores están dentro de rangos razonables. Herramientas como Great Expectations, Pandera o los contracts de dbt permiten automatizar estas validaciones. Si el schema no cumple, el pipeline debe fallar con un error claro, no seguir adelante con datos incorrectos.

Error 3: Hardcodear transformaciones

Transformaciones escritas directamente en el código sin parametrizar ni documentar. Mapeos de campos como diccionarios enterrados en un script, reglas de negocio que nadie recuerda por qué están ahí, valores mágicos que convierten un estado en otro. Cuando alguien necesita cambiar una regla, tiene que bucear en código que no entiende.

Externaliza las reglas de transformación: tablas de mapeo en base de datos o ficheros de configuración, reglas de negocio documentadas y versionadas, constantes con nombre descriptivo. Si usas dbt como capa de transformación, los modelos SQL con macros parametrizables y documentación integrada resuelven gran parte de este problema.

Error 4: No monitorizar ni alertar

Un pipeline sin monitorización es un pipeline que falla en silencio. Y un fallo silencioso es peor que uno ruidoso, porque los datos erróneos llegan a dashboards, informes y modelos sin que nadie se entere hasta que alguien nota que las cifras no cuadran. A veces, semanas después.

La monitorización debe cubrir al menos tres niveles: ejecución (el pipeline ha corrido o no, ha tardado lo esperado o no), datos (los volúmenes son razonables, no hay nulos inesperados, los totales cuadran) y frescura (los datos se han actualizado en el plazo esperado). Las alertas deben llegar donde el equipo las vea: Slack, email o el sistema que uséis.

• Alerta si el pipeline no se ejecuta en la ventana esperada.
• Alerta si el número de registros procesados cae o sube más de un umbral respecto al día anterior.
• Alerta si aparecen nulos en campos que deberían ser obligatorios.
• Alerta si la latencia del pipeline supera un umbral definido.

Error 5: Pipeline monolítico

Un pipeline que hace todo en un solo paso (extrae, transforma, calcula métricas, carga y envía notificaciones) es difícil de depurar, difícil de testear y difícil de reutilizar. Cuando falla, no sabes en qué punto. Cuando necesitas cambiar una transformación, tocas un bloque que afecta a todo lo demás.

Divide el pipeline en pasos independientes con responsabilidades claras: extracción, staging, transformación, carga, validación. Cada paso debe poder ejecutarse por separado, tener sus propios logs y ser testeable de forma independiente. Los orquestadores como Airflow, Dagster o Prefect están diseñados para gestionar estas dependencias entre pasos.

Error 6: No testear las transformaciones

Las transformaciones de datos son lógica de negocio. Calcular el margen bruto, clasificar un cliente por segmento, determinar si un pedido está en retraso: todo eso son reglas que pueden romperse con un cambio de datos, un caso borde no previsto o una actualización de librería. Sin tests, no hay forma de saber si una transformación sigue haciendo lo que debería.

Implementa tests a dos niveles. Tests unitarios que validen la lógica de cada transformación con datos de ejemplo (entrada conocida, salida esperada). Y tests de integración que verifiquen que el flujo completo produce un resultado coherente. En nuestra guía de calidad de datos en pipelines ETL detallamos cómo integrar estas validaciones en el flujo.

Error 7: Ignorar datos tardíos (late-arriving data)

No todos los datos llegan cuando se espera. Un evento de venta que se registra con retraso, una transacción que aparece al día siguiente, un fichero que llega a deshora. Si tu pipeline procesa los datos del día y cierra la ventana sin contemplar que pueden llegar registros tardíos, pierdes datos o los duplicas cuando llegan.

Las estrategias habituales son: ventanas de procesamiento con solapamiento (reprocesar las últimas 48 horas en lugar de solo las últimas 24), marcas de agua (watermarks) que definen hasta cuándo se aceptan datos tardíos, y particiones con reprocesamiento selectivo. La estrategia correcta depende de la fuente y de cuánto retraso es tolerable, pero ignorar el problema no es una opción.

Error 8: No definir data contracts

Cuando un equipo produce datos que otro equipo consume, necesitas un acuerdo explícito sobre qué datos se entregan, con qué estructura, en qué frecuencia, con qué nivel de calidad y quién es responsable. Sin ese acuerdo, cualquier cambio en origen rompe lo que hay aguas abajo.

Un data contract no tiene que ser un documento de 50 páginas. Basta con un fichero versionado (YAML, JSON) que defina: el esquema de la tabla o el evento (campos, tipos, obligatoriedad), la frecuencia de actualización, las reglas de calidad mínimas (no nulos en campo X, valores dentro del rango Y), el propietario y el canal de comunicación para cambios. Herramientas como dbt contracts, Soda agreements o incluso un simple schema registry cubren esta necesidad.

Principios de arquitectura para pipelines fiables

Más allá de los errores individuales, hay principios que deberían guiar el diseño de cualquier pipeline de datos.

1. 1Idempotencia por defecto: diseña cada paso para que pueda reejecutarse sin efectos secundarios.
2. 2Fallar ruidosamente: mejor un pipeline que falla y avisa que uno que sigue adelante con datos incorrectos.
3. 3Separar extracción de transformación: no mezcles la lógica de obtención de datos con la lógica de negocio. Son responsabilidades distintas.
4. 4Versionado y trazabilidad: cada cambio en el pipeline debería estar en control de versiones, y cada ejecución debería dejar un registro de qué datos procesó y cuándo.
5. 5Testing como parte del flujo: los tests no son algo que se añade al final. Son parte del pipeline, igual que una transformación o una carga.
6. 6Observabilidad desde el diseño: logs, métricas y alertas no son un extra. Son un requisito para operar un pipeline en producción.

Estos principios aplican tanto si trabajas con un script de Python como si usas un orquestador completo con dbt, Airflow y Great Expectations. La escala cambia, pero los fundamentos no. Si necesitas ayuda para diseñar o rediseñar tus pipelines, en nuestra página de plataforma de datos explicamos cómo abordamos estos proyectos.

Checklist rápido de revisión

Antes de pasar un pipeline a producción, verifica al menos estos puntos.

• ¿Puedo ejecutar el pipeline dos veces seguidas sin duplicar datos?
• ¿Valido el schema de entrada al inicio de cada ejecución?
• ¿Las reglas de transformación están documentadas y parametrizadas?
• ¿Hay alertas configuradas para fallos, anomalías de volumen y frescura?
• ¿El pipeline está dividido en pasos con responsabilidades claras?
• ¿Hay tests unitarios y de integración para las transformaciones?
• ¿Contemplo datos tardíos o fuera de ventana?
• ¿Existe un data contract con los productores de los datos de entrada?

Para mas informacion, puedes consultar la reviews de Gartner para plataformas cloud de datos.

Preguntas frecuentes

¿Qué es la idempotencia en un pipeline de datos?

Un pipeline es idempotente cuando puedes ejecutarlo varias veces con los mismos datos de entrada y obtener siempre el mismo resultado, sin duplicados ni efectos secundarios. Esto se consigue normalmente con estrategias como MERGE/UPSERT en lugar de INSERT, o con un patrón de write-audit-publish que reemplaza particiones completas en cada ejecución.

¿Cuándo debería empezar a usar data contracts?

En cuanto tengas más de un equipo produciendo datos que otro equipo consume. Los data contracts definen el esquema, la frecuencia, los niveles de calidad y el responsable de cada dataset. Sin ellos, cualquier cambio en origen rompe lo que hay aguas abajo sin previo aviso.

¿Hace falta testing en un pipeline de datos?

Sí. Las transformaciones de datos contienen lógica de negocio que puede romperse con un cambio de esquema, un valor inesperado o una actualización de librería. Tests unitarios para transformaciones individuales y tests de integración para el flujo completo evitan que los errores lleguen a producción sin detectarse.

¿Qué herramientas de monitorización se usan para pipelines?

Las más habituales son: Great Expectations y Soda para validación de datos, dbt tests para la capa de transformación, Airflow o Dagster para orquestación con alertas integradas, y herramientas de observabilidad como Monte Carlo o Elementary para monitorización continua. Para equipos pequeños, un sistema de alertas con Slack o email conectado al orquestador suele ser suficiente.

¿Cuál es la diferencia entre un pipeline ETL y un pipeline ELT?

En ETL, los datos se transforman antes de cargarse en el destino. En ELT, se cargan primero en bruto y se transforman después dentro del propio destino (normalmente un data warehouse). ELT es el patrón dominante en arquitecturas modernas con warehouses potentes como BigQuery o Snowflake, porque permite transformar con SQL sobre el propio motor analítico y facilita la trazabilidad.