Matérialisation pour les vues métriques

La matérialisation des vues métriques accélère les requêtes à l’aide de vues matérialisées pour précalculer les agrégations. Les pipelines Lakeflow orchestrent des vues matérialisées définies par l’utilisateur pour une vue de métrique donnée. Lors de l’exécution de la requête, l’optimiseur de requêtes dirige les requêtes vers la vue matérialisée la plus appropriée grâce à une mise en correspondance automatique des requêtes tenant compte des agrégations (réécriture des requêtes). Vous interrogez la vue des métriques comme d’habitude, sans aucun effort manuel supplémentaire. Databricks actualise les matérialisations pour les maintenir à jour. Il choisit également quelle matérialisation interroger afin d’obtenir des requêtes plus rapides à moindre coût.

Fonctionnement de la matérialisation

La matérialisation pour les vues de métriques implique deux phases : la définition de la matérialisation et l’exécution de requêtes sur celle-ci.

Phase de définition

Lorsque vous définissez une vue de métrique avec matérialisation, vous spécifiez vos champs, mesures et planification d’actualisation dans l’affichage des métriques YAML. À partir de cette définition, Databricks crée un pipeline Lakeflow managé qui génère et gère les vues matérialisées.

Définition de la vue des métriques et processus de matérialisation

Cela permet de séparer la définition de métrique de la façon dont elle est stockée :

• La vue métrique est un objet Catalogue Unity qui définit les champs, mesures et jointures de la métrique, ainsi que la configuration de matérialisation (planification et granularité). C’est la seule source de vérité pour ce que signifie la métrique.
• Le pipeline transforme cette définition en une ou plusieurs vues matérialisées, chacune étant précalculée à un niveau de granularité spécifique. Databricks choisit celui à lire au moment de la requête.

Exécution de la requête

Lorsque vous exécutez SELECT ... FROM <metric_view>, l’optimiseur de requête utilise la réécriture des requêtes prenant en compte l’agrégation pour optimiser les performances :

• Chemin rapide : Effectue des lectures depuis des vues matérialisées pré-calculées lorsqu'une matérialisation appropriée existe.
• Chemin d’accès de secours : lit directement à partir des données sources lorsqu’aucune matérialisation appropriée n’est disponible.

L’optimiseur de requête équilibre automatiquement les performances et l’actualisation en choisissant entre les données matérialisées et sources. Vous recevez les résultats de manière transparente quel que soit le chemin d’accès que l’optimiseur utilise. Pour plus d’informations sur l’exécution de requêtes sur des vues de métriques, consultez Vues des métriques de requête.

Exigences

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

• Votre espace de travail doit avoir le calcul serverless activé. Cela est nécessaire pour exécuter des pipelines Lakeflow.
• Une ressource d'entrepôt SQL ou de calcul exécutant Databricks Runtime 17.3 ou une version ultérieure.

Note

La matérialisation nécessite Databricks Runtime 17.3 ou 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 minimal pour chaque fonctionnalité, consultez la disponibilité des fonctionnalités de vue de métrique.

Référence de configuration

Vous configurez la matérialisation dans un champ de niveau materialization supérieur dans la définition YAML de l’affichage des métriques. Ce champ définit la réécriture de requête mode (toujours relaxed), une actualisation schedule facultative et une liste de materialized_views à maintenir. 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 connaître la spécification complète de champ par champ, y compris les champs obligatoires et facultatifs, les valeurs autorisées et les schedule restrictions de clause, consultez Matérialisation.

Exemple de définition

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 :

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

Note

Le bloc materialization utilise le mot-clé dimensions: pour répertorier 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 façon dont les données matérialisées sont physiquement réparties, de la même manière que les clauses CLUSTER BY et PARTITION BY d’une vue matérialisée. Pour obtenir la spécification complète du champ, consultez Matérialisation.

Créer la vue métrique à l’aide de SQL

Pour créer cette vue de métrique en dehors de l’Explorateur de catalogues, encapsulez 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.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 des requêtes

En relaxed mode, la réécriture automatique des requêtes vérifie uniquement si les vues matérialisées candidates ont les champs et mesures nécessaires pour servir la requête.

Les vérifications suivantes sont ignorées :

• Fraîcheur: Cela ne vérifie pas que la matérialisation est à jour.
• Paramètres SQL : il ne vérifie pas que les paramètres tels que TIMEZONE ou ANSI_MODE correspondent.
• Déterminisme : il ne vérifie pas que les résultats matérialisés sont entièrement déterministes.

Les requêtes qui correspondent à une matérialisation utilisent la dernière actualisation. Les requêtes qui ne correspondent pas basculent sur la source et renvoient des données en direct. Par conséquent, la fraîcheur des données peut varier selon qu’une requête se qualifie pour la réécriture. Pour vérifier la cohérence, alignez le calendrier d’actualisation de la matérialisation sur votre pipeline source. Par exemple, si votre source est mise à jour quotidiennement via un pipeline par lots, planifiez les actualisations de la matérialisation pour qu’elles s’exécutent une fois ce pipeline terminé. Vous pouvez également utiliser une matérialisation non agrégée pour garantir que toutes les requêtes s’exécutent à partir du même instantané.

Vous ne pouvez pas créer de matérialisation lorsque l’affichage des métriques ou l’une de ses tables sources utilise :

• Sécurité au niveau des lignes (RLS),masquage au niveau des colonnes (CLM) ou stratégies ABAC. Les résultats pré-calculés peuvent contourner les contrôles d’accès par utilisateur destinés à être appliqués au moment de la requête.
• Expressions dépendantes de l’appelant, dont le résultat change en fonction de l’exécution de la requête (par exemple, current_user() ou is_member()). Une matérialisation est pré-calculée une seule fois et partagée ; la fournir à un autre utilisateur produirait donc des résultats incorrects ou non sécurisés.

Databricks valide cette restriction lorsque vous créez, modifiez ou actualisez une matérialisation. Ces opérations échouent avec la condition METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED d’erreur (SQLSTATE 42K0E). Voir 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 de 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 requête.

Type agrégé

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

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

Pour des agrégations optimales :

• Incluez les dimensions les plus couramment utilisées dans GROUP BY les clauses.
• Incluez toutes les colonnes de filtre potentielles (colonnes utilisées au WHERE moment de la requête).
• Matérialisez au niveau le plus détaillé dont vos requêtes ont besoin. Par exemple, une matérialisation à (region, sku, event_day) peut répondre à l’ensemble des cas 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 à une seule ligne (par exemple, un horodatage brut avec une précision en millisecondes). Cela n’a aucun avantage et gonfle le stockage.
• Surveillez 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), MEDIANet centiles) et nécessitent une correspondance exacte par rapport à une matérialisation.

Une agrégation unique peut uniquement traiter des requêtes qui correspondent à ses dimensions spécifiques (correspondance exacte) ou à un sous-ensemble de ses dimensions (correspondance de cumul). Databricks recommande de créer plusieurs matérialisations agrégées pour différentes formes de requête.

Type non agrégé

Ce type matérialise l’ensemble du modèle de données non agrégé (les champs source, joins, filter et fields) pour une couverture plus étendue avec un impact moindre sur les performances que le type agrégé.

Utilisez un type non agrégé lorsque l’une des valeurs suivantes est true :

• Votre vue métrique implique des transformations de source ou des jointures coûteuses.
• Les modèles de requête sont imprévisibles ou variés.
• Tous les utilisateurs qui interrogent la vue de métrique doivent voir la cohérence dans les données.

Avec des matérialisations non agrégées, les vues source coûteuses et les jointures ne sont calculées qu’une seule fois lors de l’actualisation, plutôt qu’à chaque requête. Lorsque des matérialisations agrégées et non agrégées existent, Databricks calcule les matérialisations agrégées à partir de celle non agrégée. Cela fournit un instantané cohérent et évite la recomputation redondante 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 en mode réécriture de requête.

Une matérialisation non agrégée n’aide pas quand la source est une référence de table directe sans filtre sélectif. Dans ce cas, il n’a aucun avantage d’interroger directement la source.

Pour obtenir des conseils supplémentaires sur la façon et le moment d’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 requête achemine automatiquement votre requête vers la meilleure matérialisation disponible. Il utilise trois stratégies de réécriture de requête : correspondance exacte, correspondance de cumul et correspondance non agrégée.

La requête s’exécute automatiquement sur la meilleure matérialisation au lieu des tables de base à l’aide de cet algorithme :

1. Tout d’abord, l’optimiseur de requêtes recherche une correspondance exacte.
2. S’il n’existe aucune correspondance exacte, l’optimiseur de requête tente une correspondance de cumul.
3. S’il n’existe aucune correspondance de cumul et qu’une matérialisation non agrégée existe, l’optimiseur de requête tente une correspondance non agrégée.
4. S’il n’existe aucune correspondance non agrégée, la requête lit directement à partir des tables sources.

Les sections suivantes expliquent le fonctionnement de chaque stratégie.

Note

Les matérialisations doivent terminer la matérialisation avant que la réécriture de requête puisse prendre effet.

Correspondance exacte

La requête demande exactement ce qui a été pré-calculé dans la matérialisation. La réécriture de requête lit le résultat stocké sans travail supplémentaire, ce qui permet des résultats rapides.

Pour bénéficier d’une correspondance exacte :

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

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

Correspondance de cumul

La requête demande un résumé à un niveau de granularité plus grossier que celui qui a été précalculé. L’optimiseur lit le résultat pré-calculé et l’agrège jusqu’au niveau des besoins de la requête.

Pour être admissible à la mise en correspondance groupée :

• Granularité plus grossière : la requête regroupe selon moins de dimensions ou une granularité temporelle plus grossière que la matérialisation.
• Toutes les mesures sont additives : chaque mesure demandée par votre requête doit pouvoir être correctement recalculée en combinant des résultats partiels (par exemple, SUM des SUMs ou MAX des MAXes). MEDIAN ne peut pas être réduit, car il repose sur la distribution de groupe.
• Tous les filtres participants doivent être des expressions déterministes : si votre requête a une WHERE clause, 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() non.

La correspondance de cumul n’est pas éligible pour les mesures non additives, car elles ne peuvent pas être correctement agrégées à partir de résultats partiels. Voir les 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 requête qui regroupe uniquement par region et sélectionne total_revenue constitue une correspondance de roll-up. La requête nécessite moins de dimensions que celles qui ont été matérialisées, de sorte que le moteur agrège les totaux quotidiens pour obtenir des totaux au niveau régional.

Note

La correspondance de rollup n’est pas disponible lorsque la vue des métriques utilise une jointure one_to_many. Dans ce cas, chaque matérialisation se limite uniquement à la correspondance exacte. Pour plus d’informations sur les jointures un-à-plusieurs, consultez jointures un-à-plusieurs.

Mesures additives

Une mesure est additive si son résultat d’agrégation peut être considéré correctement en réagrégeant à partir de matérialisations agrégées existantes. Il s’agit de la condition essentielle pour la mise en correspondance des rollups.

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 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 à la correspondance de cumul.
• Si la définition de mesure inclut une FILTER clause, elle doit être déterministe.
• La mesure ne peut pas être une mesure avec fenêtre (par exemple, un total glissant sur 7 jours ou une comparaison d’une année sur l’autre définie à l’aide d’un bloc de fenêtre).

Le tableau suivant résume la façon dont les modèles de mesure courants correspondent aux types :

Modèle de mesure	Type de correspondance	Reason
Agrégat additif unique (SUM, COUNT, MIN, MAX)	Cumul éligible	Peut être réagrégé à partir de résultats partiels
COUNT(DISTINCT) ou d’autres agrégats non-additifs	Correspondance exacte uniquement	Impossible de réagréger
Agrégats multiples dans une seule expression (SUM(x) + MIN(y))	Correspondance exacte uniquement	Impossible d’isoler des agrégats individuels pour le cumul
Agrégat additif avec déterministe FILTER	Éligible au regroupement	Le filtre est déterministe, l’agrégat est additif
Mesure de fenêtre	Correspondance exacte uniquement	Le cadre de fenêtre dépend du grain exact

Jumelage non agrégé

La requête ne correspond à aucune agrégation précalculée, mais le travail de préparation coûteux (jointures et filtres) est déjà effectué. La réécriture de requête commence à partir du jeu de données 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 secours avant d’aller à la source. Toute forme de requête peut l’utiliser, sous réserve des restrictions décrites en mode réécriture de requête.

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

Vérifier qu’une requête utilise des vues matérialisées

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

• Exécutez EXPLAIN EXTENDED sur votre requête pour voir le plan de requête. 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 indiqué dans le fichier YAML.
• Examinez le profil de requête, comme indiqué ci-dessous.

Cycle de vie de 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 de métriques (à l’aide de CREATE, de ALTER ou de l’Explorateur de catalogues), la définition de la vue de métriques est mise à jour immédiatement. Les vues matérialisées sont actualisées de façon 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 Planification pour définir une planification. Vous pouvez sélectionner une période d’intervalle ou définir la matérialisation à exécuter à un moment spécifique.
3. Sélectionnez un type. Une seule matérialisation non agrégée est autorisée par vue de métrique. Pour plus d’informations, consultez Types de matérialisations pour les vues métriques.
4. Utilisez la liste déroulante Champs pour sélectionner les champs à inclure dans la matérialisation.
5. Utilisez la liste déroulante Mesures pour sélectionner les mesures à inclure.

Lorsque vous créez une vue de métrique, Databricks crée un pipeline Lakeflow et planifie immédiatement une mise à jour initiale s’il existe des vues matérialisées spécifiées. La vue des métriques reste interrogeable sans matérialisation en revenant à l’interrogation à partir des données sources.

Lorsque vous modifiez une vue de métrique, 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 des requêtes tant que la prochaine mise à jour planifiée n’est pas terminée.

La modification de la planification de matérialisation ne déclenche pas d’actualisation.

Sans planification, le pipeline exécute une mise à jour initiale lors de la création, mais les actualisations suivantes doivent être déclenchées manuellement ou les données sont obsolètes. Databricks recommande de toujours définir une planification afin que les données restent fraîches, sauf si vous testez ou prototypez.

Consultez l’actualisation manuelle pour contrôler plus finement le comportement d’actualisation.

Inspecter le pipeline sous-jacent

La matérialisation des vues de métriques est implémentée à l’aide de pipelines Lakeflow. Vous pouvez accéder au pipeline de deux façons :

• Dans l’Explorateur de catalogues : l’onglet Vue d’ensemble de la vue de métrique comprend un lien direct sous l’en-tête Planification de l’actualisation. Pour savoir comment accéder à l’Explorateur de catalogues, consultez Qu’est-ce que l’Explorateur de catalogues ?.
• Utilisation de SQL : Exécuter DESCRIBE EXTENDED. La section Informations d’actualisation contient le lien de pipeline et l’état d’actualisation actuel.

DESCRIBE EXTENDED my_metric_view;

Exemple de sortie :

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

Actualisation manuelle

Depuis le lien vers la page du pipeline Lakeflow, vous pouvez lancer manuellement une mise à jour du pipeline afin d’actualiser les matérialisations. Vous pouvez également déclencher une actualisation manuelle à l’aide de la commande SQL suivante :

REFRESH MATERIALIZED VIEW <metric-view-name>

Actualisation incrémentielle

Les vues matérialisées utilisent l’actualisation incrémentielle chaque fois que possible et ont les mêmes limitations que les vues matérialisées standard concernant les sources de données et la structure de plan.

Pour en savoir plus sur les prérequis et les restrictions, consultez la mise à jour incrémentielle des vues matérialisées .

Billing

L’actualisation des vues matérialisées entraîne des frais d’utilisation des pipelines Lakeflow. Pour rechercher la consommation DBU du pipeline, consultez Quelle est la consommation DBU d’un pipeline serverless ?.

Restrictions connues

Les restrictions suivantes s’appliquent à la matérialisation des vues de métriques :

• Vous ne pouvez pas matérialiser une vue de métrique qui définit des paramètres.
• Une fois qu’une matérialisation est créée pour une vue de métrique, vous ne pouvez pas modifier le propriétaire.
• Databricks ne prend pas en charge la propriété de groupe des vues de métrique matérialisées.
• Seule la stratégie de correspondance exacte peut être utilisée pour les vues de mesures avec des jointures de type un-à-plusieurs.
• La matérialisation schedule ne prend pas en charge la clause TRIGGER ON UPDATE.