Partager via

Mettre à l’échelle des travaux Azure Stream Analytics pour augmenter le débit

  • Article

Cet article vous indique comment régler une requête Stream Analytics pour augmenter le débit des travaux Stream Analytics. Vous pouvez utiliser le guide suivant pour mettre à l’échelle votre travail afin de gérer une charge plus élevée et de bénéficier de davantage de ressources système (par exemple, plus de bande passante, de ressources processeur, de mémoire).

Au préalable, lisez les articles suivants :

Cas 1 : Votre requête est par définition entièrement parallélisable sur plusieurs partitions d’entrée

Si votre requête est par définition entièrement parallélisable sur plusieurs partitions d’entrée, vous pouvez suivre les étapes suivantes :

  • Créez une requête massivement parallèle en utilisant le mot clé PARTITION BY. Pour plus d’informations, consultez Utiliser la parallélisation des requêtes dans Azure Stream Analytics.
  • En fonction des types de sortie utilisés dans votre requête, certaines sorties peuvent soit ne pas être parallélisables, soit nécessiter une configuration supplémentaire pour être parallèlement embarrassantes. Par exemple, la sortie Power BI n’est pas parallélisable. Les sorties sont toujours fusionnées avant l’envoi vers le récepteur de sortie. Les blobs, les tables, Azure Data Lake Storage, Service Bus et Azure Function sont automatiquement parallélisés. Les sorties SQL et Azure Synapse Analytics comportent une option pour la parallélisation. Un hub d'événements doit avoir la configuration PartitionKey définie pour correspondre au champ PARTITION PAR (généralementPartitionId). Pour Event Hubs, assurez-vous également que le nombre de partitions d’entrée est égal au nombre de partitions de sortie pour éviter tout croisement entre les partitions.
  • Exécutez votre requête avec 1 unité de streaming (SU) V2 (qui correspond à la pleine capacité d'un seul nœud informatique) pour mesurer le débit maximal réalisable, et si vous utilisez GROUPE PAR, mesurez le nombre de groupes (cardinalité) que le travail peut gérer. Les symptômes généraux qui indiquent que le travail a atteint les limites des ressources système sont les suivants.
    • La mesure du pourcentage d’utilisation des unités de flux (SU) est supérieure à 80 %. Cela indique que l’utilisation de la mémoire est élevée. Les facteurs contribuant à l'augmentation de cette mesure sont décrits Comprendre et ajuster les unités de streaming Stream Analytics.
    • L’horodatage de sortie est en retard par rapport au temps horloge. En fonction de la logique de votre requête, l'horodatage de sortie peut avoir un décalage logique par rapport à l'heure de l'horloge murale. Toutefois, ils doivent avancer à peu près à la même vitesse. Si l’horodatage de sortie est de plus en plus en retard, cela indique que le système est surchargé. Cela peut être le résultat de la limitation du récepteur de sortie en aval ou d’une utilisation élevée du processeur. Comme nous ne fournissons pas de métrique d’utilisation du processeur à ce stade, il peut être difficile de différencier les deux.
      • Si le problème est dû à la limitation du récepteur, vous devez augmenter le nombre de partitions de sortie (ainsi que les partitions d'entrée pour que le travail reste entièrement parallélisable) ou augmenter la quantité de ressources du récepteur (par exemple, le nombre d'unités de requête pour Cosmos DB. ).
    • Dans le diagramme de tâches, il existe une métrique d'événement de backlog par partition pour chaque entrée. Si la métrique d’événement de backlog continue à augmenter, cela indique également que la ressource système est contrainte (en raison de la limitation du récepteur de sortie ou d’une utilisation élevée du processeur).
  • Une fois que vous avez déterminé les limites de ce qu'une tâche SU V2 peut atteindre, vous pouvez extrapoler linéairement la capacité de traitement de la tâche à mesure que vous ajoutez d'autres SU, en supposant que vous n'avez pas de biais de données qui rende certaines partitions « chaudes ».

Remarque

Choisissez le bon nombre d'unités de streaming : étant donné que Stream Analytics crée un nœud de traitement pour chaque SU V2 ajouté, il est préférable de faire du nombre de nœuds un diviseur du nombre de partitions d'entrée, afin que les partitions puissent être réparties uniformément entre les nœuds. Par exemple, vous avez mesuré que votre travail avec 1 US V2 peut atteindre une vitesse de traitement de 4 Mo/s et le nombre de partitions d’entrée est 4. Vous pouvez alors choisir d’exécuter votre travail avec 2 US V2 pour atteindre une vitesse de traitement d’environ 8 Mo/s, ou 4 US V2 pour atteindre 16 Mo/s. Vous pouvez alors décider quand augmenter le nombre d’unités de streaming du travail jusqu’à quelle valeur, en fonction de votre vitesse d’entrée.

Cas 2 : Votre requête n’est pas massivement parallèle.

Si votre requête n’est pas parallèle de manière embarrassante, vous pouvez suivre ces étapes.

  • Démarrez avec une requête sans PARTITION BY pour éviter la complexité de partitionnement et exécutez-la avec 1 US V2 pour mesurer la charge maximale, comme dans le Cas 1.
  • Si vous pouvez obtenir votre charge prévue en termes de débit, vous avez terminé. Vous pouvez également choisir de mesurer le même travail en cours d'exécution avec des nœuds fractionnaires à 2/3 SU V2 et 1/3 SU V2, pour connaître le nombre minimum d'unités de streaming qui fonctionne pour votre scénario.
  • Si vous ne parvenez pas à atteindre le débit souhaité, essayez de diviser votre requête en plusieurs étapes si elle n'en comporte pas déjà plusieurs, et allouez jusqu'à un SU V2 pour chaque étape de la requête. Par exemple si vous avez trois étapes, allouez trois SU V2 dans l'option "Scale".
  • Pour exécuter une telle tâche, Stream Analytics place chaque étape sur son propre nœud avec une ressource SU V2 dédiée.
  • Si vous n’avez pas encore atteint votre cible de charge, vous pouvez essayer d’utiliser PARTITION BY en commençant par les étapes les plus proches de l’entrée. Pour l'opérateur GROUPE PAR qui n'est pas naturellement partitionnable, vous pouvez utiliser le modèle d'agrégation local/global pour effectuer un GROUPE PAR partitionné suivi d'un GROUPE PAR non partitionné. Par exemple, si vous souhaitez compter le nombre de voitures passant par chaque poste de péage toutes les 3 minutes et que le volume de données dépasse ce qui peut être géré par un seul SU V2.

Requête :

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

Dans la requête, vous comptez les voitures par poste de péage et par partition, puis vous additionnez le nombre de toutes les partitions.

Une fois partitionnée, pour chaque partition de l'étape, allouez un SU V2 afin que chaque partition puisse être placée sur son propre nœud de traitement.

Remarque

Si votre requête ne peut pas être partitionnée, l’ajout d’unités de streaming supplémentaires dans une requête en plusieurs étapes peut ne pas toujours améliorer le débit. Une façon d'améliorer les performances consiste à réduire le volume lors des étapes initiales en utilisant un modèle d'agrégation local/global, comme décrit à l'étape 5.

Cas 3 : Vous exécutez un grand nombre de requêtes indépendantes dans un travail.

Pour certains cas d'utilisation d'ISV, où il est plus rentable de traiter les données de plusieurs locataires dans une seule tâche, en utilisant des entrées et des sorties distinctes pour chaque locataire, vous finissez par exécuter un certain nombre (par exemple 20) requêtes indépendantes dans une seule tâche. . L’hypothèse est que la charge de chaque sous-requête de ce type est relativement faible.

Dans ce cas, vous pouvez suivre ces étapes.

  • Dans ce cas, n’utilisez pas PARTITION BY dans la requête
  • Réduisez le nombre de partitions d’entrée à la valeur la plus faible possible de 2 si vous utilisez Event Hubs.
  • Exécutez la requête avec un SU V2. Avec la charge attendue pour chaque sous-requête, ajoutez autant de ces sous-requêtes que possible, jusqu’à ce que le travail atteigne les limites des ressources système. Reportez-vous à cas 1 pour connaître les symptômes lorsqu’il se produit.
  • Une fois que vous atteignez la limite de sous-requête mesurée, commencez à ajouter la sous-requête à une nouvelle tâche. Le nombre de travaux à exécuter en fonction du nombre de requêtes indépendantes doit être assez linéaire, en partant du principe que vous n’avez aucune asymétrie de charge. Vous pouvez ensuite prévoir le nombre de tâches SU V2 que vous devez exécuter en fonction du nombre de locataires que vous souhaitez servir.
  • Si vous utilisez une jointure de données de référence avec de telles requêtes, vous devez unir les entrées avant la jointure avec les mêmes données de référence. Ensuite, fractionnez les événements si nécessaire. Dans le cas contraire, chaque jointure des données de référence conserve une copie des données de référence en mémoire, ce qui risque d’augmenter l’utilisation de la mémoire inutilement.

Notes

Combien de locataires à placer dans chaque travail ? Ce modèle de requête comporte souvent un grand nombre de sous-requêtes et aboutit à une topologie très volumineuse et complexe. Le contrôleur du travail peut ne pas être en mesure de gérer une topologie si volumineuse. En règle générale, restez en dessous de 40 clients pour un travail avec 1/3 US V2 et 60 clients pour des travaux avec 2/3 et 1 US V2. Quand vous dépassez la capacité du contrôleur, le travail ne démarre pas correctement.

Obtenir de l’aide

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

Étapes suivantes