Progettare e implementare una tabella temporale (cronologia) per registrare le modifiche nel tempo

Le pipeline di dati spesso richiedono il rilevamento non solo dei valori correnti, ma ogni modifica che si verifica nel tempo. Le tabelle temporali forniscono un meccanismo per registrare automaticamente le modifiche a livello di riga, abilitando query temporizzate e tracce di audit complete. A differenza delle dimensioni a modifica lenta che si concentrano sulla cronologia dei dati aziendali, le tabelle temporali acquisisce la cronologia tecnica per la tracciabilità operativa e il debug.

Comprendere le tabelle temporali e il tipo 2 SCD

Le tabelle temporali e le dimensioni a modifica lenta tipo 2 servono a scopi diversi, anche se entrambi tengono traccia delle modifiche cronologiche. Comprendere quando usare ogni approccio consente di progettare soluzioni appropriate.

ScD Type 2 tiene traccia delle modifiche apportate alle entità aziendali nel tempo per la creazione di report analitici. Quando un cliente passa da Seattle a Portland, si vuole attribuire le vendite cronologiche alla posizione del cliente al momento di ogni transazione. SCD Type 2 gestisce versioni significative per il business con date di inizio e fine esplicite.

Le tabelle temporali (cronologia) acquisisce le modifiche tecniche per le esigenze operative. Quando si risolve il motivo per cui i dati caricati in modo non corretto, è necessario visualizzare esattamente i valori esistenti in ogni momento, quali file sono stati elaborati e quando si sono verificate modifiche. Le tabelle temporali forniscono automaticamente questa funzionalità forense.

Prendere in considerazione l'uso di tabelle temporali quando è necessario:

• Eseguire il debug dei problemi di inserimento dati esaminando lo stato della tabella in timestamp specifici
• Controllare tutte le modifiche per i requisiti normativi o di conformità
• Riprodurre analisi o report da un punto specifico nel tempo
• Tenere traccia dei metadati operativi, ad esempio tempi di caricamento e informazioni sui file di origine

Abilitare il flusso di dati delle modifiche per il monitoraggio a livello di riga

Il feed di dati delle modifiche di Delta Lake acquisisce automaticamente ogni modifica a livello di riga. Se abilitata, i record di runtime modificano gli eventi con metadati che indicano se ogni riga è stata inserita, eliminata o aggiornata. Il feed di dati delle modifiche è disabilitato per impostazione predefinita, pertanto è necessario abilitarlo in modo esplicito nelle tabelle in cui è necessaria questa funzionalità.

Per abilitare il feed delle modifiche ai dati in una nuova tabella:

CREATE TABLE bronze.sales_transactions (
    transaction_id STRING,
    customer_id STRING,
    amount DECIMAL(10,2),
    transaction_date TIMESTAMP,
    source_file STRING,
    load_timestamp TIMESTAMP
)
USING DELTA
TBLPROPERTIES (delta.enableChangeDataFeed = true);

Per le tabelle esistenti, abilita il feed di modifica dei dati con l'istruzione ALTER TABLE.

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

Cronologia delle tabelle di query

Dopo aver abilitato il feed di dati delle modifiche, è possibile eseguire una query sulla cronologia delle modifiche per visualizzare esattamente le modifiche apportate. Il feed di dati delle modifiche aggiunge tre colonne di metadati ai dati:

Modifiche delle query all'interno di un intervallo di tempo specifico:

SELECT 
    transaction_id,
    amount,
    _change_type,
    _commit_version,
    _commit_timestamp
FROM table_changes('bronze.sales_transactions', '2026-01-01', '2026-01-31')
WHERE _change_type IN ('insert', 'update_postimage')
ORDER BY _commit_timestamp;

Questa query consente di identificare quando sono stati modificati record specifici, utili per il debug dei problemi di qualità dei dati.

Usare il viaggio nel tempo per le query a un momento specifico

Delta Lake gestisce un log delle transazioni che consente di eseguire query sui dati in qualsiasi momento della cronologia. Questa funzionalità supporta scenari di debug in cui è necessario confrontare i dati correnti con uno stato precedente.

Interrogare i dati a un timestamp specifico:

SELECT * FROM bronze.sales_transactions
TIMESTAMP AS OF '2026-01-15 14:30:00';

Interrogare i dati in una versione specifica:

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

Per visualizzare la cronologia completa delle operazioni eseguite in una tabella:

DESCRIBE HISTORY bronze.sales_transactions;

L'output della cronologia include il tipo di operazione, il timestamp, l'utente e le metriche dettagliate per ogni modifica.

Rendere persistente la cronologia delle modifiche per il controllo a lungo termine

Poiché il viaggio in tempo predefinito di Delta Lake presenta limiti di conservazione, è consigliabile rendere persistenti i dati delle modifiche in una tabella di cronologia separata per i requisiti di controllo a lungo termine. Questo approccio crea un record permanente di tutte le modifiche.

Usare Structured Streaming per acquisire continuamente le modifiche:

(spark.readStream
    .option("readChangeFeed", "true")
    .option("ignoreDeletes", "false")
    .table("bronze.sales_transactions")
    .writeStream
    .option("checkpointLocation", "/checkpoints/sales_history")
    .trigger(availableNow=True)
    .toTable("audit.sales_transactions_history")
)

L'opzione readChangeFeed indica a Spark di leggere il feed di dati delle modifiche, che restituisce eventi di modifica a livello di riga, inclusi inserimenti, aggiornamenti ed eliminazioni. L'opzione ignoreDeletes controlla se le operazioni di eliminazione sono incluse nel flusso. Impostando false si garantisce che i record di eliminazione vengano acquisiti nella tabella di cronologia, fornendo una tracciabilità completa di tutte le modifiche ai dati.

La tabella di cronologia contiene ogni evento di modifica con metadati completi, consentendo query nell'intera durata dei dati, non solo la finestra di conservazione.

Configurare la conservazione per i requisiti di conformità

Per le tabelle temporali che supportano le esigenze di conformità o normative, configurare le impostazioni di conservazione in base ai requisiti:

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (
    delta.logRetentionDuration = 'interval 90 days',
    delta.deletedFileRetentionDuration = 'interval 90 days'
);

Entrambe le proprietà devono essere impostate insieme. Controlla logRetentionDuration per quanto tempo vengono conservati i metadati della cronologia, mentre deletedFileRetentionDuration controlla per quanto tempo i file di dati eliminati vengono conservati prima VACUUM di rimuoverli.

I periodi di conservazione più lunghi aumentano i costi di archiviazione, ma forniscono un accesso prolungato ai dati storici e la disponibilità del flusso di modifiche dei dati per il controllo.

Con le tabelle temporali configurate correttamente, è possibile tracciare ogni modifica ai dati dall'inserimento attraverso la trasformazione, supportando sia il debug operativo che i requisiti di conformità alle normative.