REX The Fabulous : quand Omni révèle la puissance de dbt

florence8897
4 sept.
4 min de lecture

Dernière mise à jour : 5 sept.

Introduction

Chez Corail Analytics, nous accompagnons de plus en plus d’équipes data qui souhaitent tirer pleinement parti du duo dbt + Omni.

Dans ce billet, on revient sur l’intégration avancée mise en place par The Fabulous et sur les principaux écueils rencontrés, et surmontés, en chemin.

1. Contexte : une stack moderne en place, mais une couche BI limitée

The Fabulous utilisait auparavant Looker Studio, qui offrait peu de flexibilité :

Pas de couche sémantique.
Nécessité de tout modéliser en amont dans BigQuery sans possibilité de travailler sur des données de développement.
Peu de flexibilité pour des analyses dynamiques (cohortes, filtres temporels, etc.).

Avec Omni, leur objectif était de passer à une logique de self-service BI moderne, avec :

Une exploration flexible des données (notamment les cohortes).
Une exploitation facilitée des environnements de dev et de prod, directement depuis l’interface Omni, en permettant de basculer d’un environnement à l’autre en un clic.
Une couche sémantique solide appuyée sur la modélisation et la documentation dbt.
Tirer pleinement partie de la stratégie d'optimisation des coûts de leur data model dans leur outil de BI (notamment le partitionnement des tables).

2. Le vrai challenge : faire cohabiter Omni, dbt, et des vues dérivées complexes

Malgré une modélisation bien construite dans dbt, The Fabulous a rencontré un problème bloquant :

👉 Le problème : les vues dérivées dans Omni ne retrouvaient pas les tables

Exemple :

Environnement dev : table user_acquisition dans le dataset dbtDevUserAcquisition.
Environnement prod : même table, mais dans le dataset dbtUserAcquisition.
Omni, en suivant la logique standard de vues dérivées, ne parvenait pas à mapper correctement ces tables, car la couche dbt vient perturber le parcours classique de résolution.

Table dérivée : Kezako

Une vue dérivée dans Omni est une requête SQL enregistrée qui sert de base de données virtuelle dans l’outil.

Elle permet de préparer des données ou de faire des calculs complexes en amont de l’analyse, sans avoir à modifier les tables sources.

Concrètement : c’est comme créer une vue matérialisée ou une CTE (Common Table Expression) dans votre BI. Elle est définie via du SQL dans Omni et devient ensuite explorable comme une source classique (topics, dimensions, filtres, etc.).

Intérêt : Pour simplifier les analyses en masquant la complexité SQL aux utilisateurs. Pour réutiliser des calculs complexes ou des jointures dans plusieurs rapports. Pour nettoyer ou transformer les données avant de les exposer dans un dashboard.

Exemple : Vous avez une table brute avec des logs de navigation. Vous créez une vue dérivée qui : agrège les sessions par utilisateur et par jour et calcule la durée moyenne de session. Vous exposez ensuite cette vue dans un dashboard sans que les utilisateurs aient à connaître la requête.

3. La solution : fiabiliser la logique dev/prod et le mapping dans Omni

Environnement & Git :

Mise en place de l’environnement dbt avec Git par The Fabulous.
Coordination entre les environnements dev/prod dans Omni dans les cas les plus complexes par Corail Analytics x Omni.

Vues dérivées intelligentes :

Création de vues dérivées “dbt-aware”, tenant compte des datasets différenciés.
Rétablissement du mapping correct dans Omni entre les tables dbt et les entités visibles.

Partitionnement & performance :

Ajout d’un filtre dynamique dans les vues dérivées pour permettre à l’utilisateur de filtrer directement par date (et exploiter les partitions BigQuery).
Optimisation du chargement en filtrant sur la bonne partition dès la lecture.

4. Résultat : un self-service robuste et des insights accélérés

Grâce à cette intégration poussée :

Omni réagit de la même manière en dev et en prod, avec des vues dérivées cohérentes.
Fiabiliser les procédures de tests et de recettes par la BI avant de procéder à une mise en production afin de renforcer la confiance des utilisateurs métiers.

Et ainsi, The Fabulous peut tirer le plein parti des bénéfices d’Omni :

La modélisation initiale devient moins complexe, permettant aux développeurs d’offrir plus d’agilité aux utilisateurs BI tout en renforçant la cohérence du modèle dans le temps.
Les utilisateurs métiers peuvent explorer dynamiquement leurs données sans solliciter l’équipe data.

5. Omni : une vraie volonté de co-construire avec ses clients et partenaires

Ce projet a aussi permis à Omni d’enrichir sa documentation et de mieux cadrer certains cas complexes. Ainsi, The Fabulous bénéficie :

D’une stack moderne pleinement intégrée : dbt + Omni.
D’un double environnement BI isolé en toute circonstance pour sécuriser les déploiements.
D’une excellente optimisation de leurs coûts grâce à l’exploitation du partitionnement des tables.

En conclusion :

Avant	Après
Looker Studio + dbt, rigide	Omni + dbt, flexible
Pas de semantic layer	Semantic layer complète
Analyses figées et précalculées en amont	Analyses dynamiquement paramétrables par l'utilisateur
Manque d’autonomie	Self-service sécurisé