Puntos clave
- Los cambios a MLV necesitan una conciliación por niveles: filas, después claves, después agregados de columna.
- Los métodos de comparación tienen en cuenta el tipo, con tolerancias escritas por columna.
- Una fila de checklist por columna (responsable, método, aprobación) es obligatoria en gold.
- Los jobs de validación emiten resultados legibles por máquina y una muestra acotada de discrepancias.
- Guarda esos artefactos como evidencia del release junto a la definición de la MLV.
- Vuelve a ejecutar el arnés ante cambios relevantes en la MLV, no solo en el primer cambio.
Una checklist de migración que solo compara recuentos de filas da luz verde a totales equivocados, fechas equivocadas y estados equivocados. Los recuentos de filas detectan pérdidas catastróficas. Se les escapa el CAST silencioso que convierte decimales en floats, el null que se volvió una cadena vacía y la columna que tomó un valor por defecto sin avisar.
Lleva los cambios a MLV a tablas por columna y agregados según el tipo. Toma prestada la conciliación por niveles en la que ya confían las migraciones de datos clásicas: filas, después claves, después agregados de columna. Automatízala. Trata los artefactos como evidencia del release, no como una captura de pantalla enterrada en el chat.
Modelo con nombre: filas → claves → agregados de columna
- Filas: los recuentos y las ventanas de frescura responden si ha desaparecido volumen. Solo es una prueba de humo.
- Claves: la presencia, los duplicados y los huérfanos responden si han llegado las mismas entidades. Para aquí si hay fallos duros.
- Agregados de columna: las sumas según el tipo, las tasas de nulos y las distribuciones responden si los valores siguen significando lo mismo.
- Checklist: cada columna tiene responsable, método de comparación, tolerancia, último resultado y aprobación.
- Contrato: la deriva semántica se esconde en las columnas. Una validación que no puede nombrar una columna no puede proteger un cambio.
Figura 1. Las filas detectan catástrofes. Las claves detectan entidades que faltan. Los agregados de columna detectan el CAST silencioso que rompe los totales. Ejecútalos en orden y para ante fallos duros.
Contexto y restricción
Un fallo habitual: un cambio cuadra en filas y falla en una medida que suma una columna decimal que la MLV amplió a floats aproximados. A los consumidores posteriores no les importa que Spark terminara antes. Les importa que dos totales difieran lo suficiente como para empezar una discusión.
La conciliación por niveles existe porque cada nivel responde a una pregunta distinta. Las filas preguntan "¿hemos perdido volumen?". Las claves preguntan "¿tenemos las mismas entidades?". Los agregados de columna preguntan "¿los valores siguen significando lo mismo?". Las comparaciones según el tipo detectan discrepancias entre float y decimal o entre null y vacío que la igualdad sobre cadenas tapa. Una fila de checklist por columna hace posibles la responsabilidad y la aprobación. El QA con capturas de pantalla no es evidencia.
La figura 2 es la pantalla de Learn para los informes de calidad de datos de MLV. Las comprobaciones de la plataforma ayudan. No sustituyen un contrato de columnas por escrito con responsables y tolerancias.
Figura 2. Los recuentos de filas detectan catástrofes. Los agregados de columna y los informes de calidad detectan el CAST silencioso que rompe los totales. Fuente: Microsoft Learn: MLV data quality reports.
La figura 3 es la pantalla de detalle. Trata los resultados de la conciliación por columna como evidencia del release para los cambios a MLV, no como apuntes opcionales en un notebook.
Figura 3. Trata los artefactos de la conciliación por columna como evidencia del release para los cambios a MLV, no como apuntes opcionales en un notebook. Fuente: Microsoft Learn: MLV data quality reports.
1. Ejecuta los niveles en orden y para ante fallos duros
Empieza con los recuentos de filas y las ventanas de frescura. Después compara las claves de negocio (presencia, duplicados, huérfanos). Solo entonces ejecuta los agregados de columna y las comprobaciones de distribución. Si las claves no coinciden, las sumas de columna mentirán sobre el motivo. Parar pronto ahorra tiempo de análisis y evita la falsa tranquilidad de "los totales se parecen".
2. Haz obligatorias las comparaciones según el tipo
Los decimales, los floats, los timestamps y las cadenas necesitan tolerancias y semánticas de null distintas. Cadena vacía frente a null es una decisión de producto, no una curiosidad de Spark. Fija los tipos esperados a partir del contrato y haz que falle cuando la MLV publique otro tipo "porque seguía ordenando bien". Las comparaciones de floats necesitan un epsilon explícito o una cuantización decimal que puedas defender en la revisión.
3. Una fila de checklist por columna
Cada columna tiene responsable, método de comparación, tolerancia, último resultado y aprobación. Las tablas anchas dejan de ser un ejercicio de intuición. Los revisores pueden preguntar quién aceptó el riesgo residual de un float difuso en lugar de esperar que alguien se acuerde. Las filas que faltan en la checklist son trabajo sin terminar, no un pulido opcional. La figura 4 muestra esa fila.
Figura 4. Una fila de checklist por columna. El responsable, el método, la tolerancia y la aprobación convierten el riesgo residual en algo que un revisor puede nombrar.
4. Automatiza en scripts de análisis, no en presentaciones
Los notebooks o los jobs deben emitir resultados legibles por máquina: pasa o falla, diferencias, claves de ejemplo que fallan. Las personas interpretan las excepciones. Las personas no deberían copiar a mano cada viernes los recuentos de dos ventanas de consulta en Excel. Automatizar también significa que puedes volver a ejecutar tras un cambio "mínimo" en la MLV sin heroicidades.
5. Guarda muestras de discrepancias junto a los agregados
Los agregados te dicen que algo está mal. Las muestras te dicen qué. Conserva un conjunto acotado de claves discrepantes por cada columna que falla, para el triaje. Sin muestras, cada fallo se convierte en un proyecto de investigación. Con muestras, ves el error del CAST o del join en minutos.
6. Guarda los artefactos de validación como evidencia del release
Adjunta los resultados al registro del release igual que adjuntas los ids de ejecución de los pipelines. Los auditores y tu yo futuro preguntarán qué se comparó el día del cambio. Las capturas del chat envejecen mal. Los archivos de resultados versionados junto al notebook de la MLV envejecen con honestidad. La figura 5 muestra ese recorrido.
Figura 5. Ejecuta el arnés, emite pasa o falla con muestras acotadas y adjunta los archivos junto a la definición de la MLV. Vuelve a ejecutarlo cuando cambie la MLV.
Construir un arnés que la gente de verdad ejecute
Haz que el arnés sea aburrido: las mismas instantáneas de entrada, el mismo orden de niveles y el mismo esquema de salida en cada ejecución. Parametriza el nombre de la MLV y el stage. Publica una guía de una página en el repo para que la guardia no tenga que hacer ingeniería inversa de tu notebook de mayo. Si el arnés tarda una hora en arrancar, la gente se lo saltará con prisas. Optimiza para volver a ejecutarlo. Cachea las extracciones de la línea base cuando el lado del warehouse es caro, y registra qué instantánea de línea base usaste para que las discusiones sean sobre los datos y no sobre qué martes era.
Qué debe significar "suficientemente cerca" por escrito
Si dos sumas decimales difieren por una regla de redondeo que aceptas, escribe la regla junto a la columna. "Parece bien" no es una tolerancia. Mejor comparar valores cuantizados (por ejemplo, decimales a dos posiciones) que esperar que la igualdad de floats se porte bien. Cuando una columna es no determinista a propósito (timestamps de procesamiento), exclúyela de la paridad o compara solo por fechas de efecto de negocio. Las exclusiones están permitidas. Las exclusiones silenciosas, no.
Errores comunes
Verde solo por filas. El volumen cuadra; los totales no.
Convertirlo todo a cadena y comparar. Los tipos y los nulos desaparecen en coincidencias de texto.
Una única puntuación gigante de "calidad de datos". Nadie sabe qué columna falló ni a quién le toca arreglarla.
QA manual con capturas de pantalla. Irrepetible, imposible de revisar y perdido al acabar la reunión.
Agregados sin muestras. Debates interminables sobre si el arnés está mal.
Validar una sola vez en el cambio. La deriva vuelve con el siguiente ajuste de la MLV; el arnés tiene que ser reutilizable.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Los cambios a MLV requieren una conciliación por niveles: filas, claves, agregados de columna.
- Los métodos de comparación tienen en cuenta el tipo y tienen tolerancias documentadas.
- Una checklist por columna con responsable y aprobación es obligatoria en gold (y recomendable en silver).
- Los jobs de validación emiten resultados legibles por máquina y una muestra acotada de discrepancias.
- Los artefactos se conservan como evidencia del release junto a la definición de la MLV.
- El arnés se vuelve a ejecutar ante cambios relevantes en la MLV, no solo en el primer cambio.
Adáptalo antes de usarlo
La validación por columna cuesta cómputo y tiempo de escritura. Los cambios equivocados cuestan confianza. Las tolerancias estrictas generan ruido en columnas float legítimas; documenta epsilons por columna en lugar de una holgura global. La política alrededor de quién es responsable de cada columna puede frenar la aprobación. Ese frenazo sale más barato que una deriva sin aprobar en producción. Automatizar las muestras exige cuidado con los datos personales; aplica hash o restringe las columnas que salen del lakehouse.
Referencias principales: MLV data quality reports en Microsoft Learn, junto con los patrones clásicos de pruebas de conciliación en migraciones. Combina las herramientas de la plataforma con un contrato de columnas por escrito para que "verde" signifique algo concreto.
Valida columna a columna, con tipos, responsables y artefactos que puedas reproducir. Los cambios a MLV dejan de ser un acto de fe en cuanto la checklist puede nombrar qué ha derivado.