Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Per migliorare le prestazioni e l'affidabilità, Dataflow Gen2 usa gli elementi di gestione temporanea per archiviare i dati intermedi durante la trasformazione dei dati. Questo articolo descrive quali elementi di staging sono, i modelli ELT che sbloccano una sola volta nella fase, fanno riferimento a molti modelli e come gestire i dati contenuti.
Che cosa sono gli elementi di staging?
Gli elementi di staging sono percorsi di archiviazione dati intermedi usati da Dataflow Gen2 per archiviare i dati durante la trasformazione dei dati. Questi elementi sono noti come "DataflowsStagingLakehouse" e "DataflowsStagingWarehouse". Gli elementi di staging vengono usati per archiviare i dati intermedi durante la trasformazione dei dati per migliorare le prestazioni. Questi elementi vengono creati automaticamente quando si crea il primo flusso di dati e vengono gestiti da Dataflow Gen2. Questi elementi sono nascosti dall'utente nell'area di lavoro, ma potrebbero essere visibili in altre esperienze, ad esempio Recupera dati o Esplora lakehouse. È consigliabile non accedere o modificare direttamente i dati negli elementi di staging perché potrebbero causare comportamenti imprevisti. Inoltre, l'archiviazione dei dati stessi negli elementi di staging non è supportata e potrebbe comportare la perdita di dati.
Modelli ELT: fase una sola volta, fare riferimento a molti
Oltre a fornire l'archiviazione intermedia, lo staging sblocca un insieme di modelli ELT basati su un singolo principio: memorizzare una volta, referenziare molte volte. Una query di origine viene contrassegnata come 'staged' in modo che l'output venga materializzato nell'archiviazione staging interna. Le query successive fanno quindi riferimento a quella query preparata invece di rileggere l'origine. Fast Copy è un acceleratore facoltativo che rende più veloce il popolamento della query a fasi, ma non è ciò che definisce il modello.
Il modello è importante perché una volta distribuiti i dati, le query downstream possono:
- Viene eseguita su una copia indicizzata e su cui è possibile eseguire query senza colpire di nuovo l'origine.
- Trasferisci filtri, join e aggregazioni all'esecuzione sull'endpoint SQL di staging anziché eseguirli nel motore di mashup.
- Diramare verso più trasformazioni o destinazioni parallele da un singolo risultato materializzato.
Casi d'uso comuni
I modelli seguenti vengono in genere sovrapposti a una query di origine a fasi.
| caso d'uso | Description |
|---|---|
| Trasformare i dati preparati in modelli analitici | Le query a cui si fa riferimento modellano i dati in tabelle dei fatti e delle dimensioni, riepiloghi, rollup o indicatori KPI tramite deduplicazione, raggruppamento e generazione di chiavi. |
| Pushdown delle risorse di calcolo piegate | Le query di riferimento scritte sui dati in staging aggregano i join, i filtri e le operazioni di raggruppamento nell'endpoint SQL di staging, trasferendo il calcolo al motore di data warehouse invece del motore mashup. Questo è spesso il più grande vantaggio in termini di prestazioni che l'ambiente di staging consente. |
| Ramo Qualità dei Dati e Audit | Le query a cui si fa riferimento convalidano o controllano i dati a fasi (controlli Null, convalida dei vincoli, conteggi di righe) senza rileggere l'origine. |
| Distribuzione a più destinazioni | Più query a cui viene fatto riferimento caricano una destinazione diversa dalla stessa origine di staging (ad esempio, una Lakehouse e un Warehouse). |
| Unione temporanea | Ogni origine viene inserita in staging nella propria query, quindi una query a cui viene fatto riferimento a valle unisce i risultati di staging, restituendo il join all'endpoint SQL di staging. |
Quando la gestione temporanea non è la scelta adatta
La gestione temporanea aggiunge costi di archiviazione e una scrittura aggiuntiva prima dell'esecuzione delle query downstream. È consigliabile ignorarlo quando:
- La tua trasformazione si integra già completamente nel sistema di origine, senza necessità di calcolo nel motore mashup.
- Il flusso di dati ha un unico output e nessuna diramazione, convalida o distribuzione downstream.
- La latenza della sorgente è il collo di bottiglia e la sorgente non può essere parallelizzata tramite staging.
Per altre indicazioni su quando abilitare o disabilitare la gestione temporanea, vedere Procedure consigliate per ottenere prestazioni ottimali con Dataflow Gen2.
Dati negli elementi di staging
Gli elementi di staging non sono progettati per l'accesso diretto da parte degli utenti. Dataflow Gen2 gestisce i dati negli elementi di staging e garantisce che i dati siano in uno stato coerente. L'accesso diretto ai dati negli elementi di staging non è supportato perché non può essere garantito che i dati siano in uno stato coerente. Se è necessario accedere ai dati negli elementi di staging, è possibile usare il connettore del flusso di dati in Power BI, Excel o altri flussi di dati.
Importante
L'API interna che gestisce i dati di staging ai consumer downstream (ad esempio modelli semantici o altri flussi di dati che usano il connettore Flussi di dati) può riscontrare timeout intermittenti. Questi timeout possono causare errori di aggiornamento durante il consumo di elementi, spesso manifestandosi con l'errore "La chiave non corrisponde ad alcuna riga nella tabella". Questo errore non indica un problema di dati. Significa che il back-end non è riuscito a recuperare i risultati della fase di staging in tempo.
Soluzione alternativa consigliata: Configurare una destinazione dati (Lakehouse o Warehouse) per il flusso di dati e aggiornare gli elementi downstream per la lettura da tale destinazione direttamente tramite il connettore Lakehouse o Warehouse. In questo modo viene ignorata l'API di gestione temporanea interna e viene migliorata l'affidabilità dell'aggiornamento.
Per altre informazioni, vedere Limitazioni di Data Factory.
La rimozione dei dati dagli elementi di staging può essere forzata da una delle azioni seguenti:
- Disabilitare lo staging nel flusso di dati e aggiornarlo (dopo 30 giorni i dati vengono rimossi tramite il processo di Garbage Collection).
- Eliminare il flusso di dati (rimuove direttamente i dati).
- Eliminare l'area di lavoro (elimina direttamente StagingLakehouse e StagingWarehouse).
Implicazioni relative ai costi della gestione temporanea
Staging Lakehouse e staging Warehouse archiviano i dati intermedi come parte dell'elaborazione del flusso di dati. L'archiviazione utilizzata da questi elementi di staging viene fatturata come parte dell'archiviazione OneLake. Ciò significa che i dati archiviati negli elementi di staging vengono conteggiati per il consumo complessivo di archiviazione di OneLake e i costi associati.
Per gestire in modo efficace i costi di archiviazione:
- Monitorare l'utilizzo dell'archiviazione di staging: tenere presente che i dati di staging si accumulano con ogni aggiornamento del dataflow fino a quando non vengono recuperati automaticamente o rimossi esplicitamente.
- Disabilitare lo staging quando non è necessario: se le trasformazioni si integrano nel sistema di origine, potrebbe non essere necessario abilitare lo staging. La disabilitazione della gestione temporanea riduce il consumo di archiviazione.
- Pulire i flussi di dati inutilizzati: l'eliminazione di flussi di dati non più necessari rimuove immediatamente i dati di staging associati.
- Prendere in considerazione la frequenza di aggiornamento: gli aggiornamenti frequenti con la gestione temporanea abilitata possono causare un consumo di archiviazione più elevato. Bilanciare i vantaggi delle prestazioni rispetto ai costi di archiviazione.
Per ulteriori informazioni sui prezzi dell'archiviazione di OneLake, vedere Prezzi di Microsoft Fabric.