MetricFlow est le moteur de génération SQL derrière la couche sémantique dbt. Les métriques sont définies une fois en YAML et MetricFlow les traduit en SQL natif à l’entrepôt. La mise en place d’une couche sémantique fonctionnelle nécessite plusieurs composants, chacun documenté dans une note dédiée ci-dessous.
Séquence de configuration
Installation et configuration MetricFlow — Par où commencer. Les packages pip spécifiques aux adapteurs pour dbt Core, le chemin intégré de dbt Cloud, et les deux prérequis au niveau du projet (config de la timespine, manifeste sémantique) qui doivent être en place avant que quoi que ce soit d’autre fonctionne.
Timespine MetricFlow — Une table de dates continue contre laquelle MetricFlow effectue des jointures pour les métriques cumulatives et le remplissage des lacunes dans les séries temporelles. Requise pour toute métrique utilisant des fenêtres glissantes ou grain_to_date. Vaut la peine d’être configurée tôt même si ces métriques n’existent pas encore.
Composants du modèle sémantique MetricFlow — Les blocs de construction d’un modèle sémantique : entités (clés de jointure qui connectent les modèles), dimensions (colonnes sur lesquelles regrouper et filtrer) et mesures (agrégations qui alimentent les métriques). Un modèle sémantique par modèle mart. Tout le reste dans la couche sémantique dépend de leur bonne configuration.
Types de métriques MetricFlow — Les cinq types de métriques supportés par MetricFlow : simple, cumulative, dérivée, ratio et conversion. Chacun résout un problème spécifique. Les métriques ratio existent spécifiquement pour éviter l’erreur de somme-des-ratios que les métriques dérivées produisent silencieusement lors du regroupement par une dimension.
Requêtes MetricFlow via la CLI — Comment interroger les métriques depuis le terminal avec mf query (Core) ou dbt sl query (Cloud). La syntaxe Jinja de référence des dimensions pour les filtres, le contrôle de la granularité temporelle et la façon de valider les configs avant de requêter.
Organisation des métriques dans dbt — Où placer les fichiers YAML de modèles sémantiques et de métriques. Structure co-localisée pour les petits projets, structure de sous-dossiers parallèles pour les plus grands. La règle d’une entité primaire et pourquoi les modèles sémantiques doivent référencer les modèles mart plutôt que les intermédiaires.
Pour aller plus loin
Une fois les bases en place :
Patterns avancés MetricFlow — Comparaisons période-sur-période avec offset_window, métriques de segment filtrées utilisant la syntaxe Jinja Dimension(), et gestion des lacunes null dans la sortie des séries temporelles.
Métriques-as-code — La pratique élargie : pourquoi conserver les définitions de métriques dans un YAML versionné change le modèle de gouvernance, à quoi ressemble le flux de travail de revue PR pour les changements de métriques, et comment cela alimente les outils d’analytique pilotés par l’IA avec un vocabulaire gouverné.
Architecture de la couche sémantique — Contexte sur la place de MetricFlow dans le paysage aux côtés de Snowflake Semantic Views et Databricks Metric Views, et pourquoi la couche sémantique est le prérequis pour des requêtes générées par IA fiables.