Qualità dei dati nelle viste lake materializzate

Nell'era dei Big Data, l'architettura medallion ha guadagnato importanza come un framework affidabile per la gestione e l'elaborazione dei dati in diverse fasi di perfezionamento, dai dati non elaborati ai set di dati altamente curati. Questo approccio strutturato non solo migliora la gestibilità dei dati, ma garantisce anche che la qualità dei dati venga mantenuta nel ciclo di vita dei dati.

Garantire la qualità dei dati è essenziale in ogni fase dell'architettura medallion, fondamentale per prendere decisioni aziendali informate. Una scarsa qualità dei dati può portare a intuizioni errate e inefficienze operative.

Questo articolo illustra come implementare la qualità dei dati nelle viste lake materializzate (MLV) in Microsoft Fabric.

Implementare la qualità dei dati

Quando si trasformano i dati, diventa importante comporre query precise per escludere dati di scarsa qualità dalle tabelle di origine, aumentando così il tempo di elaborazione e causando occasionalmente un errore dell'intera pipeline a causa di problemi di dati secondari.

La qualità dei dati viene mantenuta impostando vincoli durante la definizione degli MLV. Le viste materializzate all'interno di Fabric offrono un approccio per implementare controlli per la gestione della qualità dei dati in modo efficiente.

Quando vengono specificati vincoli, è possibile implementare le azioni seguenti.

FAIL : questa azione interrompe l'aggiornamento di un MLV se viene violato un vincolo, interrompendo la prima istanza. Si tratta del comportamento predefinito, anche senza specificare la parola chiave FAIL.

DROP : questa azione elabora mlv e rimuove i record che non soddisfano il vincolo specificato. Fornisce inoltre il conteggio dei record rimossi nella visualizzazione derivazione.

Annotazioni

Se entrambe le azioni DROP e FAIL sono definite in un MLV, l'azione FAIL ha la precedenza.

Definizione dei controlli di qualità dei dati in una vista lake materializzata

Nell'esempio seguente viene definito il vincolo cust_blank, che controlla se il customerName campo non è Null. Le righe con un valore Null customerName vengono escluse dall'elaborazione.

CREATE MATERIALIZED LAKE VIEW IF NOT EXISTS silver.customers_enriched  
(CONSTRAINT cust_blank CHECK (customerName is not null) on MISMATCH DROP)
AS
SELECT
    c.customerID,
    c.customerName,
    c.contact, 
    CASE  
       WHEN COUNT(o.orderID) OVER (PARTITION BY c.customerID) > 0 THEN TRUE  
       ELSE FALSE  
    END AS has_orders 
FROM bronze.customers c LEFT JOIN bronze.orders o 
ON c.customerID = o.customerID; 

Limitazioni correnti

• L'aggiornamento dei vincoli di qualità dei dati dopo la creazione di un MLV non è supportato. Per aggiornare i vincoli di qualità dei dati, è necessario ricreare il MLV.
• L'uso di funzioni e ricerca di criteri con operatori come LIKE o regex in condizione di vincolo è limitato.

Problemi noti

• La creazione e l'aggiornamento di un MLV con azione FAIL nel vincolo possono comportare un problema di "tabella differenziale non trovata". In questi casi, è consigliabile ricreare MLV ed evitare di usare l'azione FAIL.

Contenuti correlati

• Aggiornare le viste del lago materializzate