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:
- Referência de comandos da política de criação de batches de ingestão
- Melhores práticas de ingestão – otimizar o débito
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 excedidoCount
: Limite de números de ficheiros do Batch atingidoTime
: 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 definidoSingleBlob_IngestIfNotExists
: Ingerir um único blob porque "IngestIfNotExists" foi definidoSingleBlob_IngestByTag
: Ingerir um único blob porque "ingest-by" foi definidoSingleBlob_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:
- Se o tamanho não comprimido for fornecido nas opções de origem de ingestão, esse valor é utilizado.
- Ao ingerir ficheiros locais com SDKs, os arquivos zip e os fluxos gzip são inspecionados para avaliar o respetivo tamanho não processado.
- 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. |
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários