Compartir a través de

Directiva de procesamiento por lotes de ingesta

  • Artículo

Información general

Se aplica a: ✅Microsoft Fabric✅Azure Data Explorer

Durante el proceso de ingesta en cola, el servicio optimiza el rendimiento mediante la procesamiento por lotes de pequeños fragmentos de datos de entrada juntos antes de la ingesta. El procesamiento por lotes reduce los recursos consumidos por el proceso de ingesta en cola y no requiere recursos posteriores a la ingesta para optimizar las pequeñas particiones de datos producidas por la ingesta no por lotes.

La desventaja de realizar el procesamiento por lotes antes de la ingesta es el retraso forzado. Por lo tanto, la hora de un extremo a otro desde la solicitud de la ingesta de datos hasta que los datos listos para la consulta sean mayores.

Al definir la IngestionBatching directiva, deberá encontrar un equilibrio entre optimizar el rendimiento y el retraso del tiempo. Esta directiva se aplica a la ingesta en cola. Define el retraso máximo forzado permitido al procesar por lotes blobs pequeños juntos. Para más información sobre el uso de comandos de directiva de procesamiento por lotes y la optimización del rendimiento, consulte:

Sellado de un lote

Hay un tamaño óptimo de aproximadamente 1 GB de datos sin comprimir para la ingesta masiva. La ingesta de blobs con mucho menos datos es poco óptima, por lo que, en la ingesta en cola, el servicio procesará por lotes pequeños blobs juntos.

En la lista siguiente se muestran los desencadenadores de directiva de procesamiento por lotes básicos para sellar un lote. Un lote está sellado e ingerido cuando se cumple la primera condición:

  • Size: se alcanzó o superó el límite de tamaño del lote.
  • Count: se alcanzó el límite de número de archivo por lotes
  • Time: el tiempo de procesamiento por lotes ha expirado.

La IngestionBatching directiva se puede establecer en bases de datos o tablas. Los valores predeterminados son los siguientes: tiempo de retraso máximo de 5 minutos , 500 elementos, tamaño total de 1 GB.

Importante

El impacto de establecer esta política en valores muy pequeños es un aumento del COGS (costo de bienes vendidos) y un rendimiento reducido. Además, reducir los valores de directiva de procesamiento por lotes podría dar lugar a un aumento de la latencia de ingesta de un extremo a otro eficaz, debido a la sobrecarga de administrar varios procesos de ingesta en paralelo.

En la lista siguiente se muestran las condiciones para sellar lotes relacionados con la ingesta de blobs únicos. Un lote está sellado e ingerido cuando se cumplen las condiciones:

Si se establece la SystemFlush condición, se sellará un lote cuando se desencadene un vaciado del sistema. Con el SystemFlush conjunto de parámetros, el sistema vacía los datos, por ejemplo, debido al escalado de la base de datos o al restablecimiento interno de los componentes del sistema.

Valores predeterminados y límites

Tipo Propiedad Valor predeterminado Configuración de baja latencia Valor mínimo Valor máximo
Número de artículos MaximumNumberOfItems 500 500 1 25 000
Tamaño de datos (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Time (TimeSpan) MaximumBatchingTimeSpan 00:05:00 00:00:20 - 00:00:30 00:00:10 00:30:00

La forma más eficaz de controlar la latencia de un extremo a otro mediante la directiva de procesamiento por lotes de ingesta es modificar su límite de tiempo en el nivel de tabla o base de datos , según el límite más alto de los requisitos de latencia. Una directiva de nivel de base de datos afecta a todas las tablas de esa base de datos que no tienen definida la directiva de nivel de tabla y a cualquier tabla recién creada.

Importante

Si establece el límite de tiempo de la directiva de procesamiento por lotes de ingesta demasiado bajo en tablas de entrada bajas, puede incurrir en un trabajo adicional de proceso y almacenamiento a medida que la base de datos intenta optimizar las particiones de datos recién creadas. Para más información sobre las particiones de datos, consulte extensiones.

Tamaño de los datos por lotes

El tamaño de los datos de la directiva de procesamiento por lotes se establece para los datos sin comprimir. En el caso de los archivos Parquet, AVRO y ORC, se calcula una estimación basada en el tamaño de archivo. En el caso de los datos comprimidos, el tamaño de los datos sin comprimir se evalúa de la siguiente manera en orden descendente de precisión:

  1. Si el tamaño sin comprimir se proporciona en las opciones de origen de ingesta, se usa ese valor.
  2. Al ingerir archivos locales mediante SDK, se inspeccionan los archivos ZIP y las secuencias gzip para evaluar su tamaño sin procesar.
  3. Si las opciones anteriores no proporcionan un tamaño de datos, se aplica un factor al tamaño de datos comprimido para calcular el tamaño de los datos sin comprimir.

Latencias de procesamiento por lotes

Las latencias pueden deberse a muchas causas que se pueden solucionar mediante la configuración de la directiva de procesamiento por lotes.

Causa Solución
La latencia de datos coincide con la time configuración, con demasiados datos para alcanzar el size límite o count Reducir el time límite
Procesamiento por lotes ineficaz debido a un gran número de archivos muy pequeños Aumente el tamaño de los archivos de origen. Si usa receptor de Kafka, configúrelo para enviar datos en fragmentos de ~100 KB o superior. Si tiene muchos archivos pequeños, aumente count (hasta 2000) en la directiva de ingesta de bases de datos o tablas.
Procesamiento por lotes de una gran cantidad de datos sin comprimir Esto es habitual al ingerir archivos Parquet. Reduzca size incrementalmente la directiva de procesamiento por lotes de tablas o bases de datos hacia 250 MB y compruebe si hay mejoras.
Trabajo pendiente porque la base de datos está en escalado Acepte las sugerencias de Azure Advisor para escalar horizontalmente o escalar verticalmente la base de datos. Como alternativa, escale manualmente la base de datos para ver si el trabajo pendiente está cerrado. Si estas opciones no funcionan, póngase en contacto con el soporte técnico para obtener ayuda.