We zijn bij The Information Lab al even fan van dbt maar toch worden we steeds weer plezierig verrast door features die we eerder hadden onderschat.

Binnen dbt spreekt de workflow redelijk voor zich en zijn bepaalde aspecten nu eenmaal leuker dan andere. Normaal gezien zou je dit scharen onder een necessary evil en vrede hebben met een aspect van werk dat minder gemakkelijk gaat als dat zou kunnen. Dit hebben we dan ook gedaan, totdat we opnieuw gingen kijken naar de openheid van dbt en de community om het product heen. Ben je het ergens niet mee eens of zie je iets dat gemakkelijker kan ? Maak een package en stel het beschikbaar !

Wat is een package?

Software engineers moduleren code vaak in bibliotheken. Deze bibliotheken helpen programmeurs om met hun tijd gerichter in te richten: Ze kunnen meer tijd besteden aan het focussen op hun unieke bedrijfslogica en minder tijd aan het implementeren van code die iemand anders al heeft besteed aan het perfectioneren.

In dbt worden bibliotheken zoals deze packages genoemd. De packages van dbt zijn juist zo krachtig omdat zoveel van de analytische problemen die je tegenkomt , niet uniek zijn en door organisaties worden gedeeld.

Je ziet dus ook weer hier het element van software engineering doorsijpelen richting data engineering; Gebruik best-practices die al een lange tijd binnen software development bestaan om de volwassenheid van je data engineering naar een hoger niveau te tillen.

Waar vind ik die packages?

De meest centrale plek voor dbt packages is een registry opgezet door dbt zelf : de package hub .
De hub dient al een centrale plek waarvandaan je de packages op een eenvoudige manier binnen je dbt project kunt importeren (en up-to-date kunt houden).

Een andere plaats om packages te vinden is GitHub. De ontwikkelaar van de packages heeft dit als project gedeeld met anderen en deze kan vanaf daar ook worden geinstalleerd.

Prive en lokale packages zijn ook nog een optie: Je kunt deze packages specifiek schrijven voor gebruik binnen enkel je eigen team door gebruik te maken van een prive of gesloten repository. Je zult deze over het algemeen minder tegenkomen.

Hoe installeer ik die packages ?

Het installeren van de packages gaat een stuk gemakkelijker als wat wij ondertussen gewend zijn vanuit de software development hoek :
1. Maak een bestand aan genaamd “packages.yml”
2. Voer in welke packages je wilt hebben met hun versie nummer

packages:
  - package: dbt-labs/codegen
    version: [">=0.6.0", "<0.7.0"]
  - package: tnightengale/dbt_meta_testing
    version: [">=0.3.5", "<0.4.0"]

3. Run het commando “dbt deps”
4. ??
5. Profit!

Hoe gebruik ik die packages ?

Elke package heeft zijn eigen manier van aansturen, zijn eigen commandos en zijn eigen werkwijze. De packages zijn over het algemeen goed gedocumenteerd (vooral als ze op de hub staan) met een duidelijke verwachting en voorbeelden over het gebruik.

Zijn er nog voorbeelden van wat packages voor je kunnen doen ?

2 packages waar ik zelf erg enthousiast van word zijn de packages Codegen en dbt_meta_testing

Codegen maakt van 1 van mijn minst plezierige taken een peulenschil :
Het aanmaken van .yml bestanden met tabel/column informatie.
Het kan nog wel eens een klus zijn om alle kolommen uit een tabel te vissen , dit mest de juist spacing in je .yml te zetten met beschrijving en vervolgens maar te hopen dat je niets bent vergeten (daar straks meer over).

Codegen

Codegen kan , naast een hoop andere functies , heel eenvoudig de .yml aanmaken voor al je sources binnen een schema met :

{{ codegen.generate_source('<schema>',database_name = '<database>') }}

Of de .yml aanmaken voor een specifiek model :

{{ codegen.generate_model_yaml(model_name='<model>') }}

Je plakt bovenstaande commando’s in een Scratchpad , drukt op Compile en de output is je volledige .yml , met de juiste indentation. De eerste keer dat ik het voorbij zag komen maakte ik een klein vreugdedansje !

Codegen is hier te vinden op de package hub.

dbt_meta_testing

dbt_meta_testing kwam ik tegen toen ik in het Slack kanaal van dbt opperde dat ik er niet zeker was dat mijn documentatie 100% up-to-date was.
meta_testing heeft 2 functies ; controlen of alle documentatie aanwezig is en of al je testing aanwezig is. Ik gebruik hem zelf voornamelijk voor het eerste gedeelte : documentatie.
Een nieuwe kolom is snel aangemaakt op verzoek van de business maar wordt nogal eens snel vergeten op het documentatie vlak. Door het toevoegen van een enkele regel code in je project.yml file :

 +required_docs: true

controlleerd dbt_meta_testing op 3 dingen :

  • Het model heeft een niet-lege beschrijving
  • De kolommen in het model zijn gespecificeerd in het model .yml
  • De kolommen gespecificeerd in het model .yml hebben niet-lege beschrijvingen

Vul simpelweg het volgende commando in en de check wordt gedaan :

dbt run-operation required_docs

dbt_meta_testing is hier te vinden op de package hub.