Calidad de datos en pipelines ETL/ELT en empresa

La calidad de datos en los pipelines es uno de esos temas que todos saben que importa y que la mayoría pospone para después del lanzamiento. El problema es que después del lanzamiento los dashboards ya están en producción y cuando los checks fallan hay usuarios afectados. Esta guía explica cómo integrar la calidad en el pipeline desde el inicio sin convertirlo en un proyecto separado.

¿Qué tipos de controles de calidad necesita un pipeline?

dbt Tests: la forma más sencilla de empezar

Si tu stack de transformación usa dbt, los tests nativos son la forma más sencilla de implementar calidad de datos sin añadir herramientas adicionales. dbt tiene cuatro tests declarativos out of the box: not_null, unique, accepted_values y relationships. Se configuran en archivos YAML junto al modelo, se ejecutan con 'dbt test' y fallan el pipeline si no pasan. Para el 70–80% de los controles básicos de una empresa mediana, esto es suficiente. Para controles más complejos, dbt-utils y dbt-expectations añaden muchas más opciones sin salir del framework de dbt.

Cómo priorizar qué controles implementar primero

1. 1Identifica las métricas de negocio más críticas del dashboard — las que si son incorrectas generarían decisiones equivocadas.
2. 2Traza el linaje de esas métricas hasta la fuente para entender qué campos les alimentan.
3. 3Implementa controles críticos solo en esos campos críticos primero. No trates de controlar todo a la vez.
4. 4Define qué controles bloquean el pipeline (fallos que producen datos incorrectos) y qué controles solo alertan (anomalías que pueden tener explicación).
5. 5Añade el resto de controles progresivamente a medida que el equipo identifica nuevas anomalías en producción.

Monitorización continua: Great Expectations y Soda

Para controles más avanzados o para monitorización continua de los datos en producción (no solo en el momento de la carga), Great Expectations y Soda Core son las herramientas más maduras. Great Expectations es más flexible y potente pero tiene una curva de aprendizaje mayor. Soda Core es más sencillo de implementar y tiene integración directa con dbt. Ambas permiten definir expectativas sobre los datos y ejecutarlas de forma programada para detectar degradaciones de calidad entre cargas.

Arquitectura de controles: dónde colocar cada check en el pipeline

Un error habitual es concentrar todos los controles de calidad en un único punto del pipeline. Lo más eficaz es distribuirlos en capas, de forma que cada etapa valide lo que le corresponde y los problemas se detecten lo antes posible.

Capa de ingesta (staging)

Aquí los datos llegan tal cual los entrega la fuente. Los controles en esta capa verifican que la estructura es la esperada: número de columnas correcto, tipos de datos consistentes, campos obligatorios presentes y volumen dentro del rango habitual. Si una fuente que normalmente envía 10.000 registros envía 500, algo ha cambiado y conviene investigar antes de seguir.

Esta misma lógica, no dar nada por bueno solo porque se ha ejecutado sin errores, es la que aplica a cualquier arquitectura por capas (bronze/silver/gold): una carga que se completa sin fallos no es sinónimo de una carga correcta. El control de volumen es barato de implementar y detecta un porcentaje sorprendente de problemas antes de que lleguen al dato que consume negocio.

Capa de transformación

Después de las transformaciones (limpieza, joins, cálculos), los controles verifican que la lógica de negocio se ha aplicado correctamente. Aquí es donde se comprueban rangos válidos (un descuento no puede ser del 200%), consistencia entre campos relacionados (la fecha de envío no puede ser anterior a la fecha de pedido) y que los cálculos derivados cuadran con los datos de entrada.

Capa de consumo (mart)

Antes de que los datos lleguen al dashboard o al sistema que los consume, los controles finales verifican integridad referencial, unicidad de claves primarias y que las métricas de negocio cuadran con fuentes de contraste. Es la última barrera antes de que un dato incorrecto afecte a una decisión.

Patrones de error más comunes en pipelines reales

Estos son los problemas que aparecen con más frecuencia en pipelines de datos empresariales y que los controles de calidad deben cubrir:

• Duplicados silenciosos: un cambio en la frecuencia de carga o un retry mal gestionado introduce registros duplicados que inflan métricas sin que nadie lo note hasta que las cifras no cuadran con otro sistema.
• Cambios de esquema no comunicados: el equipo de origen añade una columna, cambia un tipo de dato o renombra un campo. Sin un check de esquema en staging, el pipeline falla o, peor, procesa datos incorrectamente sin error visible.
• Valores por defecto que pasan como reales: campos que llegan con un 0 o una cadena vacía en lugar de nulo. El pipeline los trata como datos válidos y las métricas se distorsionan.
• Desfases temporales entre fuentes: cuando el pipeline cruza datos de dos fuentes con frecuencias de actualización distintas, puede generar inconsistencias temporales que parecen errores de calidad pero son problemas de sincronización.
• Drift de distribución: los datos siguen llegando correctos individualmente, pero la distribución general cambia (más ventas en una categoría, menos clientes activos). Si no monitorizas la distribución además de los valores individuales, no detectas el cambio hasta que alguien pregunta por qué las cifras no cuadran.

Cómo gestionar los fallos de calidad sin paralizar al equipo

Uno de los riesgos de implementar controles de calidad es que el pipeline empiece a fallar con frecuencia y el equipo pierda confianza en el sistema o, peor, empiece a ignorar las alertas. Para evitarlo, conviene seguir estas prácticas:

1. 1Clasifica cada control con una severidad clara: crítico (bloquea el pipeline), advertencia (alerta pero no bloquea) o informativo (se registra para análisis posterior).
2. 2Empieza con pocos controles críticos y muchos de advertencia. A medida que entiendas los patrones normales de tus datos, puedes promover advertencias a críticos.
3. 3Configura canales de notificación diferenciados: los fallos críticos van a un canal de alerta inmediata (Slack, PagerDuty); las advertencias van a un informe diario de resumen.
4. 4Registra un historial de fallos de calidad. Con el tiempo, este registro te permite identificar las fuentes más problemáticas y priorizar dónde invertir en mejoras.
5. 5Revisa los umbrales trimestralmente. Un check que generaba sentido cuando lo definiste puede volverse irrelevante o demasiado estricto a medida que cambia el negocio.

Herramientas complementarias a dbt para calidad de datos

Además de dbt Tests, Great Expectations y Soda Core mencionados anteriormente, hay otras herramientas y enfoques que conviene conocer según la madurez del equipo:

Para un enfoque completo de gobierno del dato adaptado a tu empresa, consulta nuestra página de gobierno del dato y calidad explicamos el proceso completo.

Si te interesa profundizar, en dbt para equipos que empiezan: guía práctica exploramos este tema en detalle.

Para más contexto, puedes consultar la informe de Gartner sobre datos listos para IA.

Preguntas frecuentes sobre calidad de datos en pipelines

¿Cuándo debo ejecutar los tests de calidad: antes o después de cargar los datos?

Lo ideal es ejecutarlos en múltiples puntos del pipeline: en la capa de staging (datos crudos de la fuente, antes de transformar), después de las transformaciones principales y antes de publicar en el mart o la capa de consumo. Detectar el problema lo antes posible en el pipeline reduce el impacto y facilita la corrección.

¿Qué pasa cuando un control de calidad falla en producción?

Depende de cómo hayas configurado el control: si es crítico, el pipeline falla y los datos de esa carga no se publican (el sistema sirve la versión anterior). Si es de alerta, el pipeline continúa pero se notifica al equipo. Tener este comportamiento bien definido antes de llegar a producción evita decisiones de emergencia cuando ocurre un fallo real.

¿Es necesario tener dbt para implementar calidad de datos?

No. Puedes implementar controles de calidad con Great Expectations, Soda o scripts SQL personalizados sobre cualquier warehouse sin usar dbt. dbt facilita mucho la integración porque los tests son código versionado junto a las transformaciones, pero no es un requisito.