Concepts de point de contrôle et de relecture dans les travaux Azure Stream Analytics

Azure Stream Analytics maintient les informations d’état en interne à chaque exécution d’un travail, et il sauvegarde périodiquement cet état vers un point de contrôle. Si une tâche échoue ou est mise à niveau, Stream Analytics peut utiliser le point de contrôle le plus récent pour récupérer. Lorsque la tâche ne peut pas utiliser le point de contrôle, elle effectue plutôt une réexécution, en retraitant les événements d’entrée récents afin de reconstruire son état.

Cet article explique comment fonctionnent les points de contrôle et les replays dans Azure Stream Analytics et comment ils influencent le temps nécessaire à la récupération d’un travail.

Logique de requête avec état dans les éléments temporels

L’une des capacités uniques d’un emploi Azure Stream Analytics est d’effectuer des traitements avec état, tels que les agrégats fenêtrés, les jointures temporelles et les fonctions d’analyse temporelle. Chacun de ces opérateurs conserve des informations d’état pendant l’exécution du travail. La taille maximale de la fenêtre pour ces éléments de requête est de sept jours.

Le concept de fenêtre temporelle apparaît dans plusieurs éléments de requête Stream Analytics :

  • Agrégats fenêtrés (GROUP BY de fenêtres de Bascule, Récurrente et Glissante)
  • Jointures temporelles (JOIN avec DATEDIFF)
  • Fonctions analytiques temporelles (ISFIRST, LAST et LAG avec LIMIT DURATION)

Récupération du travail à partir d’une défaillance de nœud, y compris la mise à niveau du système d’exploitation

Chaque fois qu’un travail Stream Analytics s’exécute, le service répartit la charge en interne afin de répartir le travail entre plusieurs nœuds Worker. Le service enregistre l’état de chaque nœud de travail à intervalles de quelques minutes, ce qui lui permet de récupérer en cas de défaillance.

Parfois, un nœud worker donné peut tomber en panne, ou une mise à jour du système d’exploitation peut avoir lieu pour ce nœud ouvrier. Pour récupérer automatiquement, Stream Analytics acquiert un nouveau nœud sain et restaure l’état du nœud worker précédent depuis le dernier point de contrôle disponible. Pour reprendre le travail, la tâche rejoue une petite quantité de données afin de restaurer l’état à partir du dernier point de sauvegarde. En règle générale, l’écart de restauration n’est que de quelques minutes. Lorsque vous sélectionnez suffisamment d’unités de streaming pour la tâche, la rediffusion se termine rapidement.

Dans une requête entièrement parallèle, le temps nécessaire pour rattraper le retard après un échec de nœud worker est proportionnel à l’opération suivante :

[taux d’événements d’entrée] x [longueur d’intervalle] / [nombre de partitions de traitement]

Si jamais vous constatez un retard de traitement important dû à une défaillance de nœud ou à une mise à jour du système d’exploitation, envisagez de rendre la requête entièrement parallèle, et d’adapter la tâche pour allouer plus d’unités de streaming. Pour plus d’informations, consultez Mettre à l’échelle un travail Azure Stream Analytics pour augmenter le débit.

Stream Analytics n’affiche actuellement aucun rapport lors de ce type de processus de récupération.

Récupération de tâches après une mise à niveau de service

Microsoft met parfois à niveau les fichiers binaires qui exécutent les travaux Stream Analytics dans le service Azure. À ces moments-là, Microsoft met à jour les tâches d’exécution vers une version plus récente, et la tâche redémarre automatiquement.

Azure Stream Analytics utilise des points de contrôle dans la mesure du possible pour restaurer les données à partir du dernier état de point de contrôle. Lorsque Stream Analytics ne peut pas utiliser de points de contrôle internes, une technique de rediffusion restaure l’état complet de la requête de streaming. Pour permettre aux jobs Stream Analytics de rejouer exactement la même entrée, définissez la politique de rétention des données sources au moins aux tailles de fenêtre de votre requête. Ne pas le faire peut entraîner des résultats incorrects ou partiels lors d’une mise à niveau du service, car Stream Analytics peut ne pas conserver les données sources suffisamment en arrière pour inclure la taille complète de la fenêtre.

En général, la quantité de relecture nécessaire est proportionnelle à la taille de la fenêtre multipliée par le taux d’événements moyen. Par exemple, pour un travail avec un taux d’entrée de 1 000 événements par seconde, une taille de fenêtre supérieure à une heure est une grande relecture. Le service peut devoir retraiter jusqu’à une heure de données pour initialiser l’état afin de produire des résultats complets et corrects, ce qui peut entraîner un retard de sortie (pas de sortie) pendant une période prolongée. Les requêtes sans fenêtre ou autre opérateur temporel, tel que JOIN ou LAG, n’a aucune relecture.

Estimer le temps de rattrapage de relecture

Pour estimer la durée du délai dû à une mise à niveau du service, suivez cette technique :

  • Chargez le hub d’événements d’entrée avec suffisamment de données pour couvrir la plus grande taille de fenêtre de votre requête, au taux d’événement attendu. Les horodatages des événements doivent être proches de l’horloge murale pendant toute cette période, comme s’il s’agissait d’un flux d’entrée en direct. Par exemple, si vous avez une fenêtre de trois jours dans votre requête, envoyez les événements au hub d’événements pendant trois jours, puis continuez à envoyer des événements.
  • Commencez le travail en utilisant le maintenant comme heure de début.
  • Mesurez le temps entre le début et le moment où le travail génère sa première sortie. Ce temps correspond à peu près au délai que le travail subit lors d’une mise à niveau du service.
  • Si le délai est trop long, essayez de partitionner votre tâche et d’augmenter le nombre d’unités de streaming afin que la charge se répartisse sur plus de nœuds. Sinon, réduisez la taille des fenêtres dans votre requête et effectuez d’autres agrégations ou un autre traitement avec état sur la sortie produite par le travail Stream Analytics dans le récepteur en aval (par exemple, avec Azure SQL Database).

Pour la stabilité générale des services lors de la mise à niveau des travaux critiques, envisagez d’exécuter des travaux en double dans des régions Azure jumelées. Pour plus d’informations, consultez Garantir la fiabilité des travaux Stream Analytics pendant les mises à jour du service.

Reprise de travail après un arrêt et démarrage initié par l’utilisateur

Pour modifier la syntaxe des requêtes sur un travail de streaming, ou pour ajuster les entrées et sorties, il faut arrêter le travail pour effectuer les modifications et améliorer la conception du travail. Dans de tels cas, lorsque vous arrêtez le travail de streaming et que vous le redémarrez, le scénario de récupération ressemble à une mise à niveau de service.

Un redémarrage de travail initié par l’utilisateur ne peut pas utiliser de données de points de contrôle. Pour estimer le délai de sortie lors d’un tel redémarrage, utilisez la même procédure que celle décrite dans la section précédente, et appliquez une atténuation similaire si le délai est trop long.

Contenu connexe

Pour plus d’informations sur la fiabilité et l’extensibilité, consultez les articles suivants :

  • Last updated on