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.

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. Consulta Configurare una pipeline Serverless Delta Live Tables.

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.

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 REPLACE 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'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:

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 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 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. 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, incluse le tabelle gestite di Unity Catalog e le tabelle esterne basate su Delta Lake.
    • Viste materializzate.
    • Tabelle di streaming, comprese le destinazioni delle operazioni di APPLY CHANGES 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.

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 ad ogni aggiornamento, a seconda di come sono cambiate le 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. Consultare semantica di aggiornamento della Pipeline.

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à della tabella pipelines.reset.allowed 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 che vengono aggiornate tramite pipeline serverless possono utilizzare l'aggiornamento incrementale. Le viste materializzate che non utilizzano pipeline serverless vengono sempre aggiornate completamente.

Quando le viste materializzate vengono create utilizzando un SQL Warehouse o una pipeline di Delta Live Tables serverless, vengono aggiornate automaticamente in modo incrementale se le loro 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 vista 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. 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
WITH Sì, sono supportate espressioni di tabella comuni.
UNION ALL*
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*
LEFT OUTER JOIN*
FULL OUTER JOIN*
RIGHT OUTER JOIN*
OVER Sì. PARTITION_BY colonne devono essere specificate per l'incrementalizzazione nelle funzioni finestra.
QUALIFY
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 usa un modello di costo per selezionare la tecnica usata per l'aggiornamento. La tabella seguente descrive queste tecniche:

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 La vista materializzata è stata aggiornata in modo incrementale usando la tecnica specificata.

Per determinare la tecnica usata, eseguire una query nel registro eventi delta live tables in cui il 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.

Vedi Che cos'è il registro degli eventi Delta Live Tables?.