Condividi tramite

Aggiornamento incrementale per le viste materializzate

Questo articolo descrive la semantica e i requisiti per gli aggiornamenti incrementali nelle viste materializzate e identifica le operazioni, le parole chiave e le clausole SQL che supportano l'aggiornamento incrementale. Include una discussione sulle differenze tra gli aggiornamenti incrementali e completi e include raccomandazioni per la scelta tra viste materializzate e tabelle di streaming.

Quando si eseguono aggiornamenti delle viste materializzate usando le pipeline serverless, è possibile aggiornare in modo incrementale molte query. Gli aggiornamenti incrementali consentono di risparmiare sui costi di calcolo rilevando le modifiche nelle origini dati usate per definire la vista materializzata e calcolando in modo incrementale il risultato.

Gli aggiornamenti automatici sono eseguiti sulla computazione serverless

Le operazioni di aggiornamento vengono eseguite nelle pipeline serverless, indipendentemente dal fatto che l'operazione sia stata definita in Databricks SQL o con pipeline dichiarative di Lakeflow Spark.

Per le viste materializzate definite con Databricks SQL, l'area di lavoro non deve essere abilitata per le pipeline dichiarative di Lakeflow Spark serverless. L'aggiornamento userà automaticamente una pipeline serverless.

Per le viste materializzate definite usando le pipeline dichiarative di Lakeflow Spark, è necessario configurare la pipeline per l'uso serverless. Consulta Configurare una pipeline serverless.

Quali sono le semantiche di aggiornamento per le viste materializzate?

Le viste materializzate garantiscono risultati equivalenti alle query batch. Si consideri ad esempio la query di aggregazione seguente:

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

Quando si esegue questa query usando qualsiasi prodotto Azure Databricks, il risultato viene calcolato usando la semantica batch per aggregare tutti i record nell'origine transactions_table, ovvero tutti i dati di origine vengono analizzati e aggregati in un'unica operazione.

Note

Alcuni prodotti Azure Databricks memorizzano nella cache i risultati automaticamente all'interno o tra più sessioni se le origini dati non sono state modificate dopo l'esecuzione dell'ultima query. I comportamenti di memorizzazione nella cache automatica differiscono dalle viste materializzate.

L'esempio seguente trasforma questa query batch in una vista materializzata:

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

Quando si aggiorna una vista materializzata, il risultato calcolato è identico alla semantica della query batch. Questa query è un esempio di vista materializzata che può essere aggiornata in modo incrementale, vale a dire che l'operazione di aggiornamento tenta di elaborare solo dati nuovi o modificati nell'transactions_table di origine per calcolare i risultati.

Considerazioni sulle origini dati per le viste materializzate

Sebbene sia possibile definire una vista materializzata su qualsiasi origine dati, non tutte le origini dati sono adatte alle viste materializzate. Considerare le avvertenze e le raccomandazioni seguenti:

Important

Le viste materializzate tentano di aggiornare in modo incrementale i risultati per le operazioni supportate. Alcune modifiche apportate alle origini dati richiedono un aggiornamento completo.

Tutte le origini dati per le viste materializzate devono essere in grado di gestire la semantica di aggiornamento completo, anche se la query che definisce la vista materializzata supporta l'aggiornamento incrementale.

  • Per le query in cui un aggiornamento completo sarebbe troppo costoso, utilizzare le tabelle di streaming per garantire l'elaborazione una sola volta. Gli esempi includono tabelle molto grandi.
  • Non definire una vista materializzata su un'origine dati se i record devono essere elaborati una sola volta. Invece, usare le tabelle di streaming. Di seguito sono riportati alcuni esempi:
    • Origini dati che non mantengono la cronologia dei dati, ad esempio Kafka.
    • Operazioni di inserimento, ad esempio query che usano il caricatore automatico per inserire dati dall'archiviazione di oggetti cloud.
    • Qualsiasi origine dati in cui si prevede di eliminare o archiviare i dati dopo l'elaborazione, ma deve conservare le informazioni nelle tabelle downstream. Ad esempio, una tabella partizionata con data in cui si prevede di eliminare record precedenti a una determinata soglia.
  • Non tutte le origini dati supportano gli aggiornamenti incrementali. Le origini dati seguenti supportano l'aggiornamento incrementale:
    • Tabelle Delta, comprese quelle gestite da Unity Catalog e le tabelle esterne supportate da Delta Lake.
    • Viste materializzate.
    • Tabelle di streaming, comprese le destinazioni delle operazioni di AUTO CDC ... INTO.
  • Alcune operazioni di aggiornamento incrementale richiedono l'abilitazione del rilevamento delle righe nelle origini dati sottoposte a query. Il rilevamento delle righe è una funzionalità Delta Lake supportata solo dalle tabelle Delta, che includono viste materializzate, tabelle di streaming e tabelle gestite di Unity Catalog. Vedere Usare il rilevamento delle righe per le tabelle Delta.
  • Le origini dati con filtri di riga o maschere di colonna definite non supportano l'aggiornamento incrementale. Vedere Filtri di riga e maschere di colonna

Ottimizzare le viste materializzate

Per ottenere prestazioni ottimali, Databricks consiglia di abilitare le funzionalità seguenti in tutte le tabelle di origine delle viste materializzate:

È possibile impostare queste funzionalità durante la creazione o versioni successive con l'istruzione ALTER TABLE . Per esempio:

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

Tipi di aggiornamento per le viste materializzate

Quando viene aggiornata una vista materializzata, è possibile specificare un aggiornamento o un aggiornamento completo.

  • Un aggiornamento tenta di eseguire un aggiornamento incrementale, ma eseguirà una ricomputazione completa dei dati, se necessario. L'aggiornamento incrementale è disponibile solo quando il calcolo a cui si è connessi è serverless.
  • Un aggiornamento completo ricalcola sempre tutti gli input alla visualizzazione materializzata e reimposta tutti i checkpoint.

Per determinare il tipo di aggiornamento usato da un aggiornamento, vedere Determinare il tipo di aggiornamento di un aggiornamento.

Aggiornamento predefinito

Aggiornamento predefinito per una vista materializzata nei tentativi serverless di eseguire un aggiornamento incrementale. Un aggiornamento incrementale elabora le modifiche nei dati sottostanti dopo l'ultimo aggiornamento e quindi aggiunge tali dati alla tabella. A seconda delle tabelle di base e delle operazioni incluse, è possibile aggiornare in modo incrementale solo determinati tipi di viste materializzate. Se non è possibile un aggiornamento incrementale o l'ambiente di calcolo connesso è classico anziché serverless, viene eseguita una ricomputazione completa.

L'output di un aggiornamento incrementale e una ricomputazione completa sono gli stessi. Azure Databricks esegue un'analisi dei costi per scegliere l'opzione più economica tra un aggiornamento incrementale e una ricompilazione completa.

Solo le viste materializzate che vengono aggiornate tramite pipeline serverless possono utilizzare l'aggiornamento incrementale. Le viste materializzate che non usano pipeline serverless vengono sempre ricalcolate completamente.

Quando si creano viste materializzate con SQL Warehouse o Serverless Lakeflow Spark Declarative Pipelines, Azure Databricks le aggiorna in modo incrementale, se le interrogazioni sono supportate. Se una query usa espressioni non supportate, Azure Databricks esegue invece una ricompilazione completa, che può aumentare i costi.

Per determinare il tipo di aggiornamento usato da un aggiornamento, vedere Determinare il tipo di aggiornamento di un aggiornamento.

Aggiornamento completo

Un aggiornamento completo sovrascrive i risultati nella vista materializzata cancellando la tabella e i checkpoint e rielaborando tutti i dati disponibili nell'origine.

Per eseguire un aggiornamento completo sulle viste materializzate definite tramite Databricks SQL, usare la sintassi seguente:

REFRESH MATERIALIZED VIEW mv_name FULL

Per le viste materializzate definite in Pipeline dichiarative di Lakeflow Spark, è possibile scegliere di eseguire un aggiornamento completo nei set di dati selezionati o in tutti i set di dati in una pipeline. Vedi semantica di aggiornamento della pipeline.

Important

Quando un aggiornamento completo viene eseguito su un'origine dati in cui i record sono stati rimossi a causa della soglia di conservazione dei dati o dell'eliminazione manuale, i record rimossi non vengono riflessi nei risultati calcolati. Potrebbe non essere possibile recuperare i dati obsoleti se i dati non sono più disponibili nell'origine. Questo potrebbe anche modificare lo schema per le colonne che non esistono più nei dati di origine.

Supporto per l'aggiornamento incrementale della vista materializzata

La tabella seguente elenca il supporto per l'aggiornamento incrementale in base alla parola chiave o alla clausola SQL.

Important

Alcune parole chiave e clausole richiedono l'attivazione del tracciamento delle righe nelle origini dati interpellate. Vedere Usare il rilevamento delle righe per le tabelle Delta.

Queste parole chiave e clausole sono contrassegnate con una stella (*) nella tabella seguente.

Parola chiave o clausola SQL Supporto per l'aggiornamento incrementale
SELECT espressioni* Sì, sono supportate espressioni che includono funzioni predefinite deterministiche e funzioni definite dall'utente non modificabili.
GROUP BY Yes
WITH Sì, sono supportate espressioni di tabella comuni.
UNION ALL* Yes
FROM Le tabelle di base supportate includono tabelle Delta, viste materializzate e tabelle di streaming.
WHERE, HAVING* Le clausole di filtro, ad esempio WHERE e HAVING, sono supportate.
INNER JOIN* Yes
LEFT OUTER JOIN* Yes
FULL OUTER JOIN* Yes
RIGHT OUTER JOIN* Yes
OVER Yes. PARTITION_BY le colonne devono essere specificate per l'incrementalizzazione nelle funzioni di finestra.
QUALIFY Yes
EXPECTATIONS Sì, le viste materializzate che includono le aspettative possono essere aggiornate in modo incrementale. Tuttavia, l'aggiornamento incrementale non è supportato per i casi seguenti:
  • Quando la vista materializzata legge da una vista che contiene aspettative.
  • Quando la vista materializzata ha un'aspettativa DROP e include NOT NULL colonne nello schema.
Funzioni non deterministiche Le funzioni temporali non deterministiche sono supportate nelle WHERE clausole . Sono incluse funzioni come current_date(), current_timestamp()e now(). Altre funzioni non deterministiche non sono supportate.
Origini non Delta Fonti come volumi, ubicazioni esterne e cataloghi stranieri non sono supportate.

Determinare il tipo di aggiornamento di un aggiornamento

Per ottimizzare le prestazioni degli aggiornamenti delle viste materializzate, Azure Databricks usa un modello di costo per selezionare la tecnica usata per l'aggiornamento. La tabella seguente descrive queste tecniche:

Technique Aggiornamento incrementale? Description
FULL_RECOMPUTE No La vista materializzata è stata completamente ricompilata
NO_OP Non applicabile La vista materializzata non è stata aggiornata perché non sono state rilevate modifiche alla tabella di base.
Qualsiasi di:
  • ROW_BASED
  • PARTITION_OVERWRITE
  • WINDOW_FUNCTION
  • APPEND_ONLY
  • GROUP_AGGREGATE
  • GENERIC_AGGREGATE
 Yes La vista materializzata è stata aggiornata in modo incrementale usando la tecnica specificata.

Per determinare la tecnica usata, eseguire una query sul registro eventi di Lakeflow Spark Declarative Pipelines in cui event_type è planning_information:

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

Sostituire <fully-qualified-table-name> con il nome qualificato completo della vista materializzata, incluso il catalogo e lo schema.

Output di esempio per questo comando:

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

Vedere Registro eventi della pipeline.

  • Last updated on