Política de criação de lotes para ingestão

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer

Durante o processo de ingestão em fila, o serviço otimiza a taxa de transferência agrupando pequenos blocos de dados de entrada antes da ingestão. O processamento em lote reduz os recursos consumidos pelo processo de ingestão em fila e não requer recursos pós-ingestão para otimizar os pequenos fragmentos de dados produzidos pela ingestão sem lote.

A desvantagem de fazer o processamento em lote antes da ingestão é o atraso forçado. Portanto, o tempo de ponta a ponta desde a solicitação da ingestão de dados até os dados prontos para consulta é maior.

Ao definir a política, você precisará encontrar um equilíbrio entre a otimização da taxa de transferência e o IngestionBatching atraso de tempo. Esta política aplica-se à ingestão em fila. Ele define o atraso forçado máximo permitido ao agrupar pequenos blobs em lote. Para saber mais sobre como usar comandos de política de envio em lote e otimizar a taxa de transferência, consulte:

• Referência de comando da política de lote de ingestão
• Práticas recomendadas de ingestão - otimização para taxa de transferência

Selagem de um lote

Há um tamanho ideal de cerca de 1 GB de dados não compactados para ingestão em massa. A ingestão de blobs com muito menos dados é subótima, portanto, na ingestão em fila, o serviço agrupará pequenos blobs em lote.

A lista a seguir mostra os gatilhos básicos da política de lote para selar um lote. Um lote é selado e ingerido quando se verifica a primeira condição:

• Size: Limite de tamanho do lote atingido ou excedido
• Count: Limite de número de arquivos em lote atingido
• Time: O tempo de processamento em lote expirou

A IngestionBatching política pode ser definida em bancos de dados ou tabelas. Os valores padrão são os seguintes: tempo máximo de atraso de 5 minutos, 500 itens, tamanho total de 1 GB.

A lista a seguir mostra as condições para selar lotes relacionados à ingestão de um único blob. Um lote é selado e ingerido quando estiverem reunidas as seguintes condições:

• SingleBlob_FlushImmediately: Ingerir um único blob porque 'FlushImmediately' foi definido
• SingleBlob_IngestIfNotExists: Ingerir um único blob porque 'IngestIfNotExists' foi definido
• SingleBlob_IngestByTag: Ingerir um único blob porque 'ingest-by' foi definido
• SingleBlob_SizeUnknown: Ingerir um único blob porque o tamanho do blob é desconhecido

Se a SystemFlush condição estiver definida, um lote será selado quando uma descarga do sistema for acionada. Com o SystemFlush conjunto de parâmetros, o sistema libera os dados, por exemplo, devido ao dimensionamento do banco de dados ou à redefinição interna dos componentes do sistema.

Incumprimentos e limites

A maneira mais eficaz de controlar a latência de ponta a ponta usando a política de lote de ingestão é alterar seu limite de tempo no nível da tabela ou do banco de dados , de acordo com o limite superior dos requisitos de latência. Uma política de nível de banco de dados afeta todas as tabelas nesse banco de dados que não têm a política de nível de tabela definida e qualquer tabela recém-criada.

Tamanho dos dados do lote

O tamanho dos dados da política de lote é definido para dados não compactados. Para arquivos Parquet, AVRO e ORC, uma estimativa é calculada com base no tamanho do arquivo. Para dados compactados, o tamanho dos dados não compactados é avaliado da seguinte forma em ordem decrescente de precisão:

1. Se o tamanho não compactado for fornecido nas opções de origem de ingestão, esse valor será usado.
2. Ao ingerir arquivos locais usando SDKs, arquivos zip e fluxos gzip são inspecionados para avaliar seu tamanho bruto.
3. Se as opções anteriores não fornecerem um tamanho de dados, um fator será aplicado ao tamanho dos dados compactados para estimar o tamanho dos dados não compactados.

Latências de lote

As latências podem resultar de muitas causas que podem ser resolvidas usando configurações de política de lotes.