Modèles de solution Azure Stream Analytics

Comme de nombreux autres services présents dans Azure, Stream Analytics trouve sa grande utilité lorsqu’il est associé à d’autres services pour créer une solution de bout en bout plus étendue. Cet article aborde les solutions Azure Stream Analytics simples ainsi que différents modèles d’architecture. Vous pouvez vous appuyer sur ces modèles pour développer des solutions plus complexes. Les modèles décrits dans cet article sont exploitables dans un large éventail de scénarios. Des exemples de modèles propres aux scénarios sont disponibles dans les Architectures de solution Azure.

Créer un travail Stream Analytics pour alimenter l’expérience des tableaux de bord en temps réel

Avec Azure Stream Analytics, vous pouvez rapidement mettre en place des alertes et des tableaux de bord en temps réel. Une solution simple ingère des événements à partir d’Event Hubs ou d’IoT Hub, puis alimente le tableau de bord Power BI avec un jeu de données en streaming. Pour plus d’informations, consultez le tutoriel détaillé Analyser les données d’appel frauduleux avec Stream Analytics et visualiser les résultats dans un tableau de bord Power BI.

Vous pouvez générer cette solution en quelques minutes à l’aide du portail Azure. Vous n’avez pas besoin de beaucoup coder. Vous pouvez simplement utiliser le langage SQL pour exprimer la logique métier.

Ce modèle de solution offre la plus faible latence, de la source d’événements au tableau de bord Power BI dans un navigateur. Azure Stream Analytics est le seul service Azure comportant cette fonctionnalité intégrée.

Utiliser SQL pour le tableau de bord

Le tableau de bord Power BI offre une faible latence, mais il est inutilisable dans la production de rapports Power BI complets. Un modèle de création de rapports courant se veut tout d’abord sortir vos données dans une base de données SQL. Ainsi, utilisez le connecteur SQL de Power BI pour interroger SQL sur les données les plus récentes.

L’utilisation d’une base de données SQL vous offre plus de flexibilité, au détriment d’une latence légèrement plus élevée. Cette solution est optimale pour les travaux dont les exigences en termes de latence sont supérieures à une seconde. Avec cette méthode, vous pouvez augmenter les fonctionnalités de Power BI pour segmenter et traiter les données destinées aux rapports, et de nombreuses autres options de visualisation. Vous gagnez également en flexibilité avec l’utilisation d’autres solutions de tableau de bord, telles que Tableau.

SQL n’est pas une banque de données haut débit. Le débit maximal, vers une base de données SQL depuis Azure Stream Analytics, se situe actuellement autour de 24 Mo/s. Si les sources d’événements de votre solution produisent des données à un taux plus élevé, vous devez utiliser une logique de traitement dans Stream Analytics pour réduire le taux de sortie vers SQL. Des techniques, telles que le filtrage, les agrégats fenêtrés, les critères spéciaux avec des jointures temporelles, et des fonctions analytiques, peuvent être utilisées. Il est possible d’optimiser le taux de sortie vers SQL en recourant aux techniques décrites dans l’article Sortie Azure Stream Analytics dans Azure SQL Database.

Incorporer des insights en temps réel dans votre application avec la messagerie d’événements

La deuxième utilisation la plus appréciée de Stream Analytics est la création d’alertes en temps réel. Dans ce modèle de solution, vous pouvez utiliser une logique métier dans Stream Analytics afin de détecter les modèles temporels et spatiaux ou les anomalies, et produire ensuite des signaux d’alerte. Toutefois, contrairement à la solution de tableau de bord dans laquelle Stream Analytics utilise Power BI comme point de terminaison par défaut, certains récepteurs de données intermédiaires peuvent être utilisés. Ces récepteurs comprennent Event Hubs, Service Bus et Azure Functions. Vous, en tant que créateur d’applications, devez décider quel récepteur de données convient le mieux à votre scénario.

La logique de consommateur d’événements en aval doit être implémentée pour générer des alertes dans votre workflow d’entreprise existant. À partir du moment où vous pouvez implémenter une logique personnalisée dans Azure Functions, Azure Functions représente le moyen le plus rapide pour vous d’effectuer cette intégration. Un tutoriel sur l’utilisation d’Azure Functions en tant que sortie de tâche Stream Analytics est disponible dans la section Exécuter Azure Functions à partir des tâches Azure Stream Analytics. Azure Functions prend également en charge différents types de notifications, y compris le texte et les e-mails. Vous pouvez aussi utiliser Logic Apps pour ce genre d’intégration, en plaçant Event Hubs entre Stream Analytics et Logic Apps.

Le service Azure Event Hubs, par ailleurs, offre le point d’intégration le plus souple. De nombreux autres services, tels qu’Azure Data Explorer et Time Series Insights, peuvent consommer des événements à partir d’Event Hubs. Des services peuvent être connectés directement au récepteur Event Hubs à partir d’Azure Stream Analytics pour terminer la solution. Event Hubs est également le répartiteur de messagerie au débit le plus élevé, disponible sur Azure pour de tels scénarios d’intégration.

Sites web et applications dynamiques

Vous pouvez créer des visualisations en temps réel personnalisées, telles que la visualisation de tableaux de bord ou de cartes, avec Azure Stream Analytics et Azure SignalR Service. L’utilisation de SignalR permet la mise à jour des clients web et l’affichage du contenu dynamique en temps réel.

Incorporer à votre application des insights en temps réel par le biais de magasins de données

La plupart des services et applications web utilisent aujourd’hui un modèle de requête/réponse pour gérer la couche de présentation. Le modèle de requête/réponse est simple à créer et peut être facilement mis à l’échelle dans un temps de réponse faible, avec un front-end sans état et des magasins scalables, comme Azure Cosmos DB.

Les volumes importants de données génèrent souvent des goulots d’étranglement dans un système CRUD. Le modèle de solution de provisionnement en événements s’utilise pour résoudre les goulots d’étranglement au niveau des performances. Les insights et modèles temporels sont également ardus et inefficaces pour l’extraction à partir d’un magasin de données classique. Les applications modernes basées sur les données volumineuses adoptent souvent une architecture basée sur les dataflows. Azure Stream Analytics, en tant que moteur de calcul pour les données en mouvement, est un élément central dans cette architecture.

Dans ce modèle de solution, les événements sont traités et agrégés dans des magasins de données par Azure Stream Analytics. La couche d’application interagit avec les magasins de données par l’intermédiaire du modèle de requête/réponse classique. Du fait de la capacité de Stream Analytics à traiter un grand nombre d’événements en temps réel, l’application s’en trouve extrêmement évolutive, sans nécessiter la fourniture en bloc de la couche magasin de données. La couche magasin de données est avant tout une vue matérialisée dans le système. La sortie d’Azure Stream Analytics vers Azure Cosmos DB décrit l’utilisation d’Azure Cosmos DB en tant que sortie Stream Analytics.

Dans les applications réelles, où la logique de traitement est complexe et où il est nécessaire de mettre à niveau certaines parties de la logique séparément, plusieurs tâches Stream Analytics peuvent être combinées avec Event Hubs, en tant que répartiteur d’événements intermédiaire.

Ce modèle améliore la résilience et facilite la gestion du système. Cependant, même si Stream Analytics garantit le traitement en une seule et unique fois, il existe malgré tout une faible probabilité pour que les événements en double puissent se retrouver dans l’intermédiaire Event Hubs. Il est important pour le travail Stream Analytics en aval de dédupliquer les événements à l’aide de clés logiques dans une fenêtre de recherche arrière. Pour plus d’informations sur la remise d’événements, consultez la référence Garanties de remise d’événements.

Utiliser les données de référence pour la personnalisation des applications

La fonctionnalité des données de référence Azure Stream Analytics est prévue plus particulièrement pour la personnalisation de l’utilisateur final, telles que le seuil d’alerte, les règles de traitement et les limites géographiques. La couche d’application peut accepter les modifications apportées aux paramètres et les stocker dans une base de données SQL. Le travail Stream Analytics interroge régulièrement sur les modifications à partir de la base de données, et rend les paramètres de personnalisation accessibles par le biais d’une jointure de données de référence. Pour plus d’informations sur l’utilisation des données de référence pour la personnalisation d’application, consultez Données de référence SQL et Jointure de données de référence.

Ce modèle peut être également utilisé pour implémenter un moteur de règles, où les seuils des règles sont définis à partir de données de référence. Pour plus d’informations sur les règles, consultez Traiter des règles configurables basées sur un seuil dans Azure Stream Analytics.

Ajouter Machine Learning à vos insights en temps réel

Le modèle de détection d’anomalie intégrée d’Azure Stream Analytics est un moyen pratique pour introduire Machine Learning dans votre application en temps réel. Pour un plus large éventail des besoins Machine Learning, consultez Azure Stream Analytics s’intègre au service de scoring d’Azure Machine Learning.

Pour les utilisateurs expérimentés qui souhaitent intégrer le scoring et la formation en ligne dans le même pipeline Stream Analytics, consultez cet exemple pour savoir comment procéder en utilisant la régression linéaire.

Entreposage de données en temps réel

L’entreposage de données en quasi temps réel, également appelé entrepôt de données de streaming est un autre modèle courant. En plus des événements arrivant dans Event Hubs et IoT Hub depuis votre application, vous pouvez utiliser Azure Stream Analytics running on IoT Edge pour répondre aux besoins de nettoyage, de réduction ainsi que de stockage et transfert de données. Stream Analytics running on IoT Edge peut gérer convenablement les problèmes de connectivité et de limitation de la bande passante dans le système. Stream Analytics peut prendre en charge des débits allant jusqu’à 200 Mo/s lors de l’écriture dans Azure Synapse Analytics.

Archivage des données en temps réel pour l’analytique

La plupart des activités d’analytique et de science des données s’effectuent encore hors connexion. Les données peuvent être archivées sur Azure Stream Analytics via les formats de sortie Azure Data Lake Store Gen2 et Parquet. Cette fonctionnalité supprime la difficulté d’alimenter directement en données Azure Data Lake Analytics, Azure Databricks et Azure HDInsight. Azure Stream Analytics sert de moteur ETL en quasi temps réel dans cette solution. Vous pouvez explorer des données archivées dans Data Lake avec différents moteurs de calcul.

Utiliser les données de référence pour l’enrichissement

L’enrichissement des données constitue souvent une condition exigée pour les moteurs ETL. Azure Stream Analytics prend en charge l’enrichissement des données avec les données de référence provenant de la base de données SQL et du stockage Blob Azure. L’enrichissement des données peut être effectué pour l’arrivage de données dans Azure Data Lake et dans Azure Synapse Analytics.

Rendre des insights opérationnels à partir de données archivées

Si vous combinez le modèle d’analytique hors connexion avec le modèle d’application en quasi temps réel, vous pouvez créer une boucle de rétroaction. La boucle de rétroaction permet à l’application de s’ajuster automatiquement aux modifications des modèles dans les données. Cette boucle de rétroaction peut se révéler aussi simple qu’une modification de la valeur du seuil d’alerte, ou aussi complexe que le réentraînement des modèles Machine Learning. La même architecture de solution peut être appliquée autant aux travaux ASA s’exécutant dans le cloud que sur IoT Edge.

Guide pratique pour superviser les travaux ASA

Un travail Azure Stream Analytics peut s’exécuter 24/24 7/7 pour traiter des événements entrants sans interruption en temps réel. Sa garantie de durée de fonctionnement est cruciale pour l’intégrité de l’application dans son ensemble. Même si Stream Analytics est le seul service d’analytique en streaming du secteur qui offre une garantie de disponibilité de 99,9 %, vous risquez tout de même de connaître quelques temps d’arrêt. Au fil des années, Stream Analytics a introduit les métriques, les journaux et les états des tâches pour refléter l’intégrité des travaux. Tous sont exposés via le service Azure Monitor, et peuvent même être exportés vers OMS. Pour plus d’informations, consultez Effectuer le monitoring d’un travail Stream Analytics avec le portail Azure.

Il y a deux éléments clés à surveiller :

• État d’échec du travail

  Avant toute chose, vous devez vous assurer que le travail est en cours d’exécution. Sans travail associé à un état en cours d’exécution, aucune nouvelle métrique et aucun journal n’est généré. Les tâches peuvent afficher un état d’échec pour diverses raisons, comme un niveau d’utilisation d’unité de stockage élevé (autrement dit, des ressources insuffisantes).

• Métrique du délai en filigrane

  Cette métrique reflète le retard pris par votre pipeline de traitement en temps Horloge (secondes). Un certain délai est attribué à la logique de traitement inhérente. En conséquence, la supervision de la tendance croissante est beaucoup plus importante que la surveillance de la valeur absolue. Le délai de l’état stable devrait être corrigé par la conception de votre application, pas par la supervision ou les alertes.

En cas d’échec, les journaux d’activité et les journaux de diagnostic sont les meilleurs endroits où commencer à rechercher des erreurs.

Créer des applications stratégiques et résilientes

Quels que soient la garantie du contrat SLA d’Azure Stream Analytics utilisé et le soin que vous apportez à exécuter votre application de bout en bout, des pannes se produisent. Si votre application est stratégique, vous devez être prêt à réagir face aux interruptions, afin de procéder à une récupération correctement.

Pour les applications de génération d’alertes, le plus important est de détecter l’alerte suivante. Vous pouvez choisir de redémarrer la tâche à l’heure en cours au moment de la récupération, et donc d’ignorer les alertes passées. La sémantique de l’heure de début du travail s’établit en fonction de la première heure de sortie, pas de la première heure d’entrée. L’entrée est rembobinée vers l’arrière, jusqu’à une quantité appropriée de temps permettant de garantir que la première sortie à l’heure spécifiée est complète et correcte. En procédant ainsi, vous n’obtenez aucun agrégat partiel et ne déclenchez aucune alerte de façon inattendue.

Vous pouvez également choisir de démarrer la sortie à partir d’un certain moment dans le passé. Les stratégies de conservation Event Hubs et IoT Hub contiennent une quantité raisonnable de données permettant d’autoriser le traitement dans le passé. Le compromis tient dans la rapidité avec laquelle vous pouvez rattraper le retard par rapport à l’heure actuelle, et commencer à générer de nouvelles alertes dans les délais. Les données perdent rapidement leur valeur au fil du temps, il est donc important de rattraper au plus vite l’heure actuelle. Il existe deux façons de rattraper rapidement un retard :

• Provisionner davantage de ressources (SU) lors du rattrapage du retard.
• Redémarrer à partir de l’heure actuelle.

Le redémarrage à l’heure actuelle est simple à réaliser, en acceptant le compromis de devoir laisser un intervalle vide lors du traitement. Le redémarrage par ce moyen peut accessoirement fonctionner pour les scénarios d’alerte, mais s’avérer problématique avec les scénarios de tableau de bord, et être voué à l’échec pour l’archivage et les scénarios d’entreposage de données.

Le provisionnement de ressources supplémentaires peut accélérer le processus, mais l’effet d’une augmentation brutale de la vitesse de traitement est complexe.

• Vérifiez que votre travail peut être mis à l’échelle sur un plus grand nombre de SU. Les requêtes ne sont pas toutes adaptables. Vous devez vous assurer que votre requête est parallélisée.

• Veillez à ce qu’il existe suffisamment de partitions en amont dans les services Event Hubs ou IoT Hub pour que vous puissiez ajouter plus d’unités de débit (TU) et ainsi mettre à l’échelle le débit d’entrée. N’oubliez pas, chaque TU Event Hubs atteint la limite maximale à une vitesse de sortie de 2 Mo/s.

• Assurez-vous d’avoir approvisionné suffisamment de ressources dans les récepteurs de sortie (c’est-à-dire SQL Database, Azure Cosmos DB), afin qu’ils ne limitent pas la surtension en sortie, qui peut parfois entraîner le blocage du système.

L’essentiel est plus de tout d’anticiper la modification de la vitesse de traitement, de tester ces scénarios avant la mise en production, et d’être prêt à la mise à l’échelle correcte du traitement pendant la durée de récupération après une défaillance.

Dans le scénario extrême où les événements entrants sont tous retardés, il est possible que tous les événements différés soient supprimés si vous avez appliqué une plage d’arrivée tardive à votre travail. La suppression des événements peut sembler étrange au début, mais si l’on considère que Stream Analytics est un moteur de traitement en temps réel, celui-ci s’attend donc à ce que les événements entrants soient proches de l’heure indiquée sur l’horloge. Il doit donc supprimer les événements qui violent ces contraintes.

Architectures lambda ou processus de renvoi

Heureusement, le modèle d’archivage de données précédent peut être utilisé pour traiter normalement ces événements tardifs. L’idée est que le travail d’archivage traite les événements entrants à l’heure d’arrivée, et archive les événements dans le compartiment du moment opportun, dans un objet blob Azure ou dans Azure Data Lake Store, avec leur heure d’événement. Peu importe l’heure tardive à laquelle un événement arrive, il n’est jamais supprimé. Il est toujours placé dans le compartiment du moment opportun. Lors de la récupération, il est possible de retraiter les événements archivés et de renvoyer les résultats dans le magasin voulu. Cela est similaire à la façon dont les modèles lambda sont implémentés.

Le processus de renvoi doit être effectué avec un système de traitement par lots hors connexion ; celui-ci a probablement un autre modèle de programmation qu’Azure Stream Analytics. Cela signifie que vous devez réimplémenter la logique de traitement complète.

Pour un renvoi, il demeure important de provisionner au moins temporairement plus de ressources sur les récepteurs de sortie, afin de gérer un débit plus élevé que les besoins du traitement de l’état stable.

Exemple complet

Évidemment, tous les modèles de solution mentionnés ci-dessus sont combinables entre eux, dans un système de bout en bout complexe. Le système composé peut inclure des fonctionnalités de tableaux de bord, d’alertes, d’application de provisionnement en événements, d’entreposage de données et d’analytique hors connexion.

L’essentiel est de concevoir votre système dans des modèles composables, de telle sorte que chaque sous-système peut être généré, testé, mis à niveau et récupéré séparément.

Étapes suivantes

Vous venez de découvrir différents modèles de solution avec Azure Stream Analytics. Pour approfondir ces connaissances et créer votre premier travail Stream Analytics, consultez les articles suivants :

• Créer un travail Stream Analytics à l’aide du portail Azure.
• Créer un travail Stream Analytics à l’aide d’Azure PowerShell.
• Créer un travail Stream Analytics à l’aide de Visual Studio.