REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

PAIX-TRAVAIL-PATRIE PEACE-WORK-FATHERLAND
********** **********
UNIVERSITE DE DOUALA THE UNIVERSITY OF DOUALA
******** ********
ECOLE DOCTORALE DES SCIENCES POSTGRADUATE SCHOOL FOR
FONDAMENTALES ET APPLIQUEES PURE AND APPLIED SCIENCES
********** ********
LABORATOIRE D’INFORMATIQUE APPLIED COMPUTER SCIENCE
APPLIQUEE LABORATORY

Master II Recherche

LE STREAMING

Réalisé par :
Noms et prénoms Matricules

DJOULAKO Camel Léonce

TCHAMO NOUSSI Franck Loic
SOMBSI Adèle Marguerite

Enseignant : Dr. Justin MOSKOLAI

Année Académique : 2020-2021

Table des matières

Table des matières............................................................................................................................1

Introduction......................................................................................................................................3

I. Présentation générale................................................................................................................4

1. Flux de données (Streaming data).........................................................................................4

2. Qu'est-ce que le streaming ?..................................................................................................5

3. Fonctionnement du streaming data........................................................................................6

a. Présentation du Stream Data Processing (traitement de flux de données)........................6

b. Quelques exemples............................................................................................................7

c. Batch Processing vs Real-Time Streams...........................................................................7

d. Avantages du streaming de données..................................................................................8

e. Cas d'utilisation..................................................................................................................8

II. Architecture de Big Data.....................................................................................................10

1- Pourquoi mettre en place une architecture Big Data ?...........................................................10

2- Les composants d’une architecture Big Data.........................................................................10

3- Les principaux types d’architecture Big Data........................................................................13

3-1 l’Architecture Lambda......................................................................................................14

3-2 L’Architecture Kappa.......................................................................................................16

3-3 Architecture Big Data pour l’IOT.....................................................................................17

III. Traitement en temps réel.....................................................................................................20

1. Définition.............................................................................................................................20

2. Défis....................................................................................................................................20

3. Architecture.........................................................................................................................21

1
 4. Choix de technologies.........................................................................................................21

Conclusion......................................................................................................................................24

Références : livres et articles..........................................................................................................25

2
Introduction

Le Big Data a atteint son paroxysme ces dernières années avec les objets connectés et
l’intégration des capteurs dans les objets de la vie courante (voiture, réfrigérateur, télévision,
thermostats, vêtements …). En 2019, on dénombre près de 15 milliards d’objets connectés dans
le monde et depuis janvier 2021 il y a environ 30 milliards d’objets connectés avec un
accroissement de 20% selon le Magazine lemonde.fr. Beaucoup de cas d’usage et de modèles
économiques s’appuient aujourd’hui sur des données générées en streaming. Il peut s’agir
d’applications opérationnelles d’entreprises, de l’analyse du parcours client d’un site web, de la
recommandation en temps réel, de la détection de fraude, de la cyber sécurité et du tracking des
internautes. Au-delà de leur débit, et de la vitesse avec laquelle elles sont produites, les données
streaming se caractérisent principalement par un délai de péremption. Selon IBM, 60% de celles-
ci perdent de leur valeur métier dans les instants qui suivent leur création. Elles doivent être donc
traitées à l’immédiat ou en temps réel pour être valorisées.

3
 I. Présentation générale

1. Flux de données (Streaming data)

Également connu sous le nom de traitement de flux d’événements (Event Stream Processing), le
Streaming data est le flux continu de données générées par diverses sources. En utilisant la
technologie de traitement de flux (stream processing technology), les flux de données peuvent
être traités, stockés, analysés et exploités au fur et à mesure qu'ils sont générés en temps réel.

En d’autre termes, le streaming data ou encore Event Stream Processing) est le traitement ou
l'analyse de flux continus d'événements. Les plateformes d'Event Stream Processing traitent les
données entrantes tandis qu'elles arrivent. Celui-ci effectue des calculs ultra-rapides et continus
sur des données diffusées en continu à grande vitesse, et utilisent un moteur de requêtes continu
qui déclenche des alertes et des actions en temps réel, ainsi que des visualisations en direct et

Figure 1 : Diagramme du flux de données

configurées par l'utilisateur.

Un événement est défini comme un changement d'état tel qu'une transaction ou un prospect
naviguant sur votre site web. Un événement est essentiellement un point de données capturé dans
un système d'entreprise. Un flux d'événements est une séquence d'événements commerciaux
ordonnés dans le temps. Les clients sont constamment en train d'acheter, d'appeler le service
d'assistance ou de remplir leur panier dans un flux constant d'événements quotidiens dans toute
entreprise.

4
L'Event stream processing suit et traite activement les flux d'événements dans une entreprise afin
d'identifier de manière proactive les opportunités, les risques et d'optimiser les résultats
commerciaux. L'approche traditionnelle du traitement des données (stockage, analyse et action)
pose le problème fondamental de la latence des décisions. Les informations sont souvent les plus
pertinentes dès qu'elles sont capturées, et le traitement des événements aide les organisations à
traiter ces informations de manière plus rapide. Il permet de résoudre de nombreux problèmes :
identifier la fraude au moment où elle se produit, proposer une offre contextuelle alors que le
client est encore dans le magasin, ou prévoir les perturbations pour minimiser les retards. Avec la
nécessité de traiter les données en temps réel, l'event processing devient de plus en plus
important.

2. Qu'est-ce que le streaming ?

Le terme « streaming » est utilisé pour décrire des flux de données (data streams) continus et
sans fin, qui fournissent un flux constant de données pouvant être utilisées sans avoir besoin
d'être téléchargées au préalable.

De même, les flux de données sont générés par tous types de sources, dans divers formats et
volumes. Qu’il s’agisse d’applications, d’appareils mis en réseau ou des fichiers journaux de
serveur, d'activité sur le site Web, de transactions bancaires ou de données de localisation, ils
peuvent tous être agrégés pour collecter de manière transparente des informations et des analyses
en temps réel à partir d'une seule source de vérité.

5
 3. Fonctionnement du streaming data

Figure 2 : Database streaming

Au cours des années précédentes, l'infrastructure existante était beaucoup plus structurée car elle
ne disposait que d'une poignée de sources générant des données. L'ensemble du système pourrait
être architecturé de manière à spécifier et à unifier les données et les structures de données. Avec
l'avènement des systèmes de traitement de flux, la façon dont nous traitons les données a
considérablement changé pour répondre aux exigences modernes.

a. Présentation du Stream Data Processing (traitement de flux de données)

De nos jours, les données sont générées par une quantité infinie de sources : capteurs IoT,
serveurs, journaux de sécurité, applications ou systèmes internes/externes. Il est presque

6
impossible de réguler la structure, l'intégrité des données ou de contrôler le volume ou la vitesse
des données générées.

Bien que les solutions traditionnelles sont conçues pour ingérer, traiter et structurer les données
avant qu'elles ne puissent être utilisées, l'architecture de données en streaming ajoute la
possibilité de consommer, de conserver, de stocker, d'enrichir et d'analyser les données en
mouvement.

Ainsi, les applications fonctionnant avec des flux de données (data streams) nécessiteront
toujours deux fonctions principales : le stockage et le traitement. Le stockage doit pouvoir
enregistrer de grands flux de données de manière séquentielle et cohérente. Le traitement doit
pouvoir interagir avec le stockage, consommer, analyser et exécuter des calculs sur les données.

b. Quelques exemples

Certains exemples réels de données en streaming incluent des cas d'utilisation dans tous les
secteurs, y compris les transactions boursières en temps réel, la gestion des stocks en temps réel,
les flux de médias sociaux, les interactions de jeu multi-joueurs et les applications de
covoiturage.

Par exemple, lorsqu'un passager appelle Lyft, des flux de données en temps réel se rejoignent
pour créer une expérience utilisateur transparente. Grâce à ces données, l'application rassemble le
suivi de localisation en temps réel, les statistiques de trafic, les prix et les données de trafic en
temps réel pour faire correspondre simultanément le passager avec le meilleur conducteur
possible, calculer les prix et estimer le temps jusqu'à la destination en fonction à la fois du temps
réel et les données historiques.

7
En ce sens, le streaming de données est la première étape pour toute organisation axée sur les
données, alimentant l'ingestion, l'intégration et l'analyse en temps réel du Big Data.

c. Batch Processing vs Real-Time Streams

Les méthodes de traitement de données par lots nécessitent que les données soient téléchargées
par lots avant de pouvoir être traitées, stockées ou analysées, tandis que les données en continu
circulent en continu, permettant à ces données d'être traitées simultanément, en temps réel à la
seconde où elles sont générées.

Aujourd'hui, les données arrivent naturellement sous forme de flux d'événements sans fin. Ces
données sont disponibles dans tous les volumes, formats, à partir de divers emplacements et
cloud, sur site ou cloud hybride.

Avec la complexité des exigences modernes d'aujourd'hui, les méthodes de traitement des
données héritées sont devenues obsolètes pour la plupart des cas d'utilisation, car elles ne peuvent
traiter les données que sous forme de groupes de transactions collectées au fil du temps. Les
organisations modernes doivent agir sur des données à la milliseconde près, avant que les
données ne deviennent obsolètes. Ces données continues offrent de nombreux avantages qui
transforment le fonctionnement des entreprises.

d. Avantages du streaming de données

La collecte de données n'est qu'une pièce du puzzle. Les entreprises d'aujourd'hui ne peuvent tout
simplement pas attendre que les données soient traitées par lots. Au lieu de cela, tout, de la
détection des fraudes aux plateformes boursières, aux applications de covoiturage et aux sites
Web de commerce électronique, repose sur des flux de données en temps réel.

8
Associées aux données de streaming, les applications évoluent non seulement pour intégrer les
données, mais aussi pour traiter, filtrer, analyser et réagir à ces données en temps réel, au fur et à
mesure qu'elles sont reçues. Cela ouvre une nouvelle pléthore de cas d'utilisation tels que la
détection de fraude en temps réel, les recommandations Netflix ou une expérience d'achat
transparente sur plusieurs appareils qui se met à jour au fur et à mesure que vous magasinez.

En bref, toute industrie qui traite des méga données peut bénéficier de données continues et en
temps réel bénéficiera de cette technologie.

e. Cas d'utilisation

Les systèmes de traitement de flux (Stream processing systems) comme Apache Kafka et
Confluent donnent vie aux données et aux analyses en temps réel. Bien qu'il existe des cas
d'utilisation du streaming de données dans tous les secteurs, cette capacité à intégrer, analyser,
dépanner et/ou prévoir des données en temps réel, à grande échelle, ouvre de nouveaux cas
d'utilisation. Les organisations peuvent non seulement utiliser des données antérieures ou des
données par lots stockées, mais également obtenir des informations précieuses sur les données en
mouvement.

Les cas d'utilisation typiques incluent :

 Données de localisation
 Détection de fraude
 Transactions boursières en temps réel
 Marketing, ventes et analyse commerciale
 Activité client/utilisateur
 Suivi et reporting des systèmes informatiques internes

9
 Surveillance des journaux : dépannage des systèmes, serveurs, appareils, etc.
 SIEM (Security Information and Event Management) : analyse des journaux et des
données d'événements en temps réel pour la surveillance, les métriques et la détection des
menaces
 Inventaire de vente au détail/d'entrepôt : gestion des stocks sur tous les canaux et
emplacements, et offre une expérience utilisateur transparente sur tous les appareils
 Correspondance de covoiturage : combinaison de données de localisation, d'utilisateur et
de tarification pour une analyse prédictive - mise en correspondance des passagers avec
les meilleurs conducteurs en termes de proximité, de destination, de tarification et de
temps d'attente
 Apprentissage automatique et IA : en combinant des données passées et présentes pour un
système nerveux central,
 L’analyse prédictive offre de nouvelles possibilités.

10
II. Architecture de Big Data

1- Pourquoi mettre en place une architecture Big Data ?

Les systèmes de bases de données traditionnels ne permettent plus de répondre aux exigences
imposées par le Big Data. Ils ne sont plus à mesure de traiter des volumes de données aussi
massifs et assez rapidement. C’est pourquoi, pour pouvoir profiter des avantages du Big Data, il
faut repousser les limites des écosystèmes notamment en termes de volume, de vitesse de
traitement et de variété des données à manager.

Une architecture Big Data est conçue pour gérer l’ingestion, le traitement et l’analyse de
données trop volumineuses ou complexes pour les systèmes de base de données traditionnels. Le
seuil à partir duquel les organisations basculent dans le domaine Big Data varie selon les
capacités des utilisateurs et leurs outils. Pour certaines, ce seuil est fixé à plusieurs centaines de
giga-octets de données, tandis que pour d’autres, il s’agit de centaines de téraoctets.
L’amélioration des outils de gestion du Big Data redéfinit la notion même de Big Data. Ce terme
est de plus en plus associé à la valeur que vous pouvez tirer de vos jeux de données via une
analytique avancée, plutôt qu’à la taille stricte des données, bien que dans ce cas, ces données ont
tendance à être très volumineuses.

En mettant en place une architecture Big Data adaptée dans son entreprise, une organisation va
pouvoir effectuer :

 Un traitement par lots des sources Big Data au repos.

 Un traitement en temps réel des Big Data en mouvement

 Une exploration interactive des Big Data.

 Une Analyse prédictive

 Des tâches basées sur les technologies d’apprentissage machine et de l’intelligence

artificielle.

Il est donc conseiller d’utiliser des architectures Big Data lorsque vous devez :

11
  Stocker et traiter des données dans des volumes trop vastes pour une base de données
traditionnelle.

 Transformer des données non structurées en vue d’une analyse et de la création de

rapports.

 Capturer, traiter et analyser des flux de données indépendants en temps réel ou avec une
faible latence.

2- Les composants d’une architecture Big Data

La plupart des architectures Big Data incluent tout ou une partie des composants suivants :

 Sources de données : Toutes les solutions Big Data reposent sur une ou plusieurs sources
de données. Voici quelques exemples :

◦ Magasins de données d’application (data mart), tels que des bases de données
relationnelles.
◦ Fichiers statiques produits par les applications, tels que les fichiers journaux de
serveur web.
◦ Sources de données en temps réel, tels que les appareils IoT.
◦ Base de données hybride, cloud, datawarehouse

 Stockage des données : Les données destinées aux opérations de traitement par lots sont
généralement stockées dans un magasin de fichiers distribués, qui peut contenir de vastes
volumes de fichiers volumineux dans divers formats. Ce type de magasin est souvent
appelé «Data Lake ou lac de données ». (ex : Les options pour l’implémentation de ce
stockage incluent des conteneurs Azure Data Lake Store ou les conteneurs blob dans le
stockage Azure.)

 Traitement par lots : Étant donné que les jeux de données sont trop lourds, une solution
Big Data doit souvent traiter les fichiers de données à l’aide de traitements par lots à
longue durée d’exécution pour filtrer, agréger et préparer les données en vue de l’analyse.
Généralement, ces travaux impliquent la lecture des fichiers source, leur traitement et
l’écriture de la sortie dans de nouveaux fichiers. Les options incluent l’exécution de

12
 travaux U-SQL dans Azure Data Lake Analytics, à l’aide de travaux personnalisés de
mappage/réduction, Pig ou Hive dans un cluster HDInsight Hadoop ou à l’aide des
programmes Java, Scala ou Python dans un cluster HDInsight Spark.

 Ingestion de messages en temps réel : Si la solution inclut des sources en temps réel,
l’architecture doit inclure un moyen pour capturer et stocker des messages en temps réel
pour le traitement de flux de données. Il peut s’agir d’un simple magasin de données, où
les messages entrants sont déposés dans un dossier en vue du traitement. Toutefois, de
nombreuses solutions ont besoin d’un magasin d’ingestion des messages qui agit comme
une mémoire tampon pour les messages et qui prend en charge un traitement de montée
en puissance, une remise fiable et d’autres sémantiques de files d’attente de message.
Cette partie d’une architecture de diffusion est communément appelée mise en mémoire
tampon du flux. Les options incluent Azure Event Hubs, Azure IoT Hub et Kafka.

 Traitement de flux. Après avoir capturé les messages en temps réel, la solution doit les
traiter en filtrant, en agrégeant et, plus généralement, en préparant les données pour
l’analyse. Les données de flux traitées sont ensuite écrites dans un récepteur de sortie.
Azure Stream Analytics fournit un service de traitement de flux managé reposant sur des
requêtes SQL à l’exécution permanente qui fonctionnent sur les flux de données
indépendants. Vous pouvez également utiliser des technologies de flux Apache open
source comme Storm et Spark dans un cluster HDInsight.

 Magasin de données analytique. De nombreuses solutions Big Data préparent les

données pour l’analyse, puis fournissent les données traitées dans un format structuré qui
peut être interrogé à l’aide des outils d’analyse. Le magasin de données analytique utilisé
pour répondre à ces requêtes peut être un entrepôt de données relationnelles de type
Kimball, comme indiqué dans les solutions décisionnelles (BI) plus traditionnelles. Les
données peuvent également être présentées via une technologie NoSQL à faible latence,
telle que HBase, ou via une base de données Hive interactif qui fournit une abstraction de
métadonnées sur les fichiers de données dans le magasin de données distribuées. Azure
Synapse Analytics fournit un service managé pour l’entreposage cloud des données à
grande échelle. HDInsight prend en charge les formats Hive interactif, HBase et Spark
SQL, qui peuvent également servir à préparer les données en vue de l’analyse.

13
 Analyse et rapports. La plupart des solutions Big Data ont pour but de fournir des
informations sur les données par le biais de l’analyse et des rapports. Pour permettre aux
utilisateurs d’analyser les données, l’architecture peut inclure une couche de modélisation
des données, comme un cube OLAP multidimensionnel ou un modèle de données
tabulaire dans Azure Analysis Services. Elle peut également prendre en charge le
décisionnel libre-service, en utilisant les technologies de modélisation et de visualisation
de Microsoft Power BI ou Microsoft Excel. L’analyse et les rapports peuvent aussi
prendre la forme d’une exploration interactive des données par les scientifiques de
données ou les analystes de données. Pour ces scénarios, plusieurs services Azure
prennent en charge les blocs-notes analytiques, tels que Jupiter, ce qui permet à ces
utilisateurs de tirer parti de leurs connaissances avec Python ou R. Pour l’exploration de
données à grande échelle, vous pouvez utiliser Microsoft R Server seul ou avec Spark.

 Orchestration. La plupart des solutions Big Data consistent en des opérations de

traitement de données répétées, encapsulées dans des workflows, qui transforment les
données source, déplacent les données entre plusieurs sources et récepteurs, chargent les
données traitées dans un magasin de données analytique, ou envoient les résultats
directement à un rapport ou à un tableau de bord. Pour automatiser ces workflows, vous
pouvez utiliser une technologie d’orchestration telle qu’Azure Data Factory ou Apache
Oozie avec Sqoop.

14
Le diagramme ci-dessus montre les composants logiques qui constituent une architecture Big
Data. Certaines solutions individuelles ne contiennent pas tous les éléments de ce diagramme.

En fonction du type d’architecture choisi et adopté, certains de ces composants seront absents,
mutualisés ou combinés dans la structure.

3- Les principaux types d’architecture Big Data

Il existe 2 principaux types d’architecture Big Data à savoir Lambda et Kappa. Chacune des
architectures permet de répondre à un besoin spécifique. Le choix du modèle architectural le plus
adapté à votre stratégie dépend de vos besoins, de vos infrastructures existantes, de vos objectifs
et de votre contexte métier.

- Notion d’architecture distribuée

Lorsque l’on souhaite mener des projets data-driven (gouverné ou dirigé par la donnée), il faut
avoir que c’est une architecture distribuée qui doit être implémentée pour considérer les
problèmes de scalabilité, de performance et de synchronisation des différentes couches.

15
Etant donné que la quantité de données Big Data à stocker dépasse les capacités de traitement et
de stockage des systèmes traditionnels qui n’utilise qu’une machine unique, il est nécessaire de
mettre en place des architectures dites distribuées. Concrètement, cela revient à diviser la charge
de stockage et de traitement d’une machine sur plusieurs machines afin de gagner en rapidité, en
réactivité et en performance.

Les solutions Lambda et Kappa reposent sur ce système puisque, comme précisé ci-dessous, les
tâches d’intégration, de traitement et de stockage sont réparties en plusieurs couches.

3-1 l’Architecture Lambda

Elle a été créée pour la première fois par Nathan Marz, c’est l’architecture la plus couramment
utilisée pour le traitement et la gestion des données volumineuses en temps réel et par lots de
manière simultanée.

Lorsque vous utilisez des jeux de données très volumineux, l'exécution des requêtes des clients
peut prendre beaucoup de temps.

Ces requêtes ne peuvent pas être effectuées en temps réel et nécessitent souvent des algorithmes
comme MapReduce, qui s’exécutent en parallèle sur l’ensemble du jeu de données. Les résultats
sont ensuite stockés séparément des données brutes et utilisés à des fins d’interrogation.

L’inconvénient de cette approche est qu’elle entraîne une latence. si le traitement dure quelques
heures, une requête peut donc retourner des résultats datant de plusieurs heures. Dans l’idéal,
vous devez obtenir des résultats en temps réel (malgré une certaine perte de précision) et
combiner ces résultats avec ceux de l’analyse en mode batch.

L’architecture lambda, proposée pour la première fois par Nathan Marz, résout ce problème en
créant deux chemins d’accès aux flux de données. Toutes les données entrantes dans le système
transitent par ces deux chemins d’accès :

16
 Une couche de traitement par lots (chemin à froid) stocke toutes les données entrantes
dans leur forme brute et effectue un traitement par lots de ces données. Le résultat de ce
traitement est stocké sous forme d’une vue de traitement par lots.

 Une couche vitesse (chemin réactif) analyse les données en temps réel. Cette couche est
conçue pour une faible latence, au détriment de la précision.

La couche de traitement par lots alimente une couche service qui indexe la vue de
traitement par lots pour améliorer l’interrogation. La couche vitesse met à jour de la
couche service avec les mises à jour incrémentielles basées sur les données les plus
récentes.

17
 Fig. Architecture Lambda

Les données qui circulent dans le chemin réactif sont limitées par les conditions de latence
imposées par la couche vitesse, afin de garantir un traitement aussi rapide que possible. Souvent,
cela nécessite d’accepter une certaine perte de précision afin d’obtenir les données aussi
rapidement que possible. Par exemple, imaginons un scénario IoT où un grand nombre de
capteurs de température transmettent des données de télémétrie. La couche vitesse permet de
traiter les données entrantes dans une fenêtre temporelle coulissante.

En revanche, les données qui transitent par le chemin à froid ne sont pas soumises aux mêmes
exigences de faible latence. Cela permet d’obtenir un calcul plus précis sur plusieurs jeux de
données volumineux, une tâche qui peut prendre beaucoup de temps.

Pour finir, le chemin relatif et le chemin à froid convergent au niveau de l’application cliente
analytique. Si le client a besoin d’afficher en temps opportun des données potentiellement moins
précises en temps réel, il obtiendra son résultat avec le chemin réactif. Sinon, il devra
sélectionner les résultats avec le chemin à froid pour obtenir des données plus précises mais à un
moment moins opportun. En d’autres termes, le chemin réactif offre des données dans une fenêtre
temporelle relativement restreinte, après laquelle les résultats peuvent être mis à jour avec des
données plus précises grâce au chemin à froid.

18
Les données brutes stockées au niveau de la couche de traitement par lots sont immuables. Les
données entrantes sont toujours ajoutées aux données existantes, et les données précédentes ne
sont jamais remplacées. Toute modification apportée à la valeur d’une donnée particulière est
stockée comme un nouvel enregistrement d’événement horodaté. Cela permet un recalcul à
n’importe quel point dans le temps dans tout l’historique des données collectées. La possibilité de
recalculer la vue de traitement par lots à partir de données brutes d’origine est importante car elle
permet de créer de nouvelles vues à mesure que le système évolue.

Un inconvénient de l’architecture lambda est sa complexité. La logique de traitement apparaît en

deux emplacements différents — le chemin réactif et le chemin à froid — avec différentes
infrastructures. Cela double la logique de calcul et la complexité de la gestion de l’architecture
pour ces deux chemins.

3-2 L’Architecture Kappa

L’architecture kappa a été proposée par Jay Kreps comme alternative à l’architecture lambda. Elle vise
les mêmes objectifs de base que l’architecture lambda, mais avec une différence importante : toutes les
données transitent via un chemin unique en utilisant un système de traitement de flux. Elle fusionne la
couche batch et la couche realtime.

Figure 3 : Architecture Kappa

19
Il existe certaines similarités avec la couche de traitement par lots de l’architecture lambda, dans
la mesure où les données des événements restent immuables et sont collectées dans leur totalité et
non comme un sous-ensemble. Les données sont reçues sous forme d’un flux d’événements dans
un journal unifié, distribué et tolérance aux pannes. Ces événements sont classés, et l’état actuel
d’un événement change uniquement lorsqu’un nouvel événement est ajouté. Comme pour la
couche vitesse de l’architecture lambda, tout le traitement des événements est effectué sur le flux
d’entrée et perdure sous forme d’une vue en temps réel.

Si vous avez besoin de recalculer la totalité du jeu de données (comparable à ce que fait la couche
de traitement par lots dans l’architecture lambda), il vous suffit de relancer le flux, généralement
en utilisant un parallélisme pour effectuer le calcul en temps opportun.

3-3 Architecture Big Data pour l’IOT

L’accroissement des IOTs a boosté l’évolution de s Big Data. D’un point de vue pratique,
Internet des objets (IoT) représente n’importe quel appareil connecté à Internet. Cela inclut votre
PC, téléphone mobile, montre connectée, thermostat intelligent, réfrigérateur connecté, véhicule
connecté, les appareils de surveillance cardiaque et tout autre appareil qui se connecte à Internet
et échange des données. Le nombre d’appareils connectés augmente chaque jour, tout comme la
quantité de données collectées à partir de ceux-ci. Souvent, ces données sont collectées dans des
environnements à fortes contraintes, parfois à latence élevée. Dans d’autres cas, les données sont
envoyées à partir d’environnements à faible latence par des milliers voire des millions
d’appareils, ce qui nécessite de recevoir rapidement les données et de les traiter en conséquence.
Ainsi, une planification appropriée est requise pour gérer ces contraintes et ces conditions
spécifiques.

Les architectures basées sur les événements sont des éléments essentiels dans les solutions IoT.
Le diagramme suivant présente une architecture logique possible pour IoT. Le diagramme met en
avant les composants de diffusion d’événements de l’architecture.

20
 Fig. Les composants de diffusion d’évènements de l’architecture

La passerelle cloud ingère les événements d’appareils à la limite du cloud en utilisant un système
de messagerie fiable et à faible latence.

Les appareils peuvent envoyer les événements directement à la passerelle cloud ou via une
passerelle de champ. Une passerelle de champ est un appareil ou un logiciel spécialisé,
généralement colocalisée avec les appareils, qui reçoit les événements et les transfère à la
passerelle cloud. La passerelle de champ peut aussi prétraiter les événements d’appareils bruts,
remplissant des fonctions de filtrage, d’agrégation ou de transformation de protocole.

Après ingestion, les événements transitent par un ou plusieurs processeurs de flux qui peuvent
acheminer les données (par exemple, vers le stockage) ou procéder à l’analytique et autres
traitements.

Voici quelques types de traitement courants. (Cette liste n’est certainement pas exhaustive.)

 Écriture de données d’événement dans un stockage froid pour archivage ou traitement

analytique par lots.

 Analytique de séquence à chaud (« hot path analytics »), avec une analyse du flux
d’événements en (quasi) temps réel, pour détecter les anomalies, reconnaître les modèles

21
 dans des fenêtres de temps glissantes ou déclencher des alertes quand une condition
spécifique est rencontrée dans le flux.

 Gestion de types de messages d’appareils non liés à la télémétrie, tels que les notifications
et les alarmes.

 Apprentissage automatique.

Les cadres gris représentent les composants d’un système IoT qui ne sont pas directement liés à
la diffusion d’événements, mais qui sont inclus ici par souci d’exhaustivité.

 Le registre d’appareils est une base de données qui recense les appareils provisionnés,
avec notamment leur ID et les métadonnées associées usuelles, telles que l’emplacement.

 L’API de provisionnement est une interface externe commune pour provisionner et

inscrire de nouveaux appareils.

 Certaines solutions IoT autorisent l’envoi de messages de commande et de contrôle aux

appareils.

22
III. Traitement en temps réel

Le traitement en temps réel concerne les flux de données capturés en temps réel et traités avec
une latence minimale pour générer des réponses automatisées ou des rapports en temps réel (ou
en quasi-temps réel). Par exemple, une solution de supervision du trafic en temps réel pourrait
utiliser des données de capteur pour détecter des pics de trafic. Ces données permettraient de
mettre à jour dynamiquement une carte montrant les embouteillages, ou mettre en place
automatiquement des voies réservées aux véhicules à occupation multiple ou d’autres systèmes
de gestion du trafic.

1. Définition

Le traitement en temps réel se définit comme le traitement d’un flux non borné de données
d’entrée, avec des critères de latence très stricts pour le traitement en millisecondes ou en
secondes. En général, ces données entrantes arrivent dans un format non structuré ou semi-
structuré, par exemple, JSON, et ont les mêmes exigences de traitement que le traitement par lots,
mais avec des temps de réponse plus courts pour gérer la consommation en temps réel.

Les données traitées sont souvent écrites dans un magasin de données analytiques, optimisé pour
l’analytique et la visualisation. Elles peuvent également être transférées directement dans la
couche d’analytique et de création de rapports à des fins d’analyse, d’informatique décisionnelle
et de visualisation de tableaux de bord en temps réel.

2. Défis

23
L’une des grandes difficultés des solutions de traitement en temps réel est d’ingérer, de traiter et
de stocker les messages en temps réel, en particulier pour les grands volumes. Le traitement doit
être effectué de manière à ne pas bloquer le pipeline d’ingestion. Le magasin de données doit
prendre en charge de gros volumes d’écritures. Il existe une autre problématique : la capacité à
effectuer des actions rapidement à partir des données, par exemple, à générer des alertes en temps
réel ou à présenter les données dans un tableau de bord en temps réel (ou en quasi-temps réel).

3. Architecture

Une architecture de traitement en temps réel comporte les composants logiques suivants :

 Ingestion de messages en temps réel : L’architecture doit prévoir un moyen de capturer

et de stocker les messages en temps réel, qui seront exploités par un consommateur de
traitement des flux de données. Dans les cas de base, ce service peut être implémenté
comme un magasin de données simple au sein duquel les nouveaux messages sont
déposés dans un dossier. Mais la solution requiert souvent un répartiteur de messages,
comme Azure Event Hubs, qui fonctionne comme un tampon pour les messages. Il doit
prendre en charge le traitement avec montée en charge et la distribution fiable.

 Traitement des flux de données. Après avoir capturé les messages en temps réel, la
solution doit les traiter en filtrant, en agrégeant et, plus généralement, en préparant les
données pour l’analyse.

 Magasin de données analytiques. De nombreuses solutions Big Data sont conçues pour
préparer les données à des fins d’analyse, puis fournir les données traitées dans un format
structuré et interrogeable à l’aide d’outils d’analyse.

24
  Analyse et rapports. La plupart des solutions Big Data ont pour but de fournir des
informations sur les données par le biais de l’analyse et des rapports.

Figure 4 : Architecture de traitement en temps réel

4. Choix de technologies

Les technologies suivantes sont recommandées pour les solutions de traitement en temps réel
dans Azure.

 Ingestion de messages en temps réel

 Azure Event Hubs. Azure Event Hubs est une solution de messagerie permettant
d’ingérer des millions de messages d’événements par seconde. Ces données capturées
peuvent être traitées par de nombreux clients en parallèle. Si Event Hubs prend en
charge AMQP (Advance Message Queuing Protocol 1.0) en mode natif, il fournit
également une couche de compatibilité binaire qui permet aux applications utilisant le
protocole Kafka (Kafka 1.0 et ultérieur) de traiter les événements avec Event Hubs
sans modification de l’application.

25
  Azure IoT Hub. Azure IoT Hub assure une communication bidirectionnelle entre les
appareils connectés à Internet, et propose une file d’attente de messages évolutive
capable de gérer des millions d’appareils connectés simultanément.

 Apache Kafka. Kafka est une application open source de traitement des flux de
données et de mise en file d’attente des messages capable de traiter jusqu’à plusieurs
millions de messages par seconde, en provenance de différents producteurs, et de les
acheminer vers plusieurs consommateurs. Kafka est disponible dans Azure sous la
forme d’un type de cluster HDInsight.

 Stockage des données

 Conteneurs Azure Storage Blob ou Azure Data Lake Store. Les données entrantes
en temps réel sont généralement capturées dans un répartiteur de messages (voir
ci-dessus), mais, dans certains cas, il peut être judicieux de surveiller l’apparition
de nouveaux fichiers dans un dossier pour les traiter au fil de leur création ou de
leur mise à jour. Par ailleurs, de nombreuses solutions de traitement en temps réel
combinent des données de diffusion en continu avec des données de référence
statiques, qui peuvent être stockées dans un magasin de fichiers. Enfin, le stockage
de fichiers peut servir de destination de sortie pour les données en temps réel
capturées à des fins d’archivage, ou en vue de traitements par lots supplémentaires
dans une architecture lambda.

 Traitement des flux de données

 Azure Stream Analytics. Azure Stream Analytics peut exécuter des requêtes
perpétuelles sur un flux de données non borné. Ces requêtes consomment des flux de
données provenant de répartiteurs de messages ou de stockage, filtrent et agrègent les
données en fonction de fenêtres temporelles, et écrivent les résultats dans des
récepteurs tels que des systèmes de stockage ou des bases de données, ou directement
dans des rapports Power BI. Stream Analytics utilise un langage de requête SQL qui
prend en charge des constructions géospatiales et temporelles, et peut être étendu via
JavaScript.

26
  Storm. Apache Storm est une infrastructure open source de traitement des flux de
données qui utilise une topologie Spout et Bolt pour consommer, traiter et générer les
résultats à partir de sources de données de diffusion en continu et en temps réel. Il est
possible de configurer Storm dans un cluster Azure HDInsight, et d’implémenter une
topologie en Java ou en C#.

 Spark Streaming. Apache Spark est une plateforme distribuée open source pour le
traitement général des données. Elle comprend l’API Spark Streaming, qui permet
d’écrire du code dans n’importe quel langage Spark pris en charge, notamment Java,
Scala et Python. Spark 2.0 a introduit l’API Spark Structured Streaming, qui propose
un modèle de programmation plus simple et plus cohérent. Spark 2.0 est disponible
dans un cluster Azure HDInsight.

 Magasin de données analytiques

 Azure Synapse Analytics, Azure Data Explorer, HBase, Spark ou Hive. Il est
possible de stocker les données traitées en temps réel dans une base de données
relationnelle comme Synapse Analytics, Azure Data Explorer, un magasin NoSQL
comme HBase, ou sous forme de fichiers dans un système de stockage distribué
permettant de définir et d’interroger des tables Spark ou Hive.

 Analytiques et rapports
 Azure Analysis Services, Power BI et Microsoft Excel. Les données traitées en
temps réel qui sont stockées dans un magasin de données analytiques peuvent
servir pour les analyses et les rapports historiques de la même façon que des
données traitées par lots. Par ailleurs, Power BI permet de publier des
visualisations et des rapports en temps réel (ou en quasi-temps réel) à partir de
sources de données analytiques si la latence est suffisamment faible, ou, dans
certains cas, directement à partir de la sortie de traitement des flux de données.

Dans une solution entièrement en temps réel, la majeure partie de l’orchestration est gérée par les
composants d’ingestion de messages et de traitement des flux de données. Toutefois, dans une
architecture lambda qui combine le traitement par lots et le traitement en temps réel, il vous

27
faudra peut-être utiliser une infrastructure d’orchestration comme Azure Data Factory ou Apache
Oozie et Sqoop pour gérer les workflows de traitement par lots des données capturées en temps
réel.

28
Conclusion

L’instauration d’une architecture Big Data était auparavant réservée aux grands groupes tels que
Google ou Facebook puisqu’elle était très coûteuse et nécessitait de disposer de nombreux
analystes, scientifiques et architectes spécialistes de la donnée. Aujourd’hui la nécessité de traiter
des ensembles de données volumineuses et la baisse du coût de stockage ont rendu accessibles
ces architectures Big Data à la plupart des entreprises qui utilisent la gouvernance des données.
Grâce à la mise en place d’une solution de gestion et de traitement Big Data, vous pourrez
pleinement tirer parti de vos données, quelles que soit leurs sources et leur format pour obtenir
des analyses avancées et bâtir de plan d’actions stratégiques guidés par les données.

29
Références : livres et articles

[1] Streaming Data: How it Works, Benefits, and use cases, https://www.avast.com/fr-fr/c-what-
is-streaming

[2] Qu’est-ce qu’une architecture Big Data et pourquoi en avez-vous besoin ?,

https://www.talend.com/fr/resources/architecture-big-data/

[3] Big Data : le traitement streaming & le temps réel des données, https://www.itpro.com/fr/big-
data-le-traitement-streaming-le-temps-reel-des-donnees/

[4] Traitement en temps réel, https://www.docs.microsoft.com/fr-fr/azure/architecture/data-

guide/traitement-data/real-time-processing

[5] Architectures des Big Data, https://www.docs.microsoft.com/fr-fr/azure/architecture/data-

guide/big-data/

[6] Tout comprendre sur le streaming data. Talend. https://www.talend.com/fr/resources/what-

streaming-data/

30