Aggiornamento completo per le tabelle di streaming

Un aggiornamento completo di una tabella di streaming elimina tutti i dati e i metadati esistenti e riavvia il flusso dall'inizio. In particolare, tronca la tabella di streaming, rimuove tutti i dati del checkpoint e riavvia il processo di streaming con nuovi checkpoint per ogni flusso che scrive nella tabella. Questa pagina descrive quando potrebbe essere necessario eseguire un aggiornamento completo e l'impatto dell'esecuzione di un aggiornamento completo. Include anche le procedure consigliate per gli aggiornamenti completi.

Per indicazioni su come attivare un aggiornamento completo, vedere Eseguire un aggiornamento della pipeline.

Impatto sulle origini dati

Un aggiornamento completo rimuove tutti i dati esistenti dalla tabella di streaming. Se l'origine dati ha limiti di conservazione, ad esempio gli argomenti Kafka con brevi periodi di conservazione, alcuni dati cronologici potrebbero diventare irreversibili dopo un aggiornamento completo.

Ad esempio, se l'origine è Kafka con conservazione di 24 ore ed è stato eseguito un aggiornamento completo dopo tale finestra, i messaggi meno recenti non sono più disponibili e non possono essere rielaborati.

Annotazioni

Gli aggiornamenti completi non sono consigliati per carichi di lavoro di streaming con volumi elevati o quando la conservazione upstream impedisce la riproduzione dei dati cronologici.

Se la tabella di streaming include tabelle downstream dipendenti, la pipeline fallisce finché tali tabelle non vengono completamente aggiornate, a meno che la tabella di streaming non abbia skipChangeCommits abilitato. Anche le viste materializzate downstream devono essere completamente aggiornate.

Quando eseguire un aggiornamento completo

Gli aggiornamenti completi nelle pipeline dichiarative di Lakeflow Spark devono essere attivati in modo esplicito. È possibile eseguire un aggiornamento completo facendo clic su Aggiornamento completo nell'interfaccia utente della pipeline o abilitando l'aggiornamento automatico in Lakeflow Connect.

Un aggiornamento completo è consigliato quando le modifiche impediscono a una query di streaming di riprendere in modo sicuro dal checkpoint esistente o quando i dati elaborati in precedenza non sarebbero coerenti con la logica aggiornata, lo schema o la configurazione dell'origine. Le sezioni seguenti descrivono scenari comuni.

Modifiche agli schemi

Le modifiche dello schema seguenti nella tabella di destinazione non sono compatibili con le versioni precedenti e richiedono un aggiornamento completo:

• Ridenominazione delle colonne senza la modalità di mappatura delle colonne abilitata.
• Modifica delle colonne di deduplicazione.
• Modifica dei tipi di dati delle colonne, tra cui:
  • Restringimento del tipo (ad esempio, BIGINT → INT o DOUBLE → FLOAT).
  • Modifiche di tipo non compatibili , ad esempio STRING → INT.
• Eliminazione rigida delle colonne dallo schema della tabella.

Per questi tipi di modifiche allo schema, Databricks consiglia di creare una nuova colonna con lo schema o il nome desiderato, quindi usando una visualizzazione nella parte superiore della tabella di streaming per unire i valori precedenti e nuovi.

Modifiche al layout dei dati fisici

Le modifiche al layout dei dati fisici seguenti richiedono un aggiornamento completo:

• Migrazione dal partizionamento legacy a un nuovo schema di clustering.

Modifiche alla sorgente upstream

Le seguenti modifiche alla sorgente upstream richiedono un aggiornamento completo:

• Modifica delle tabelle di origine lette dalla query di streaming.
• Passaggio da un tipo di origine all'altro( ad esempio, da Kafka a Delta o da Auto Loader a Kafka).
• Modifica dei percorsi di origine, ad esempio percorsi di tabella o sottoscrizioni di argomenti Kafka.
• Eliminazione e ricreazione di una tabella Delta di origine, anche quando lo schema rimane invariato.

Modifiche all'elaborazione con stato

Le modifiche all'elaborazione con stato seguenti richiedono un aggiornamento completo:

• Modifica delle chiavi di raggruppamento delle aggregazioni o delle funzioni di aggregazione.
• Aggiunta o rimozione di aggregazioni.
• Modifica delle chiavi di join o dei tipi di join.
• Aggiunta o rimozione di join.
• Modifica delle colonne di deduplicazione o della logica di deduplicazione.

Problemi di continuità dei dati

Un aggiornamento completo può essere necessario quando la continuità dei dati viene compromessa:

• I log CDC non sono più disponibili a causa della scadenza della conservazione.
• Danneggiamento o cancellazione della directory del punto di controllo di streaming.
• Danneggiamento o perdita di file di monitoraggio dello schema o file relativi al percorso dello schema.

Per ulteriori informazioni sul ripristino di una pipeline a seguito di un errore di checkpoint nello streaming, consultare Recuperare una pipeline da un errore di checkpoint nello streaming.

Limitazioni

Le limitazioni seguenti si applicano agli aggiornamenti completi. Per informazioni utili a lavorare entro questi limiti, vedere Procedure consigliate.

• Un aggiornamento completo non elabora nuovamente i dati a meno che l'origine non mantenga il set di dati cronologico completo.
• I set di dati di grandi dimensioni possono rendere gli aggiornamenti completi costosi e dispendiosi in termini di tempo.
• I consumatori a valle che dipendono dalla tabella potrebbero fallire o fornire risultati incompleti fino al completamento dell'aggiornamento.

Procedure consigliate

Situazione	Procedure consigliate
Progettare per la stabilità	Pianificare lo schema per evitare modifiche che richiedono un aggiornamento completo. L'aggiunta di colonne è in genere sicura, mentre la modifica di colonne o schemi di partizionamento esistenti richiede in genere la ricompilazione della tabella.
Trasmetti da fonti con periodi di conservazione brevi	Lo streaming da origini, ad esempio un argomento Kafka, che non dispone di lunghi periodi di conservazione significa che un aggiornamento completo perde i dati non ancora presenti nell'origine. Per evitare di perdere dati cronologici, trasmettere i dati non elaborati in una tabella di streaming (una tabella bronze nell'architettura medallion). Usare tipi di colonna flessibili (ad esempio variant o string), per evitare che questa tabella richieda un aggiornamento completo se i dati upstream cambiano. Questa tabella può archiviare i dati cronologici e essere usata dalle tabelle di streaming downstream (che possono avere tipi più rigorosi o altre modifiche strutturali). Se le tabelle downstream richiedono un aggiornamento completo, questa tabella include dati cronologici, senza richiedere un aggiornamento completo.
Prendere in considerazione le alternative prima di eseguire un aggiornamento completo	Le opzioni alternative includono: Se si modifica l'origine di un flusso, è consigliabile creare un nuovo flusso anziché aggiornare il flusso esistente di una tabella di streaming. Ciò mantiene i dati esistenti nella tabella, ma può scrivere dati duplicati perché il nuovo flusso ha un nuovo checkpoint. In alternativa, è possibile reimpostare il checkpoint, ma ciò può causare la scrittura di dati duplicati nella tabella di destinazione. Se nessuna delle opzioni è accettabile, è consigliabile creare una nuova tabella di streaming e usare una vista per unire le tabelle di streaming precedenti e nuove.
Quando è necessario un aggiornamento completo	Seguire queste procedure consigliate quando è necessario un aggiornamento completo: Testare l'operazione in un ambiente di sviluppo o pre-produzione. Annotare le dipendenze a valle interessate. Pianificare l'aggiornamento durante una finestra di manutenzione per ridurre al minimo l'impatto sui carichi di lavoro di produzione. Assicurarsi che il sistema di origine mantenga dati cronologici sufficienti per riprodurre il flusso.

Per riempire i dati dopo un aggiornamento completo, è possibile creare un append onceflusso. Esegue un singolo backfill senza continuare l'esecuzione dopo il primo backfill. Il codice rimane nella pipeline e, se la pipeline viene aggiornata di nuovo, il riempimento viene rieseguito.