Mettre à l’échelle un job Azure Stream Analytics pour augmenter le débit

Cet article explique comment paramétrer une requête Azure Stream Analytics pour augmenter le débit. Utilisez ces modèles de montée en charge pour gérer une charge plus élevée en utilisant davantage de bande passante, de CPU et de mémoire.

Azure Stream Analytics mesure la capacité de calcul en unités de streaming (SUs). Chaque su V2 représente la capacité totale d’un nœud de calcul unique. Une requête parallèle embarrassante est une requête où chaque partition d’entrée peut être traitée indépendamment, sans données partagées entre les partitions.

Prerequisites

Avant de commencer, passez en revue les articles suivants :

• Comprendre et ajuster les unités de diffusion en continu
• Créer des travaux parallélisables

Mettre à l’échelle une requête entièrement parallélisable

Si votre requête est massivement parallèle entre les partitions d’entrée, procédez comme suit :

1. Créez votre requête pour utiliser le mot clé PARTITION BY . Pour plus d’informations, consultez Utiliser la parallélisation des requêtes dans Azure Stream Analytics.

2. Selon les types de sortie utilisés dans votre requête, certaines sorties peuvent ne pas être parallélisables ou avoir besoin d’une configuration supplémentaire pour être embarrassantement parallèle. Par exemple, configurez vos sorties pour la parallélisation. Tous les types de sortie ne prennent pas en charge les écritures parallèles :

   Type de sortie	Prise en charge de la parallélisation
   Stockage Blob Azure, Azure Table Storage, Azure Data Lake Storage, Azure Service Bus, Azure Functions	Automatique
   Azure SQL Database, Azure Synapse Analytics	Optionnel. Nécessite une configuration
   Hubs d'événements Azure	Nécessite que PartitionKey corresponde au champ PARTITION BY (généralement PartitionId). Mettre en correspondance les nombres de partitions d’entrée et de sortie pour éviter le croisement.
   Power BI	Non parallélisable. Les sorties sont toujours fusionnées avant l’envoi vers le récepteur

3. Exécutez votre requête avec 1 SU V2 (qui est la capacité totale d’un nœud informatique unique) pour mesurer le débit maximal réalisable. Si vous utilisez GROUP BY, mesurez le nombre de groupes (cardinalité) que le travail peut gérer.

4. Vérifiez s’il existe des limites pour les ressources du système. Les symptômes suivants indiquent que votre travail de Azure Stream Analytics atteint les limites des ressources :

   Symptôme	Cause la plus probable	Action
   La métrique de % d’utilisation des SU dépasse 80 %	Utilisation élevée de la mémoire. Consultez Comprendre et ajuster les unités de diffusion en continu.	Ajouter d’autres SU V2s.
   L’horodatage de sortie prend du retard par rapport à la durée chronométrée	Selon la logique de votre requête, l’horodatage de sortie peut présenter un décalage logique par rapport au temps horloge. Toutefois, ils devraient progresser à peu près au même rythme. Si l’horodatage de sortie prend de plus en plus de retard, c'est un indicateur que le système est surchargé. Il peut s’agir d’une limitation du récepteur de sortie en aval ou d’une utilisation élevée du processeur. Stream Analytics ne fournit pas de métrique d’utilisation du processeur pour l’instant. Il peut donc être difficile de différencier les deux.	Si le problème est dû à une limitation du débit du récepteur, augmentez le nombre de partitions de sortie (et de partitions d’entrée pour maintenir le parallélisme), ou augmentez les ressources du récepteur (par exemple, les Request Units pour Azure Cosmos DB).
   La métrique des événements en attente par partition continue d’augmenter (visible dans le diagramme de la tâche)	Bridage du récepteur de sortie ou forte utilisation du processeur	Identique à ce qui précède.

5. Extrapoler la capacité de façon linéaire. Une fois que vous avez déterminé ce que 1 SU V2 peut gérer, ajoutez d’autres unités de stockage proportionnellement, en supposant qu’aucune asymétrie des données entre les partitions n’est prise en compte.

Mettre à l’échelle une requête non parallèle

Si votre requête n’est pas embarrassantement parallèle, procédez comme suit :

1. Démarrez sans PARTITION BY pour éviter toute complexité. Exécutez la requête avec 1 SU V2 pour mesurer le débit maximal. Recherchez les mêmes symptômes de limitation des ressources décrits dans la section précédente (utilisation des SU supérieure à 80 %, retard de l’horodatage de sortie, arriéré croissant).

2. Si vous atteignez votre débit cible, vous avez terminé. Si vous le souhaitez, testez avec 2/3 SU V2 et 1/3 SU V2 pour trouver le nombre minimal de SU V2 pour votre scénario.

3. Si vous ne pouvez pas atteindre le débit souhaité, divisez la requête en plusieurs étapes. Allouez jusqu’à 1 SU V2 pour chaque étape. Par exemple, une requête en trois étapes nécessite 3 SU V2. Azure Stream Analytics place chaque étape sur son propre nœud dédié.

4. Si vous n’avez toujours pas atteint votre cible de débit, ajoutez PARTITION BY aux étapes plus proches de l’entrée. Pour les opérations GROUP BY qui ne sont pas naturellement partitionnables, utilisez le modèle d’agrégation local/global : effectuez d’abord un GROUP BY partitionné, puis un GROUP BY nonpartitionné. Par exemple, pour compter les voitures passant par chaque cabine de péage toutes les 3 minutes lorsque le volume dépasse ce que 1 SU V2 peut gérer :

   WITH Step1 AS (
   SELECT COUNT(*) AS Count, TollBoothId, PartitionId
   FROM Input1 Partition By PartitionId
   GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
   )
   SELECT SUM(Count) AS Count, TollBoothId
   FROM Step1
   GROUP BY TumblingWindow(minute, 3), TollBoothId
   

   Cette requête compte les voitures par cabine de péage par partition à l’étape 1, puis agrège les nombres partitionnés à l’étape finale.

   Après avoir partitionner la requête, allouez 1 SU V2 pour chaque partition de chaque étape afin que chaque partition s’exécute sur son propre nœud de traitement.

   Note

   Si votre requête ne peut pas être partitionnée, l’ajout d’autres su V2s dans une requête en plusieurs étapes peut ne pas améliorer le débit. Pour obtenir des performances, réduisez le volume dans les étapes initiales à l’aide du modèle d’agrégation local/global indiqué à l’étape 4.

Exécuter plusieurs requêtes indépendantes à grande échelle dans une seule tâche

Pour les scénarios éditeurs de logiciels indépendants (ISV) multilocataires où vous traitez les données de plusieurs locataires dans un seul travail Azure Stream Analytics (avec des entrées et des sorties distinctes par locataire), la charge de chaque sous-requête est généralement petite. Suivez ces étapes :

1. N’utilisez pas PARTITION BY dans la requête.

2. Si vous utilisez Azure Event Hubs, réduisez le nombre de partitions d’entrée à la valeur minimale de 2.

3. Exécutez la requête avec 1 SU V2. Ajoutez des sous-requêtes jusqu’à ce que le travail atteigne les limites de ressources. Les symptômes sont les mêmes que ceux d’une requête entièrement parallélisable : utilisation des SU supérieure à 80 %, retard de l’horodatage de sortie ou accumulation croissante.

4. Une fois la limite de sous-requête atteinte, ajoutez de nouvelles sous-requêtes à un travail distinct. Le nombre de tâches augmente linéairement avec le nombre de requêtes indépendantes (en l’absence de déséquilibre de charge). Vous pouvez ensuite prévoir le nombre de travaux SU V2 que vous devez exécuter en tant que fonction du nombre de locataires que vous souhaitez servir.

5. Pour les jointures de données de référence, unionez toutes les entrées avant de joindre les données de référence, puis fractionnez les événements par la suite. Sinon, chaque jointure de données de référence conserve une copie distincte des données de référence en mémoire, ce qui peut entraîner une utilisation inutile de la mémoire.

Obtenir de l’aide

Pour obtenir de l’aide supplémentaire, essayez la page de questions microsoft Q&A pour Azure Stream Analytics.

Contenu connexe

• Présentation d’Azure Stream Analytics
• Commencer à utiliser Azure Stream Analytics
• Références sur le langage des requêtes d'Azure Stream Analytics
• Références sur l’API REST de gestion d’Azure Stream Analytics