Partager via

Stratégie de traitement par lot de l’ingestion

  • Article

Vue d’ensemble

S’applique à : ✅Microsoft Fabric✅Azure Data Explorer

Pendant le processus d’ingestion mis en file d’attente, le service optimise le débit en regroupant les petits segments 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 batchée.

L’inconvénient du traitement par lot avant l’ingestion est le délai forcé. Par conséquent, l’heure de bout en bout de la demande de l’ingestion des données jusqu’à ce que les données prêtes pour la requête soit supérieure.

Lorsque vous définissez la IngestionBatching stratégie, vous devez trouver un équilibre entre l’optimisation du débit et du délai. Cette stratégie s’applique à l’ingestion mise en file d’attente. Il définit le délai maximal forcé autorisé lors du traitement par lots de petits objets blob ensemble. Pour en savoir plus sur l’utilisation des commandes de stratégie de traitement par lots 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 en file d’attente, le service regroupe de petits objets blob.

La liste suivante montre 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 batch 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 : 5 minutes maximum de délai, 500 éléments, taille totale de 1 Go.

Important

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

La liste suivante présente des conditions pour sceller 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 objet blob unique, car « FlushImmediately » a été défini
  • SingleBlob_IngestIfNotExists: Ingérer un objet blob unique, car « IngestIfNotExists » a été défini
  • SingleBlob_IngestByTag: Ingérer un objet blob unique, car ' ingestion-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 système est déclenché. Avec le jeu de paramètres, le système vide les données, par exemple en raison de la SystemFlush mise à l’échelle de la base de données ou de la réinitialisation interne des composants système.

Valeurs par défaut et limites

Type Propriété Par défaut Paramètre de faible latence Valeur minimale Valeur maximale
Nombre d’articles MaximumNumberOfItems 500 500 1 25 000
Taille des données (Mo) MaximumRawDataSizeMB 1 024 1 024 100 4096
Time (TimeSpan) MaximumBatchingTimeSpan 00:05:00 00:00:20 - 00:00:30 00:00:10 00:30:00

Le moyen le plus efficace de contrôler la latence de bout en bout à l’aide d’une stratégie de traitement par lots 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 qui n’ont pas la stratégie au niveau de la table définie et toute table nouvellement créée.

Important

Si vous définissez la limite de temps de la stratégie Batching d’ingestion trop faible sur les tables de faible entrée, vous risquez d’entraîner un travail de calcul et de stockage supplémentaire lorsque la base de données tente d’optimiser les partitions de données nouvellement créées. Pour plus d’informations sur les partitions de données, consultez les étendues.

Taille des données batch

La taille des données de stratégie de traitement par lots 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 sources 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 de données compressée 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 lots.

Cause Solution
La latence des données correspond au time paramètre, avec trop peu de données pour atteindre la limite ou count la size limite Réduire la time limite
Traitement par lots inefficace en raison d’un grand nombre de fichiers très petits 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 version ultérieure. Si vous avez de nombreux petits fichiers, augmentez ( count jusqu’à 2000) 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 manière incrémentielle la stratégie de traitement par lots de table ou de base de données vers 250 Mo et vérifiez l’amélioration.
Backlog, car la base de données est sous mise à l’échelle Acceptez toutes les suggestions d’Azure Advisor pour effectuer une mise à l’échelle ou effectuer un scale-up de votre base de données. Vous pouvez également mettre à l’échelle manuellement votre base de données pour voir si le backlog est fermé. Si ces options ne fonctionnent pas, contactez le support technique pour obtenir de l’aide.