Actualisation incrémentielle pour les vues matérialisées

Cet article décrit la sémantique et les exigences relatives aux actualisations incrémentielles sur les vues matérialisées et identifie les opérations, mots clés et clauses SQL qui prennent en charge l’actualisation incrémentielle. Il comprend une discussion sur les différences entre les actualisations incrémentielles et complètes, et inclut des recommandations pour choisir entre les vues matérialisées et les tables de diffusion en continu.

Lors de l’exécution de mises à jour sur des vues matérialisées à l’aide de pipelines serverless, de nombreuses requêtes peuvent être actualisées de manière incrémentielle. Les actualisations incrémentielles économisent les coûts de calcul en détectant les modifications apportées aux sources de données utilisées pour définir la vue matérialisée et calculer de façon incrémentielle le résultat.

Les rafraîchissements s’opèrent grâce au calcul sans serveur

Les opérations d’actualisation sont exécutées sur des pipelines serverless, indépendamment si l’opération a été définie dans Databricks SQL ou avec des pipelines déclaratifs Spark Lakeflow.

Pour les vues matérialisées définies à l’aide de Databricks SQL, votre espace de travail n’a pas besoin d’être activé pour les pipelines déclaratifs Spark Lakeflow sans serveur. La mise à jour utilisera automatiquement un pipeline sans serveur.

Pour les vues matérialisées définies à l’aide de pipelines déclaratifs Spark Lakeflow, vous devez configurer les pipelines pour qu'ils utilisent sans serveur. Consultez Configurer un pipeline serverless.

Quelles sont les sémantiques d’actualisation pour les vues matérialisées ?

Les vues matérialisées garantissent des résultats équivalents aux requêtes par lots. Par exemple, considérez la requête d’agrégation suivante :

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Lorsque vous exécutez cette requête à l’aide d’un produit Azure Databricks, le résultat est calculé à l’aide de la sémantique de traitement par lots pour agréger tous les enregistrements de la source transactions_table, ce qui signifie que toutes les données sources sont analysées et agrégées en une seule opération.

L’exemple suivant transforme cette requête par lots en vue matérialisée :

CREATE OR REPLACE MATERIALIZED VIEW transaction_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Lorsque vous actualisez une vue matérialisée, le résultat calculé est identique à la sémantique de requête batch. Cette requête est un exemple d’une vue matérialisée qui peut être actualisée de manière incrémentielle, ce qui signifie que l’opération d’actualisation effectue une tentative optimale de traiter uniquement les données nouvelles ou modifiées dans la source transactions_table pour calculer les résultats.

Considérations relatives à la source de données pour les vues matérialisées

Bien que vous puissiez définir une vue matérialisée sur n’importe quelle source de données, toutes les sources de données ne sont pas adaptées aux vues matérialisées. Tenez compte des avertissements et recommandations suivants :

Toutes les sources de données pour les vues matérialisées doivent être robustes pour la sémantique d’actualisation complète, même si la requête qui définit la vue matérialisée prend en charge l’actualisation incrémentielle.

• Pour les requêtes où une actualisation complète serait trop coûteuse, utilisez des tables de streaming pour garantir un traitement exactement une seule fois. Les exemples incluent des tables très volumineuses.
• Ne définissez pas d’affichage matérialisé par rapport à une source de données si les enregistrements ne doivent être traités qu’une seule fois. Utilisez plutôt des tables de diffusion en continu. Voici quelques exemples :
  • Sources de données qui ne conservent pas l’historique des données, telles que Kafka.
  • Opérations d’ingestion, telles que les requêtes qui utilisent le chargeur automatique pour ingérer des données à partir du stockage d’objets cloud.
  • Toute source de données dans laquelle vous envisagez de supprimer ou d’archiver des données après traitement, mais doit conserver des informations dans des tables en aval. Par exemple, une table partitionnée à date dans laquelle vous envisagez de supprimer des enregistrements antérieurs à un certain seuil.
• Toutes les sources de données ne prennent pas en charge les actualisations incrémentielles. Les sources de données suivantes prennent en charge l’actualisation incrémentielle :
  • Tables Delta, y compris les tables gérées par Unity Catalog et les tables externes supportées par Delta Lake.
  • Vues matérialisées.
  • Tables de diffusion en continu, y compris les cibles des opérations de AUTO CDC ... INTO.
• Certaines opérations d’actualisation incrémentielle nécessitent que le suivi des lignes soit activé sur les sources de données interrogées. Le suivi des lignes est une fonctionnalité Delta Lake uniquement prise en charge par les tables Delta, qui incluent des vues matérialisées, des tables de diffusion en continu et des tables gérées par le catalogue Unity. Consultez Utiliser le suivi des lignes pour les tables Delta.
• Les sources de données avec des filtres de lignes ou des masques de colonne définis ne prennent pas en charge l’actualisation incrémentielle. Afficher les filtres de lignes et les masques de colonne

Optimiser des vues matérialisées

Pour obtenir les meilleures performances, Databricks recommande d’activer les fonctionnalités suivantes sur toutes les tables sources de vue matérialisée :

• Vecteurs de suppression
• Suivi des lignes
• Modifier le flux de données

Vous pouvez définir ces fonctionnalités pendant la création ou une version ultérieure avec l’instruction ALTER TABLE . Par exemple:

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Types d’actualisation pour les vues matérialisées

Lorsqu’une vue matérialisée est mise à jour, vous pouvez spécifier une actualisation ou une actualisation complète.

• Une actualisation tente d’effectuer une actualisation incrémentielle, mais effectue une recompilation complète des données si nécessaire. L’actualisation incrémentielle est disponible uniquement lorsque le calcul auquel vous êtes connecté est serverless.
• Une actualisation complète recalcule toujours toutes les entrées dans la vue matérialisée et réinitialise tous les points de contrôle.

Pour déterminer le type d’actualisation utilisé, consultez Déterminer le type d’actualisation d’une mise à jour.

Actualisation par défaut

Actualisation par défaut pour une vue matérialisée sur les tentatives serverless d’effectuer une actualisation incrémentielle. Une actualisation incrémentielle traite les modifications apportées aux données sous-jacentes après la dernière actualisation, puis ajoute ces données à la table. Selon les tables de base et les opérations incluses, seuls certains types de vues matérialisées peuvent être actualisés de manière incrémentielle. Si une actualisation incrémentielle n’est pas possible ou si le calcul connecté est classique au lieu de serverless, une récompute complète est effectuée.

La sortie d’une actualisation incrémentielle et une recompilation complète sont identiques. Azure Databricks exécute une analyse des coûts pour choisir l’option moins coûteuse entre une actualisation incrémentielle et une recompilation complète.

Seules les vues matérialisées mises à jour à l’aide de pipelines sans serveur peuvent utiliser la mise à jour incrémentielle. Les vues matérialisées qui n’utilisent pas de pipelines serverless sont toujours entièrement recomputées.

Lorsque vous créez des vues matérialisées avec un entrepôt SQL ou des pipelines déclaratifs Lakeflow Spark serverless, Azure Databricks les actualise de façon incrémentielle si leurs requêtes sont prises en charge. Si une requête utilise des expressions non prises en charge, Azure Databricks exécute une recompilation complète à la place, ce qui peut augmenter les coûts.

Pour déterminer le type d’actualisation utilisé, consultez Déterminer le type d’actualisation d’une mise à jour.

Actualisation complète

Une actualisation complète remplace les résultats de la vue matérialisée en désactivant la table et les points de contrôle, et en retraiteant toutes les données disponibles dans la source.

Pour effectuer une actualisation complète sur les vues matérialisées définies à l’aide de Databricks SQL, utilisez la syntaxe suivante :

REFRESH MATERIALIZED VIEW mv_name FULL

Pour les vues matérialisées définies dans les pipelines déclaratifs Spark Lakeflow, vous pouvez choisir d’exécuter une actualisation complète sur les jeux de données sélectionnés ou sur tous les jeux de données d’un pipeline. Consultez la sémantique d’actualisation du pipeline .

Prise en charge de l’actualisation incrémentielle des vues matérialisées

Le tableau suivant répertorie la prise en charge de l’actualisation incrémentielle par mot clé ou clause SQL.

Déterminer le type d’actualisation d’une mise à jour

Pour optimiser les performances des actualisations de vues matérialisées, Azure Databricks utilise un modèle de coût afin de sélectionner la technique adoptée pour l’actualisation. Le tableau suivant décrit ces techniques :

Pour déterminer la technique utilisée, interrogez le journal des événements des Pipelines déclaratifs Spark Lakeflow où event_type est égal à planning_information.

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Remplacez <fully-qualified-table-name> par le nom complet de la vue matérialisée, incluant le catalogue et le schéma.

Exemple de sortie pour cette commande :

• • timestamp
  • message
• • 2025-03-21T22:23:16.497+00:00
  • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Consultez le journal des événements pipeline.