Vues des métriques du modèle
Les vues de métriques créent une couche sémantique pour vos données, transformant les tables et les vues en métriques commerciales standardisées. Ils définissent ce qu’il faut mesurer, comment l’agréger et comment le segmenter. En conséquence, chaque utilisateur de l’organisation rapporte la même valeur pour le même KPI, ce qui élimine les rapports incohérents et permet une analyse flexible sur n’importe quel champ.
Les composants essentiels que vous définissez sont les sources, les jointures, les filtres, les champs et les mesures.
Pour un exemple complet avec des jointures, des champs, des mesures et des métadonnées d'agent, consultez Tutoriel : créer une vue métrique avec des jointures et la modélisation des données.
Composants principaux
Une vue métrique se compose des éléments suivants :
Composant | Description | Exemple |
|---|---|---|
Source | La table de base, la vue ou la query SQL contenant les données. |
|
Jointures | Relations entre les tables, les vues et les vues de métriques pour enrichir des données. | Joindre la table |
Filtres | Conditions appliquées aux données source pour définir la portée. |
|
Champs | Colonnes utilisées pour regrouper, filtrer et agréger des métriques. Comprend des colonnes catégorielles et des colonnes numériques non agrégées. Également appelées dimensions. | Catégorie de produit, Mois de commande, Prix unitaire |
Mesures | Agrégations de colonnes qui produisent des métriques. |
|
Définir une source
Vous pouvez utiliser un asset de type table ou une query SQL comme source pour votre vue métrique. Vous devez disposer d'au moins SELECT privilèges sur tout asset référencé.
Un asset de type tableau est tout objet Unity Catalog qui expose un schéma tabulaire et prend en charge les SELECT queries, y compris les tables, les vues, les vues matérialisées, les tables de streaming, les tables étrangères, les tables système et les vues métriques.
Utilisez un asset de type table comme source
Pour utiliser un asset de type table comme source, spécifiez le nom pleinement qualifié. Par exemple : samples.tpch.orders.
Utilisez une vue métrique comme source
Vous pouvez utiliser une vue métrique existante comme source pour une nouvelle vue métrique :
version: 1.1
source: views.examples.source_metric_view
fields:
- name: Order month
expr: '`Order Month`'
measures:
- name: Latest order month
expr: MAX(`Order month`)
- name: Latest order year
expr: "DATE_TRUNC('year', MEASURE(`Latest order month`))"
Lors de l'utilisation d'une vue de métriques comme source, les mêmes règles de modularité s'appliquent pour le référencement des champs et des mesures. Voir la modularité.
Utilisez une query SQL comme source
Pour utiliser une requête SQL, écrivez le texte de la query directement dans le YAML :
version: 1.1
source: SELECT * FROM samples.tpch.orders o LEFT JOIN samples.tpch.customer c ON o.o_custkey
= c.c_custkey
fields:
- name: Order key
expr: o_orderkey
measures:
- name: Order Count
expr: COUNT(o_orderkey)
Lorsque vous utilisez une query SQL comme source avec une clause JOIN, définissez des contraintes de clé primaire et de clé étrangère sur les tables sous-jacentes et utilisez l'option RELY pour des performances de query optimales. Consultez Déclarer les contraintes de clé primaire, de clé étrangère et d'unicité et l'optimisation des requêtes à l'aide des contraintes de clé primaire et d'unicité.
Champs
Les champs, également appelés dimensions, sont des colonnes de vue métrique que vous pouvez utiliser dans les clauses SELECT, WHERE et GROUP BY > au moment de la query. Un champ peut être une colonne catégorielle, telle que la région ou le statut, ou une colonne numérique non agrégée, telle que le prix ou la quantité, que vous pouvez agréger au moment de la query. Chaque expression de champ doit renvoyer une valeur scalaire. Il peut faire référence à des colonnes provenant des données source ou à des champs définis précédemment dans la vue métrique. Chaque champ se compose de deux composants :
name: L'alias de la colonneexpr: Une expression SQL qui référence les données sources ou les champs précédemment définis dans la vue de métrique.
Les champs de vue métrique de type chaîne sont toujours STRING, même lorsque la colonne source est CHAR ou VARCHAR. Étant donné que le remplissage d'espaces CHAR(n) est perdu, les comparaisons peuvent renvoyer des résultats différents. Par exemple, column = 'COLLEGE' correspond à une valeur CHAR(10) dans la table source (qui est complétée par des espaces) mais pas dans le champ d'affichage métrique.
Mesures
Les mesures sont des expressions qui produisent des résultats sans niveau d'agrégation prédéterminé. Elles doivent être exprimées à l'aide de fonctions agrégées. Pour référencer une mesure dans une query, utilisez la fonction MEASURE. Les mesures peuvent faire référence à des colonnes de base dans les données source, à des champs définis précédemment ou à des mesures définies précédemment. Chaque mesure se compose des composants suivants :
name: l'alias de la mesureexpr: une expression SQL agrégée pouvant inclure des fonctions d'agrégation SQL
L’exemple suivant illustre les modèles de mesure courants pour l’analyse des données de commande et de revenus. Ces exemples utilisent la table de commandes TPC-H, qui contient des données de transaction de ventes, y compris les prix des commandes (o_totalprice), les identifiants clients (o_custkey), les clés de commande (o_orderkey), les dates de commande (o_orderdate) et les niveaux de priorité (o_orderpriority) :
measures:
# Simple count measure
- name: Order Count
expr: COUNT(1)
# Sum aggregation measure
- name: Total Revenue
expr: SUM(o_totalprice)
# Distinct count measure
- name: Unique Customers
expr: COUNT(DISTINCT o_custkey)
# Calculated measure combining multiple aggregations
- name: Average Order Value
expr: SUM(o_totalprice) / COUNT(DISTINCT o_orderkey)
# Filtered measure with WHERE condition
- name: High Priority Order Revenue
expr: SUM(o_totalprice) FILTER (WHERE o_orderpriority = '1-URGENT')
# Measure using a field
- name: Average Revenue per Month
expr: SUM(o_totalprice) / COUNT(DISTINCT DATE_TRUNC('MONTH', o_orderdate))
Consultez les fonctions d'agrégation pour obtenir une liste des fonctions d'agrégation.
Appliquer des filtres
Un filtre s'applique à toutes les queries qui référencent la vue métrique. Pour définir un filtre dans l'interface utilisateur, consultez l'étape 3 : définir un filtre.
Pour définir un filtre dans la définition YAML, écrivez une expression booléenne. L'exemple suivant montre des modèles de filtre courants :
# Single condition
filter: o_orderdate > '2024-01-01'
# Multiple conditions
filter: o_orderdate > '2024-01-01' AND o_orderstatus = 'F'
# IN clause
filter: o_orderstatus IN ('F', 'P') AND o_orderdate >= '2024-01-01'
Travailler avec les jointures
Les vues de métriques prennent en charge les jointures pour enrichir vos données sources avec des attributs provenant de tables associées. Vous pouvez modéliser des schémas en étoile (table de faits jointe aux tables de dimensions), des schémas en flocon de neige (jointures de dimensions à plusieurs niveaux) et des relations un à plusieurs (expansion des faits à partir d'une source dimensionnelle). Pour plus de détails sur les types de jointure, la cardinalité, les modèles de schémas et les restrictions, consultez Jointures dans les vues de métriques.
Pour définir les jointures dans l'interface utilisateur, consultez Étape 2 : Ajouter une jointure. Pour définir les jointures dans la définition YAML, utilisez les modèles des sections suivantes.
Les tables jointes ne peuvent pas inclure de colonnes de type MAP. Pour décompresser les valeurs des colonnes de type MAP, consultez Exploser les éléments imbriqués d'une carte ou d'un tableau.
Modéliser les schémas en étoile.
Dans un schéma en étoile, le source est la table de faits et s'associe à une ou plusieurs tables de dimensions à l'aide d'un LEFT OUTER JOIN. Les vues de métriques joignent les tables de faits et de dimensions nécessaires pour la query spécifique, en fonction des champs et des mesures sélectionnés.
Spécifiez les colonnes de jointure à l'aide d'une clause on (expression booléenne) ou d'une clause using (noms de colonnes partagés). La jointure doit suivre une relation plusieurs-à-un. En cas de relations plusieurs-à-plusieurs, le moteur sélectionne la première ligne correspondante de la table de dimension jointe.
L’exemple suivant joint orders (table de faits) à customer (table de dimensions) et expose les attributs des clients en tant que champs. Le paramètre rely.at_most_one_match: true déclare que la jointure est plusieurs-à-un (chaque commande a exactement un client), ce qui permet au moteur d’optimiser les queries qui filtrent les champs de la table jointe.
Définissez at_most_one_match: true uniquement lorsque la relation est plusieurs-à-un. Cette propriété n'est pas validée au moment de l'exécution. Si la jointure produit un débordement, les mesures renvoient des résultats incorrects.
Consultez Optimiser les jointures avec rely.
version: 1.1
source: samples.tpch.orders
joins:
- name: customer
source: samples.tpch.customer
on: source.o_custkey = customer.c_custkey
fields:
- name: Customer name
expr: customer.c_name
measures:
- name: Total revenue
expr: SUM(o_totalprice)
Syntaxe et formatage YAML
Les définitions de la vue de métrique suivent la syntaxe de notation YAML standard. Consultez la référence de la syntaxe YAML de la vue de métrique pour connaître la syntaxe et le formatage requis.
Bonnes pratiques
Utilisez les directives suivantes lors de la modélisation des vues de métriques :
- Mesures atomiques du modèle : start par définir d’abord les mesures les plus simples (par exemple,
SUM(revenue),COUNT(DISTINCT customer_id)). Créez des mesures complexes en utilisant la composabilité. - **Standardisez les valeurs de champ :** Utilisez des Transformations (tels que des
CASEinstructions) pour convertir les codes de base de données en noms commerciaux clairs (par exemple, convertissez le statut de commande 'O' en 'Ouvert' et 'F' en 'Exécuté'). - Définissez la portée avec des filtres : Si une vue d'indicateur ne doit inclure que les commandes terminées, définissez ce filtre dans la vue d'indicateur afin que les utilisateurs n'incluent pas accidentellement de données incomplètes.
- Utiliser une nomenclature claire : Les noms des métriques doivent être reconnaissables par les utilisateurs métier (par exemple, « Valeur vie client » au lieu de
cltv_agg_measure). - Séparez les champs temporels : incluez des champs temporels granulaires (tels que « Date de commande ») et des champs temporels tronqués (tels que « Mois de commande » ou « Semaine de commande ») pour permettre une analyse détaillée et une analyse des tendances.