Stratégie de traitement par lot de l’ingestion

  • Article

Vue d’ensemble

Pendant le processus d’ingestion mis en file d’attente, le service optimise le débit en regroupant par lot de petits blocs de données d’entrée avant l’ingestion. Le traitement par lots réduit les ressources consommées par le processus d’ingestion mis en file d’attente et ne nécessite pas de ressources post-ingestion pour optimiser les petites partitions de données produites par l’ingestion non par lot.

L’inconvénient du traitement par lot avant l’ingestion est le délai forcé. Par conséquent, l’heure de bout en bout entre la demande d’ingestion des données et la préparation des données pour la requête est plus grande.

Lorsque vous définissez la IngestionBatching stratégie, vous devez trouver un équilibre entre l’optimisation du débit et le délai. Cette stratégie s’applique à l’ingestion en file d’attente. Il définit le délai forcé maximal autorisé lors du traitement par lot de petits objets blob. Pour en savoir plus sur l’utilisation des commandes de stratégie de traitement par lot et l’optimisation du débit, consultez :

Scellement d’un lot

Il existe une taille optimale d’environ 1 Go de données non compressées pour l’ingestion en bloc. L’ingestion d’objets blob avec beaucoup moins de données n’est pas optimale. Par conséquent, dans l’ingestion mise en file d’attente, le service regroupe les petits objets blob.

La liste suivante présente les déclencheurs de stratégie de traitement par lots de base pour sceller un lot. Un lot est scellé et ingéré lorsque la première condition est remplie :

  • Size: limite de taille de lot atteinte ou dépassée
  • Count: Limite du nombre de fichiers de lots atteinte
  • Time: Le temps de traitement par lot a expiré

La IngestionBatching stratégie peut être définie sur des bases de données ou des tables. Les valeurs par défaut sont les suivantes : délai maximal de 5 minutes , 1 000 éléments, taille totale de 1 Go.

Important

L’impact de la définition de cette stratégie sur des valeurs très faibles est une augmentation du coût des biens vendus (COGS) du cluster et une baisse des performances. En outre, la réduction des valeurs de stratégie de traitement par lot peut effectivement entraîner une augmentation de la latence d’ingestion de bout en bout, en raison de la surcharge liée à la gestion de plusieurs processus d’ingestion en parallèle.

La liste suivante présente les conditions de scellement des lots liés à l’ingestion d’objets blob uniques. Un lot est scellé et ingéré lorsque les conditions sont remplies :

  • SingleBlob_FlushImmediately: Ingérer un seul objet blob, car « FlushImmediately » a été défini
  • SingleBlob_IngestIfNotExists: Ingérer un seul objet blob, car « IngestIfNotExists » a été défini
  • SingleBlob_IngestByTag: Ingérer un seul objet blob, car « ingest-by » a été défini
  • SingleBlob_SizeUnknown: Ingérer un objet blob unique, car la taille de l’objet blob est inconnue

Si la SystemFlush condition est définie, un lot est scellé lorsqu’un vidage du système est déclenché. Une fois le SystemFlush paramètre défini, le système vide les données, par exemple en raison de la mise à l’échelle du cluster ou de la réinitialisation interne des composants système.

Valeurs par défaut et limites

Type Propriété Default Paramètre de faible latence Valeur minimale Valeur maximale
Nombre d’éléments MaximumNumberOfItems 500 500 1 25 000
Taille des données (Mo) MaximumRawDataSizeMB 1 024 1 024 100 4096
Durée (s) MaximumBatchingTimeSpan 300 20 - 30 10 1800

Le moyen le plus efficace de contrôler la latence de bout en bout à l’aide d’une stratégie de traitement par lot d’ingestion consiste à modifier sa limite de temps au niveau de la table ou de la base de données , en fonction de la limite supérieure des exigences de latence. Une stratégie au niveau de la base de données affecte toutes les tables de cette base de données pour lesquelles la stratégie au niveau de la table n’est pas définie, ainsi que les tables nouvellement créées.

Important

Si vous définissez la limite de temps de la stratégie de traitement par lots d’ingestion trop faible sur les tables à faible entrée, vous risquez d’entraîner des tâches de calcul et de stockage supplémentaires lorsque le cluster tente d’optimiser les partitions de données nouvellement créées. Pour plus d’informations sur les partitions de données, consultez extensions.

Taille des données de lot

La taille des données de la stratégie de traitement par lot est définie pour les données non compressées. Pour les fichiers Parquet, AVRO et ORC, une estimation est calculée en fonction de la taille du fichier. Pour les données compressées, la taille des données non compressées est évaluée comme suit dans l’ordre décroissant de précision :

  1. Si la taille non compressée est fournie dans les options de source d’ingestion, cette valeur est utilisée.
  2. Lors de l’ingestion de fichiers locaux à l’aide de kits SDK, les archives zip et les flux gzip sont inspectés pour évaluer leur taille brute.
  3. Si les options précédentes ne fournissent pas de taille de données, un facteur est appliqué à la taille des données compressées pour estimer la taille des données non compressées.

Latences de traitement par lots

Les latences peuvent provenir de nombreuses causes qui peuvent être traitées à l’aide des paramètres de stratégie de traitement par lot.

Cause Solution
La latence des données correspond au time paramètre, avec trop peu de données pour atteindre la size limite ou count Réduire la time limite
Traitement par lots inefficace en raison d’un grand nombre de très petits fichiers Augmentez la taille des fichiers sources. Si vous utilisez Le récepteur Kafka, configurez-le pour envoyer des données en blocs d’environ 100 Ko ou plus. Si vous avez de nombreux petits fichiers, augmentez la count valeur (jusqu’à 2 000) dans la stratégie d’ingestion de base de données ou de table.
Traitement par lot d’une grande quantité de données non compressées Cela est courant lors de l’ingestion de fichiers Parquet. Diminuez size de façon incrémentielle pour la stratégie de traitement par lots de table ou de base de données vers 250 Mo et case activée d’amélioration.
Backlog, car le cluster est sous-mis à l’échelle Acceptez toutes les suggestions d’Azure Advisor pour effectuer un scale-up ou un scale-up de votre cluster. Vous pouvez également mettre à l’échelle manuellement votre cluster pour voir si le backlog est fermé. Si ces options ne fonctionnent pas, contactez le support pour obtenir de l’aide.