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é.
Résoudre les tableaux et les cartes dans la source
Les champs, les mesures et les jointures fonctionnent tous sur des colonnes scalaires plates. Si vos données sources contiennent des colonnes de type ARRAY ou MAP, résolvez-les en colonnes plates dans la query source avant de les référencer ailleurs dans la vue des métriques. Il existe deux stratégies de Transformations, selon que vous souhaitez une ligne par élément de tableau ou une valeur unique par ligne source. Les deux s’appliquent que le tableau se trouve dans la source de niveau supérieur ou dans une table à laquelle vous effectuez une jointure. Consultez Transformer des types de données complexes pour obtenir l’ensemble complet des fonctions de transformation.
Aucun dataset du catalogue samples ne possède de colonne de type tableau ; les exemples de cette section utilisent donc une vue orders qui contient un tableau de structures line_items. Utilisez l’exemple suivant pour créer une vue avec un champ qui est un tableau. Remplacez catalog.schema par le catalogue et le schéma dans lesquels vous souhaitez écrire. Vous devez disposer des autorisations nécessaires pour créer des objets dans ce schéma.
CREATE OR REPLACE VIEW catalog.schema.orders AS
SELECT
o.o_orderkey,
o.o_custkey,
o.o_orderdate,
o.o_orderstatus,
collect_list(named_struct(
'product_id', l.l_partkey,
'quantity', cast(l.l_quantity as int)
)) AS line_items
FROM samples.tpch.orders o
JOIN samples.tpch.lineitem l ON o.o_orderkey = l.l_orderkey
GROUP BY o.o_orderkey, o.o_custkey, o.o_orderdate, o.o_orderstatus;
Aplatir un tableau en lignes
Pour analyser chaque élément de tableau comme une ligne distincte, utilisez explode() dans la query source afin de décompresser le tableau. Chaque élément devient une ligne distincte et les autres colonnes de la ligne source sont répétées pour chaque élément. Voir Exploser les éléments imbriqués d'une carte ou d'un tableau.
L'exemple suivant décompresse le tableau line_items afin que chaque élément devienne une ligne :
version: 1.1
source: |
SELECT o_orderkey, o_custkey, item.product_id, item.quantity
FROM catalog.schema.orders
LATERAL VIEW explode(line_items) AS item
fields:
- name: Product
expr: product_id
measures:
- name: Total quantity
expr: SUM(quantity)
- name: Line item count
expr: COUNT(1)
L’explosion du tableau dans source multiplie les lignes sources ; ainsi, une agrégation telle que COUNT(1) compte les éléments du tableau, et non les lignes d’origine. Pour mesurer également les lignes d’origine sans fan-out, modélisez plutôt la table éclatée sous forme de jointure one_to_many. Voir Jointures un-à-plusieurs.
Agréger un tableau en une valeur unique
Pour réduire un tableau à une valeur par ligne source sans modifier le nombre de lignes, appliquez une fonction de tableau scalaire dans la query source, telle que aggregate(), array_size() ou reduce(). Chaque ligne source conserve sa granularité, et la colonne compute est disponible pour les champs et les mesures.
L'exemple suivant compute le nombre d'éléments et la quantité totale du tableau line_items par commande :
version: 1.1
source: |
SELECT o_orderkey, o_custkey,
array_size(line_items) AS item_count,
aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
FROM catalog.schema.orders
measures:
- name: Total quantity
expr: SUM(total_quantity)
- name: Average items per order
expr: AVG(item_count)
Comme la query source réduit le tableau avant que la vue métrique ne le traite, la source conserve une ligne par commande et mesure l’agrégat sur les commandes comme d’habitude.
Résoudre un tableau dans une table jointe
La même règle s'applique lorsque le tableau se trouve dans une table que vous souhaitez joindre, et non dans la source de premier niveau. Une jointure s'opère sur des colonnes plates ; résolvez donc le tableau dans la sous-requête source de la table jointe avant la jointure. Écrivez la jointure source sous forme de query SQL qui aplatit ou agrège le tableau, puis effectuez la jointure sur les colonnes résultantes. Voir Jointures dans les vues métriques.
L'exemple suivant utilise customer comme source et joint la vue orders avec cardinality: one_to_many. La jointure source agrège le tableau line_items de chaque commande en une valeur scalaire total_quantity avant la jointure, afin que la vue des métriques puisse l'additionner par client sans dupliquer les lignes de clients :
version: 1.1
source: samples.tpch.customer
joins:
- name: orders
source: |
SELECT o_orderkey, o_custkey,
aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
FROM catalog.schema.orders
on: orders.o_custkey = source.c_custkey
cardinality: one_to_many
fields:
- name: Customer name
expr: c_name
measures:
- name: Total quantity
expr: SUM(orders.total_quantity)
- name: Order count
expr: COUNT(orders.o_orderkey)
Pour traiter plutôt chaque élément de tableau comme sa propre ligne dans la table jointe, aplatissez le tableau avec explode() dans la jointure source de la même manière. Voir Aplatir un tableau en lignes.
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 ARRAY ou MAP. Pour résoudre les tableaux ou les mappages en colonnes plates avant la jointure, consultez Résoudre les tableaux et les mappages dans la source.
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.