Condividi tramite

Aggiornamento incrementale per le viste materializzate

  • Articolo

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 in viste materializzate usando 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.

Le pipeline serverless sono necessarie per l'aggiornamento incrementale

L'aggiornamento incrementale per le viste materializzate richiede pipeline serverless.

Le operazioni di aggiornamento per le viste materializzate definite in Databricks SQL vengono sempre eseguite usando pipeline serverless.

Per le viste materializzate definite usando le pipeline di tabelle live Delta, è necessario configurare la pipeline per l'uso serverless. Vedere Configurare una pipeline di tabelle live Delta serverless.

Qual è la semantica 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.

Nota

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

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'origine transactions_table 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:

Importante

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 affidabili per 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 proibitivo, usare le tabelle di streaming per garantire l'elaborazione esattamente una 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. Usare invece 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, incluse le tabelle gestite di Unity Catalog e le tabelle esterne supportate da Delta Lake.
    • Viste materializzate.
    • Tabelle di streaming, incluse le destinazioni delle APPLY CHANGES INTO operazioni.
  • 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. Consultare Usare il rilevamento delle righe per le tabelle Delta.

Ottimizzare le viste materializzate

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

Tipi di aggiornamento per le viste materializzate

Gli aggiornamenti alle viste materializzate sono completi o incrementali. Per tutte le operazioni, i risultati di un aggiornamento incrementale e l'aggiornamento completo sono gli stessi. Azure Databricks esegue un'analisi dei costi per identificare se le modifiche alle origini dati richiedono un aggiornamento completo.

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 rielaborando tutti i dati disponibili nell'origine. Tutte le viste materializzate potrebbero essere completamente aggiornate in un determinato aggiornamento, a seconda della modalità di modifica delle origini dati.

Facoltativamente, è possibile forzare un aggiornamento completo. Per le viste materializzate definite con Databricks SQL, usare la sintassi seguente:

REFRESH MATERIALIZED VIEW mv_name FULL

Per le viste materializzate definite in una pipeline di tabelle live Delta, è possibile scegliere di eseguire un aggiornamento completo nei set di dati selezionati o in tutti i set di dati in una pipeline. Vedere Come le tabelle live Delta aggiornano tabelle e viste.

Importante

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.

Nota

Facoltativamente, è possibile disabilitare gli aggiornamenti completi in una tabella impostando la proprietà pipelines.reset.allowed table su false.

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.

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

Quando le viste materializzate vengono create usando una pipeline di SQL warehouse o tabelle live Deltaless serverless, vengono aggiornate automaticamente in modo incrementale se le query sono supportate. Se una query include espressioni non supportate per un aggiornamento incrementale, viene eseguito un aggiornamento completo, con conseguenti costi aggiuntivi.

Supporto per l'aggiornamento incrementale della visualizzazione materializzata

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

Importante

Alcune parole chiave e clausole richiedono l'abilitazione del rilevamento delle righe nelle origini dati sottoposte a query. Consultare 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 Sì
WITH Sì, le espressioni di tabella comuni sono supportate.
UNION ALL* Sì
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* Sì
LEFT OUTER JOIN* Sì
FULL OUTER JOIN* Sì
RIGHT OUTER JOIN* Sì
OVER Sì. Le colonne PARTITION_BY devono essere specificate per l'incrementalizzazione nelle funzioni finestra.
QUALIFY Sì
EXPECTATIONS No. Le viste materializzate che usano le aspettative vengono sempre aggiornate completamente.

Nota

Le funzioni non deterministiche, ad esempio CURRENT_TIMESTAMP, non sono supportate.

Determinare il tipo di aggiornamento di un aggiornamento

Per ottimizzare le prestazioni degli aggiornamenti delle viste materializzate, Azure Databricks utilizza un modello di costo per selezionare la tecnica utilizzata per l'aggiornamento. Queste tecnologie sono descritte nella tabella seguente:

Tecnica Aggiornamento incrementale? Descrizione
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.
ROW_BASED oppure PARTITION_OVERWRITE Sì La vista materializzata è stata aggiornata in modo incrementale usando la tecnica specificata.

Per determinare la tecnica usata, eseguire una query sul registro eventi delle tabelle Delta live dove 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 completo della vista materializzata, inclusi il catalogo e lo schema.

Si veda Che cos'è il registro eventi delle tabelle Delta Live?.