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 pipelines serverless sont requis pour l’actualisation incrémentielle
L’actualisation incrémentielle pour les vues matérialisées nécessite des pipelines serverless.
Les opérations d’actualisation des vues matérialisées définies dans Databricks SQL s’exécutent toujours à l’aide de pipelines serverless.
Pour les vues matérialisées définies à l’aide de pipelines Delta Live Tables, vous devez configurer le pipeline pour qu’il utilise serverless. Consultez Configurer un pipeline Delta Live Tables 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 de n’importe quel 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.
Remarque
Certains produits Azure Databricks cachent automatiquement les résultats dans ou entre les sessions si les sources de données n’ont pas changé après l’exécution de la dernière requête. Les comportements de mise en cache automatique diffèrent des vues matérialisées.
L’exemple suivant transforme cette requête par lots en vue matérialisée :
CREATE OR REFRESH MATERIALIZED VIEW transation_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 :
Important
Les vues matérialisées font un meilleur effort pour actualiser les résultats de manière incrémentielle pour les opérations prises en charge. Certaines modifications apportées aux sources de données nécessitent une actualisation complète.
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 prohibitive, utilisez des tables de diffusion en continu pour garantir un traitement exactement une 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 le catalogue Unity et les tables externes sauvegardées par Delta Lake.
- Vues matérialisées.
- Tables de diffusion en continu, y compris les cibles des
APPLY CHANGES INTO
opérations.
- 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.
Types d’actualisation pour les vues matérialisées
Les actualisations des vues matérialisées sont complètes ou incrémentielles. Pour toutes les opérations, les résultats d’une actualisation incrémentielle et de l’actualisation complète sont identiques. Azure Databricks exécute une analyse des coûts pour identifier si les modifications apportées aux sources de données nécessitent une actualisation complète.
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 retraiteant toutes les données disponibles dans la source. Toutes les vues matérialisées peuvent être entièrement actualisées sur une mise à jour donnée, selon la façon dont les sources de données ont changé.
Vous pouvez éventuellement forcer une actualisation complète. Pour 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 un pipeline Delta Live Tables, 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. Découvrez comment Delta Live Tables met à jour les tables et les vues.
Important
Lorsqu’une actualisation complète s’exécute sur une source de données où les enregistrements ont été supprimés en raison du seuil de rétention des données ou de la suppression manuelle, les enregistrements supprimés ne sont pas reflétés dans les résultats calculés. Vous ne pourrez peut-être pas récupérer d’anciennes données si les données ne sont plus disponibles dans la source.
Remarque
Vous pouvez éventuellement désactiver les actualisations complètes sur une table en définissant la propriété pipelines.reset.allowed
false
de table sur .
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.
Seules les vues matérialisées mises à jour à l’aide de pipelines serverless peuvent utiliser l’actualisation incrémentielle. Les vues matérialisées qui n’utilisent pas de pipelines serverless sont toujours entièrement actualisées.
Lorsque des vues matérialisées sont créées à l’aide d’un pipeline SQL Warehouse ou Delta Live Tables serverless, elles sont automatiquement actualisées de manière incrémentielle si leurs requêtes sont prises en charge. Si une requête inclut des expressions non prises en charge pour une actualisation incrémentielle, une actualisation complète est effectuée, ce qui peut entraîner des coûts supplémentaires.
Prise en charge de l’actualisation incrémentielle de l’affichage matérialisé
Le tableau suivant répertorie la prise en charge de l’actualisation incrémentielle par mot clé ou clause SQL.
Important
Certains mots clés et clauses nécessitent que le suivi des lignes soit activé sur les sources de données interrogées. Consultez Utiliser le suivi des lignes pour les tables Delta.
Ces mots clés et clauses sont marqués avec une étoile (*) dans le tableau suivant.
Mot clé ou clause SQL | Prise en charge de l’actualisation incrémentielle |
---|---|
Expressions SELECT * |
Oui, les expressions incluant des fonctions intégrées déterministes et des fonctions définies par l’utilisateur immuables sont prises en charge. |
GROUP BY |
Oui |
WITH |
Oui, les expressions de table courantes sont prises en charge. |
UNION ALL * |
Oui |
FROM |
Les tables de base prises en charge comprennent les tables Delta, les vues matérialisées et les tables de streaming. |
WHERE , HAVING * |
Les clauses de filtre, telles que WHERE et HAVING , sont prises en charge. |
INNER JOIN * |
Oui |
LEFT OUTER JOIN * |
Oui |
FULL OUTER JOIN * |
Oui |
RIGHT OUTER JOIN * |
Oui |
OVER |
Oui. Les colonnes PARTITION_BY doivent être spécifiées pour l’incrémentialisation sur les fonctions de fenêtre. |
QUALIFY |
Oui |
EXPECTATIONS |
Non. Les vues matérialisées qui utilisent les expressions sont toujours entièrement actualisées. |
Remarque
Les fonctions non déterministes, comme par exemple CURRENT_TIMESTAMP
, ne sont pas prises en charge.
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 :
Technique | Actualisation incrémentielle ? | Description |
---|---|---|
FULL_RECOMPUTE |
Non | La vue matérialisée a été entièrement recalculée |
NO_OP |
Non applicable | La vue matérialisée n’a pas été mise à jour, car aucune modification de la table de base n’a été détectée. |
ROW_BASED ou PARTITION_OVERWRITE |
Oui | La vue matérialisée a été actualisée de manière incrémentielle à l’aide de la technique spécifiée. |
Pour déterminer la technique utilisée, interrogez le journal des événements Delta Live Tables où event_type
est 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.
Consultez Qu’est-ce que le journal des événements Delta Live Tables ?.