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 |
Sì |
WITH |
Sì, sono supportate espressioni di tabella comuni. |
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ì.
PARTITION_BY colonne 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 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 |
Sì | 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.