Matérialisation pour les vues métriques

info

Aperçu public

Cette fonctionnalité est en aperçu public.

La matérialisation pour les vues métriques accélère les queries en utilisant des vues matérialisées pour précalculer les agrégations. Les LakeFlow Pipelines orchestrent les vues matérialisées définies par l'utilisateur pour une vue métrique donnée. Au moment de la query, l'optimiseur de query achemine les queries vers la meilleure vue matérialisée en utilisant la correspondance de query automatique prenant en compte les agrégats (réécriture de query). Vous interrogez la vue métrique comme d'habitude, sans effort manuel supplémentaire. Databricks refresh les matérialisations pour les maintenir à jour. Il choisit également quelle matérialisation interroger pour des query plus rapides à moindre coût.

Comment fonctionne la matérialisation

La matérialisation pour les vues métriques implique deux phases : définir la matérialisation et exécuter des query par rapport à celle-ci.

Phase de définition

Lorsque vous définissez une vue métrique avec matérialisation, vous spécifiez vos champs, vos mesures et votre planification de refresh dans le YAML de la vue métrique. À partir de cette définition, Databricks crée un Lakeflow Pipelines géré qui construit et maintient les vues matérialisées.

Ceci maintient la définition de la métrique séparée de la manière dont elle est stockée :

• La vue des métriques est un objet Unity Catalog qui définit les champs, les mesures et les jointures de la métrique, ainsi que la configuration de la matérialisation (planification et granularité). C'est la source unique de vérité pour ce que signifie la métrique.
• **Le pipeline** matérialise cette définition en une ou plusieurs vues matérialisées, chacune précalculée à une granularité spécifique. Databricks choisit celle à lire au moment de la query.

Exécution de la query

Lorsque vous exécutez SELECT ... FROM <metric_view>, l'optimiseur de query utilise la réécriture de query tenant compte des agrégats pour optimiser les performances :

• Chemin rapide : lit à partir de vues matérialisées pré-calculées lorsqu'une matérialisation appropriée existe.
• Chemin de fallback : lit directement les données sources lorsqu'aucune matérialisation appropriée n'est disponible.

L'optimiseur de requêtes gère automatiquement l'équilibre entre la performance et la fraîcheur en choisissant entre les données matérialisées et les données source. Vous obtenez des résultats en toute transparence, quel que soit le chemin utilisé par l'optimiseur. Pour en savoir plus sur l'exécution de query sur les vues de métriques, consultez Query les vues de métriques.

Exigences

Pour utiliser la matérialisation pour les vues de métriques :

• Votre Workspace doit avoir le compute Serverless activé. Ceci est requis pour exécuter les LakeFlow Pipelines.
• Un SQL Warehouse ou une ressource de compute exécutant Databricks Runtime 17.3 et versions ultérieures.

remarque

La matérialisation nécessite Databricks Runtime 17.3 ou une version ultérieure. La création d'une vue de métrique sans matérialisation est prise en charge sur Databricks Runtime 16.4 et versions ultérieures. Pour le runtime minimum de chaque fonctionnalité, consultez la disponibilité des fonctionnalités de la vue de métrique.

Référence de configuration

Vous configurez la matérialisation dans un champ materialization de niveau supérieur dans la définition YAML de la vue de métrique. Ce champ définit la réécriture de query mode (toujours relaxed), un refresh facultatif schedule, et une liste de materialized_views à conserver. Chaque vue matérialisée est soit aggregated, qui pré-calcule des dimensions et des mesures spécifiques, soit unaggregated, qui matérialise le modèle de données complet.

Pour la spécification complète champ par champ, y compris les champs obligatoires et facultatifs, les valeurs autorisées et les restrictions de clause schedule, consultez Matérialisation.

Définition d'exemple

L'exemple suivant définit une vue de métrique avec une matérialisation non agrégée et deux matérialisations agrégées :

YAML

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

remarque

Le bloc materialization utilise le mot-clé dimensions: pour lister les champs à matérialiser, même si la définition de niveau supérieur utilise fields:. Les deux mots-clés sont équivalents. Voir Champs.

La matérialisation revenue_breakdown utilise cluster_by et partition_by pour contrôler la disposition physique des données matérialisées, de la même manière que les clauses CLUSTER BY et PARTITION BY sur une vue matérialisée. Pour la spécification complète des champs, consultez la Matérialisation.

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.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Mode de réécriture de query

En mode relaxed, la réécriture automatique de query vérifie uniquement si les vues matérialisées candidates disposent des champs et des mesures nécessaires pour traiter la query.

Les vérifications suivantes sont ignorées :

• **Actualité** : Il ne vérifie pas que la matérialisation est à jour.
• SQL settings : Il ne vérifie pas que des paramètres tels que TIMEZONE ou ANSI_MODE correspondent.
• **Déterminisme** : Il ne vérifie pas que les résultats matérialisés soient entièrement déterministes.

Les query qui correspondent à une matérialisation utilisent le dernier refresh. Les requêtes qui ne correspondent pas reviennent à la source et renvoient des données en direct. En conséquence, la fraîcheur des données peut varier selon qu'une query est éligible à une réécriture. Pour vérifier la cohérence, alignez votre calendrier de refresh des matérialisations avec votre pipeline source. Par exemple, si votre source se met à jour quotidiennement avec un pipeline batch, planifiez les actualisations de matérialisation pour qu'elles s'exécutent une fois ce pipeline terminé. Alternativement, utilisez une matérialisation non agrégée pour garantir que toutes les requêtes lisent à partir du même instantané.

Vous ne pouvez pas créer de matérialisation lorsque la vue d'indicateurs ou l'une de ses tables source utilise :

• Sécurité au niveau des lignes (RLS), masquage au niveau des colonnes (CLM) ou politiques ABAC. Les résultats précalculés peuvent contourner les contrôles d'accès par utilisateur qui sont censés être appliqués au moment de la query.
• Expressions dépendantes de l'appelant, dont le résultat change en fonction de la personne qui exécute la query (par exemple, current_user() ou is_member()). Une matérialisation est pré-calculée une seule fois et partagée, ainsi, la servir à un utilisateur différent renverrait des résultats incorrects ou non sécurisés.

Databricks valide cette restriction lorsque vous créez, modifiez ou refresh une matérialisation. Ces opérations échouent avec la condition d'erreur : METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E). Consultez METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Types de matérialisations pour les vues métriques

Les sections suivantes expliquent les types de vues matérialisées disponibles pour les vues métriques et fournissent des conseils sur la sélection de la configuration appropriée pour vos sources de données et modèles de query.

Type agrégé

Ce type pré-calcule les agrégations pour des combinaisons de mesures et de champs spécifiées pour une couverture ciblée.

Utilisez un type agrégé lorsqu’il existe des combinaisons spécifiques de dimensions et de mesures qui sont fréquemment interrogées. Avec les matérialisations agrégées, les stratégies de correspondance exacte et de correspondance de regroupement s’appliquent toutes deux, offrant ainsi les meilleures performances de requête pour ces modèles.

Pour des agrégations optimales :

• Incluez les dimensions les plus couramment utilisées dans les clauses GROUP BY.

• Incluez toutes les colonnes de filtre potentielles (colonnes utilisées dans WHERE au moment de la query).

• Matérialisez au niveau le plus détaillé dont vos queries ont besoin. Par exemple, une matérialisation à (region, sku, event_day) peut servir tous les éléments suivants :

  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku avec WHERE region = 'US'

• Évitez les dimensions si granulaires qu'elles produisent principalement des groupes d'une seule ligne (par exemple, un Timestamp brut avec une précision en millisecondes). Ceci n'a aucun avantage et gonfle le stockage.

• Veuillez surveiller les mesures non additives. Les mesures non additives ne peuvent pas être réagrégées à partir de résultats partiels (par exemple, COUNT(DISTINCT), MEDIAN et les centiles) et nécessitent une correspondance exacte avec une matérialisation.

Une seule agrégation peut uniquement servir des queries qui correspondent à ses dimensions spécifiques (correspondance exacte) ou à un sous-ensemble de ses dimensions (correspondance agrégée). Databricks recommande de créer plusieurs matérialisations agrégées pour différentes formes de query.

Type non agrégé

Ce type matérialise l'intégralité du modèle de données non agrégé (les champs source, joins, filter et fields) pour une couverture plus large avec moins d'impact sur les performances par rapport au type agrégé.

Utilisez un type non agrégé lorsque l'une des conditions suivantes est vraie :

• Votre vue métrique implique des transformations ou des jointures de source coûteuses.
• Les modèles de query sont imprévisibles ou variés.
• Tous les utilisateurs interrogeant la vue de métriques doivent voir une cohérence au sein des données.

Avec les matérialisations non agrégées, les vues sources et les jointures coûteuses sont compute une fois lors du refresh plutôt qu’à chaque query. Lorsque les matérialisations agrégées et non agrégées existent, Databricks compute les matérialisations agrégées à partir de la matérialisation non agrégée. Cela fournit un instantané cohérent et évite les calculs redondants de la source. Une correspondance non agrégée est toujours éligible, quelle que soit la forme de la requête, sous réserve des restrictions décrites dans le mode de réécriture de requête.

Une matérialisation non agrégée n'est pas utile lorsque la source est une référence de table directe sans filtre sélectif. Dans ce cas, cela n’a aucun avantage par rapport à l’interrogation directe de la source.

Pour des conseils supplémentaires sur comment et quand utiliser ces types de matérialisation, consultez Choisir un type de matérialisation pour les vues de métriques.

Réécriture automatique des requêtes

Lorsque vous interrogez une vue de métrique, la réécriture de query achemine automatiquement votre query vers la meilleure matérialisation disponible. Il utilise trois stratégies de réécriture de query : correspondance exacte, correspondance de rollup et correspondance non agrégée.

La query s'exécute automatiquement sur la meilleure matérialisation au lieu des tables de base en utilisant cet algorithme :

1. Tout d'abord, l'optimiseur de requêtes tente une correspondance exacte.
2. S'il n'y a pas de correspondance exacte, l'optimiseur de query tente une correspondance par agrégation.
3. S'il n'y a pas de correspondance de regroupement et qu'une matérialisation non agrégée existe, l'optimiseur de query tente une correspondance non agrégée.
4. S'il n'y a pas de correspondance non agrégée, la query lit directement à partir des tables source.

Les sections suivantes expliquent comment fonctionne chaque stratégie.

remarque

Les matérialisations doivent être terminées avant que la réécriture de la query ne prenne effet.

Correspondance exacte

La query demande exactement ce qui a été précalculé dans la matérialisation. La réécriture de la query lit le résultat stocké sans travail supplémentaire, ce qui permet d'obtenir des résultats rapides.

Pour être éligible à la correspondance exacte :

• Les GROUP BY expressions de la query doivent correspondre exactement aux dimensions de matérialisation.
• Les mesures de la query doivent être un sous-ensemble des mesures de matérialisation.

Par exemple, une matérialisation a les dimensions [region, order_date] et les mesures [total_revenue, order_count]. Une query qui regroupe par region et order_date et demande total_revenue est une correspondance exacte, car les dimensions sont les mêmes et la mesure a été précalculée.

Correspondance de rollup.

La query demande un résumé à un niveau plus grossier que ce qui a été précalculé. L'optimiseur lit le résultat précalculé et le réagrège jusqu'au niveau dont la query a besoin.

Pour être admissible à la correspondance de regroupement :

• Granularité plus grossière : la query regroupe par moins de dimensions ou une granularité temporelle plus large que la matérialisation.
• **Toutes les mesures sont additives** : chaque mesure que votre query demande doit être une mesure qui peut être recalculée correctement en combinant les résultats partiels (par exemple, SUM de SUM MAX ou MAXde). MEDIAN ne peut pas être regroupé car il dépend de la distribution de groupe.
• Tous les filtres participants doivent être des expressions déterministes : Si votre query possède une clause WHERE, le filtre doit toujours produire le même résultat pour la même entrée. Par exemple, WHERE region = 'US' est déterministe, mais les expressions telles que rand() ou uuid() ne le sont pas.

La correspondance de cumul n'est pas éligible pour les mesures non additives, car elles ne peuvent pas être correctement réagrégées à partir de résultats partiels. Veuillez consulter Mesures additives.

Par exemple, en utilisant la même matérialisation avec les dimensions [region, order_date] et les mesures [total_revenue, order_count], une query qui regroupe uniquement par region et demande total_revenue est une correspondance de regroupement. La query nécessite moins de dimensions que ce qui a été matérialisé, de sorte que le moteur agrège les totaux quotidiens en totaux au niveau de la région.

Mesures additives

Une mesure est *additive* si son résultat agrégé peut être correctement recalculé en réagrégeant à partir de matérialisations agrégées existantes. Il s'agit de l'exigence fondamentale pour la correspondance de regroupement.

Tout agrégat utilisant DISTINCT (par exemple, COUNT(DISTINCT), SUM(DISTINCT)) n'est pas additif et ne peut pas être cumulé.

Les fonctions suivantes sont additives :

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

Des restrictions supplémentaires s'appliquent aux mesures additives :

• La définition de la mesure doit contenir exactement une fonction d'agrégation. Une mesure dont la définition combine plusieurs agrégats (par exemple, sum(cost) + min(revenue)) n'est pas éligible pour la correspondance de cumul.
• Si la définition de la mesure inclut une clause FILTER, elle doit être déterministe.
• La mesure ne peut pas être une mesure de fenêtre (par exemple, un total mobile sur 7 jours ou une comparaison d'une année sur l'autre définie avec un bloc de fenêtre).

Correspondance non agrégée

La query ne correspond à aucune agrégation précalculée, mais le travail préparatoire coûteux (jointures et filtres) est déjà effectué. La réécriture de query start à partir du dataset préparé de la matérialisation non agrégée au lieu de revenir aux tables sources.

Si une matérialisation non agrégée existe, cette stratégie est toujours éligible en tant que fallback avant d'accéder à la source. Toute forme de query peut l'utiliser, sous réserve des restrictions décrites dans Mode de réécriture de query.

Par exemple, votre query regroupe par category et demande unique_customers, mais aucune matérialisation agrégée n’inclut ces champs et mesures. Il existe cependant une matérialisation non agrégée avec le jeu de données joint et filtré prêt. L'optimiseur de query lit ce dataset préparé et exécute GROUP BY category, COUNT(DISTINCT customer_id) au moment de la query, au lieu de rejoindra les tables brutes à partir de zéro.

Vérifier qu'une query utilise des vues matérialisées

Il existe deux façons de vérifier si une query utilise une vue matérialisée :

• Exécutez EXPLAIN EXTENDED sur votre query pour voir le plan de query. Si la matérialisation a été utilisée, le nœud feuille inclut __materialization_mat_<pipeline ID>___metric_view_mat_ et le nom de la matérialisation du fichier YAML.
• Consultez le profil de la query, comme indiqué ci-dessous.

Cycle de vie de la matérialisation

Cette section explique comment les matérialisations sont créées, gérées et actualisées tout au long de leur cycle de vie.

Créer et modifier

Lorsque vous créez ou modifiez une vue métrique (à l'aide de CREATE, ALTER ou de l'Explorateur de catalogues), la définition de la vue métrique est mise à jour immédiatement. Les vues matérialisées refresh de manière asynchrone en arrière-plan à l'aide d'un pipeline géré.

Pour définir une nouvelle matérialisation dans l'éditeur de l'explorateur de catalogues :

1. Cliquez sur Matérialisations .
2. Cliquez sur Planifier pour définir un calendrier. Vous pouvez sélectionner une période d'intervalle ou définir l'exécution de la matérialisation à un moment précis.
3. Sélectionnez un **Type**. Une seule matérialisation non agrégée est autorisée par vue métrique. Pour plus d'informations, consultez Les types de matérialisations pour les vues métriques.
4. Utilisez le menu déroulant **Champs** pour sélectionner les champs à inclure dans la matérialisation.
5. Utilisez le menu déroulant **Mesures** pour sélectionner les mesures à inclure.

Lorsque vous créez une vue métrique, Databricks crée un LakeFlow Pipelines et planifie une mise à jour initiale immédiatement si des vues matérialisées sont spécifiées. La vue métrique reste interrogeable sans matérialisation en se rabattant sur l'interrogation des données sources.

Lorsque vous modifiez une vue de métriques, Databricks ne planifie pas de nouvelles mises à jour, sauf si vous activez la matérialisation pour la première fois. Les vues matérialisées ne sont pas utilisées pour la réécriture automatique de query tant que la prochaine mise à jour planifiée n'est pas terminée.

La modification de la planification de la matérialisation ne déclenche pas un refresh.

Sans planification, le pipeline exécute une mise à jour initiale lors de sa création, mais les refresh ultérieurs doivent être Trigger manuellement ou les données deviennent obsolètes. Databricks recommande de toujours définir une planification afin que les données restent à jour, sauf si vous effectuez des tests ou du prototypage.

Consultez Refresh manuel pour un contrôle plus précis du comportement de refresh.

Inspecter le pipeline sous-jacent

La matérialisation des vues métriques est implémentée à l'aide des Lakeflow pipelines. Vous pouvez accéder au pipeline de deux manières :

• Dans l'Explorateur de catalogues : l'onglet Vue d'ensemble de la vue de métriques comprend un link direct sous l'en-tête Refresh Schedule . Pour savoir comment accéder à l'Explorateur de catalogues, consultez Qu'est-ce que l'Explorateur de catalogues ?.
• Utilisation de SQL : Exécutez DESCRIBE EXTENDED. La section Information sur le refresh contient le Link de pipeline et le statut de refresh actuel.

SQL

DESCRIBE EXTENDED my_metric_view;

Résultat d’exemple :

SQL

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Manual refresh

À partir du Link vers la page du LakeFlow Pipelines, vous pouvez start manuellement une mise à jour du pipeline pour mettre à jour les matérialisations. Vous pouvez également trigger un refresh manuel à l’aide de la commande SQL suivante :

SQL

REFRESH MATERIALIZED VIEW <metric-view-name>

refresh incrémentielle

Les vues matérialisées utilisent l'incrémentielle refresh dans la mesure du possible et présentent les mêmes limitations que les vues matérialisées standard en ce qui concerne les sources de données et la structure du plan.

Pour plus de détails sur les prérequis et les restrictions, consultez le refresh incrémentiel des vues matérialisées.

Facturation

L’actualisation des vues matérialisées entraîne des frais d’utilisation des LakeFlow Pipelines. Pour connaître la consommation de DBU du pipeline, consultez Qu’est-ce que la consommation de DBU d’un pipeline serverless ?.

Restrictions connues

Les restrictions suivantes s'appliquent à la matérialisation pour les vues de métriques :

• Vous ne pouvez pas matérialiser une vue de métrique qui définit des parameters.
• Après la création d'une matérialisation pour une vue métrique, vous ne pouvez pas changer le propriétaire.
• Databricks ne prend pas en charge la propriété de groupe des vues de métriques matérialisées.
• Seule la stratégie de correspondance exacte est admissible pour les vues métriques avec des jointures un-à-plusieurs.