Política de envio em lote de ingestão

  • Artigo

Visão geral

Durante o processo de ingestão na fila, o serviço otimiza a taxa de transferência agrupando partes de dados de entrada pequenas antes da ingestão. O envio em lote reduz os recursos consumidos pelo processo de ingestão na fila 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 o envio em lote antes da ingestão é o atraso forçado. Portanto, a hora de ponta a ponta de solicitar a ingestão de dados até que os dados prontos para consulta sejam maiores.

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. Essa política se aplica à ingestão na fila. Ele define o atraso forçado máximo permitido ao agrupar blobs pequenos em lote. Para saber mais sobre como usar comandos de política de envio em lote e otimizar a taxa de transferência, confira:

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á blobs pequenos em lote.

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

  • Size: limite de tamanho do lote atingido ou excedido
  • Count: limite de número de arquivo do 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 , 1000 itens, tamanho total de 1 GB.

Importante

O impacto de definir essa política como valores muito pequenos é um aumento no COGS (custo de mercadorias vendidas) do cluster e desempenho reduzido. Além disso, a redução dos valores da política de envio em lote pode, na verdade, resultar em maior latência efetiva de ingestão de ponta a ponta, devido à sobrecarga do gerenciamento de vários processos de ingestão em paralelo.

A lista a seguir mostra condições para selar lotes relacionados à ingestão de blob único. Um lote é selado 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 estiver definida, um lote será selado quando uma liberação do sistema for disparada. Com o SystemFlush conjunto de parâmetros, o sistema libera os dados, por exemplo, devido ao dimensionamento de cluster 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 MaximumNumberOfItems 500 500 1 25,000
Tamanho dos dados (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Tempo (s) MaximumBatchingTimeSpan 300 20 - 30 10 1800

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 mais alto de 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 trabalhos adicionais de computação e armazenamento à medida que o cluster tenta otimizar os fragmentos de dados recém-criados. Para obter mais informações sobre fragmentos de dados, confira 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 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 envio em lote

Latências podem resultar de várias 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 Reduzir 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 Coletor kafka, configure-o para enviar dados em ~100 KB partes ou superiores. 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 descompactados Isso é comum ao ingerir arquivos Parquet. Diminua size incrementalmente para a política de envio em lote de tabela ou banco de dados para 250 MB e marcar para melhoria.
Lista de pendências porque o cluster está em escala Aceite qualquer sugestão do assistente do Azure para escalar horizontalmente ou escalar verticalmente o cluster. Como alternativa, dimensione manualmente o cluster 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.