Aller au contenu principal

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.

remarque

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

info

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, leading et all. Pour la syntaxe complète et les descriptions, consultez les valeurs range prises en charge. Pour plus de détails sur les modificateurs inclusive et exclusive sur trailing et leading, 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 BY de la query. Valeurs possibles : first et last.

Une mesure de fenêtre prend également en charge le champ facultatif suivant :

  • Décalage : Déplace le cadre de la fenêtre en arrière ou en avant le long du champ order par un intervalle fixe. Utilisez ceci pour les mesures d'une période à l'autre, telles que mensuelles ou annuelles. Pour la syntaxe, les unités prises en charge et les contraintes, voir mesures de fenêtre.

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 offset: k

current

[t, t]

[t + k, t + k]

cumulative

(-infinity, t]

(-infinity, t + k]

trailing N

[t - N, t)

[t + k - N, t + k)

leading N

(t, t + N]

(t + k, t + k + N]

all

partition entière

partition entière (inchangée)

plage

Cadre sans Offset

Image avec offset: k

current

[t, t]

[t + k, t + k]

cumulative

(-infinity, t]

(-infinity, t + k]

trailing N

[t - N, t)

[t + k - N, t + k)

leading N

(t, t + N]

(t + k, t + k + N]

all

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 ?

inclusive

n unités, y compris la ligne d'ancrage.

Oui

exclusive (default)

n unités sans inclure la ligne d’ancrage.

Non

Mot clé

Signification

Ancrer une ligne dans une plage ?

inclusive

n unités, y compris la ligne d'ancrage.

Oui

exclusive (default)

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

2025-01-02

1

2025-01-03

4

2025-01-04

2

2025-01-05 (ancre)

5

Date

Valeur

2025-01-02

1

2025-01-03

4

2025-01-04

2

2025-01-05 (ancre)

5

Chaque modificateur sélectionne trois jours de lignes par rapport à l'ancre et additionne leurs valeurs :

Modifier

Dates dans la fenêtre

Valeurs

Somme

trailing 3 day inclusive

01-03, 01-04, 01-05

4 + 2 + 5

11

trailing 3 day exclusive

01-02, 01-03, 01-04

1 + 4 + 2

7

Modifier

Dates dans la fenêtre

Valeurs

Somme

trailing 3 day inclusive

01-03, 01-04, 01-05

4 + 2 + 5

11

trailing 3 day exclusive

01-02, 01-03, 01-04

1 + 4 + 2

7

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.

YAML
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: date spécifie que le champ date ordonne la fenêtre.
  • range: trailing 7 day définit la fenêtre comme les 7 jours précédant chaque date, à l'exclusion de la date elle-même.
  • semiadditive: last retourne la dernière valeur de la fenêtre de 7 jours lorsque date n'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 $$ :

SQL
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.

YAML
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.

YAML
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_sales est la mesure de base, qui somme les ventes pour le mois en cours.
  • monthly_sales_py est la même mesure décalée de 12 mois vers l'arrière en utilisant offset: -12 month. Pour janvier 2025, elle renvoie la valeur de janvier 2024.
  • yoy_growth et yoy_growth_pct composent les deux mesures pour exprimer le changement absolu et en pourcentage. L'utilisation de NULLIF évite les erreurs de division par zéro lorsque la valeur de l'année précédente est zéro.

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.

YAML
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: date ordonne la fenêtre chronologiquement.
  • range: cumulative définit la fenêtre comme toutes les données depuis le début du dataset jusqu'à et y compris chaque date.
  • semiadditive: last renvoie la valeur cumulative la plus récente lorsque date n'est pas inclus dans la GROUP BY de 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.

YAML
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 date et une autre pour limiter la somme à l'année current.
  • Le champ year limite la somme cumulative de sorte qu'il se Reset au début de chaque nouvelle année.
  • Les champs month et year forment une hiérarchie de dates sur le champ d'ordre date: chacun est défini sur le champ date par son nom, et non sur la colonne o_orderdate sous-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é.

YAML
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: date ordonne la fenêtre chronologiquement.
  • range: current restreint la fenêtre à une seule journée sans agrégation sur plusieurs jours.
  • semiadditive: last retourne le solde le plus récent lors de l'agrégation sur plusieurs jours.
remarque

« 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:

SQL
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 :

YAML
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 :

SQL
SELECT month, MEASURE(ytd_sales) AS ytd_sales
FROM ytd_metric_view
GROUP BY month
ORDER BY month;
attention

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.

SUM(o_totalprice)

Composé

Une expression qui combine mathématiquement une ou plusieurs autres mesures à l'aide de la fonction MEASURE().

MEASURE(total_revenue) / MEASURE(order_count)

Type de mesure

Description

Exemple

Atomique

Agrégation simple et directe sur une colonne source. Ce sont les blocs de construction.

SUM(o_totalprice)

Composé

Une expression qui combine mathématiquement une ou plusieurs autres mesures à l'aide de la fonction MEASURE().

MEASURE(total_revenue) / MEASURE(order_count)

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.

YAML
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.

YAML
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é.

  1. 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.
  2. Utilisez MEASURE() pour les références : utilisez la fonction MEASURE() lorsque vous référencez une autre mesure dans un expr. Ne répétez pas la logique d'agrégation manuellement. Par exemple, évitez SUM(a) / COUNT(b) si des mesures existent déjà pour les deux valeurs.
  3. 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.
  4. 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.

Ressources supplémentaires