Refresh incrémentiel pour les vues matérialisées
L'incrémentielle refresh sur une vue matérialisée détecte les modifications dans les données source et recalcule uniquement les résultats affectés, plutôt que de recalculer la query entière. Les sections suivantes couvrent la sémantique, les exigences, les Opérations SQL prises en charge et comment choisir entre les vues matérialisées et les tables de streaming.
Pour un aperçu du fonctionnement des refresh de pipeline, consultez Comment les pipelines refresh ?.
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. Incremental refreshes save compute costs by detecting changes in the data sources used to define the materialized view and incrementally computing the result.
Les rafraîchissements s'exécutent sur un compute serverless
Les opérations de refresh sont exécutées sur des pipelines serverless, que l'opération ait été définie comme autonome ou avec des Lakeflow Pipelines.
Pour les vues matérialisées autonomes, votre Workspace n'a pas besoin d'être activé pour les pipelines Serverless LakeFlow Pipelines. Le refresh utilise automatiquement un pipeline serverless.
Pour les vues matérialisées définies à l'aide de Lakeflow pipelines, vous devez configurer le pipeline pour utiliser le serverless. Voir configurer un pipeline serverless.
Quelle est la sémantique de refresh pour les vues matérialisées ?
Les vues matérialisées garantissent des résultats équivalents aux requêtes par batch. Par exemple, considérez la query 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 query à l'aide d'un produit Databricks, le résultat est calculé à l'aide de la sémantique de traitement par batch pour agréger tous les enregistrements dans 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.
Certains produits Databricks mettent en cache les résultats automatiquement au sein des sessions ou entre les sessions si les sources de données n'ont pas changé après l'exécution de la dernière query. Les comportements de mise en cache automatique diffèrent des vues matérialisées.
L'exemple suivant transforme cette query batch en une vue matérialisée :
- SQL
- Python
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
@dp.materialized_view()
def transaction_summary():
return (spark.read.table("transactions_table")
.groupBy("account_id")
.agg(
count("*").alias("txn_count"),
sum("txn_amount").alias("account_revenue")
)
)
Lorsque vous refresh une vue matérialisée, le résultat calculé est identique à la sémantique de la query batch. Cette requête est un exemple de vue matérialisée qui peut être refreshée de manière incrémentielle, ce qui signifie que l'opération de refresh s'efforce de traiter uniquement les données nouvelles ou modifiées dans la source transactions_table pour calculer les résultats.
Considérations relatives aux sources 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 bien adaptées aux vues matérialisées. Prenez en compte les mises en garde et les recommandations suivantes :
Les vues matérialisées tentent de leur mieux d'incrémentiellement refresh les résultats pour les opérations prises en charge. Certains changements dans les sources de données nécessitent un refresh. Vous pouvez définir une politique de refresh qui échoue plutôt que d'exécuter un refresh complet.
Toutes les sources de données pour les vues matérialisées doivent prendre en charge la sémantique de refresh complète, même si la query qui définit la vue matérialisée prend en charge le refresh incrémentiel.
-
Pour les queries où un refresh complet serait trop coûteux, utilisez des tables de streaming pour garantir un traitement « exactement une fois ». Parmi les exemples figurent de très grandes tables.
-
Ne définissez pas de vue matérialisée 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 streaming. Exemples :
- Sources de données qui ne conservent pas l'historique des données, telles que Kafka.
- Opérations d'ingestion, telles que les query qui utilisent Auto Loader pour ingérer des données depuis le stockage d'objets cloud.
- Toute source de données où vous prévoyez de supprimer ou d'archiver les données après traitement, mais où vous devez conserver les informations dans les tables en aval. Par exemple, une table partitionnée par date où vous prévoyez de supprimer les enregistrements plus anciens qu'un certain threshold.
-
Toutes les sources de données ne prennent pas en charge les refresh incrémentiel. Les sources de données suivantes prennent en charge le refresh incrémentiel :
- Les tables Delta, y compris les tables gérées par Unity Catalog et les tables externes prises en charge par Delta Lake.
- Vues matérialisées.
- Tables de streaming, y compris les cibles des
AUTO CDC ... INTOopérations. - Tables Iceberg gérées par Unity Catalog (v2 et v3). Iceberg v3 est recommandé pour une meilleure prise en charge du refresh incrémentiel. Voir Utiliser les fonctionnalités Apache Iceberg v3. Les tables Iceberg étrangères ne sont pas prises en charge.
-
Certaines opérations de refresh incrémentiel nécessitent que le suivi des lignes soit activé sur les sources de données interrogées. Le suivi des lignes est une fonctionnalité de Delta Lake prise en charge uniquement par les tables Delta, qui incluent les vues matérialisées, les tables de streaming et les tables gérées par Unity Catalog. Consultez Suivi des lignes dans Databricks.
-
Les sources de données avec des filtres de lignes ou des masques de colonnes définis ne prennent pas en charge le refresh incrémentiel. Voir Filtres de lignes et masques de colonne
Optimiser les vues matérialisées
Pour obtenir les meilleures performances, Databricks recommande d’activer les fonctionnalités suivantes sur toutes les tables sources de vues matérialisées :
Vous pouvez définir ces fonctionnalités lors de la création ou ultérieurement à l'aide de l'instruction ALTER TABLE (exécutée à partir de Databricks SQL). Par exemple :
ALTER TABLE <table-name> SET TBLPROPERTIES (
delta.enableDeletionVectors = true,
delta.enableRowTracking = true,
delta.enableChangeDataFeed = true);
Types de refresh pour les vues matérialisées
Lorsqu'une vue matérialisée est mise à jour, vous pouvez spécifier un refresh ou un refresh complet.
- Un refresh tente d'effectuer un refresh incrémentiel, mais effectuera un recalcul complet des données si nécessaire. Le refresh incrémentiel n'est disponible que lorsque le compute auquel vous êtes connecté est serverless.
- Un refresh complet recalcule toujours toutes les entrées de la vue matérialisée et réinitialise tous les points de contrôle.
Pour déterminer le type de refresh utilisé par une mise à jour, consultez Déterminer le type de refresh d'une mise à jour.
default refresh
Le refresh default pour une vue matérialisée sur Serverless tente d'effectuer un refresh incrémentiel . Une refresh incrémentielle traite les modifications des données sous-jacentes après la dernière refresh, 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 incémentielle. Si un incremental refresh n'est pas possible ou si le compute connecté est classique au lieu de Serverless, un recalcul complet est effectué.
Databricks applique une refresh complète ou incrémentielle. La décision est basée sur l'option la plus rentable et si une query prend en charge l'incrémentielle refresh. Pour modifier ce comportement, voir Politique de refresh.
Le résultat d'un refresh incrémentiel et d'un recalcul complet est le même. Databricks effectue une analyse des coûts pour choisir l'option la moins chère entre un refresh incrémentiel et un recalcul complet.
Seules les vues matérialisées mises à jour à l'aide de pipelines Serverless peuvent utiliser la refresh incrémentielle. Les vues matérialisées qui n'utilisent pas de pipelines Serverless sont toujours entièrement recalculées.
Lorsque vous créez des vues matérialisées avec un SQL warehouse ou des pipelines Lakeflow serverless, Databricks les refresh de manière incrémentielle si leurs requêtes sont prises en charge. Si une query utilise des expressions non prises en charge, Databricks exécute plutôt un recalcul complet, ce qui peut augmenter les coûts.
Pour déterminer le type de refresh utilisé par une mise à jour, consultez Déterminer le type de refresh d'une mise à jour.
Full refresh complète
Une full refresh écrase les résultats de la vue matérialisée en effaçant la table et les points de contrôle, et en retraitant toutes les données disponibles dans la source.
Pour effectuer un refresh complet 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 LakeFlow Pipelines, vous pouvez choisir d'effectuer un refresh complet sur des datasets sélectionnés ou sur tous les datasets d'un pipeline. Consultez les sémantiques de refresh des pipelines.
Lorsqu'un refresh complet est exécuté sur une source de données où des enregistrements ont été supprimés en raison du threshold de conservation des données ou d'une suppression manuelle, les enregistrements supprimés ne sont pas reflétés dans les résultats compute. Vous pourriez ne pas être en mesure de récupérer d'anciennes données si les données ne sont plus disponibles à la source. Cela pourrait également modifier le schéma des colonnes qui n'existent plus dans les données source.
Prise en charge du refresh incrémentiel de la vue matérialisée
Le tableau suivant liste la prise en charge du refresh incrémental par mot-clé ou clause SQL. Pour tester une query spécifique pour son incrémentalité, vous pouvez utiliser EXPLAIN CREATE MATERIALIZED VIEW.
Certains mots-clés et clauses nécessitent que le suivi des lignes soit activé sur les sources de données interrogées. Voir suivi des lignes dans Databricks.
Ces mots-clés et clauses sont marqués d'un astérisque (*) dans le tableau suivant.
Mot-clé ou clause SQL | Équivalent du dataframe PySpark | Prise en charge de l'incremental refresh |
|---|---|---|
|
| Oui, les expressions, y compris les fonctions intégrées déterministes et les fonctions définies par l'utilisateur (UDF) immuables, sont prises en charge. |
|
| Oui |
| Chaînage de variables DataFrame. | Oui, les expressions de table communes sont prises en charge. |
| N/A | Non. Les vues matérialisées qui utilisent des CTE récursifs ne sont pas éligibles au refresh incrémentiel et reviennent à un recalcul complet. |
|
| Oui |
|
| Les tables de base prises en charge incluent les tables Delta, les tables Iceberg gérées par Unity Catalog, les vues matérialisées et les tables de streaming. |
|
| Les clauses de filtre telles que |
|
| Oui |
|
| Oui |
|
| Oui |
|
| Oui |
|
| Oui. Les colonnes |
|
| Oui |
|
| Oui, les vues matérialisées qui incluent des attentes peuvent être refresh de manière incrémentielle. Cependant, le refresh incrémentiel n'est pas pris en charge dans les cas suivants :
|
UDFs | UDFs | Databricks tente de détecter lorsqu'une UDF modifie son comportement et d'effectuer un refresh complet. Cependant, les UDF qui appellent d'autres fonctions ou bibliothèques peuvent modifier le comportement d'une manière que Databricks ne reconnaît pas. Lorsque le comportement d'une UDF change, il est de votre responsabilité d'effectuer un refresh complet pour appliquer l'UDF mise à jour à la vue matérialisée complète. |
Fonctions non déterministes | Fonctions non déterministes | Les fonctions temporelles non déterministes sont prises en charge dans les clauses |
Sources non prises en charge | Sources non prises en charge | Les sources telles que les volumes, les emplacements externes et les catalogues étrangers ne sont pas prises en charge. Les tables Iceberg étrangères ne sont pas prises en charge. Les tables Iceberg gérées par Unity Catalog sont prises en charge. |
Insights sur l'incrémentalisation
Lorsque vous développez un pipeline dans l'éditeur de pipeline ou surveillez une mise à jour de pipeline, le panneau Tables inclut une colonne Incrémentation indiquant comment chaque vue matérialisée a été traitée lors de la dernière mise à jour :
Statut | Description |
|---|---|
Incrémentiel | La vue matérialisée a été actualisée de manière incrémentielle. |
Nouveau calcul complet | La vue matérialisée a été entièrement recalculée. |
Aucune modification | Aucune modification des données sources n'a été détectée, la vue matérialisée n'a donc pas été mise à jour. |
When Databricks detects a problem that prevented a materialized view from incrementally refreshing, or that might prevent it in a future update, and has a recommended fix, a 
insight appears next to the status. Sélectionnez-le pour ouvrir le panneau Problèmes filtré sur cette vue matérialisée. Chaque insight explique la cause et recommande une correction. Les correctifs courants incluent :
- Activez le suivi des lignes ou les vecteurs de suppression sur les tables source. Consultez Optimiser les vues matérialisées.
- Réécrivez un opérateur non pris en charge dans la définition de la vue matérialisée. Voir Prise en charge de l'incrémentielle des vues matérialisées refresh.
- Configurez le pipeline pour utiliser le compute serverless.
Des insights peuvent apparaître même lorsque le statut est Aucun changement , afin que vous puissiez corriger les problèmes avant qu'ils n'affectent une mise à jour. Un insight peut également vous mener à la ligne pertinente dans votre code source. Depuis l'interface utilisateur de monitoring, cela ouvre l'éditeur de pipeline à cette ligne. Les insights couvrent les problèmes courants qui empêchent le refresh incrémentiel. L'absence d'insight ne garantit pas qu'une vue matérialisée puisse se refresh de manière incrémentielle.
Pour obtenir les mêmes informations par programmation, ou pour examiner les mises à jour antérieures, interrogez les Logs d'événements comme décrit dans la section suivante.
Déterminer le type de refresh d’une mise à jour
Pour optimiser les performances des vues matérialisées refreshes, Databricks utilise un modèle de coût pour sélectionner la technique utilisée pour le refresh. Le tableau suivant décrit ces techniques :
Technique | Refresh incrémentiel ? | Description |
|---|---|---|
| Non | La vue matérialisée a été entièrement recalculée |
| 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. |
L'un des éléments suivants :
| Oui | La vue matérialisée a été actualisée de manière incrémentielle à l'aide de la technique spécifiée. |
Voir aussi Politique de refresh.
Pour déterminer la technique utilisée, interrogez le journal des événements du pipeline Lakeflow 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 entièrement qualifié de la vue matérialisée, y compris le catalogue et le schéma.
Exemple de sortie pour cette commande :
Horodatage | Message |
|---|---|
|
|
Consulter le Pipeline event Logs.
Politique de refresh
Par défaut, Databricks sélectionne automatiquement la stratégie de refresh la plus rentable (incrémentielle ou complète) en fonction de la structure de la query, du volume de modifications des données et de la modélisation des coûts du système. Ce comportement par default optimise les performances de refresh sans nécessiter de configuration manuelle.
Certaines charges de travail, cependant, nécessitent un comportement de refresh plus prévisible ou explicitement contrôlé. Pour prendre en charge ces scénarios, vous pouvez spécifier un REFRESH POLICY dans la définition de la vue matérialisée. Une politique de refresh contrôle si Databricks effectue un refresh incrémentiel, quand elle peut revenir à un refresh complet, et si un refresh doit échouer au lieu d'effectuer un recalcul complet.
Avec REFRESH POLICY, vous pouvez configurer le système pour :
AUTO(default) - Utiliser la sélection automatique, basée sur les coûts. Databricks choisit la refresh incrémentielle ou complète en fonction de l'efficacité et des capacités de query. Recommandé pour la plupart des utilisateurs.INCREMENTAL- Préférez le refresh incrémentiel. Databricks effectue une refresh incrémentielle chaque fois que possible. Il revient à un full refresh si le plan de query ne prend plus en charge l'incremental refresh.INCREMENTAL STRICT- Exiger strictement un refresh incrémentiel. Le refresh incrémentiel est requis lors d'une opération normale. Si l'incrémentalisation n'est pas possible, l'opération de refresh ou de création échoue.FULL- Toujours effectuer des actualisations complètes. Databricks n'effectue jamais de refresh incrémentiel, même lorsque la query peut être incrémentée.
- SQL
- Python
-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;
from pyspark import pipelines as dp
@dp.materialized_view(
refresh_policy = 'incremental_strict'
)
def my_mv():
return spark.read("main.default.source_table")
La politique de refresh optimale dépend des caractéristiques de votre charge de travail :
AUTOconvient à la plupart des charges de travail. Il équilibre le coût et les performances et s'adapte automatiquement lorsque le comportement de la query change.INCREMENTALest utile lorsque l'incrémentielle refresh offre des avantages, mais il est acceptable que Databricks effectue des complètes refresh lorsque l'incrémentalisation devient temporairement indisponible (par exemple, lorsque le suivi des lignes sur une table source est désactivé).INCREMENTAL STRICTdoit être utilisé lorsque le refresh incrémentiel est nécessaire pour satisfaire les contraintes de coût, de performance ou de SLA, et que les refresh complets inattendus sont inacceptables. Cette politique est recommandée lorsque les utilisateurs préfèrent que la mise à jour échoue, ce qui leur permet de déboguer le problème plutôt que de procéder à un full refresh.FULLest approprié lorsque le refresh incrémentiel apporte peu d'avantages, que le dataset est petit, ou que la structure de la query change fréquemment de manière à empêcher l'incrémentation.
Pour plus de détails et la syntaxe, veuillez consulter la clause REFRESH POLICY (pipelines), ou si le dataset est défini dans Databricks SQL, la clause REFRESH POLICY.