Maak gebruik van DBT-audits om nauwkeurige modelgeneratie te garanderen

Invoering

In het veranderende landschap van data-analyse en -engineering zijn efficiënte en betrouwbare tools voor datatransformatie cruciaal. dbt (data build tool) is uitgegroeid tot een toonaangevende oplossing die mogelijkheden biedt die datatransformatieworkflows stroomlijnen, de datakwaliteit verbeteren en collaboratieve datapraktijken ondersteunen. Veel bedrijven willen misschien DBT gaan gebruiken, maar blijven steken bij een oudere, legacy sql-gebaseerde etl-tool. In deze blog geven we een voorbeeld van het gebruik van de dbt audit helper als een manier om de resultaten te controleren bij het verplaatsen van uw legacy query naar dbt.

Vereisten

Bij elke verhuizing tussen tools is de ideale eerste stap om een overzicht te maken van de verschillende pipelines en hun logica. Dit overzicht fungeert als de ruggengraat van waaruit de ontwikkeling kan beginnen. Zorg ervoor dat u de bronnen en bestemmingen documenteert van waaruit de data wordt gelezen en geschreven, en de logica die bestaat uit SQL-query's, joins, filters en andere transformaties.

De dbt-omgeving instellen

We gaan hier niet in detail in op het opzetten van een dbt-airflow-omgeving, aangezien de documentatie hierover algemeen beschikbaar is. De basisstappen zijn echter:

Installeer dbt: Volg de officiële installatiehandleiding.
Initialiseer een dbt-project: voer dbt init uit gevolgd door de projectnaam om een nieuw dbt-project te maken.
Profielen configureren: Stel een profiles.yml-bestand in met de benodigde databaseverbindingsgegevens.
Maak de bronnen: Definieer de gegevensbronnen in dbt/models/sources/source_name.yml.
Stel opnamepijplijnen in: gebruik Airflow DAG's om aangepaste Python-opnames uit te voeren of kies uit het brede scala aan bestaande operators, afhankelijk van de vereisten.
Vul de opnamelaag: voer de opnamepijplijnen uit om de opnamelaag te vullen met brongegevens.

Zodra er gegevens in de opnamelaag staan die in de brongegevens gedefinieerd hadden moeten zijn, kunnen we beginnen met het migreren van de pijplijnen.

Let op: De opnamelaag moet kopieën van de brongegevens bevatten.

SQL naar dbt vertalen

Om de modellen te maken die de huidige transformaties zullen vervangen, organiseert u eerst de modellen op basis van het aantal lagen dat het project heeft (staging, intermediate, reporting). Voor bestand maakt u een bestand in de relevante laagmap onder modellen (dbt/models/staging/transformation_name.sql). Tijdens de overgangsfase kan het handig zijn om voorvoegsels in de tabelnamen of verschillende schema's te introduceren, zodat de gegevens die door de oude SQL worden gegenereerd en de gegevens die door dbt worden gegenereerd, in dezelfde laag kunnen bestaan ter vergelijking.

Let op: Gebruik tags om de modellen te groeperen, zodat ze in gegroepeerde dbt-builds kunnen worden uitgevoerd.

Test de modelnauwkeurigheid met een auditmodel

Een belangrijke stap bij het maken van de modellen is het testen of het gedrag van de modeltransformaties resulteert in gegevens die gelijk zijn aan de gegevens die zijn gegenereerd door de legacy tooltransformaties. Hier stellen we voor om een auditmodel te gebruiken om een vergelijkingsaudit te genereren. Een voorbeeld van zo'n model wordt hieronder weergegeven. Om dit model te genereren, hebben we gebruikgemaakt van de audit_helper-bibliotheek. https://hub.getdbt.com/dbt-labs/audit_helper/latest/

-- definieer de relatie van de dbt-modeltabel

{% set a_relation = source( 'snowflake' , 'pharmaceuticals_india' ) %}

-- definieer de relatie van de oude tabel

{% set b_relation = bron( 'snowflake2' , 'pharmaceuticals_india' ) %}

{% als uitvoeren %}

{% set audit_query = audit_helper.compare_row_counts(

a_relatie = a_relatie,

b_relatie = b_relatie

) %}

{% set audit_resultaten = run_query(audit_query) %}

{% doe audit_results.print_table() %}

{% eindig %}

{% als uitvoeren %}

{% set audit_query2 = audit_helpervergelijk_relatie_kolommen(

a_relatie = a_relatie,

b_relatie = b_relatie

) %}

{% set audit_resultaten2 = run_query(audit_query2) %}

{% doe audit_results2.print_table() %}

{% eindig %}

{% als uitvoeren %}

{% set audit_query3 = audit_helpervergelijk_relaties(

a_relatie = a_relatie,

b_relatie = b_relatie

) %}

{% set audit_results3 = run_query(audit_query3) %}

{% doe audit_results3.print_table() %}

{% eindig %}

{% als uitvoeren %}

{% set audit_query4 = audit_helpervergelijk_alle_kolommen(

a_relatie = a_relatie,

b_relatie = b_relatie,

primaire_sleutel = "ID" ,

) %}

{% set audit_results4 = run_query(audit_query4) %}

{% doe audit_results4.print_table() %}

{% eindig %}

selecteren 0 als audit_test

In de eerste stap gebruiken we audit_helper.compare_row_counts . Hierbij tellen we de rijen in beide tabellen en retourneren we het totale aantal.

In de tweede stap gebruiken we audit_helper.compare_relation_columns die de volgorde en het gegevenstype van de kolommen in beide tabellen controleert.

In de derde stap gebruiken we audit_helper.compare_relations. Dit retourneert het percentage van overeenkomende relaties.

In de laatste stap gebruiken we audit_helper.compare_all_columns. Dit controleert de overeenkomende rijen in beide tabellen en bekijkt hoeveel NULL-waarden elke kolom heeft voor elke kolom, en hoeveel elke kolom mist in vergelijking met de andere tabel.

De optie "select 0 as audit_test" aan het einde van de modellen fungeert als een tijdelijke query om te voorkomen dat er gegevens worden geretourneerd, terwijl wordt voldaan aan de vereiste van DBT om een selectieresultaat van elk model te retourneren.

Zodra alle modellen die de oude gereedschapstransformaties vervangen zijn gegenereerd, moet de volgende stap het opzetten van tests voor elke modus zijn .

demonstratie

Hier hebben we een db genaamd db1 die twee schema's bevat Schema1 en Schema1__legacy. Elk van de schema's bevat een tabel genaamd "pharmaceuticals_india". Hieronder zien we de uitvoer van het vergelijken van twee 100% gelijke tabellen.

Om het resultaat van een mislukte audit weer te geven, hebben we een kolom uit de tabel in Schema1 verwijderd. De uitvoer ziet er als volgt uit.

Conclusie

Het auditmodel dat we presenteerden, biedt een uitgebreide methode om gegevens te vergelijken tussen legacysystemen en nieuw geïmplementeerde DBT-modellen, wat zorgt voor consistentie en nauwkeurigheid van gegevens gedurende het transformatieproces. Deze aanpak stelt gebruikers in staat om eenvoudig discrepanties tussen datasets te identificeren, ongeacht of deze voortkomen uit verschillen in rijtellingen, kolomstructuren of gegevensinhoud. Door gebruik te maken van de audit_helper-bibliotheek kunnen deze vergelijkingen worden uitgevoerd met minimale overhead, wat het een testbenadering met lage impact maakt die de nauwkeurigheid van nieuwe modellen efficiënt valideert zonder dat er buitensporige middelen nodig zijn of complexiteit wordt geïntroduceerd.

Een van de belangrijkste voordelen van deze methodologie is dat het gedetailleerde zichtbaarheid biedt in potentiële problemen. Van basisrijtellingsmismatches tot meer ingewikkelde kolom- en data-integriteitscontroles, dit proces stelt gebruikers in staat om de exacte aard van discrepanties te achterhalen.

Uiteindelijk kunnen organisaties door DBT en audit_helper te gebruiken voor modelgeneratie een soepele, risicoloze overgang van oude ETL-tools naar moderne, cloudgebaseerde datapijplijnen realiseren. Dit zorgt ervoor dat transformaties op de lange termijn correct, schaalbaar en onderhoudbaar zijn. Een dergelijke aanpak bouwt vertrouwen op in het migratieproces, waardoor teams de voordelen van DBT kunnen omarmen, zoals modulariteit, versiebeheer en samenwerking, zonder de nauwkeurigheid van kritieke bedrijfsgegevens op te offeren.