El problema
Tenés tests de calidad configurados en tu pipeline. Un día, uno falla. ¿Qué hacés?
La respuesta obvia parece ser "frenar todo". Si hay un problema de calidad, no querés que datos incorrectos lleguen a los consumidores. Pero frenar el pipeline completo porque se duplicaron tres cuentas puede ser peor que el problema original.
Imaginate que falla algo a las 8 de la mañana. Si lo podés arreglar en 10 o 15 minutos, genial. Pero si estás todo el día para resolver el problema, mientras tanto no se cargó nada de datos en ninguna tabla del modelo. Ni en staging, ni en los marts, ni en ningún lado. Los usuarios no tienen datos actualizados, y vos estás debuggeando un problema que quizás no era tan crítico.
El remedio puede ser peor que la enfermedad.
Frenar es una decisión drástica
Frenar un pipeline es una decisión bastante drástica. Significa que si falla algo, no se carga absolutamente nada más. Todo lo que está definido en el pipeline queda sin actualizar.
La pregunta que hay que hacerse es: ¿qué tan crítico es ese error?
No todos los fallos de calidad tienen el mismo impacto. Si se duplicó un account_id que después usás para hacer joins, vas a romper todos tus números. Eso probablemente justifique frenar. Pero si hay un campo opcional con valores fuera de rango en un 0.1% de los registros, quizás no.
Dentro de un mismo pipeline puede haber cosas críticas y cosas que no lo son. Podés configurar que dependiendo de lo que esté fallando, el pipeline frene o no. Podés decir: detecté el error, pero que el pipeline corra igual, y después lo reviso.
Factores para decidir
La decisión de frenar o no depende de varios factores:
Criticidad del dato afectado. Si el test que falla valida algo que asumís en todas tus transformaciones posteriores (como la unicidad de una clave), el impacto de dejarlo pasar es alto. Si es un campo secundario que pocos consumidores usan, el impacto es menor.
Madurez del proceso. Si no tenés nada de calidad implementado, más vale arrancar validando aunque sea a lo bruto. Pero eso no significa que cada vez que encuentres algo tengas que frenar todo. Un primer paso puede ser que no falle, que sea un warning, que se registre en algún lado, y que alguien lo vaya corrigiendo. Cuando estás más maduro, podés empezar a manejar umbrales y severidades más finas.
Capacidad de respuesta del equipo. Si cada vez que falla algo se frena todo y tardás un día en arreglarlo, vas a tener usuarios sin datos y un equipo saturado. Tiene que haber un balance entre detectar problemas y no bloquear todo el flujo.
Umbrales: una herramienta útil con sus trampas
Una práctica común es manejar umbrales. En lugar de fallar si hay un solo duplicado, configurás que falle si el porcentaje de duplicados supera cierto valor.
Pero hay una trampa. Si estás procesando incrementalmente y el universo de datos es grande, un umbral sobre toda la tabla puede ocultar problemas serios.
Supongamos que tenés 10.000 cuentas y procesás diariamente las nuevas y las que cambiaron. Si hoy entraron 10 cuentas y las 10 fallaron, pero el test corre sobre todo el universo de la tabla, te va a dar 0.1%. Parece nada. Pero el problema es enorme: todas las de hoy están mal.
Por eso, cuando usás umbrales, tenés que tener en cuenta sobre qué universo de datos aplican. A veces tiene sentido validar contra el incremento del día, no contra toda la tabla.
Warning vs error: un espectro de severidades
La severidad de un test no tiene que ser binaria. Podés configurar que algunos tests generen un warning (se registra, se notifica, pero el pipeline sigue) y otros generen un error (el pipeline frena).
Un enfoque razonable:
- Warning para problemas detectados que no son críticos. Se registran, se cuantifican, alguien los revisa después.
- Error para problemas críticos de datos. Ahí sí, es mejor frenar todo y decir: los números no están bien por este motivo, y lo vamos a arreglar.
La clave es que esta configuración no es técnica. Es una decisión de gobierno. Alguien tiene que definir qué es crítico y qué no, qué impacto tiene cada tipo de fallo, y qué capacidad tiene el equipo para responder.
El linaje como aliado
Si tus tests conocen el linaje del pipeline, podés hacer algo más inteligente que simplemente frenar o no frenar.
Supongamos que detectás un duplicado en account_id. Si tenés determinado el linaje, sabés qué tablas están impactadas por ese campo. Podés avisar a los consumidores de esas tablas específicas, en lugar de frenar todo o no hacer nada.
Esto requiere tener el linaje documentado y accesible. Pero cuando lo tenés, la respuesta a un fallo de calidad puede ser mucho más precisa: no es "freno todo" ni "dejo pasar todo", sino "aviso a quienes les impacta y decido qué hacer".
Empezar por lo crítico
Si no tenés nada de calidad implementado, no hace falta gobernar todo de entrada. Identificá los 2, 3, 10 modelos o tablas que son clave para el negocio. Los que tienen impacto grande si fallan.
Para esos, definí las reglas de calidad que correspondan. Determiná el linaje. Documentá la metadata. Y después decidí qué pasa cuando fallan: ¿frena? ¿avisa? ¿a quién?
No podés dejar lo crítico abierto a que hoy funcione y mañana no sepas si los números están bien o mal. Pero tampoco necesitás gobernar las 200 tablas de tu warehouse antes de avanzar.
En resumen
Frenar el pipeline ante un fallo de calidad es una decisión de gobierno, no un detalle técnico.
Depende de qué tan crítico sea el dato afectado, qué tan maduro esté el proceso, y qué capacidad tenga el equipo para responder. No todos los fallos justifican frenar todo, pero algunos sí.
La configuración de severidades (warning vs error), el uso de umbrales, y el conocimiento del linaje permiten respuestas más inteligentes que el binario "freno todo" o "dejo pasar todo".
La pregunta no es "¿configuro los tests para que frenen?". Es "¿qué pasa cuando este test falla, y quién decide qué hacer?".