Autor
En su actividad diaria, los analistas Data Engineer y Data deben mejorar los procesos de ingestión data. Más allá de las pruebas unitarias habituales, puede resultar interesante comparar fácil y rápidamente dos conjuntos data (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 resulta 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 data 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 quiere recuperar todos los productos elegibles para una promoción en una sola tabla según la semana condiciones de promoción.
Como declaración inicial, consideramos los siguientes productos en stock:
Según las condiciones de promoción de la semana 1:
el dataset_1 es:
En la semana 2, las condiciones de promoción evolucionan a:
La evolución de la tubería data genera el dataset_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 data, 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:
Finalmente, todo tiene buen aspecto:
Consejos y trucos
En CTE, aunque pueda 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 data pueden ser desordenadas. Entonces, clasificación de resultados por clave (la granularidad de los conjuntos data) y bandera puede ayudar enormemente a interpretar y comparar filas equivalentes procedentes de ambos conjuntos data.
Para facilitar las investigaciones e identificar el origen de la brecha, el sospechoso datasets campos comunes 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 sólo 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 eficaz, ya que los operadores de conjuntos son más potentes que los joins.
Resumen
Por lo tanto, esta consulta planificada facilita a los desarrolladores la rápida validación de cambios en complejos conjuntos data. Es útil como complemento de pruebas unitarias más tradicionales, e incluso puede considerarse de forma más general al comparar dos conjuntos data cualesquiera con estructuras similares. Por último, pero no menos importante, ¡la lógica de esta consulta es incluso fácil de aprender de memoria!
Gracias por leer, espero que haya quedado claro y me encantaría conocer su opinión :)
