Hay un momento concreto que te dice que una plataforma de datos ha fracasado, y no es una caída. Es una reunión donde alguien presenta un número, otro dice que eso no parece correcto, y la sala acuerda comprobarlo aparte. Nadie confía en el gráfico. Todos mantienen su propia hoja de cálculo.
La respuesta habitual es construir un panel mejor. Eso casi nunca funciona, porque el problema nunca fue la presentación. El canal entregó datos incorrectos y nada objetó, así que el panel representó fielmente algo falso. Añadir otra vista de datos poco fiables produce otra vista poco fiable.
El silencio es el defecto de verdad
La mayoría de los canales se construyen para tener éxito. Un trabajo se ejecuta, transforma lo que se le da, escribe el resultado, sale con cero. Si un sistema de origen empieza a enviar nulos en una columna obligatoria, el trabajo tiene éxito. Si un join descarta en silencio el 30% de las filas porque un formato de clave de origen cambió, el trabajo tiene éxito. Si una columna de moneda pasa de dólares a céntimos, el trabajo tiene éxito con entusiasmo.
En todos los casos el canal hizo lo que se le dijo. Nunca se le dijo que tuviera una opinión sobre si los datos eran plausibles. Esa ausencia de opinión es el defecto, y es por lo que las pruebas de calidad de datos en los servicios de ingeniería de datos rinden más que casi cualquier otra inversión.
Cuatro tipos de prueba que detectan casi todo
No necesitas un framework elaborado. Cuatro categorías, aplicadas en el punto en que los datos entran en tu control, detectan la inmensa mayoría de los incidentes reales.
- Pruebas de esquema. ¿Tiene esta tabla las columnas esperadas, con los tipos esperados? Detecta cambios de origen que nadie anunció, la causa más común con diferencia de una corrupción silenciosa.
- Pruebas de volumen. ¿Está el recuento de filas de hoy dentro de una banda plausible del histórico reciente? Una tabla que normalmente gana 40.000 filas y gana 4 tiene un origen roto, con independencia de si el trabajo tuvo éxito.
- Pruebas de frescura. ¿Cuál es la marca de tiempo más nueva, y es lo bastante reciente como para ser usable? Datos obsoletos presentados como actuales son más peligrosos que datos que faltan, porque parecen bien.
- Pruebas de distribución. Tasas de nulos, cardinalidad y rangos de valores frente a normas recientes. Esto es lo que detecta el cambio de unidad, el nuevo valor de enumerado y la región que dejó de reportar.
Juntas suelen ser un día o dos de trabajo por canal crítico, y son la diferencia entre enterarse por una prueba y enterarse por una reunión del consejo.
Haz fallar el canal, no solo registres un aviso
La decisión que más importa es qué pasa cuando una prueba falla. Los equipos suelen empezar con avisos, porque parar un canal parece peligroso. Los avisos se ignoran en unas tres semanas. Esto es lo bastante fiable como para planificar en torno a ello.
Fallar de forma ruidosa es el valor por defecto correcto. Cuando una prueba de calidad falla, el canal se para y la tabla aguas abajo mantiene los datos de ayer conocidos como buenos en lugar de sobrescribirse con algo sospechoso. Obsoleto pero correcto supera a fresco pero incorrecto en casi cualquier contexto de negocio, porque la gente puede razonar sobre una tabla que va un día por detrás. No puede razonar sobre una tabla que está sutilmente envenenada.
Un panel que va un día obsoleto recibe una advertencia. Un panel que está silenciosamente mal recibe una decisión tomada sobre él.
La excepción es el enriquecimiento de verdad no crítico: un atributo agradable de tener donde datos parciales son mejores que nada. Marca esos explícitamente como solo aviso. El punto es que se convierte en una decisión deliberada por prueba en lugar de un valor por defecto general que nadie eligió.
Qué cambia de verdad operativamente
El efecto visible son menos números malos. El efecto mayor es sobre cómo el equipo emplea su tiempo.
Antes de las pruebas, la ruta de descubrimiento de un problema de datos va: alguien nota un número inverosímil, lo plantea días o semanas después, un analista investiga, lo rastrea hacia atrás por varias transformaciones, y al final encuentra un cambio de origen de hace tres semanas. Eso son a menudo días de trabajo, y las decisiones intermedias se tomaron sobre datos malos.
Después de las pruebas, el mismo problema aflora como un fallo concreto en una tabla concreta dentro de una ejecución del canal, nombrando la columna y la expectativa que violó. El diagnóstico es minutos, no días, y ningún número malo llegó nunca a nadie.
Hay también un efecto de segundo orden que merece nombrarse. Una vez que las pruebas existen, los equipos de origen empiezan a enterarse de sus cambios de inmediato en lugar de romper cosas en silencio durante semanas. Ese bucle de realimentación tiende a mejorar la disciplina de origen por sí solo, sin que nadie tenga que ejecutar un programa de gobierno para imponerlo.
Por dónde empezar
No por todas partes a la vez. Elige las tres tablas que alimentan los números que la dirección de verdad mira, y pon las cuatro categorías de prueba sobre esas. Eso suele ser menos de una semana, y protege los datos cuya incorrección sería más cara.
Luego añade propiedad. Cada tabla probada recibe un responsable designado que recibe el fallo. Una prueba que alerta a un canal compartido sin responsable es una prueba que se silencia. El trabajo técnico es la mitad fácil; la mitad que determina si sobrevive es decidir quién es responsable cuando se dispara.
