Auteur
In hun dagelijkse werkzaamheden moeten Data Engineers en Data Analisten de opnameprocessen van data verbeteren. Naast de gebruikelijke eenheidstests kan het interessant zijn om twee datasets (d.w.z. tabellen, views, queries, enz.) eenvoudig en snel te vergelijken voor verschillende doeleinden, zoals impactanalyse of non-regressietests. Ook het identificeren van discrepanties tussen twee gezichtspunten van een snapshot tabel is erg nuttig voor adhoc analyse of debugging.
Met dit in gedachten en voor SQL-beoefenaars is een kant-en-klaar en herbruikbaar script zinvol, vandaar het doel van dit artikel.
Gebruiksklare SQL-sjabloon uitgelegd
Laten we naar de kern van de zaak gaan met de verwachte vraag:
Laten we het nu uitleggen:
Opmerking: uiteraard is het hebben van twee datasets met vergelijkbare velden een voorwaarde om de bovenstaande query te kunnen gebruiken.
Geïllustreerd voorbeeld
Genoeg theorie, nu de praktijk! Stel dat een supermarkt alle producten die in aanmerking komen voor een promotie in één tabel wil ophalen volgens de actievoorwaarden van de week.
In eerste instantie beschouwen we onderstaande producten als op voorraad:
Volgens de promotievoorwaarden in week 1:
de dataset_1 is:
In week 2 evolueren de promotievoorwaarden naar:
De evolutie van de data pijplijn genereert de dataset_2:
Maar... zijn we echt zeker van de resultaten? Typische vragen zijn:
Opmerking: ook al lijkt het eenvoudig om de bovenstaande vragen intuïtief te beantwoorden door een triviaal voorbeeld op een kleine dataset, in echte gebruikssituaties hebben we meestal te maken met veel rijen en kolommen van complexe queries (transformaties, joins, aggregaten, windowsfuncties, ...) waardoor deze query zijn volledige betekenis krijgt.
Laten we proberen de 3 vragen te beantwoorden door de resultaten van de vergelijkende query te interpreteren:
Opmerkingen:
Eindelijk ziet alles er goed uit:
Tips en trucs
In CTE kan het een goed idee zijn om de resultaten in tijdelijke tabellen op te slaan, zelfs als u uw ingestion SQL query voor/na evolutie kunt kopiëren-plakken, om de vergelijking te vereenvoudigen, de queryprestaties te verbeteren en te profiteren van caching als u de query meerdere keren uitvoert.
In de echte wereld kunnen verschillen tussen twee datasets rommelig zijn. Dan kan het sorteren van resultaten op sleutel (de granulariteit van de datasets) en vlag enorm helpen bij het interpreteren en vergelijken van gelijkwaardige rijen uit beide datasets.
Om het onderzoek te vergemakkelijken en de oorsprong van het gat te identificeren, kunnen de gemeenschappelijke velden van de verdachte datasets uit de vergelijking worden verwijderd (d.w.z. becommentarieerd in CTE): als er geen resultaat is, betekent dit dat alle vergeleken velden gelijk zijn. U kunt zich dan bij de volgende vergelijking alleen richten op de resterende verdachte velden en deze stap voor stap uitvoeren.
Opmerking: een gelijkwaardige analyse had kunnen worden uitgevoerd met behulp van de LEFT JOIN-strategie, maar dat zou veel moeilijker te onderhouden zijn geweest (beheer van NULL's en veldenvergelijkingen) en minder efficiënt, omdat setoperators krachtiger zijn dan joins.
Samenvatting
Deze gesjabloneerde query maakt het daarom eenvoudiger voor ontwikkelaars om snel wijzigingen op complexe data pijplijnen te valideren. Het is handig als aanvulling op meer traditionele unit tests en kan zelfs op een meer algemene manier worden gebruikt bij het vergelijken van twee datasets met vergelijkbare structuren. En last but not least: de logica van deze query is zelfs eenvoudig uit je hoofd te leren!
Bedankt voor het lezen, ik hoop dat het duidelijk was en ik hoor graag je feedback :)
