Autor
En su actividad diaria, los ingenieros de Data y los analistas de Data deben mejorar los procesos de ingestión de data . Más allá de las pruebas unitarias habituales, puede ser interesante comparar fácil y rápidamente dos conjuntos de datos (es decir, tablas, vistas, consultas, etc.) con distintos fines, como el análisis de impacto o las pruebas de no regresión. Asimismo, la identificación de discrepancias entre dos puntos de vista de una tabla instantánea es bastante útil para el análisis ad hoc o la depuración.
Teniendo esto en cuenta y para los profesionales de SQL, un script preconstruido y reutilizable tiene sentido, de ahí el propósito de este artículo.
Explicación de la plantilla SQL lista para usar
Vayamos al meollo de la cuestión con la pregunta esperada:
Ahora, vamos a explicarlo:
Nota: obviamente, disponer de dos conjuntos de datos con campos comparables es un requisito previo para utilizar la consulta anterior
Ejemplo ilustrado
Basta de teoría, ¡ahora a la práctica! Supongamos que un supermercado desea recuperar en una sola tabla todos los productos que pueden acogerse a una promoción según las condiciones de promoción de la semana.
Como declaración inicial, consideramos que los siguientes productos están en stock:
Según las condiciones de promoción de la semana 1:
el conjunto de datos_1 es:
En la semana 2, las condiciones de promoción evolucionan a:
La evolución de la tubería data genera el conjunto de datos_2:
Pero... ¿estamos realmente seguros de los resultados? Las preguntas típicas son:
Nota: aunque parezca fácil responder a las preguntas anteriores de forma intuitiva debido a un ejemplo trivial sobre un pequeño conjunto de datos, en casos de uso real solemos enfrentarnos a multitud de filas y columnas procedentes de consultas complejas (transformaciones, uniones, agregados, funciones de ventana, ...) dejando que esta consulta adquiera todo su significado
Intentemos responder a las 3 preguntas interpretando los resultados de la consulta comparativa:
Observaciones:
Por fin, todo tiene buena pinta:
Trucos y consejos
En CTE, incluso si puede copiar y pegar su consulta SQL de ingestión antes/después de la evolución, podría ser una buena idea almacenar los resultados en tablas temporales para simplificar la comparación, mejorar el rendimiento de la consulta y beneficiarse del almacenamiento en caché si la ejecuta varias veces.
En el mundo real, las divergencias entre dos conjuntos de datos pueden ser confusas. Entonces, ordenar los resultados por clave (la granularidad de los conjuntos de datos) y por bandera puede ayudar enormemente a interpretar y comparar filas equivalentes procedentes de ambos conjuntos de datos.
Para facilitar las investigaciones e identificar el origen de las diferencias, los campos comunes de los conjuntos de datos sospechosos pueden eliminarse (es decir, comentarse en CTE) de la comparación: si no hay resultado, significa que todos los campos comparados son iguales. A continuación, puede centrarse únicamente en los campos sospechosos restantes para la siguiente comparación y realizarla paso a paso.
Nota: se podría haber realizado un análisis equivalente utilizando la estrategia LEFT JOIN, pero habría sido mucho más difícil de mantener (gestión de NULLs y comparación de campos) y menos eficiente, ya que los operadores de conjuntos son más potentes que las uniones.
Resumen
Por tanto, esta consulta planificada facilita a los desarrolladores la rápida validación de cambios en canalizaciones complejas de data . Es útil como complemento de pruebas unitarias más tradicionales, e incluso puede considerarse de forma más general al comparar dos conjuntos de datos con estructuras similares. Por último, la lógica de esta consulta es fácil de aprender de memoria.
Gracias por leer, espero que haya quedado claro y me encantaría conocer su opinión :)
