dbt-dremio 1.8 vs 1.9.0 & 1.10 : comprendre enfin où vos modèles sont réellement matérialisés

Introduction

Si vous utilisez dbt avec Dremio depuis quelque temps, vous avez peut-être eu une surprise en migrant vers dbt-dremio 1.9 ou 1.10 : vos modèles ne se matérialisent plus exactement là où vous le pensiez. Une configuration qui fonctionnait avant mais ne marche plus. Ou alors vous venez de démarrer mais vous ne comprenez pas exactement où se matérialisent vos modèles. Si ça vous parle, vous n’êtes pas seul.

Entre la version 1.8.1 et les versions récentes, le connecteur a changé la façon dont il résout les chemins de matérialisation. Résultat : vos tables ou vues peuvent être écrites au mauvais endroit, un chemin différent de ce que vous voudriez.

Dans cet article, on va expliquer ce qui a changé et surtout voir comment configurer proprement vos projets pour éviter les surprises. 

Sommaire

• La stack technique utilisée dans l’article
• Rappel 
• Comprendre sur un exemple
• En résumé les changements et les conseils

La stack technique utilisée dans l’article

La stack technique utilisée dans l’article a été installée en local avec le docker-compose proposé par Dremio University sauf pour dbt qui a été installé à part dans des environnements virtuels : 

• Dremio communautaire version 25 
• Minio pour le stockage
• Nessie pour le catalogue
• dbt-dremio version 1.8.1 (avec dbt-core 1.9.2), 1.9.0 (avec dbt-core 1.11.8) et 1.10.0 (avec dbt-core 1.11.7). Chacune des versions est installée dans un environnement python virtuel différent)

###########################################
# Notebook- Iceberg - Nessie Setup
###########################################

version: "3"

services:
  # Nessie Catalog Server Using In-Memory Store
  nessie:
    image: projectnessie/nessie:latest
    container_name: nessie
    networks:
      iceberg:
    ports:
      - 19120:19120
  # Minio Storage Server
  minio:
    image: minio/minio:latest
    container_name: minio
    environment:
      - MINIO_ROOT_USER=admin
      - MINIO_ROOT_PASSWORD=password
      - MINIO_DOMAIN=storage
      - MINIO_REGION_NAME=us-east-1
      - MINIO_REGION=us-east-1
    networks:
      iceberg:
    ports:
      - 9001:9001
      - 9000:9000
    command: ["server", "/data", "--console-address", ":9001"]
  # Dremio
  dremio:
    platform: linux/x86_64
    image: dremio/dremio-oss:25.0
    ports:
      - 9047:9047
      - 31010:31010
      - 32010:32010
    container_name: dremio
    environment:
      - DREMIO_JAVA_SERVER_EXTRA_OPTS=-Dpaths.dist=file:///opt/dremio/data/dist
    networks:
      iceberg:
networks:
  iceberg:

Rappel

Il faut savoir que lorsque vous utilisez Dremio, vos vues et vos tables sont stockées dans des endroits distincts si vous n’utilisez pas de catalogue : 

• les vues sont stockées dans un Space
• les tables sont stockées dans un Object Storage

En revanche, si vous utilisez un catalogue, vos vues et vos tables se matérialiseront dedans. Cela dépend de l’offre Dremio que vous choisissez d’utiliser. 

Dans cet article, nous allons rester sur la version opensource où les 2 choix sont possibles et peuvent être utilisés ensemble.

Vous pouvez retrouver la signification des mots clés de configuration pour les chemins où se matérialisent les modèles dans un autre article ou dans la documentation.

Comprendre sur un exemple

Pour mieux comprendre ce qui se passe, prenons le cas de Marcel qui a développé un petit projet dbt en étant en version 1.8.1 du connecteur dbt-dremio. Il a remarqué une amélioration de la synchronisation de la documentation dans les wikis de dremio dans la version 1.10.0 et il l’a testé. Mais en exécutant la commande dbt run il a eu des surprises. Ses modèles ne sont plus matérialisés au bon endroit ! Regardons son projet de plus près. 

Dans son fichier profiles.yml il a les paramètres de connexion suivants : 

projet_demo_profile:
  outputs:
    dev:
      dremio_space: default_space
      dremio_space_folder: default_folder
      object_storage_path: ref
      object_storage_source: minio
      password: xxxxx
      port: 9047
      software_host: localhost
      threads: 1
      type: dremio
      use_ssl: false
      user: xxxxx
  target: dev

Dans son projet dbt, il a l’arborescence suivante : 

.
├── analyses
├── macros
├── models
│   ├── domaine_analyse1
│   │   ├── 0_bronze
│   │   │   ├── br_vue1.sql
│   │   │   ├── br_vue2.sql
│   │   │   ├── br_vue3.sql
│   │   │   └── br_vue4.sql
│   │   ├── 1_silver
│   │   │   ├── slv_vue_a.sql
│   │   │   └── slv_vue_b.sql
│   │   ├── 2_gold
│   │   │   └── g_vue.sql
│   │   └── _config.yml
│   └── socle
│      ├── _config.yml
│      ├── _source.yml
│      ├── table1.sql
│      ├── table2.sql
│      ├── table3.sql
│      └── table4.sql
├── seeds
│   └── seed1.csv
├── snapshots
├── target
├── test
├── dbt_project.yml
└── README.md

Et le code de son fichier dbt_project.yml est le suivant pour la configuration des modèles et des seeds : 

name: 'projet_demo'
version: '1.0.0'

# This setting configures which "profile" dbt uses for this project.
profile: 'projet_demo_profile'

... # configurations par défaut

models:
  projet_demo:
    +twin_strategy: allow
    +persist_docs:
      relation: True
    
    domaine_analyse1: 
      +dremio_space: domaine_analyse1
      0_bronze:
        +dremio_space_folder: bronze
      1_silver:
        +dremio_space_folder: silver
      2_glod:
        +dremio_space_folder: gold
    socle:
      +materialized: table
      +object_storage_source: minio
      +object_storage_path: socle_consolide

seeds: 
  projet_demo:
    +twin_strategy: allow
    +object_storage_source: minio_bis
    +object_storage_path: referentiel

Le linéage du projet pour avoir une vue d’ensemble : 

Marcel a configuré son projet de tel sorte que les modèles de chaque couche se matérialisent dans des répertoires distincts. 

Lorsqu’il effectue la commande dbt seed && dbt run, les modèles sont matérialisés au bon endroit, c’est-à-dire comme suit : 

Maintenant Marcel a installé le connecteur dbt-dremio 1.10.0 pour tester l’amélioration de la documentation dans le wiki de Dremio. Mais il constate que les chemins sont différents lors de la commande dbt seed && dbt run : 

Et il constate que son arborescence est cassée côté Dremio, et qu’il doit faire du nettoyage. Il y trouve des doublons.

Il ne comprend pas pourquoi sa configuration ne marche plus. 

Pourquoi mon seed utilise l’object_storage_path du profiles.yml et pas celui du dbt_project.yml alors qu’il utilise le bon object_storage_source ? De même, pourquoi mes tables consolidées se matérialisent dans le mauvais l’object_storage_path ? 
Pourquoi toutes mes vues des couches  bronze, silver, gold s’enregistrent dans un répertoire parent default_folder ? C’est le répertoire défini dans le profiles.yml mais il aurait dû être écrasé par la configuration présente dans dbt_project.yml. Pourquoi maintenant il y a une concaténation ?

Répondons à ses questions. 

Au sein du projet dbt, le mot clé de configuration “object_storage_path” n’a plus d’effet c’est pour cela que la configuration par défaut est utilisée (celle définie dans le fichier profiles.yml). Désormais il faut utiliser le mot clé “schema”.

L’objet_storage_path et le dremio_space_folder ne sont plus seulement les répertoires par défaut où sont enregistrées les tables ou les vues. Ils deviennent aussi des répertoires parents. Quelle que soit la configuration que vous mettez dans le projet elle ne sera plus overwrite, elle sera préfixée par les chemins définis dans le fichier profiles.yml : <space ou object_sorage>.<chemin spécifié dans profiles.ml>.<chemin spécifié dans dbt_project.yml>.
Pour ne plus avoir ce comportement (ces répertoires parents) il suffit de décalrer no_schema comme valeur pour l’objet_storage_path et le dremio_space_folder  dans le fichier.profiles.yml. Et si vous souhaitez quand même avoir un répertoire par défaut vous pouvez le définir dans le projet (dbt_project.yml) à la racine du projet (au même niveau que la configuration twin_strategy par exemple). 

⚠️ Il y a une autre petite particularité sur le mot clé dremio_space_folder. Lisez la partie suivante pour ne rien manquer. Et faites des tests de votre côté pour vous approprier ces changements.  

Corrigons le projet de Marcel. Remplaçons les schémas du fichier profiles.yml par no_schema et remplaçons les mots clés dremio_space_folder et object_storage_path par schema dans le projet. 

# fichier profiles.yml

projet_demo_profile:
  outputs:
    dev:
      dremio_space: default_space
      dremio_space_folder: no_schema
      object_storage_path: no_schema
      object_storage_source: minio
      password: xxxxx
      port: 9047
      software_host: localhost
      threads: 1
      type: dremio
      use_ssl: false
      user: xxxxx
  target: dev

# fichier dbt_project.yml

name: 'projet_demo'
version: '1.0.0'

# This setting configures which "profile" dbt uses for this project.
profile: 'projet_demo_profile'

...

models:
  projet_demo:
    +twin_strategy: allow
    +persist_docs:
      relation: True
    
    domaine_analyse1: 
      +dremio_space: domaine_analyse1
      0_bronze:
        +schema: bronze
      1_silver:
        +schema: silver
      2_glod:
        +schema: gold
    socle:
      +materialized: table
      +object_storage_source: minio
      +schema: socle_consolide

seeds: 
  projet_demo:
    +twin_strategy: allow
    +object_storage_source: minio_bis
    +schema: referentiel

Les modèles se matérialisent maintenant là où Marcel le souhaite : 

En résumé, les changements et les conseils 

Les changements en résumé : 

• Les répertoires spécifiés dans le fichiers profiles.yml (dremio_space_folder ou object_storage_path) ne sont plus écrasés lorsqu’on en définit un autre dans le projet. Ils deviennent des répertoires parents. 
• Dans le projet le mot clé object_storage_path n’a plus d’effet il faut utiliser le mot clé schema pour spécifier un répertoire pour un object_storage_source. En revanche, pour spécifier un autre object storage il faut toujours utiliser le mot clé object_storage_source.
• ⚠️ Attention le mot clé dremio_space_folder fonctionne toujours mais il agit comme le mot clé schema. Il n’agit pas seulement pour les vues ! C’est-à-dire que si la configuration dremio_space_folder est posé au niveau d’un modèle qu’on souhaite matérialiser en table, la table sera matérialisée dans le répertoire dremio_space_folder. Par exemple supposons que l’on souhaite matérialiser un modèle models/model1.sql en table :   

Avec cette configuration, avant la table model1 aurait été matérialisé dans l’object storage : source_b.folder_b. Maintenant elle serait matérialisée dans l’object storage source_b.folder2 !  🙃

Tableau récapitulatif des mots clés à utiliser dans le projet : 

Recommandations : 

• mettre no_schema dans profiles.yml
• utiliser uniquement le mot clé schema dans les configurations du projet pour le choix des chemins (répertoires). Ne pas utiliser le mot clé dremio_space_folder même si celui-ci est fonctionnel. 

Conclusion

Dans cet article, nous avons vu les différences avec les nouvelles versions du connecteur dbt-dremio concernant le chemin où se matérialise vos modèles. N’hésitez pas à aller jeter un coup d’œil aux améliorations faites dans la version 1.10, notamment pour la synchronisation de la documentation. 😉

D’autres articles sur dbt : 

• Démarrer un projet dbt avec Dremio
• Dremio et les couches sémantiques avec dbt
• Webinaire : Découvrir dbt avec Dremio et Mage AI
• Orchestrer vos commandes dbt avec Mage AI
• dbt : les contrats sur les modèles avec PostgreSQL