Criteri di batch di inserimento

Panoramica

Si applica a: ✅Microsoft Fabric✅Azure Esplora dati

Durante il processo di inserimento in coda, il servizio ottimizza la velocità effettiva eseguendo l'invio in batch di piccoli blocchi di dati in ingresso prima dell'inserimento. L'invio in batch riduce le risorse utilizzate dal processo di inserimento in coda e non richiede risorse post-inserimento per ottimizzare le piccole partizioni di dati prodotte dall'inserimento non in batch.

Lo svantaggio di eseguire l'invio in batch prima dell'inserimento è il ritardo forzato. Di conseguenza, l'ora end-to-end dalla richiesta di inserimento dati fino a quando i dati pronti per la query non sono maggiori.

Quando si definiscono i IngestionBatching criteri, è necessario trovare un equilibrio tra l'ottimizzazione della velocità effettiva e il ritardo di tempo. Questo criterio si applica all'inserimento in coda. Definisce il ritardo forzato massimo consentito durante l'invio in batch di BLOB di piccole dimensioni. Per altre informazioni sull'uso dei comandi dei criteri di invio in batch e sull'ottimizzazione della velocità effettiva, vedere:

• Informazioni di riferimento sui comandi dei criteri di inserimento in batch
• Procedure consigliate per l'inserimento: ottimizzazione della velocità effettiva

Tenuta di un batch

Sono disponibili dimensioni ottimali di circa 1 GB di dati non compressi per l'inserimento bulk. L'inserimento di BLOB con molto meno dati non è ottimale, quindi nell'inserimento in coda il servizio eseguirà l'invio in batch di BLOB di piccole dimensioni.

L'elenco seguente mostra i trigger di base dei criteri di invio in batch per bloccare un batch. Un batch viene bloccato e inserito quando viene soddisfatta la prima condizione:

• Size: limite di dimensioni del batch raggiunto o superato
• Count: limite di numero di file batch raggiunto
• Time: l'ora di invio in batch è scaduta

I IngestionBatching criteri possono essere impostati su database o tabelle. I valori predefiniti sono i seguenti: 5 minuti di ritardo massimo, 500 elementi, dimensioni totali di 1 GB.

Importante

L'impatto dell'impostazione di questo criterio su valori molto piccoli è un aumento del COGS (costo dei beni venduti) e prestazioni ridotte. Inoltre, la riduzione dei valori dei criteri di invio in batch potrebbe comportare un aumento della latenza di inserimento end-to-end efficace, a causa del sovraccarico della gestione di più processi di inserimento in parallelo.

L'elenco seguente mostra le condizioni per bloccare i batch correlati all'inserimento di singoli BLOB. Un batch viene bloccato e inserito quando vengono soddisfatte le condizioni:

• SingleBlob_FlushImmediately: inserire un singolo BLOB perché 'FlushImmediately' è stato impostato
• SingleBlob_IngestIfNotExists: inserire un singolo BLOB perché 'IngestIfNotExists' è stato impostato
• SingleBlob_IngestByTag: inserire un singolo BLOB perché 'ingest-by' è stato impostato
• SingleBlob_SizeUnknown: inserire un singolo BLOB perché le dimensioni del BLOB sono sconosciute

Se la SystemFlush condizione è impostata, un batch verrà bloccato quando viene attivato lo scaricamento del sistema. Con il set di SystemFlush parametri, il sistema scarica i dati, ad esempio a causa del ridimensionamento del database o della reimpostazione interna dei componenti di sistema.

Impostazioni predefinite e limiti

Type	Proprietà	Predefiniti	Impostazione a bassa latenza	Valore minimo	Valore massimo
Numero di articoli	MaximumNumberOfItems	500	500	1	25,000
Dimensioni dei dati (MB)	MaximumRawDataSizeMB	1024	1024	100	4096
Time (TimeSpan)	MaximumBatchingTimeSpan	00:05:00	00:00:20 - 00:00:30	00:00:10	00:30:00

Il modo più efficace per controllare la latenza end-to-end usando i criteri di inserimento in batch consiste nel modificare il limite di tempo a livello di tabella o di database , in base al limite più elevato di requisiti di latenza. I criteri a livello di database influiscono su tutte le tabelle del database che non dispongono dei criteri a livello di tabella definiti e di qualsiasi tabella appena creata.

Importante

Se si imposta il limite di tempo dei criteri di inserimento in batch troppo basso nelle tabelle di ingresso ridotto, è possibile che vengano eseguite operazioni di calcolo e archiviazione aggiuntive quando il database tenta di ottimizzare le partizioni di dati appena create. Per altre informazioni sulle partizioni di dati, vedere extent.

Dimensioni dei dati batch

Le dimensioni dei dati dei criteri di invio in batch sono impostate per i dati non compressi. Per i file Parquet, AVRO e ORC, viene calcolata una stima in base alle dimensioni del file. Per i dati compressi, le dimensioni dei dati non compressi vengono valutate come segue in ordine decrescente di accuratezza:

1. Se le dimensioni non compresse vengono fornite nelle opzioni di origine di inserimento, viene usato tale valore.
2. Quando si inseriscono file locali tramite SDK, vengono esaminati gli archivi ZIP e i flussi gzip per valutare le dimensioni non elaborate.
3. Se le opzioni precedenti non forniscono dimensioni dei dati, un fattore viene applicato alle dimensioni dei dati compresse per stimare le dimensioni dei dati non compressi.

Latenze di invio in batch

Le latenze possono derivare da molte cause che possono essere risolte usando le impostazioni dei criteri di invio in batch.

Causa	Soluzione
La latenza dei dati corrisponde all'impostazionetime, con dati troppo piccoli per raggiungere il size limite o count	Ridurre il time limite
Invio in batch inefficiente a causa di un numero elevato di file molto piccoli	Aumentare le dimensioni dei file di origine. Se si usa il sink Kafka, configurarlo per l'invio di dati in blocchi di circa 100 KB o versione successiva. Se sono presenti molti file di piccole dimensioni, aumentare ( count fino a 2000) nei criteri di inserimento di database o tabelle.
Invio in batch di una grande quantità di dati non compressi	Questo è comune quando si inseriscono file Parquet. Ridurre size in modo incrementale i criteri di invio in batch di tabelle o database verso 250 MB e verificare la presenza di miglioramenti.
Backlog perché il database è ridimensionato	Accettare eventuali suggerimenti di Azure Advisor per aumentare o ridurre le prestazioni del database. In alternativa, ridimensionare manualmente il database per verificare se il backlog è chiuso. Se queste opzioni non funzionano, contattare il supporto tecnico per assistenza.