Política de criação de batches de ingestão

Descrição Geral

Durante o processo de ingestão em fila, o serviço otimiza o débito ao criar em lotes pequenos segmentos de dados de entrada antes da ingestão. A criação de batches reduz os recursos consumidos pelo processo de ingestão em fila e não requer recursos de pós-ingestão para otimizar as pequenas partições horizontais de dados produzidas por ingestão não lotada.

A desvantagem de fazer batches antes da ingestão é o atraso forçado. Por conseguinte, a hora ponto a ponto de pedir a ingestão de dados até que os dados prontos para a consulta sejam maiores.

Quando definir a IngestionBatching política, terá de encontrar um equilíbrio entre otimizar para débito e atraso de tempo. Esta política aplica-se à ingestão em fila. Define o atraso máximo forçado permitido ao criar em lotes pequenos blobs em conjunto. Para saber mais sobre como utilizar comandos de política de criação de batches e otimizar o débito, veja:

Selar um lote

Existe um tamanho ideal de cerca de 1 GB de dados não comprimidos para ingestão em massa. A ingestão de blobs com muito menos dados é inferior ao ideal, pelo que, na ingestão em fila, o serviço irá juntar pequenos blobs.

A lista seguinte mostra os acionadores básicos da política de criação de batches para selar um lote. Um lote é selado e ingerido quando a primeira condição é cumprida:

  • Size: Limite de tamanho do lote atingido ou excedido
  • Count: Limite de números de ficheiros do Batch atingido
  • Time: O tempo de criação de batches expirou

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

Importante

O impacto de definir esta política para valores muito pequenos é um aumento do COGS (custo de bens vendidos) do cluster e um desempenho reduzido. Além disso, a redução dos valores da política de criação de batches pode resultar num aumento da latência de ingestão ponto a ponto eficaz, devido à sobrecarga da gestão de vários processos de ingestão em paralelo.

A lista seguinte mostra as condições para selar lotes relacionados com a ingestão de blobs únicos. Um lote é selado e ingerido quando as condições são cumpridas:

  • 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 for acionada uma descarga do sistema. Com o SystemFlush conjunto de parâmetros, o sistema limpa os dados, por exemplo, devido ao dimensionamento do cluster ou à reposição interna dos componentes do sistema.

Predefinições e limites

Tipo Propriedade Predefinição Definição de latência baixa 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
Hora (seg. MaximumBatchingTimeSpan 300 20 - 30 10 1800

A forma mais eficaz de controlar a latência ponto a ponto através da política de criação de batches de ingestão é alterar o limite de tempo ao nível da tabela ou da base de dados , de acordo com o limite mais elevado de requisitos de latência. Uma política ao nível da base de dados afeta todas as tabelas nessa base de dados que não têm a política ao nível da tabela definida e qualquer tabela criada recentemente.

Importante

Se definir o limite de tempo da política de Batching de Ingestão demasiado baixo em tabelas de entrada baixa, poderá incorrer em trabalhos adicionais de computação e armazenamento à medida que o cluster tenta otimizar as partições horizontais de dados recentemente criadas. Para obter mais informações sobre as partições horizontais de dados, veja extensões.

Tamanho dos dados do Batch

O tamanho dos dados da política de criação de batches está definido para dados não comprimidos. Para ficheiros Parquet, AVRO e ORC, uma estimativa é calculada com base no tamanho do ficheiro. Para dados comprimidos, o tamanho dos dados não comprimidos é avaliado da seguinte forma por ordem descendente de precisão:

  1. Se o tamanho não comprimido for fornecido nas opções de origem de ingestão, esse valor é utilizado.
  2. Ao ingerir ficheiros locais com SDKs, os arquivos zip e os fluxos gzip são inspecionados para avaliar o respetivo tamanho não processado.
  3. Se as opções anteriores não fornecerem um tamanho de dados, é aplicado um fator ao tamanho dos dados comprimidos para estimar o tamanho dos dados descomprimidos.

Latências de criação de batches

As latências podem resultar de muitas causas que podem ser abordadas com as definições de política de criação de batches.

Causa Solução
A latência de dados corresponde à time definição, com poucos dados para atingir o size limite ou count Reduzir o time limite
Criação de batches ineficiente devido a um grande número de ficheiros muito pequenos Aumente o tamanho dos ficheiros de origem. Se estiver a utilizar o Sink do Kafka, configure-o para enviar dados em ~100 KB segmentos ou superiores. Se tiver muitos ficheiros pequenos, aumente o count (até 2000) na base de dados ou na política de ingestão de tabelas.
Batching a large amount of uncompressed data (Criar uma grande quantidade de dados não comprimidos) Isto é comum ao ingerir ficheiros Parquet. Diminua size incrementalmente para a política de criação de batches de tabelas ou bases de dados para 250 MB e verifique se há melhorias.
Atraso porque o cluster está em escala Aceite quaisquer sugestões do assistente do Azure para dimensionar ou aumentar verticalmente o cluster. Em alternativa, dimensione manualmente o cluster para ver se o atraso está fechado. Se estas opções não funcionarem, contacte o suporte para obter assistência.