Vues de métriques de modèle

Les vues de métriques créent une couche sémantique pour vos données, transformant des tables et des vues en métriques métier standardisées. Ils définissent ce qu’il faut mesurer, comment l’agréger et comment le segmenter. Par conséquent, chaque utilisateur de l’organisation signale la même valeur pour le même indicateur de performance clé, ce qui élimine les rapports incohérents et permet une analyse flexible sur tous les champs.

Les principaux composants que vous définissez sont des sources, des jointures, des filtres, des champs et des mesures.

Pour obtenir un exemple complet avec des jointures, des champs, des mesures et des métadonnées d’agent, consultez tutoriel : créer une vue de métrique avec des jointures et la modélisation des données.

Composants de base

Une vue de métrique se compose des éléments suivants :

Composant	Description	Example
Source	Table de base, vue ou requête SQL contenant les données.	samples.tpch.orders
Jointures	Relations entre les tables, les vues et les vues de métriques pour enrichir les données.	Joindre orders une table avec customers une table sur customer_key
Filtres	Conditions appliquées aux données sources pour définir l’étendue.	status = 'completed' order_date > '2024-01-01'
Champs	Colonnes utilisées pour regrouper, filtrer et agréger des métriques. Inclut des colonnes catégorielles et des colonnes numériques non agrégées. Aussi appelées dimensions.	Catégorie de produit, Mois Commande, Prix unitaire
Dispositions	Agrégations de colonnes qui produisent des métriques.	COUNT(o_orderkey) comme Nombre de commandes, SUM(o_totalprice) comme Revenu total

Définir une source

Vous pouvez utiliser une ressource de type table ou une requête SQL comme source pour votre vue de métrique. Vous devez disposer d’au moins SELECT droits sur l'une des ressources référencées.

Une ressource de type table est n’importe quel objet catalogue Unity qui expose un schéma tabulaire et prend en charge SELECT les requêtes, notamment 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.

Utiliser une ressource de type table comme source

Pour utiliser une ressource de type table comme source, spécifiez le nom complet. Par exemple : samples.tpch.orders.

Utiliser une vue de métrique comme source

Vous pouvez utiliser une vue de métrique existante comme source pour une nouvelle vue de 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`))"

Lorsque vous utilisez une vue de métrique en tant que source, les mêmes règles de composition s’appliquent pour référencer des champs et des mesures. Consultez Composabilité.

Utiliser une requête SQL comme source

Pour utiliser une requête SQL, écrivez le texte de la requête directement dans 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)

Note

Lorsque vous utilisez une requête SQL comme source avec une JOIN clause, définissez des contraintes de clé primaire et étrangère sur des tables sous-jacentes et utilisez l’option pour optimiser les RELY performances des requêtes. Consultez Déclarer la clé primaire, la clé étrangère et les contraintes uniques etl’optimisation des requêtes à l’aide de la clé primaire et des contraintes uniques.

Champs

Les champs, également appelés dimensions, sont des colonnes d’affichage des métriques que vous pouvez utiliser dans SELECT, WHEREet GROUP BY des clauses au moment de la requête. Un champ peut être une colonne catégorielle, telle que la région ou l’état, 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 requête. Chaque expression de champ doit retourner une valeur scalaire. Il peut référencer des colonnes à partir des données sources ou des champs définis précédemment dans la vue métrique. Chaque champ se compose de deux composants :

• name: alias de la colonne
• expr: expression SQL qui référence les données sources ou les champs précédemment définis dans la vue métrique

Avertissement

Les champs d’affichage de métrique de type chaîne sont toujours STRING, même lorsque la colonne source est CHAR ou VARCHAR. Étant donné que CHAR(n) le remplissage d’espace est perdu, les comparaisons peuvent retourner des résultats différents. Par exemple, column = 'COLLEGE' correspond à une CHAR(10) valeur dans la table source (qui est remplie d’espacement), mais pas dans le champ d’affichage des métriques.

Mesures

Les mesures sont des expressions qui produisent des résultats sans niveau prédéfinis d’agrégation. Ils doivent être exprimés à l’aide de fonctions d’agrégation. Pour référencer une mesure dans une requête, utilisez la MEASURE fonction. Les mesures peuvent référencer des colonnes de base dans les données sources, les champs définis précédemment ou les mesures définies précédemment. Chaque mesure se compose des composants suivants :

• name: alias de la mesure
• expr: expression SQL d’agrégation qui peut inclure des fonctions d’agrégation SQL

L’exemple suivant illustre des modèles de mesure courants pour l’analyse des données de commande et de chiffre d’affaires. Ces exemples utilisent la table TPC-H commandes, qui contient des données de transaction de vente, notamment les prix des commandes (o_totalprice), les identificateurs des 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 la liste des fonctions d’agrégation.

Appliquer des filtres

Un filtre s’applique à toutes les requêtes qui référencent la vue de 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 les 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'

Utiliser des jointures

Les vues métriques prennent en charge les jointures pour enrichir vos données source avec des attributs issus de tables associées. Vous pouvez modéliser des schémas en étoile (table de faits jointes à des tables de dimension), des schémas flocons (jointures de dimension multiniveaux) et des relations un-à-plusieurs (expansion des faits à partir d’une source dimensionnelle). Pour plus d’informations sur les types de jointure, la cardinalité, les modèles de schéma et les restrictions, consultez Jointures dans les vues de métriques.

Pour définir des jointures dans l’interface utilisateur, consultez l’étape 2 : Ajouter une jointure. Pour définir des jointures dans la définition YAML, utilisez les modèles dans les sections suivantes.

Note

Les tables jointes ne peuvent pas inclure de MAP colonnes de type. Pour décompresser des valeurs à partir de colonnes de MAP type, consultez Explosion des éléments imbriqués à partir d’une carte ou d’un tableau.

Schémas en étoile de modèle

Dans un schéma en étoile, source est la table des faits et est reliée à une ou plusieurs tables de dimension à l’aide d’un LEFT OUTER JOIN. Les vues de métriques rejoignent les tables de faits et de dimension nécessaires pour la requête spécifique, en fonction des champs et mesures sélectionnés.

Spécifiez des colonnes de jointure à l’aide d’une on clause (expression booléenne) ou d’une using clause (noms de colonnes partagées). La jointure doit suivre une relation plusieurs-à-un. En cas de relation plusieurs-à-plusieurs, le moteur sélectionne la première ligne correspondante dans la table de dimensions jointe.

L’exemple suivant associe orders (table de faits) à customer (table de dimensions) et expose les attributs du client sous forme de champs. Le paramètre rely.at_most_one_match: true indique que la jointure est de type plusieurs vers un (chaque commande a exactement un client), ce qui permet au moteur d’optimiser les requêtes qui appliquent un filtre sur des champs de la table jointe.

Avertissement

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 fan-out, 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 mise en forme YAML

Les définitions d’affichage des métriques suivent la syntaxe de notation YAML standard. Consultez la référence de syntaxe YAML de la vue métrique pour connaître la syntaxe et la mise en forme requises.

Bonnes pratiques

Utilisez les instructions suivantes lors de la modélisation des vues de métriques :

• Mesures atomiques de modèle : commencez par définir les mesures les plus simples en premier (par exemple, SUM(revenue), COUNT(DISTINCT customer_id)). Créez des mesures complexes à l’aide de la composabilité.
• Standardiser les valeurs de champ : utilisez des transformations (comme des instructions CASE) pour convertir les codes de base de données en libellés métier explicites (par exemple, convertir le statut de commande « O » en « Ouverte » et « F » en « Exécutée »).
• Définir l’étendue avec des filtres : si une vue de métrique ne doit inclure que des commandes terminées, définissez ce filtre dans l’affichage des métriques afin que les utilisateurs ne puissent pas inclure accidentellement des données incomplètes.
• Utilisez un nommage clair : les noms de métriques doivent être reconnaissables pour les utilisateurs professionnels (par exemple, « Valeur de durée de vie du client » au lieu de cltv_agg_measure).
• Champs d’heure distincts : incluez des champs d’heure granulaires (tels que « Date de commande ») et des champs d’heure tronqués (tels que « Mois de commande » ou « Semaine de commande ») pour activer l’analyse des détails et des tendances.

Ressources supplémentaires

• Jointures dans les vues de métriques
• Techniques avancées pour les vues de métriques
• Métadonnées de l’agent dans les vues de métrique
• Matérialisation pour les vues métriques
• Informations de référence sur la syntaxe YAML de l’affichage des métriques