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:
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.
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
Copilot voor Power BI. Je persoonlijke assistent voor rapportages?
Is Copilot voor Power BI een volwassen tool en hoe bruikbaar is het?Copilot voor Microsoft Fabric is sinds juni 2024 algemeen beschikbaar in Power BI. Tijdens introductie waren er hoge verwachtingen! In verschillende artikelen, guides en tutorials werden de...
Altijd keurige code met SQLFluff in DBT. Zo werkt deze handige linter
SQL-code reviews kunnen behoorlijk tijdrovend zijn. Zeker als al je collega’s code op een andere manier schrijven. Bijvoorbeeld omdat je er geen afspraken over hebt gemaakt of niet iedereen zich aan de afspraken houdt. Met SQLFluff in dbt voorkom je dat. Data engineer...
Is Microsoft Fabric de moeite waard? Dit zijn onze bevindingen
Microsoft Fabric biedt op het eerste oog ongekende mogelijkheden, maar maakt het de verwachtingen waar? Data engineer Koen Kurver zocht het uit.