Auteur
In hun dagelijkse werkzaamheden moeten Data Engineer's en Data Analisten data ingestion processen verbeteren. Naast de gebruikelijke unit tests, kan het interessant zijn om eenvoudig en snel twee datasets (d.w.z. tabellen, views, queries, etc) te vergelijken voor verschillende doeleinden, zoals impact analyse of non-regressie testen. Ook het identificeren van discrepanties tussen twee gezichtspunten van een snapshot-tabel is erg nuttig voor ad-hocanalyse of debuggen.
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 ophalen die in aanmerking komen voor een promotie in een enkele tabel volgens de week promotievoorwaarden.
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 gemakkelijk om de bovenstaande vragen intuïtief te beantwoorden dankzij een triviaal voorbeeld op een kleine dataset, in echte gebruiksgevallen 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, zelfs als u uw ingestion SQL-query voor/na evolutie kunt kopiëren-plakken, een goed idee zijn om de resultaten opslaan in tijdelijke tabellen 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, resultaten sorteren op sleutel (de granulariteit van de datasets) en vlag kan enorm helpen bij het interpreteren en vergelijken van gelijkwaardige rijen afkomstig van beide datasets.
Om het onderzoek te vergemakkelijken en de oorsprong van de kloof te identificeren, zijn de verdacht datasets algemene velden kan verwijderd worden (d.w.z. becommentarieerd in CTE) uit de vergelijking: 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 zou veel moeilijker te onderhouden zijn geweest (beheer van NULLs & 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 nuttig als aanvulling op meer traditionele unit tests, en kan zelfs op een meer algemene manier gebruikt worden bij het vergelijken van twee datasets met vergelijkbare structuren. En last but not least, de logica van deze query is zelfs gemakkelijk uit het hoofd te leren!
Bedankt voor het lezen, ik hoop dat het duidelijk was en ik hoor graag uw feedback :)
