Autor
Data Em suas atividades diárias, os engenheiros e analistas do Data devem aprimorar os processos de ingestão do data . Além dos testes unitários usuais, pode ser interessante comparar de forma fácil e rápida dois conjuntos de dados (ou seja, tabelas, exibições, consultas etc.) para diferentes finalidades, como análise de impacto ou teste de não regressão. Além disso, a identificação de discrepâncias entre dois pontos de vista de uma tabela de instantâneos é bastante útil para análise adhoc ou depuração.
Com isso em mente e para os profissionais de SQL, um script pré-criado e reutilizável faz sentido, daí o objetivo deste artigo.
Explicação do modelo SQL pronto para uso
Vamos ao cerne da questão com a consulta esperada:
Agora, vamos explicar isso:
Observação: obviamente, ter dois conjuntos de dados com campos comparáveis é um pré-requisito para usar a consulta acima
Exemplo ilustrado
Chega de teoria, agora vamos à prática! Suponha que um supermercado queira recuperar todos os produtos qualificados para uma promoção em uma única tabela, de acordo com as condições da promoção da semana.
Como declaração inicial, consideramos os produtos abaixo em estoque:
De acordo com as condições da promoção na semana 1:
o conjunto de dados_1 é:
Na semana 2, as condições de promoção evoluem para:
A evolução do pipeline data gera o conjunto de dados_2:
Mas... será que estamos realmente confiantes com os resultados? As perguntas típicas são:
Observação: mesmo que pareça fácil responder às perguntas acima de forma intuitiva devido a um exemplo trivial em um pequeno conjunto de dados, em casos de uso real, geralmente enfrentamos muitas linhas e colunas de consultas complexas (transformações, uniões, agregados, funções de janelas, etc.), o que faz com que essa consulta assuma todo o seu significado
Vamos tentar responder às três perguntas interpretando os resultados da consulta de comparação:
Observações:
Finalmente, tudo parece bem:
Dicas e truques
No CTE, mesmo que você possa copiar e colar sua consulta SQL de ingestão antes/depois da evolução, pode ser uma boa ideia armazenar os resultados em tabelas temporárias para simplificar a comparação, melhorar o desempenho da consulta e se beneficiar do armazenamento em cache se você executá-la várias vezes.
No mundo real, as divergências entre dois conjuntos de dados podem ser confusas. Então, a classificação dos resultados por chave (a granularidade dos conjuntos de dados) e sinalizador pode ajudar muito a interpretar e comparar linhas equivalentes provenientes de ambos os conjuntos de dados.
Para facilitar as investigações e identificar a origem da lacuna, os campos comuns dos conjuntos de dados suspeitos podem ser removidos (ou seja, comentados no CTE) da comparação: se não houver resultado, isso significa que todos os campos comparados são iguais. Você pode então se concentrar apenas nos campos suspeitos restantes para a próxima comparação e fazê-la passo a passo.
Observação: uma análise equivalente poderia ter sido realizada usando a estratégia LEFT JOIN, mas seria muito mais difícil de manter (gerenciamento de NULLs e comparação de campos) e menos eficiente, pois os operadores de conjunto são mais poderosos do que as uniões.
Resumo
Portanto, essa consulta de modelo facilita para os desenvolvedores a validação rápida de alterações em pipelines complexos do data . Ela é útil como complemento para testes de unidade mais tradicionais e pode até ser considerada de forma mais geral ao comparar dois conjuntos de dados com estruturas semelhantes. Por último, mas não menos importante, a lógica dessa consulta é até fácil de aprender de cor!
Obrigado por ler, espero que tenha sido claro e ficaria feliz em ouvir seu feedback :)
