Adieu la latence ! Passez au temps réel avec les Eventstreams 

Dans notre dernier article (intitulé, pour les retardataires, Votre reporting est lent... ), nous avions exploré les limites frustrantes des rapports statiques. Dans un monde en perpétuelle évolution comme le nôtre, attendre le rapport de demain pour comprendre ce qui s'est passé hier, c'est un peu comme conduire en regardant seulement dans le rétroviseur.

Pour résumer ce dont nous avions discuté : ce délai entre le moment où un événement se produit réellement et celui où il daigne apparaître dans votre reporting s'appelle le delay latency.

Ce n'est pas juste un petit retard ; c'est un véritable angle mort. C'est la période de flou durant laquelle les erreurs passent inaperçues, et commencent à faire de gros dégâts.

Afin de contrer ce genre de phénomène, Microsoft Fabric propose plusieurs outils dans sa boîte à outils. Aujourd'hui, nous allons nous pencher sur l'un des plus puissants : l'Eventstream.

Un eventstream, kezako?

Microsoft Fabric Eventstream est une solution de streaming de données en temps réel et sans code (no-code) qui capture, transforme et achemine (route) des événements provenant de multiples sources vers diverses destinations au sein de l'écosystème Fabric. 

Contrairement aux outils traditionnels de BI qui extraient les données (mode "pull"), Eventstream agit comme un écouteur d'événements (event listener) qui attend que des messages lui soient envoyés (poussés), permettant ainsi un véritable traitement des données en temps réel. C'est un composant fondamental de l'intelligence en temps réel (Real-Time Intelligence) de Microsoft Fabric, fournissant un canevas visuel unifié et sans code pour créer des flux de données en streaming. Eventstream est robuste et évolutif (scalable), propulsé par Azure Event Hubs, et offre un point de terminaison Apache Kafka natif pour une intégration transparente. Son éditeur visuel et sa large gamme de connecteurs intégrés démocratisent l'analyse en temps réel, la rendant accessible à un public plus large, au-delà des simples ingénieurs de données. 

Sur l'image ci-dessus, vous pouvez admirer le squelette d'un projet Eventstream dans Microsoft Fabric. 

Un Eventstream, c'est comme un entonnoir géant. Il commence par une (ou plusieurs) source(s) de données. Et croyez-moi, Fabric n'est pas difficile : il accepte pas mal de monde à sa table.

On peut diviser les sources en deux catégories :

1. Les Sources Externes (Les invités)

• Azure Event Hubs : Pour le streaming d'événements à très haut débit.

• Azure IoT Hub : Pour écouter ce que vos appareils IoT ont à dire (même votre frigo connecté, s'il est bavard).

• Azure Service Bus : Pour les scénarios de messagerie d'entreprise.

• Capture de données modifiées (CDC) : Pour espionner les changements dans vos bases de données (Azure SQL, PostgreSQL, MySQL, Cosmos DB...).

• Plateformes Cloud : Fabric n'est pas sectaire et s'intègre avec Google Cloud Pub/Sub, Amazon Kinesis et Confluent Cloud Kafka.

• Custom endpoint : Pour vos applications "maison" et les clients Kafka qui aiment les connexions personnalisées (protocoles Event Hub, AMQP, Kafka).

2. Les Sources Natives de Fabric (La famille)

• Événements de workspaces : Pour savoir qui fait quoi dans vos espaces de travail (le Big Brother de Fabric).

• Événements OneLake : Surveille les modifications de fichiers et dossiers dans OneLake

• Événements de Job Event : Suit à la trace l'exécution de vos pipelines et notebooks.

• Événements Azure Blob Storage : Détecte la création, la modification, la suppression... bref, la vie d'un fichier blob.

Comme on le voit, Eventstream ne se contente pas de surveiller les données elles-mêmes, il surveille aussi ce qui se passe dans Fabric (les méta-données). C'est parfait pour fliquer (pardon, "suivre") l'utilisation d'un workspace spécifique.

le Transformateur d'événements

Tous les événements générés sont donc capturés par l'Eventstream, qui les passe à la deuxième catégorie d'éléments : la transformation d'événements.

C'est la station de lavage et de maquillage du flux. Fabric nous gâte avec une interface drag and drop pour filtrer, enrichir ou redéfinir les données, le tout (presque) sans taper une ligne de code. Pas besoin d'être un développeur pour faire des miracles.

Voici les transformations disponibles :

• Filtrer : Filtre les événements en fonction des valeurs présentes ou non dans une colonne spécifique.

• Gérer les champs:  Permet d'ajouter, de supprimer, de renommer ou de changer le type d'un champ (le "string" devient un "int" magiquement).

• Agréger : Effectue des agrégations (somme, moyenne, min, max...) sur une période de temps donnée.

• Join : Permet de combiner des données provenant de deux flux différents basés sur une valeur commune.

• Group by : Permet de créer des agrégations complexes en utilisant des fenêtres de temps.

• Union : Combine deux ou plusieurs sources qui ont des colonnes similaires.

• Expand : Permet d'extraire les valeurs contenues dans un array.

Une fois que les données sont propres et apprêtées, elles peuvent partir pour leur dernière étape : la destination. C'est ici que les données transformées (ou non) seront exploitées. 

Les destinations

Il existe plusieurs types de destinations :

• Lakehouse : Le grand hangar. Le but est de pouvoir stocker les événements à moindre coût pour les historiser. (Attention, les streams ont une période de rétention comprise entre 1 et 90 jours, ce n'est pas un stockage éternel non plus !)

• Eventhouse : Le QG du temps réel. Le but est de stocker les données afin de pouvoir construire des rapports live qui clignotent à partir de cette solution de stockage.

• Derivated Stream (Flux dérivé) : Le "petit" du flux principal. Permet de stocker le résultat (souvent filtré) afin de pouvoir le retrouver dans l'onglet "Real time". Le but est de créer un flux propre pour le partager avec d'autres utilisateurs. (Note perso : J'espère qu'il sera bientôt possible de redémarrer un Eventstream à partir de ces flux dérivés, ce qui permettrait de simplifier la logique... mais ce n'est pas encore implémenté. Un jour, Microsoft, un jour...)

• Custom endpoint : La porte de sortie. Il est également possible de remonter ce flux tout neuf dans une application externe via un endpoint.

• Data Activator : Et le meilleur pour la fin... Probablement l'utilisation la plus bluffante des Eventstreams. (Mais c'est un sujet tellement vaste qu'il mérite son propre article !)

Et cerise sur le gateau, un event stream peut contenir plusieurs destinations, ce qui permet de rationaliser les couts, car oui, il y a un cout derriere tout ça

Le fait d'avoir un eventstream qui tourne, vous coutera 0.22CU par heure par event stream, ce qui signifie donc, que si vous avez 10 event streams, vous serez à 2.22CU par heure (donc si vous avez une capacité F2, ce qui represente 2CU par hour, vous venez de tuer votre capacité (RIP petit ange parti trop tot))

Il y a également un cout concernant la volumetrie de données,  0.342 CU par gigabyte, ici, le cout est assez faible car meme en prenant un sample générant enormement de d"échantillons, le cout reste releaitvement bas (on ne fait pas de l'analyse video en RT(pour le moment) dans Fabric)

Par contre, l'élément qui peut faire exploser votre consommation assez rapidement, est l'eventhouse (mais nous nous pencherons sur cet element en particulier lors d'un article futur)

Pour faire simple, l'Eventstream est le système nerveux central de vos données en temps réel dans Fabric.

Il capte (Sources), il affine (Transformations) et il distribue (Destinations).

C'est l'outil parfait pour réagir pendant l'incendie plutôt qu'après. Mais n'oubliez pas que les pompiers coûtent cher : chaque stream consomme des CUs en permanence, alors surveillez votre budget pour éviter que votre capacité  ne parte en fumée.

On a vu le "quoi", le "comment" et le "où". Il nous reste le "ET ALORS ?"

C'est le sujet de notre prochain article : on branche tout ça sur le Data Activator pour que vos données se mettent enfin au travail toutes seules.