Criteri di batch di inserimento

  • Articolo

Panoramica

Durante il processo di inserimento in coda, il servizio ottimizza la velocità effettiva raggruppando blocchi di dati in ingresso di piccole dimensioni 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 partizioni di dati di piccole dimensioni 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 dei 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 per la 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 per la velocità effettiva, vedere:

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 meno dati è poco ottimale, quindi nell'inserimento in coda il servizio in batch eseguirà un batch di BLOB di piccole dimensioni.

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

  • Size: limite di dimensioni batch raggiunto o superato
  • Count: limite di numero di file batch raggiunto
  • Time: il tempo di invio in batch è scaduto

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

Importante

L'impatto dell'impostazione di questo criterio su valori molto piccoli è un aumento del COGS (costo delle merci vendute) del cluster 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é è stato impostato "ingest-by"
  • SingleBlob_SizeUnknown: inserire un singolo BLOB perché le dimensioni dei BLOB sono sconosciute

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

Impostazioni predefinite e limiti

Tipo Proprietà Predefinito Impostazione a bassa latenza Valore minimo Valore massimo
Numero di elementi MaximumNumberOfItems 500 500 1 25,000
Dimensioni dei dati (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Tempo (sec) MaximumBatchingTimeSpan 300 20 - 30 10 1800

Il modo più efficace per controllare la latenza end-to-end usando i criteri di invio batch di inserimento 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 batch troppo basso nelle tabelle con ingresso basso, è possibile che vengano eseguite operazioni di calcolo e archiviazione aggiuntive quando il cluster 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, viene applicato un fattore alla dimensione dei dati compressi per stimare le dimensioni dei dati non compressi.

Latenze 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
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 del database o della tabella.
Invio in batch di una grande quantità di dati non compressi Questo è comune quando si inseriscono file Parquet. Ridurre in modo incrementale size i criteri di invio in batch della tabella o del database verso 250 MB e verificare la disponibilità di miglioramenti.
Backlog perché il cluster è ridimensionato Accettare eventuali suggerimenti di Azure Advisor per aumentare o ridurre il numero di istanze del cluster. In alternativa, ridimensionare manualmente il cluster per verificare se il backlog è chiuso. Se queste opzioni non funzionano, contattare il supporto tecnico per assistenza.