Techniques avancées pour les vues de métriques
Les techniques avancées pour les vues de métriques vous permettent d'exprimer une logique métier complexe et de réutiliser les définitions dans toute votre couche sémantique. Cette page explique deux techniques de ce type :
- Mesures de fenêtre : pour les calculs de séries chronologiques tels que les moyennes mobiles, les totaux cumulés et les variations d’une période à l’autre.
- Composabilité : pour construire des mesures complexes en référençant d'autres mesures plutôt qu'en réécrivant leur logique.
Cette page suppose une familiarité avec les concepts de base de la modélisation des vues métriques. Voir Vues des métriques du modèle.
Les exemples de cette page utilisent le dataset d'exemple TPC-H, qui modélise une chaîne d'approvisionnement en gros. Pour plus d'informations sur le dataset TPC-H, consultez tpch. Pour un tutoriel complet utilisant ce dataset avec des vues de métriques, consultez Tutoriel : créer une vue de métriques avec des jointures et une modélisation de données.
Mesures de la fenêtre
Expérimental
Cette fonctionnalité est expérimentale.
Les mesures de fenêtre vous permettent de définir des mesures avec des agrégations fenêtrées, cumulatives ou semi-additives dans vos vues métriques. Ils prennent en charge des calculs tels que les moyennes mobiles, les variations d'une période à l'autre et les totaux cumulés.
Vous pouvez ajouter une mesure de fenêtre dans l’éditeur de l’Explorateur de catalogues ou dans YAML.
Ajoutez une mesure de fenêtre dans l'éditeur.
Dans l'onglet UI de l'éditeur de vue métrique, cliquez sur + Window pendant que vous modifiez une mesure. + Window est disponible en mode Générateur et Personnalisé . Les options de fenêtre dans l'éditeur correspondent aux champs YAML décrits dans Définir une mesure de fenêtre.
Pour plus d'information sur la création et la modification de mesures, consultez Créer une vue métrique.
Définir une mesure de fenêtre
Une mesure de fenêtre comprend les champs obligatoires suivants :
-
ordre : Champ qui détermine l'ordre de la fenêtre.
-
range : définit l’étendue de la fenêtre. Les valeurs prises en charge incluent
current,cumulative,trailing,leadingetall. Une plagetrailingouleadingprend une unité de temps sur un champ de date ou de timestamporder, tel quetrailing 7 day, ou aucune unité sur une colonne entière consécutiveorder, telle quetrailing 3. Pour la syntaxe complète et les descriptions, consultez Valeursrangeprises en charge. Pour plus de détails sur les modificateursinclusiveetexclusivesurtrailingetleading, consultez Inclure ou exclure la ligne d’ancrage. -
semiadditive : Spécifie comment agréger la mesure lorsque le champ d'ordre n'est pas inclus dans le
GROUP BYde la query. Valeurs possibles :firstetlast.
Une mesure de fenêtre prend également en charge le champ facultatif suivant :
- Décalage : déplace le cadre de fenêtre vers l’arrière ou vers l’avant le long du champ
orderd’un montant fixe. Utilisez un décalage daté tel que-12 monthsur un champ de date ou de timestamporderpour des mesures période sur période telles que mois sur mois ou année sur année. Utilisez un décalage numérique sans unité tel que-1sur une colonne d’entiers consécutifsorderpour comparer sur une période commerciale qui n’est pas une date calendaire. Pour la syntaxe, les unités prises en charge et les contraintes, consultez Mesures de fenêtre.
Vous pouvez également référencer un parameter entier comme valeur du range ou du offset d’une mesure de fenêtre, afin qu’un appelant transmette la taille de la fenêtre au moment de la query. Voir Transmettre une taille de fenêtre en tant que parameter.
Comment offset déplace le cadre de la fenêtre
Voir Disponibilité des fonctionnalités d'affichage des métriques pour les exigences minimales en matière de compute et de version de la spécification YAML.
Le champ range définit la forme de la fenêtre par rapport à la ligne d'ancrage, et offset fait glisser ce cadre selon l'intervalle spécifié le long de order. Le tableau suivant affiche le cadre pour chaque valeur range avec et sans offset de k, par rapport à la ligne d'ancrage t:
plage | Cadre sans Offset | Image avec |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
| partition entière | partition entière (inchangée) |
offset est indépendant de semiadditive. Le choix first ou last contrôle toujours la façon dont la mesure se réduit lorsque order ne se trouve pas dans le GROUP BY de la query.
Pour de meilleurs résultats, faites correspondre offset au grain naturel de order. Pour les données mensuelles, offset: -12 month est préféré à offset: -365 day car l'arithmétique des mois et des années respecte les mois de longueur variable et les années bissextiles, tandis que l'arithmétique de day ne le fait pas.
Inclure ou exclure la ligne d'ancrage
Voir Disponibilité des fonctionnalités d'affichage des métriques pour les exigences minimales en matière de compute et de version de la spécification YAML.
Pour les plages trailing et leading, le mot-clé facultatif inclusive ou exclusive détermine si la valeur de fenêtre de la ligne d'ancrage (par exemple, aujourd'hui) fait partie de la fenêtre glissante :
Mot clé | Signification | Ancrer une ligne dans une plage ? |
|---|---|---|
| n unités, y compris la ligne d'ancrage. | Oui |
| n unités sans inclure la ligne d’ancrage. | Non |
L'exemple suivant montre comment inclusive et exclusive affectent la fenêtre glissante pour la date d'ancrage 2025-01-05 avec trailing 3 day.
Supposons que les données sous-jacentes contiennent une ligne par jour avec les valeurs suivantes :
Date | Valeur |
|---|---|
|
|
|
|
|
|
|
|
Chaque modificateur sélectionne trois jours de lignes par rapport à l'ancre et additionne leurs valeurs :
Modifier | Dates dans la fenêtre | Valeurs | Somme |
|---|---|---|---|
|
|
|
|
|
|
|
|
leading les plages suivent la même logique dans la direction opposée.
Exemple de mesure de fenêtre glissante, mobile ou en tête
L'exemple suivant calcule un décompte glissant de 7 jours des clients qui ont passé des commandes. Cette métrique suit les tendances d'engagement des clients au fil du temps en montrant le nombre de clients distincts qui ont effectué des achats au cours de la semaine précédant chaque date.
version: 1.1
source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'
fields:
- name: date
expr: o_orderdate
measures:
- name: t7d_customers
expr: COUNT(DISTINCT o_custkey)
window:
- order: date
range: trailing 7 day
semiadditive: last
Pour cet exemple, la configuration suivante s'applique :
order: datespécifie que le champdateordonne la fenêtre.range: trailing 7 daydéfinit la fenêtre comme les 7 jours précédant chaque date, à l'exclusion de la date elle-même.semiadditive: lastretourne la dernière valeur de la fenêtre de 7 jours lorsquedaten'est pas une colonne de regroupement.
Créez la vue métrique à l'aide de SQL.
Pour créer cette vue métrique en dehors de l'Explorateur de catalogues, enveloppez le YAML dans CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS et placez la définition entre les délimiteurs $$ :
CREATE OR REPLACE VIEW catalog.schema.rolling_customers WITH METRICS LANGUAGE YAML AS
$$
version: 1.1
source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'
fields:
- name: date
expr: o_orderdate
measures:
- name: t7d_customers
expr: COUNT(DISTINCT o_custkey)
window:
- order: date
range: trailing 7 day
semiadditive: last
$$
Les autres définitions complètes de cette page suivent le même modèle.
Exemple de mesure de fenêtre de période à période
L'exemple suivant calcule la croissance quotidienne des ventes en comparant le chiffre d'affaires d'aujourd'hui (somme de tous les prix de commande) au chiffre d'affaires d'hier. Cette métrique identifie les tendances de ventes quotidiennes et montre le pourcentage de changement dans les revenus.
version: 1.1
source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'
fields:
- name: date
expr: o_orderdate
measures:
- name: previous_day_sales
expr: SUM(o_totalprice)
window:
- order: date
range: trailing 1 day
semiadditive: last
- name: current_day_sales
expr: SUM(o_totalprice)
window:
- order: date
range: current
semiadditive: last
- name: day_over_day_growth
expr: (MEASURE(current_day_sales) - MEASURE(previous_day_sales)) / MEASURE(previous_day_sales) * 100
Pour cet exemple, la configuration suivante s'applique :
- L'exemple utilise deux mesures de fenêtre : l'une pour calculer le total des ventes du jour précédent et l'autre pour le jour actuel.
- Une troisième mesure calcule la variation en pourcentage (croissance) entre le jour actuel et les jours précédents.
Exemple d'utilisation d'une mesure de fenêtre annuelle offset
Le modificateur offset est l'élément constitutif des mesures d'une période à l'autre. Définissez une copie décalée d'une mesure de base, puis composez les deux pour exprimer directement les deltas, les ratios ou les taux de croissance dans la vue métrique.
L'exemple suivant calcule la croissance des Ventes en glissement annuel en comparant les Ventes de chaque mois au même mois de l'année précédente. La mesure décalée utilise offset: -12 month pour revenir 12 mois en arrière le long du champ month.
version: 1.1
source: main.default.monthly_sales
fields:
- name: month
expr: month
- name: category
expr: category
measures:
- name: monthly_sales
expr: SUM(sales)
window:
- order: month
range: current
semiadditive: last
- name: monthly_sales_py
expr: SUM(sales)
window:
- order: month
range: current
semiadditive: last
offset: -12 month
- name: yoy_growth
expr: MEASURE(monthly_sales) - MEASURE(monthly_sales_py)
- name: yoy_growth_pct
expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_py))
/ NULLIF(MEASURE(monthly_sales_py), 0)
Pour cet exemple, la configuration suivante s'applique :
monthly_salesest la mesure de base, qui somme les ventes pour le mois en cours.monthly_sales_pyest la même mesure décalée de 12 mois vers l'arrière en utilisantoffset: -12 month. Pour janvier 2025, elle renvoie la valeur de janvier 2024.yoy_growthetyoy_growth_pctcomposent les deux mesures pour exprimer le changement absolu et en pourcentage. L'utilisation deNULLIFévite les erreurs de division par zéro lorsque la valeur de l'année précédente est zéro.
Mesures de fenêtre sur une colonne d’index numérique
Nécessite Databricks Runtime 19 ou une version ultérieure et la spécification YAML version 1.1 ou une version ultérieure.
Un offset daté tel que -12 month progresse le long d'une colonne de date ou de timestamp. Une colonne de date ne convient plus lorsque votre axe de comparaison est une période commerciale qui n'est pas une date calendaire. Les semaines fiscales, les semaines ISO et les périodes comptables 4-4-5 en sont des exemples. Au lieu de cela, ordonnez une mesure de fenêtre sur une colonne d'index entière et appliquez une valeur numérique offset ou range sans unité. Un décalage numérique effectue une arithmétique entière sur l'index, donc offset: -1 signifie la position précédente dans la séquence, et range: trailing 3 signifie les trois dernières positions.
Un décalage ou une plage numérique ne renvoie le résultat correct que lorsque la colonne order répond à toutes les exigences suivantes. Seule la première exigence est validée au moment de la query. Une colonne qui rompt l’une des deux autres renvoie des nombres erronés plutôt qu’une erreur ; vérifiez-les donc vous-même :
- Intégrale : la colonne est de type
TINYINT,SMALLINT,INTouBIGINT. Les colonnesDATE,TIMESTAMP,DECIMAL,DOUBLEetSTRINGne sont pas des colonnes d’index valides. Pour effectuer une comparaison par date, utilisez plutôt unoffsetdaté. Découvrez commentoffsetdéplace le cadre de fenêtre. - Monotone et consécutif (dense) : la valeur augmente exactement de 1 d’une période réelle à la suivante, y compris au-delà de la limite de l’année ou du trimestre. Un écart ou une valeur répétée entraîne l’omission ou le comptage en double d’une période par
offset: -1. Une étiquette brute, telle qu’unfiscal_weekqui revient à 1 chaque année, n’est pas un index valide en soi. - Correspondance avec le grain de comparaison : les étapes de décalage ou de plage dans le grain de l'index. Sur un index mensuel,
offset: -1correspond au mois précédent etrange: trailing 3aux trois derniers mois. Pour une comparaison plus large, telle qu'une comparaison d'une année sur l'autre, commandez une mesure distincte sur un index annuel ou utilisez une mesure de même position dans un cycle précédent. Ne réutilisez pas un index plus fin (mois) pour effectuer un regroupement ascendant. Consultez Même position dans un cycle précédent (deux spécifications de fenêtre, aucun index).
Obtenir une colonne d’index
Vous pouvez nommer une colonne d’index pré-calculée à partir de la source, ou en dériver une dans la vue métrique. La recette dépend de la forme du calendrier :
Forme de calendrier | Indexation de recette |
|---|---|
Périodes uniformes par parent (12 mois par an, 4 trimestres par an) |
|
Périodes variables par parent (ISO 52 ou 53 semaines, 4-4-5 au grain de la semaine) | Utilisez une table de recherche de calendrier qui mappe |
Clé de chaîne ( | Analysez d’abord la chaîne en entiers, puis appliquez l’une des méthodes ci-dessus. |
Alignez les dimensions dont dépend l'index
Donnez une spécification d’ordre range: all à chaque champ de vue métrique à partir duquel l’index est calculé, tel que order_year et order_month pour month_index = order_year * 12 + order_month. Cela s’applique que l’index soit dérivé dans la vue métrique ou précalculé en amont sous forme de colonne brute. La spécification range: all fait en sorte que ces champs soient ignorés lors de la construction de la fenêtre, comme prévu, lorsqu’une query les regroupe ou les filtre.
Ces spécifications ne sont pas facultatives. Sans eux, une query qui regroupe sur order_year ou order_month partitionne la fenêtre par ces champs, ce qui limite le cadre décalé à une seule période, et la mesure de comparaison renvoie NULL.
Tous les autres champs ne reçoivent aucune spécification range: all. Un champ indépendant de l'index, tel que region, se regroupe normalement et la fenêtre se partitionne par valeur.
Comparaison consécutive ou fenêtre glissante (index plus plage numérique)
Utilisez un index avec un décalage numérique ou une plage lorsque vous entendez « adjacent dans la séquence », comme pour la période précédente, une période glissante de N périodes ou la période en cours. Triez sur l’index, appliquez un décalage numérique ou une plage, et ajoutez une spécification range: all pour chaque colonne de calendrier dont dépend l’index. Dans l’exemple suivant, l’index dépend de order_year et order_month:
version: 1.1
source: samples.tpch.orders
fields:
- name: order_year
expr: YEAR(o_orderdate) # INT breakdown column
- name: order_month
expr: MONTH(o_orderdate) # INT breakdown column
- name: month_index # consecutive monotonic index across years
expr: order_year * 12 + order_month
measures:
- name: monthly_sales
expr: SUM(o_totalprice)
window:
- order: order_year # breakdown, so range: all keeps GROUP BY order_year working
range: all
semiadditive: last
- order: order_month # breakdown
range: all
semiadditive: last
- order: month_index # the axis you compare along
range: current
semiadditive: last
- name: monthly_sales_prev # previous month: same specs plus a unitless offset of -1 on the index
expr: SUM(o_totalprice)
window:
- order: order_year
range: all
semiadditive: last
- order: order_month
range: all
semiadditive: last
- order: month_index
range: current
offset: -1 # one position back, crosses the year boundary correctly
semiadditive: last
- name: sales_trailing_3mo # rolling 3 months: unitless range on the index
expr: SUM(o_totalprice)
window:
- order: order_year
range: all
semiadditive: last
- order: order_month
range: all
semiadditive: last
- order: month_index
range: trailing 3 # the three index positions before the current month
semiadditive: last
- name: mom_pct_change
expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_prev))
/ NULLIF(MEASURE(monthly_sales_prev), 0) * 100
Pour cet exemple, la configuration suivante s'applique :
month_indexest un index monotone consécutif qui augmente de 1 chaque mois au-delà des limites de l'année.monthly_salesordonne sur l’index avecrange: currentet donne aux colonnes de répartitionorder_yearetorder_monthune spécificationrange: allafin que le regroupement par celles-ci fonctionne.monthly_sales_prevajouteoffset: -1sur l’index pour revenir un mois en arrière, ce qui franchit correctement la limite de l’année.sales_trailing_3moutilise la plage sans unitétrailing 3pour sommer trois positions d’index. Comme l’index est consécutif, trois positions correspondent toujours à trois mois, sans calcul d’unité de temps. La plage est définie sur defaultexclusive, elle couvre donc les trois mois précédant le mois en cours. Ajoutezinclusivepour inclure le mois en cours à la place.mom_pct_changecompose les mesures de base et décalées. L’utilisation deNULLIFpermet d’éviter les erreurs de division par zéro lorsque la valeur précédente est égale à zéro.
Interrogez la mesure en effectuant un regroupement sur les colonnes de répartition alignées, et non sur l'index brut :
SELECT
order_year,
order_month,
MEASURE(monthly_sales),
MEASURE(monthly_sales_prev),
MEASURE(sales_trailing_3mo),
MEASURE(mom_pct_change)
FROM catalog.schema.monthly_sales_mv
GROUP BY ALL
Même position dans un cycle précédent (deux spécifications de fenêtre, aucun index)
Une comparaison telle que « le même mois l’année dernière » est alignée par position, et non par distance absolue ; elle ne nécessite donc aucune colonne d’index. Utilisez deux spécifications de fenêtre : l’une décale le cycle parent et l’autre maintient la position interne.
version: 1.1
source: samples.tpch.orders
fields:
- name: order_year
expr: YEAR(o_orderdate)
- name: order_month
expr: MONTH(o_orderdate)
measures:
- name: monthly_sales
expr: SUM(o_totalprice)
- name: monthly_sales_py # same month, prior year
expr: SUM(o_totalprice)
window:
- order: order_year # shift the year coordinate
range: current
offset: -1
semiadditive: last
- order: order_month # hold the month fixed
range: current
semiadditive: last
- name: yoy_pct_change
expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_py))
/ NULLIF(MEASURE(monthly_sales_py), 0) * 100
Pour cet exemple, la configuration suivante s'applique :
monthly_sales_pyutilise deux spécifications de fenêtre. La spécificationorder_yeardécale la coordonnée de l’année d’une unité avecoffset: -1, et la spécificationorder_monthmaintient le mois fixe avecrange: current.- La comparaison s'aligne par position, elle ne nécessite donc aucune colonne d'index.
yoy_pct_changecompose les deux mesures pour exprimer la variation en pourcentage.
Exemple de mesure du total cumulé (en cours)
L'exemple suivant calcule le revenu cumulé des ventes depuis le début du dataset jusqu'à chaque date. Ce total cumulé indique combien de revenus totaux ont été générés au fil du temps, utile pour suivre les progrès par rapport aux objectifs de revenus annuels ou pour analyser les modèles de croissance à long terme.
version: 1.1
source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'
fields:
- name: date
expr: o_orderdate
- name: customer
expr: o_custkey
measures:
- name: running_total_sales
expr: SUM(o_totalprice)
window:
- order: date
range: cumulative
semiadditive: last
Pour cet exemple, la configuration suivante s'applique :
order: dateordonne la fenêtre chronologiquement.range: cumulativedéfinit la fenêtre comme toutes les données depuis le début du dataset jusqu'à et y compris chaque date.semiadditive: lastrenvoie la valeur cumulative la plus récente lorsquedaten'est pas inclus dans laGROUP BYde la query, plutôt que de faire la somme de toutes les dates.
Exemple de mesure cumulée de la période
L'exemple suivant calcule le revenu des ventes cumulé depuis le début de l'année (YTD). Cette mesure indique le revenu cumulé généré du 1er janvier de chaque année jusqu'à la date actuelle, avec un Reset au début de chaque nouvelle année.
version: 1.1
source: samples.tpch.orders
filter: o_orderdate > DATE'1997-01-01'
fields:
- name: date
expr: o_orderdate
- name: month
expr: DATE_TRUNC('MONTH', date)
- name: year
expr: DATE_TRUNC('year', date)
measures:
- name: ytd_sales
expr: SUM(o_totalprice)
window:
- order: date
range: cumulative
semiadditive: last
- order: year
range: current
semiadditive: last
Pour cet exemple, la configuration suivante s'applique :
- L'exemple utilise deux spécifications de fenêtre : une pour la somme cumulative sur le champ
dateet une autre pour limiter la somme à l'annéecurrent. - Le champ
yearlimite la somme cumulative de sorte qu'il se Reset au début de chaque nouvelle année. - Les champs
monthetyearforment une hiérarchie de dates sur le champ d'ordredate: chacun est défini sur le champdatepar son nom, et non sur la colonneo_orderdatesous-jacente, afin que les queries puissent regrouper cette mesure par eux. Voir Grouper par un champ de hiérarchie de dates.
Exemple de mesure semi-additive
L'exemple suivant calcule les soldes des comptes, qui ne doivent pas être additionnés sur plusieurs dates (vous ne pouvez pas ajouter le solde de lundi au solde de mardi pour obtenir le solde total). Au lieu de cela, lors de l'agrégation sur plusieurs jours, la mesure renvoie le solde le plus récent. Cependant, la mesure peut toujours être additionnée pour tous les clients afin de montrer le solde total sur l'ensemble des comptes un jour donné.
version: 1.1
fields:
- name: date
expr: date
- name: customer
expr: customer_id
measures:
- name: semiadditive_balance
expr: SUM(balance)
window:
- order: date
range: current
semiadditive: last
Pour cet exemple, la configuration suivante s'applique :
order: dateordonne la fenêtre chronologiquement.range: currentrestreint la fenêtre à une seule journée sans agrégation sur plusieurs jours.semiadditive: lastretourne le solde le plus récent lors de l'agrégation sur plusieurs jours.
« Cette mesure de fenêtre somme toujours tous les clients pour obtenir le solde global par jour. »
Requête d'une mesure de fenêtre
Vous pouvez interroger une vue métrique avec une mesure de fenêtre comme n'importe quelle autre vue métrique. Une mesure de fenêtre est calculée le long de son champ order, donc une query qui décompose les résultats dans le temps doit faire référence à ce champ, soit directement, soit par l'intermédiaire d'un champ de hiérarchie de dates défini sur celui-ci. Lorsque la query ne fait pas référence au champ d'ordre, le mot-clé semiadditive détermine la valeur renvoyée, comme décrit dans l'exemple de mesure semi-additive.
L'exemple suivant regroupe une mesure de fenêtre par state et par une expression de mois sur le champ d'ordre date:
SELECT
state,
DATE_TRUNC('month', date),
MEASURE(t7d_customers) as m
FROM my_metric_view
WHERE date >= DATE'2024-06-01'
GROUP BY ALL
Grouper par un champ de hiérarchie de date
Une hiérarchie de dates agrège le champ de commande à des niveaux plus grossiers, tels que la semaine, le mois ou l'année. Définissez chaque niveau comme un champ sur le champ d'ordre par nom, non pas sur la colonne source sous-jacente :
fields:
- name: date
expr: o_orderdate
# Date hierarchy: each level is defined on the order field `date`,
# not on the underlying o_orderdate column.
- name: month
expr: DATE_TRUNC('MONTH', date)
- name: year
expr: DATE_TRUNC('year', date)
Le regroupement d'une mesure de fenêtre par niveau hiérarchique renvoie la mesure à ce niveau de granularité. En supposant que l'exemple de période à ce jour soit créé comme ytd_metric_view comme dans l'exemple de mesure de période à ce jour, la query suivante renvoie la valeur YTD à la dernière date de chaque mois :
SELECT month, MEASURE(ytd_sales) AS ytd_sales
FROM ytd_metric_view
GROUP BY month
ORDER BY month;
Définir un niveau de hiérarchie sur la colonne source sous-jacente, telle que DATE_TRUNC('MONTH', o_orderdate), rompt son Link avec le champ d'ordre date, même si les expressions semblent équivalentes. Le regroupement d'une mesure de fenêtre par un tel champ renvoie des résultats incorrects.
Composabilité
Les vues métriques sont composables. Vous pouvez créer de nouveaux champs et mesures qui référencent ceux existants plutôt que de réécrire la logique à partir de zéro. Cela réduit la duplication et facilite la maintenance des définitions de métriques complexes.
La composabilité fonctionne à deux niveaux : au sein d'une seule vue métrique, et entre les vues métriques lorsqu'une vue métrique est utilisée comme source pour une autre.
La composabilité prend en charge les modèles de référence suivants :
- Champs précédents dans de nouveaux champs.
- Champs et mesures antérieures dans les nouvelles mesures.
- Champs issus des vues métriques utilisés comme source dans de nouveaux champs.
- Champs et mesures des vues de métriques utilisés comme source dans les nouvelles mesures.
Définir des mesures avec composabilité
Dans la section measures, vous pouvez référencer des mesures de la vue métrique source ou des mesures définies précédemment dans la même vue métrique. Cette approche améliore la cohérence, l'auditabilité et la maintenance de votre couche sémantique.
Type de mesure | Description | Exemple |
|---|---|---|
Atomique | Agrégation simple et directe sur une colonne source. Ce sont les blocs de construction. |
|
Composé | Une expression qui combine mathématiquement une ou plusieurs autres mesures à l'aide de la fonction |
|
Exemple : valeur moyenne des commandes (AOV)
L'exemple suivant définit la Valeur Moyenne de Commande (VMC) à l'aide de deux mesures atomiques : total_revenue (somme des prix des commandes) et order_count (nombre de commandes). La mesure avg_order_value fait référence aux deux mesures atomiques.
version: 1.1
source: samples.tpch.orders
measures:
# Total Revenue
- name: total_revenue
expr: SUM(o_totalprice)
# Order Count
- name: order_count
expr: COUNT(1)
# Composed Measure: Average Order Value (AOV)
- name: avg_order_value
# Defines AOV as Total Revenue divided by Order Count
expr: MEASURE(total_revenue) / MEASURE(order_count)
Si la définition de total_revenue change (par exemple, pour exclure les taxes), avg_order_value utilise automatiquement la définition mise à jour.
Composabilité avec une logique conditionnelle
Vous pouvez utiliser la composabilité pour créer des ratios complexes, des pourcentages conditionnels et des taux de croissance sans dépendre des fonctions de fenêtre pour de simples calculs d'une période à l'autre.
Exemple : Taux de réalisation
L'exemple suivant calcule le taux de réalisation : le pourcentage de commandes avec le statut 'F' (réalisées). La mesure divise les commandes réalisées par le total des commandes.
version: 1.1
source: samples.tpch.orders
measures:
# Total Orders (denominator)
- name: total_orders
expr: COUNT(1)
# Fulfilled Orders (numerator)
- name: fulfilled_orders
expr: COUNT(1) FILTER (WHERE o_orderstatus = 'F')
# Composed Measure: Fulfillment Rate (Ratio)
- name: fulfillment_rate
expr: MEASURE(fulfilled_orders) / MEASURE(total_orders)
format:
type: percentage
Bonnes pratiques pour la composabilité.
- Définissez d'abord des mesures atomiques : Établissez des mesures fondamentales (
SUM,COUNT,AVG) avant de définir des mesures qui y font référence. - Utilisez
MEASURE()pour les références : utilisez la fonctionMEASURE()lorsque vous référencez une autre mesure dans unexpr. Ne répétez pas la logique d'agrégation manuellement. Par exemple, évitezSUM(a) / COUNT(b)si des mesures existent déjà pour les deux valeurs. - Privilégiez la lisibilité : composez des mesures à l'aide de formules mathématiques claires. Par exemple,
MEASURE(gross_profit) / MEASURE(total_revenue)est plus clair qu'une seule expression SQL complexe. - Ajouter des métadonnées sémantiques : utilisez des métadonnées sémantiques pour formater les mesures composées (par exemple, pourcentages ou devises) pour les outils en aval. Consultez les métadonnées d'agent dans les vues de métriques.