Directiva de procesamiento por lotes de ingesta

  • Artículo

Información general

Durante el proceso de ingesta en cola, el servicio optimiza el rendimiento mediante el procesamiento por lotes de fragmentos de datos de entrada pequeños 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 generadas por la ingesta 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 de 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 se sella e ingiere cuando se cumple la primera condición:

  • Size: límite de tamaño de lote alcanzado o superado
  • Count: se ha alcanzado 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 , 1000 elementos, tamaño total de 1 GB.

Importante

El impacto de establecer esta directiva en valores muy pequeños es un aumento del COGS (costo de bienes vendidos) del clúster y un rendimiento reducido. Además, reducir los valores de directiva de procesamiento por lotes podría dar lugar a una mayor 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 se sella e ingiere 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 del clúster o al restablecimiento interno de los componentes del sistema.

Valores predeterminados y límites

Tipo Propiedad Valor predeterminado Configuración de latencia baja Valor mínimo Valor máximo
Número de elementos MaximumNumberOfItems 500 500 1 25 000
Tamaño de datos (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Tiempo (s) MaximumBatchingTimeSpan 300 20 - 30 10 1800

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 las tablas de entrada bajas, puede incurrir en un trabajo adicional de proceso y almacenamiento cuando el clúster intenta optimizar las particiones de datos recién creadas. Para obtener más información sobre las particiones de datos, consulte extensiones.

Tamaño de 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, una estimación se calcula en función del tamaño del 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 Reducción del 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 aproximadamente 100 KB o superior. Si tiene muchos archivos pequeños, aumente count (hasta 2000) en la directiva de ingesta de tablas o base de datos.
Procesamiento por lotes de una gran cantidad de datos sin comprimir Esto es común 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 el clúster está en escalado Acepte las sugerencias de Azure Advisor para escalar horizontalmente o escalar verticalmente el clúster. Como alternativa, escale manualmente el clúster 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.