Caso de estudio · Ingeniería de Datos · Forward Deployed
table-diff: Demostrar que una Migración Está Bien
Compara una tabla antigua con su copia migrada por hash, del día a la fila y a la celda, y filtra el ruido inofensivo que toda migración agrega.
El problema
Después de una migración, alguien tiene que demostrar que la tabla nueva es igual a la antigua. Los conteos pueden coincidir aunque los valores estén mal, y una comparación fila por fila marca casi todas las filas por ruido inofensivo.
Restricciones
- Las tablas pueden tener millones de filas, así que los datos nunca deben pasar a Python
- Tras una migración los decimales varían, las columnas CHAR se rellenan con espacios y los textos vacíos se vuelven NULL
- El resultado tiene que servir como control: el pipeline debe fallar solo si la copia está mal
Arquitectura y decisiones
Haz clic en una caja para ver por qué se eligió.
Por qué · DuckDB
Las tres pasadas son SQL dentro de DuckDB: una laptop compara 1.000.000 de filas en menos de 0,1 segundos y la memoria no crece.
Resultados
- para comparar 1.000.000 de filas en una laptop
- 0,09 s
- para comparar 1.000.000 de filas en una laptop
- días marcados: comparación directa vs con reglas de ruido
- 30 → 4
- días marcados: comparación directa vs con reglas de ruido
- errores sembrados encontrados, sin nada más reportado
- 3 de 3
- errores sembrados encontrados, sin nada más reportado
- pruebas automáticas, CI en Python 3.11–3.13
- 32
- pruebas automáticas, CI en Python 3.11–3.13
Qué haría después
- 01Leer desde Postgres y Snowflake con extensiones de DuckDB y hacer la pasada por partición dentro del warehouse
- 02Tolerancias por columna, por ejemplo amount ± 0,01
- 03Un reporte HTML con un mapa de calor de particiones por día