Begin nú met het valideren van je data: zo doe je dat met dbt

Het valideren van data die je aangeleverd krijgt, is een ondergeschoven kindje. En dat is eigenlijk heel raar. Dat durft data engineer Tijmen van Willigen best te stellen. In dit blog legt hij uit wat het verschil is tussen valideren en testen, hoe je data eenvoudig valideert met dbt én waarom dat belangrijk is.

Wat is een van de eerste dingen die je doet als je een nieuw recept uitprobeert? Je test uiteraard of het gerecht op smaak is. En voordat je een nieuwe auto koopt, maak je een proefrit.

Bovendien spring je nooit zomaar in bad: je voelt eerst hoe warm het water is. In veel dagelijkse situaties voer je tests uit. Dat doe je haast automatisch. Maar waarom doen we dat niet met data? Ik zie namelijk regelmatig dat het testen van data in veel organisaties nog geen logische stap is. En als het wel gebeurt, wordt er lang niet altijd iets gedaan met de resultaten van een test.

Best apart eigenlijk, want het uitvoeren van tests is een belangrijke eerste controle voor het borgen van je datakwaliteit. Voordat je data transformeert, check je of de aangeleverde data voldoet aan de kwaliteitseisen. Of je test of de logica die je hebt gebouwd om data te transformeren, doet wat het moet doen.

Verschil tussen valideren en testen

Daarmee kom ik meteen op een belangrijk onderscheid in tests. Je kunt namelijk valideren of testen. Over het algemeen heb je het over validatie als je de data input controleert, bijvoorbeeld of de data in het afgesproken formaat is aangeleverd. Als die validatie faalt, kun je ervoor kiezen om de aangeleverde data niet in te laden en daarmee data issues te voorkomen.

Wil je jouw gemaakte bewerkingen of logica controleren? Dan spreek je over testing. Zo houd je grip op de kwaliteit van je datatransformaties.

Validatie met dbt

Aangeleverde data valideren, is een simpele eerste check om datakwaliteit te borgen. De populaire datatransformatietool dbt maakt het reuze eenvoudig om dat te doen.

De tool bevat namelijk standaard enkele validaties die je direct kunt inzetten en voldoende mogelijkheden om je eigen validaties op te tuigen. Daar zit een zekere gradatie in. Van heel basale validaties tot diepgaandere tests om de resultaten ervan te analyseren zodat je datakwaliteit continu kunt verbeteren. Die gradatie ziet er zo uit:

validatie_volwassenheid_dbt

Meer van dit in je mailbox?

We sturen je circa 6x per jaar een email met handpicked cases, blogs en tips.

Goed om te weten overigens: hoewel het hier gaat om validaties, noemt dbt het zelf ‘tests’. Een tikkeltje verwarrend uiteraard. Ik licht de vijf tests (validaties dus) die je met dbt kunt uitvoeren even toe:

1 – Generic tests

Dbt heeft vier generic tests die standaard beschikbaar zijn. Het zijn uitstekende manieren om aangeleverde data te valideren op veelvoorkomende punten, namelijk:

  • not_null
    De inhoud van een kolom mag niet leeg zijn.
  • unique
    De inhoud van een kolom moet uniek zijn.
  • accepted_values
    De inhoud van een kolom moet overeenkomen met de afgesproken waardes.
  • relationships
    De inhoud van een kolom moet een relatie hebben met een kolom uit een andere tabel.

2 – Custom generic tests

Je kunt de vier generieke validaties ook uitbreiden. Dat doe je door custom generic tests te maken. Bijvoorbeeld om te controleren of een kolom even of oneven getallen bevat. Deze custom generic tests kun je vervolgens ook hergebruiken. Hoe je deze tests maakt, lees je in deze guide van dbt.

3 – Singular tests

Singular tests gebruik je voor specifieke gevallen. Denk aan het valideren van geografische coördinaten om bijvoorbeeld te controleren of een locatie in Europa ligt. Voor een singular test schrijf je een SQL-query die foutieve regels teruggeeft. Zodra de validatie een of meerdere (afhankelijk van de drempel die je instelt) regels teruggeeft, faalt de validatie dus. Singular tests in dbt zijn niet bedoeld om te herhalen voor verschillende modellen. Als je dat wel wilt doen, kun je beter kiezen voor custom generic tests.

4 – Test packages

Voor complexere validaties kun je in dbt gebruikmaken van test packages. Dit zijn Python packages met voorgedefinieerde validaties die door anderen zijn geschreven en die je direct kunt gebruiken. Twee van de meest bekende packages zijn:

  • dbt_utils
    Een package met generic dbt tests, SQL-generators en macro’s. Dbt_utils geeft de mogelijkheid om complexere generic tests out of the box te gebruiken.
  • dbt_expectations
    Dit pakket is een onderdeel van de Great Expectations Library in Python. Dbt_expectations geeft je uitgebreide validatiemogelijkheden, zoals statistische analyse en validaties met bijvoorbeeld regular expressions.

5 – Persisting test results

Dbt slaat validatieresultaten niet standaard op. Dus als je resultaten continu en grondig wil analyseren, bijvoorbeeld door er een rapportage van te maken of om het verloop van de datakwaliteit over tijd te monitoren, moet je een manier vinden om de resultaten op te slaan. Door dbt de test resultaten in een logging te laten opslaan, kun je de resultaten uitlezen en hergebruiken.

Waarschuwing of error?

In dbt kun je aangeven hoe ernstig validatiefouten moeten zijn. Je kunt kiezen tussen een waarschuwing (warn) of een error. Bij een waarschuwing loopt het proces gewoon door, bij een error stopt het.

Validatietests staan standaard ingesteld op error, maar je kunt dus per testtype zelf een afweging maken. Het is bovendien ook mogelijk om bij bijvoorbeeld tien gefaalde validaties een waarschuwing te krijgen en bij meer dan honderd een error.

Allemaal handige features om meer grip te krijgen op je validatieproces – en dus ook op je datakwaliteit.

Bepaal wie verantwoordelijk is

Stel, je gaat enthousiast aan de slag met het instellen van een validatie. En iedere keer dat je data valideert, komen daar verschillende waarschuwingen en errors uit. Top, het werkt! Maar wat dan?

Een validatie is niets waard als je er vervolgens geen verbeteracties aan koppelt. Daarom is het belangrijk om te bepalen wie of welk team verantwoordelijk is voor welke validatie, zodat er opvolging plaatsvindt.

Je kunt bijvoorbeeld afspreken wie verantwoordelijk is voor welk bronsysteem. In veel gevallen heb je nog wel een data engineer nodig om de validatieresultaten goed te interpreteren.

Testen loont de moeite

Ja, het kost even tijd om tests goed in te stellen. Je moet namelijk de factoren die fout kunnen gaan van tevoren uitdenken. Maar het loont de moeite. Omdat je mogelijke issues vooraf al voorkomt – en je dus minder troep achteraf hoeft op te ruimen. Dat doet wonderen voor je datakwaliteit.

Ben je pas net begonnen met dbt? Begin dan met het instellen van wat generic tests. En maak concrete afspraken over wie waar verantwoordelijk voor is. Dat maakt jouw leven heel wat gemakkelijker – dat beloof ik.

Tijmen-van-Willigen

Geschreven door

Tijmen van Willigen

Data engineer

Op de hoogte blijven van de laatste ontwikkelingen en webinars?

Schrijf je dan in voor de nieuwsbrief en ontvang circa 6x per jaar een selectie van blogs, cases, webinars en nieuws in je mailbox.

Meer over dit onderwerp