Dans ce tutoriel, vous allez apprendre à modéliser vos données avec DBT.
Le projet de référence comporte d’autres étapes intermédiaires et vous donne une vue un peu plus exhaustive de ce qui peut être réalisé, notamment autour des tests.
Les transformations avec DBT se définissent dans le module “Transform”
Dans le panneau source, dans le dossier sources, on peut ajouter une nouvelle entrée ou éditer une existante.
“Show” permet d’ouvrir en lecture seule un item, alors que “Open” ouvre un item et permet sa modification en vérouillant celui-ci pour les autres utilisateurs.
On défini les attributs suivants dans une source de donnée :
<aside> 📌 La référence pour la définition des fichiers de sources est sur le site de DBT (https://docs.getdbt.com/docs/build/sources)
</aside>
Dans la section modèle, on va pouvoir construire les étapes successives de nos transformations. généralement on commence par reprendre les données sources dans un modèle en y appliquant quelques règles de validations des données. Les modèles sont organisés par dossier, mais celà n’a aucune influence sur l’execution de ceux-ci.
Pour définir un modèle on doit fournir 3 éléments :
La force de DBT ests de ne pas utiliser des références directes aux tables dans la base de donnée, mais des références aux modèles et aux sources. Cette flexibilité permet de facielement transposer uen modélisation d’un environnement vers un autre.
Pour la table source “customers”
On crée une modèle qui s’appelle “customers”
SQL
on va réaliser ici des opérations de typage des colonnes dans la vues qui sera construite à l’execution.
La clause FROM fait appel à la table “tpch_customers” de la source “raw” prélablement définie avec le tag {{ source(”sourcename”, “tablename” }}
SELECT
"c_acctbal"::float as balance,
"c_address" as address,
"c_comment" as comment,
"c_mktsegment" as segment,
"c_name" as customername,
"c_nationkey"::integer as nationkey,
"c_phone" as phonenumber,
"c_custkey"::integer as custkey
FROM
{{ source("raw","tpch_customers")}}
Metadata YML
La version ne doit pas être modiifée et rester à 2
Models est une liste des modèles défini, dans notre cas il n’y a qu’une seule entrée “customers”
version: 2
models:
- name: customers
description: '{{ doc("customers") }}'
columns:
- name: custkey
tests:
- not_null
- unique
- name: segment
tests:
- accepted_values:
values: ['AUTOMOBILE','BUILDING','FURNITURE','HOUSEHOLD','MACHINERY']
Documentation
Ce fichier markdown comprends le tag {{ docs customers }} qui permet de définir cette documentation comme pouvant être appelable par la référence “customers”
{% docs customers %}
## Base table for customers with cast and column renaming
## Tests
* Check that the customer key is not null and unique
* Check that customer segments are in the list of values
* AUTOMOBILE
* BUILDING
* FURNITURE
* HOUSEHOLD
* MACHINERY
{% enddocs %}
<aside> 📌 L’utilisation de “Save” vous permet de sauvegarder votre travail localement. Pour rendre ce travail executable sur le serveur et partageable avec les autres avec le repo Git se fait en utilisant “Validate and Apply”
</aside>
<aside> 📌 La référence de définition de modèles est disponible sur le site de DBT https://docs.getdbt.com/docs/build/models
</aside>
SQL
SELECT
"o_clerk" as clerk,
"o_comment" as comment,
"o_custkey"::integer as custkey,
"o_orderdate"::date as orderdate,
"o_orderpriority" as orderpriority,
"o_orderstatus" as orderstatus,
"o_totalprice"::float as price,
"o_orderkey"::integer as orderkey
FROM
{{ source("raw","tpch_orders")}}
Metadata YML
version: 2
models:
- name: orders
description: '{{ doc("orders") }}'
columns:
- name: custkey
tests:
- not_null
- relationships:
to: ref('customers')
field: custkey
- name: orderkey
tests:
- not_null
- unique
- name: orderpriority
tests:
- accepted_values:
values: ['1-URGENT','2-HIGH','3-MEDIUM','4-NOT SPECIFIED','5-LOW']
Documentation MD
{% docs orders %}
## Base table for orders with cast and column renaming
## Tests
* Check that the order key is not null and unique
* Check that the customer key one of the key in customers table
* Check that orders priorites are in the list of values
* 1-URGENT
* 2-HIGH
* 3-MEDIUM
* 4-NOT SPECIFIED
* 5-LOW
{% enddocs %}
Une fois nos deux tables de données intégrée dans la modélisation DBT, on va générer une table de jointure entre celles-ci.
SQL
Cette requête fait référence aux modèles préalablement définis avec le tag {{ ref(”xyz”) }} d’une manière similaire à ce qui était fait avec les sources de données
SELECT
o.clerk,
o.orderdate,
o.orderpriorityid,
o.orderpriorityname,
o.orderstatus,
o.price,
c.balance,
c.segment,
c.customername,
c.nationkey
FROM
{{ ref("orders") }} o
INNER JOIN
{{ ref("customers") }} c
ON
o.custkey = c.custkey
Metadata
version: 2
models:
- name: orderscust
description: Final orders table with customers info
Documentation
{% docs orderscust %}
{% enddocs %}
Depuis chacun des modèles, il est possible de lancer l’execution directement.
On voit que l’argument —models base.customers a été ajouté pour restreindre l’execution
Cette possibilité permet de tester juste un modèle sans executer toute la modélisation.
Pour executer les tests définis dans le modèle il faut choisir “test” dans le menu déroulant.
L’execution de ce modèle avec “Run” ne va executer que le modèle courant :
06:59:34 Running with dbt=1.0.1
06:59:34 Found 6 models, 10 tests, 0 snapshots, 0 analyses, 166 macros, 0 operations, 0 seed files, 2 sources, 0 exposures, 0 metrics
06:59:34
06:59:39 Concurrency: 1 threads (target='dev')
06:59:39
06:59:39 1 of 1 START view model demo.customers.......................................... [RUN]
06:59:39 1 of 1 OK created view model demo.customers..................................... [CREATE VIEW in 0.15s]
06:59:39
06:59:39 Finished running 1 view model in 5.18s.
06:59:39
06:59:39 Completed successfully
06:59:39
06:59:39 Done. PASS=1 WARN=0 ERROR=0 SKIP=0 TOTAL=1
L’execution des tests va générer la sortie suivante (erreurs intentionnelles à but d’illustration)
07:03:28 Running with dbt=1.0.1
07:03:29 Found 6 models, 10 tests, 0 snapshots, 0 analyses, 166 macros, 0 operations, 0 seed files, 2 sources, 0 exposures, 0 metrics
07:03:29
07:03:34 Concurrency: 1 threads (target='dev')
07:03:34
07:03:34 1 of 4 START test accepted_values_customers_segment__AUTOMOBILE__BUILDING__FURNITURE__HOUSEHOLD__MACHINERY [RUN]
07:03:35 1 of 4 PASS accepted_values_customers_segment__AUTOMOBILE__BUILDING__FURNITURE__HOUSEHOLD__MACHINERY [PASS in 0.56s]
07:03:35 2 of 4 START test not_null_customers_custkey.................................... [RUN]
07:03:35 2 of 4 PASS not_null_customers_custkey.......................................... [PASS in 0.32s]
07:03:35 3 of 4 START test relationships_orders_custkey__custkey__ref_customers_......... [RUN]
07:03:41 3 of 4 PASS relationships_orders_custkey__custkey__ref_customers_............... [PASS in 6.28s]
07:03:41 4 of 4 START test unique_customers_custkey...................................... [RUN]
07:03:42 4 of 4 FAIL 150000 unique_customers_custkey..................................... [FAIL 150000 in 1.01s]
07:03:42
07:03:42 Finished running 4 tests in 13.76s.
07:03:42
07:03:42 Completed with 1 error and 0 warnings:
07:03:42
07:03:42 Failure in test unique_customers_custkey (models/base/customers.yml)
07:03:42 Got 150000 results, configured to fail if != 0
07:03:42
07:03:42 compiled SQL at target/compiled/sda_retail/models/base/customers.yml/unique_customers_custkey.sql
07:03:42
07:03:42 Done. PASS=3 WARN=0 ERROR=1 SKIP=0 TOTAL=4
Pour utiliser cette modélisation, on vouloir l’executer comme une Task.
Le prélable est de s’assurer que le modèle est bien commité sur le Repository en utilisant “Validate and Apply sur chacun des modèles
Depuis l’écran Transform, on peut lancer une execution globale du modèle avec le bouton “Run”. Ici nous allons utiliser la fonction “Build & Run” qui va avoir pour effet de construire un Artefact qui rendra notre modélisation réutilisable dans le futur.
Outre le nom du modèle, sa description, et l’engine cible sur lequel doit se faire cette execution, on va pouvoir saisir les paramètres additionnels d’execution DBT.
En appuyant sur “Build & Run” on lance le processus de création d’un Artefact.
Dans le module “Artefacts” on retrouvera notre modélisation DBT au même titre que nos deux chargements de données préalablement créés.
En ouvrant celui-ci on va pouvoir lancer son execution ou la programmer
DBT permet de Créer des modélisations avancées de base de données, mais apporte aussi une brique importante qu’est la documentation des données.
Pour accéder à la documentation
<aside> 📌 Il peut être nécessaire de générer la doc depuis l’écran “Transform” avec le bouton “Generate docs”. Cette action a pour effet de raffraichir intégralement la documentation
</aside>
Connexions Flows Tasks, Artefacts & Bundles Transformations SQL Navigateur de stockage Explorateur de données Exposition de services
Charger de la donnée Modéliser avec DBT Créer un artefact custom