Política de envio em lote de ingestão

Visão geral

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

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

A desvantagem de fazer lotes 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 IngestionBatching política, você precisará encontrar um equilíbrio entre a otimização da taxa de transferência e o atraso. Essa política se aplica à ingestão na fila. Ele define o atraso forçado máximo permitido ao agrupar pequenos blobs. Para saber mais sobre como usar comandos de política de envio em lote e otimizar a taxa de transferência, consulte:

• Referência do comando de política de envio em lote de ingestão
• Práticas recomendadas de ingestão - otimizando a taxa de transferência

Selando 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 é abaixo do ideal, portanto, na ingestão enfileirada, o serviço agrupará pequenos blobs em lote.

A lista a seguir mostra os gatilhos básicos da política de envio em lote para lacrar um lote. Um lote é lacrado e ingerido quando a primeira condição é atendida:

• Size: Limite de tamanho de lote atingido ou excedido
• Count: Limite de número de arquivos em lote atingido
• Time: O tempo de envio 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.

Importante

O impacto de definir essa política para valores muito pequenos é um aumento no CPV (custo dos produtos vendidos) e desempenho reduzido. Além disso, a redução dos valores da política de envio em lote pode resultar em maior latência de ingestão de ponta a ponta efetiva, devido à sobrecarga de gerenciar vários processos de ingestão em paralelo.

A lista a seguir mostra as condições para selar lotes relacionados à ingestão de blob único. Um lote é lacrado e ingerido quando as condições são atendidas:

• 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 for definida, um lote será selado quando uma liberação 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.

Padrões e limites

Tipo	Propriedade	Padrão	Configuração de baixa latência	Valor mínimo	Valor máximo
Número de itens	MáximoNúmeroDeItens	500	500	1	25,000
Tamanho dos dados (MB)	MáximoRawDataSizeMB	1024	1024	100	4096
Tempo (TimeSpan)	MaximumBatchingTimeSpan	00:05:00	00:00:20 - 00:00:30	00:00:10	00:30:00

A maneira mais eficaz de controlar a latência de ponta a ponta usando a política de envio em 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.

Importante

Se você definir o limite de tempo da política de Envio em Lote de Ingestão muito baixo em tabelas de baixa entrada, poderá incorrer em trabalho adicional de computação e armazenamento à medida que o banco de dados tenta otimizar os fragmentos de dados recém-criados. Para obter mais informações sobre fragmentos de dados, consulte extensões.

Tamanho dos dados do lote

O tamanho dos dados da política de envio em 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 descompactados é avaliado da seguinte maneira em ordem decrescente de precisão:

1. Se o tamanho descompactado for fornecido nas opções de origem de assimilação, esse valor será usado.
2. Ao ingerir arquivos locais usando SDKs, os arquivos zip e os 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 envio em lote

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

Causa	Solução
A latência de dados corresponde à time configuração, com poucos dados para atingir o size limite ou count	Reduza o time limite
Envio em lote ineficiente devido a um grande número de arquivos muito pequenos	Aumente o tamanho dos arquivos de origem. Se estiver usando o Kafka Sink, configure-o para enviar dados em partes de ~100 KB ou mais. Se você tiver muitos arquivos pequenos, aumente o count (até 2000) na política de ingestão de banco de dados ou tabela.
Envio em lote de uma grande quantidade de dados não compactados	Isso é comum ao ingerir arquivos Parquet. Diminua size incrementalmente a política de envio em lote de tabela ou banco de dados para 250 MB e verifique se há melhorias.
Lista de pendências porque o banco de dados está subdimensionado	Aceite todas as sugestões do Assistente do Azure para escalar verticalmente ou escalar verticalmente seu banco de dados. Como alternativa, dimensione manualmente seu banco de dados para ver se a lista de pendências está fechada. Se essas opções não funcionarem, entre em contato com o suporte para obter assistência.