Ecosystème Big Data

ESLSCA - MBA Finance Data

Modalités de validation

Projet de groupe QCM d’une durée de 1h

Groupe 3 - 4 personnes Individuel - 20 questions

40% de la note finale 60% de la note finale

Projet de groupe

Objectif : Définir une infrastructure Big Data pour une entreprise.

Exemples d’entreprises :

● Une application VTC (Uber, Kapten, …)

● Une application de livraison à domicile
● Une néo-banque
● Une plateforme ECommerce
● Une plateforme de RDV médicaux

Modalités : Présentation finale (15 minutes présentation + 15 minutes questions)

Plan du projet

● Définition du secteur d’activité

● Identification des acteurs et des utilisateurs
● Expression des besoins
● Documentation (outils, applications)
● Mise en place de la solution technique
● Chiffrage

Livrable : Une présentation (détaillée) de la solution envisagée.

Plan du cours

● Grands principes du Big Data

● Les bases de données

● Calcul parallèle

● Data Streaming

● Orchestration
Small Data vs Big Data ?
Définition
Le Big Data est un terme apparu il y a plus de 20 ans.

Pourtant, ce n’est que depuis quelques années qu’il s’est ancré dans l’inconscient
de tout le monde.

Si l’on parle de Big Data, cela signifie qu’il y a un avant … le Small Data ?

Qu’est-ce que la data ?

Définition (Wikipédia)
« Le big data désigne les ressources d’informations dont les caractéristiques en
termes de volume, de vélocité et de variété imposent l’utilisation de technologies
et de méthodes analytiques particulières pour générer de la valeur. »

● Volume : quantité brute à stocker / à traiter.

● Vélocité : disponibilité temps réel et débit élevé.
● Variété : format des données (image, texte, son) hétérogène.

Ce que cela implique ⇒ Technologies et méthodes spécifiques pour le Big Data

Objectif ⇒ Extraire de la valeur

Limite entre Small et Big
À quel moment une problématique “classique” devient Big Data ?

Small Data Big Data

Les 5V du Big Data
 Volume

Vélo
ur
V a le

cité
5V
Vé é
ra
c it r iét
é V a
Volume
Un des premiers critères d’un projet Big Data est incontestablement le volume des
données.
Vélocité
Les données arrivent massivement, et plus vite.
Variété
Les données sont de plus en plus “fragmentées” et de natures différentes (texte,
image, vidéo).
Véracité
À quel point peut-on faire confiance aux données ?
Valeur
Comment peut-on en extraire de la valeur ?
Pour résumer
Le Big Data, ce n’est pas juste « beaucoup de données ».

⇒ C’est un mélange de plusieurs caractéristiques.

La taille des données augmente exponentiellement, mais pas les ressources pour
les utiliser.

⇒ Leur utilisation est de plus en plus complexe.

Pourquoi le Big Data ?
Pourquoi ?
Il est légitime de se poser la question suivante :

Pourquoi et comment en sommes-nous arrivé à cette explosion de la donnée ?

Explication par les données

Les données permettent d’expliquer le plus rigoureusement possible un

phénomène que l’on étudie.
Critère économique
Une des raisons qui explique
pourquoi il y a autant de données,
c’est que le coût du stockage a
drastiquement diminué au fil des
ans.

⇒ La capacité en stockage n’est

plus (en règle général) restreinte
par des contraintes économiques.
Critère technique
La puissance de calcul
augmente d’années en
années, respectant ainsi la Loi
de Moore.

⇒ Il est aujourd’hui beaucoup

plus facile de manipuler des
données volumineuses qu’il y a
10 ans.
Cloud Computing
Le Cloud Computing, qui permet de déployer et de gérer des serveurs à
distance a véritablement contribué au Big Data.
Applications
Les équipes Marketing ont été les premières à utiliser les outils du Big Data,
surtout pour du marketing prédictif et du customer analytics.

Aujourd’hui, les applications touchent toutes les équipes de l’entreprise.

● Finance/Assurance : risque de crédit, actuariat

● Marketing : détection du churn, marketing prédictif
● Santé : aide à la décision, diagnostics automatisés, génomique
● Transports : voitures autonomes, optimisation de trajets
● ECommerce : systèmes de recommandation, analyse de promotions
Technologies du Big Data
Technologies
Nous allons aborder les principales technologies et outils du Big Data.

● Cloud Computing
● Base de données
● Data Streaming
● Calcul parallèle
● Orchestration

Ce qui sera présenté dans la suite n’est pas exhaustif mais permet d’avoir une
idée claire pour les différencier et savoir lequel utiliser en fonction du cas
d’usage.
Cloud Computing
Pourquoi le Cloud Computing est devenu si populaire ?
Parts de marché
Modèles de déploiement
Modèle économique

Les Clouds publics ont un modèle économique particulier qualifié de pay-as-you-

go, où la tarification est appliquée directement à la consommation.

L’avantage de ce modèle est de supprimer les coûts d’exploitation (CAPEX) qui

représente les investissements initiaux.
Dépenses d’exploitation on-premise
Cloud on-premise Cloud public

Investissement initial Investissement initial

100k € - 1M € 0€

● Achat de terrains ● Modèle économique pay-as-you-

● Construction du Data Center go
● Achat de matériel
● Consommation électrique
● Frais de personnel
● Frais de sécurité
Les avantages du Cloud Computing
Agrégation des clients

Ce n’est pas un client pour un Data Center, mais des centaines de milliers de
clients.

⇒ Au niveau individuel, les coûts liés au Data Center se révèlent extrêmement

faibles.

Plutôt que de payer les frais liés au Data Center, les clients payent les frais
d’utilisation des ressources, englobant les frais de maintenance.

⇒ C’est ce qui permet aux fournisseurs Cloud de proposer des prix toujours aussi
bas.
Scalabilité
La scalabilité est la capacité de supporter des charges plus importantes que par
le passé. On distingue deux types de scalabilité :
Élasticité
L’élasticité est la capacité de redimensionner à tout moment les ressources pour
s’adapter efficacement à la charge.
Scalabilité et élasticité

Scalabilité ≠ Élasticité

Dans un Cloud on-premise, la scalabilité et l’élasticité sont très difficiles à mettre en

place.

Dans un Cloud public, à l’inverse, le modèle économique pay-as-you-go permet

d’avoir à portée de main de très grandes quantités de ressources, tout en
optimisant les dépenses liées.
Échelle globale
Les fournisseurs Cloud disposent de Data Centers dans tous les continents.

⇒ Il est là aussi très facile et économique de déployer son infrastructure dans

n’importe quel région du monde.
Pour résumer

● Échange des dépenses d’exploitations en dépenses variables

● Réduction massive des coûts due à l'agrégation de milliers de clients

● Plus besoin de prévoir les charges de ressources

● Augmentation de la vitesse et de l’agilité

● Aucune dépense liée aux coûts de maintenance physiques

● Possibilité de passer à l’échelle globale en quelques minutes

Bases de données
Bases de données
Les bases de données permettent de stocker et de retrouver des données brutes
en rapport avec un thème, une activité.

Une base de données ne fait pas la même chose qu’un système de stockage de
fichiers.

Système de stockage de fichiers ⇒ Stockage d’objets

Base de données ⇒ Stockage de données
SGBD
Un système de gestion de base de données (SGBD) est l’interface entre
l’utilisateur et les bases de données.

À partir du SGBD, il est possible d’administrer, de créer, de modifier, de supprimer

et de surveiller les bases de données.

Le moteur du SGBD permet de faire des opérations (requêtes de

lectures/écritures, …) sur ces bases de données. Le plus souvent, un langage de
requête permet de décrire ces opérations.

Le langage SQL est la référence pour les requêtes sur les bases relationnelles.
SQL vs NoSQL
Deux grandes familles de SGBD s’opposent :

● Les modèles relationnels, fortement structurés, également nommés par le

langage de requête SQL.
● Les modèles non relationnels, faiblement structurés, qualifiés de bases
NoSQL.

Les bases dites NoSQL sont plus récentes et leur création a été motivé par le Big
Data, en particulier sur les sujets de volumétrie et de variété des données.
Le modèle relationnel
Dans un modèle relationnel, les données sont stockées sous forme de tables
(dites relationnelles) dans la base de données.

Chaque table est défini selon un schéma, qui identifie les colonnes et les
propriétés de la table.
Les colonnes
Chaque colonne stocke une donnée qui respecte un type particulier.

● Nombre entiers : INT, INTEGER, BIGINT

● Nombre flottants : FLOAT, DOUBLE, DECIMAL
● Texte : CHAR, VARCHAR, TEXT
● Date et heure : DATE, DATETIME, TIMESTAMP, TIME
● Booléens : BOOL, BOOLEAN

Lorsqu’une colonne ne doit pas contenir de valeurs manquantes, le mot-clé NOT

NULL est attribué à cette colonne.
Clés primaires et étrangères
Dans les tables relationnelles, nous rencontrons des clés primaires.

Une clé primaire permet d’identifier chaque ligne de manière unique. Une clé
primaire peut être composée d’une ou plusieurs colonnes.

Les clés primaires sont fréquemment des colonnes non nulles et auto-
incrémentes.

Une clé étrangère fait référence à une clé primaire d’une autre table.

C’est à l’aide de ces deux clés que l’on peut lier les tables entre-elles.
Jointures
C’est avec les jointures
que le modèle relationnel
prend tout son sens : cela
permet de relier plusieurs
tables.

Ici, user_id et
employee_id sont deux
clés de jointure
étrangères permettant de
relier les trois tables.
Méthodes de jointures
Propriétés ACID
La grande majorité des bases SQL supportent les propriétés ACID sur les requêtes.

● Atomicité : une requête est effectuée entièrement ou non ( jamais

partiellement).
● Cohérence : une requête sur un système valide l’amène dans un nouvel état
valide.
● Isolation : chaque requête doit être indépendante des autres.
● Durabilité : une requête effectuée est enregistrée de façon permanente dans
le système.

Pourquoi mettre en place ces propriétés ?

Opérations CRUD
Les quatre opérations de base pour la persistence des données sont appelées les
opérations CRUD.

● Create : création d’une donnée (INSERT)

● Read : lire une donnée (SELECT)
● Update : mettre à jour une donnée (UPDATE)
● Destroy : supprimer une donnée (DELETE)

Attention, le faux-ami CREATE sous SQL ne permet pas de créer une ligne mais de
créer une table ou une base de données.
Quelques bases SQL célèbres
TP - Base relationnelle

Création d’une base de données sur des données d’une campagne marketing.

● Installation du SGBD SQLite

● Création d’une base de données et de tables

● Insertion de données depuis un fichier CSV

Famille NoSQL
Parmi les bases dites NoSQL, nous retrouvons plusieurs modèles de bases de
données :

● Les bases orientées colonnes

● Les bases orientées documents
● Les bases clé/valeur
● Les bases orientées graphes

Nous pouvons également citer la nouvelle mouvance NewSQL, qui mélange à la

fois le modèle relationnel et les bases NoSQL, bien que son utilisation reste encore
marginale.
Bases orientées colonnes
Les bases orientées colonnes peuvent être vues comme une extension des tables
relationnelles.

● Chaque table dispose d’une clé primaire (pas forcément unique)

● Une clé secondaire facultative (potentiellement clé de tri) peut être spécifiée
● Les colonnes sont définies par ligne

La principale différence avec les tables relationnelles est que les colonnes ne sont
pas fixes pour chaque ligne, mais chaque ligne de la table peut définir ses
propres colonnes.

⇒ Le schéma, en dehors de la clé primaire, est propre à chaque ligne.

Bases orientées colonnes
Bases orientées colonnes
Cette flexibilité au niveau des colonnes permet également d’historiser beaucoup
plus facilement.

Product ID Name Price 1 Price 2 Price 3

Liquide date: 01/02/2020 date: 12/05/2020

1 vaisselle price: 2.42€ price: 2.48€

date: 08/05/2020 date: 12/09/2020 date: 19/09/2020

2 Shampooing
price: 1.56€ price: 1.12€ price: 1.56€

date: 12/05/2020
3 Fromage blanc
price: 2.02€
Bases orientées colonnes

Les bases orientés colonnes sont pensées pour la volumétrie : de ce fait, les tables
peuvent facilement contenir des dizaines de millions de lignes avec des centaines
de colonnes différentes.

Néanmoins, cela empêche certaines fonctionnalités historiquement présentes dans

le modèle relationnel d’être présente.

Par exemple, avec Cassandra, il n’est pas possible d’effectuer des jointures.
Bases orientées colonnes
Quand utiliser un base NoSQL orientée colonnes ?

Elles sont adaptées lorsque les données sont très volumineuses et que de
nombreux événements surviennent.

➔ Analyse de données collectées par webscraping

➔ Comportement des utilisateurs

➔ Gestion de catalogues (produits, achats, ventes)

Elles gardent, dans leur forme, un certain lien avec les bases relationnelles.
Bases orientées colonnes
Open Source

Managées
Bases orientées documents
Dans les bases orientées documents, on considère des collections de documents,
où chaque document contient une liste de champs clé/valeur.
Le format utilisé dans les documents est principalement le JSON ou le XML.

Document (id: 5baf47) Document (id: ea53aa) Document (id: d710bb)

{ { {
"nom": "Liquide vaisselle", "nom": "Shampooing", "nom": "Fromage blanc",
"images": [ "images": [ "images": [
"https://...", "https://...", "https://...",
"https://..." "https://..." "https://..."
], ], ],
"specs": { "specs": { "specs": {
"parfum": "Orange" "parfum": "Vanille" "mat_grasses": "0%"
} } }
} } }
Bases orientées documents
Quand utiliser un base NoSQL orientée document ?

Il faut les utiliser lorsqu’il n’y pas de relations entre les documents et les
collections.
➔ Gestion de catalogues diversifié (produits, achats, ventes)

➔ Base d’utilisateurs et de clients

➔ Web Analytics

S’il y a une cohérence assez forte entre les données (colonnes plus ou moins
similaires), on préfèrera utiliser une base NoSQL orientée colonnes.
Bases orientées documents
Open Source

Managées
TP MongoDB
● Création d’un cluster MongoDB à 3 noeuds
● Installation et prise en main de MongoDB Atlas
● Collections, documents et schémas
● Manipulation sous Python : cas synchrone et asynchrone
● Opérations CRUD et acknowledgments
● Projections et filtrages
● Pipelines d’aggrégations
Bases orientées clé/valeur
Les bases orientées clé/valeur sont utilisées pour le stockage temporaire de
données.

Chaque donnée est référencée par une clé : c’est à partir de cette dernière que l’on
y accède.

Contrairement aux autres bases NoSQL, celles-ci sont plus faciles à utiliser mais
leurs usages sont limitées.

⚠ Il n’y a aucune structure sur les valeurs associées aux clés : il faut être prudent
avec ces bases.
Bases orientées clé/valeur
L’utilisation des bases NoSQL orientées clé/valeur est très facile, car les clés
fournissent une indexation naturelle.

Clé Valeur

1 https://adresseweb.com

2 356

mail: monmail@gmail.com
3 date: 25/10/2020 13:42:12

⚠ Il n’est pas possible d’effectuer des requêtes sur ces bases.

Bases orientées clé/valeur
Quand utiliser un base NoSQL orientée clé/valeur ?

La principale utilisation des bases NoSQL orientées clé/valeur concerne la mise en

cache d’informations.

➔ Panier d’utilisateur (E-Commerce)

➔ Collecte d’événements (tracking utilisateur)

➔ Partage d’information pour des applications load-balanced

Ces bases sont en général plutôt destinées aux développeurs qui mettent en place
des solutions de haute disponibilité.
Bases orientées clé/valeur
Open Source

Managées
Autres bases
Bases orientées graphes

Bases orientées séries temporelles

Calcul parallèle
Calcul parallèle
Pourquoi avoir besoin de faire du calcul parallèle ? Et qu’est-ce que c’est
exactement ?

Le calcul parallèle (ou distribué) est le fait d’exécuter plusieurs calculs séquentiels
simultanément sur plusieurs serveurs (appelés noeuds de calcul).

Plutôt que d’utiliser la mémoire vive d’un seul serveur, cela permet d’utiliser autant
de mémoire vive qu’il y a de noeuds de calcul disponibles.

Qu’est-ce que la mémoire vive ?

Calcul parallèle
La plupart des manipulations de données sont effectuées en mémoire vive. La
limite est donc fixée par la quantité de mémoire vive disponible qui peut être
allouée.
Calcul parallèle
MapReduce
MapReduce est un modèle d’algorithme de calcul distribué, développé par Google.
Il se compose de deux parties :

● Le map, où chaque entrée est associée à une paire clé/valeur.

● Le reduce, où les paires sont agrégées sur la base d’une même clé.

L’objectif du MapReduce est de pouvoir effectuer des calculs qui ne sont pas
indépendants en dispatchant les données sur plusieurs noeuds de calcul.

⇒ Chaque noeud effectue le même traitement, mais pas sur les mêmes données.
MapReduce : comptage de mots
Prenons un exemple : nous souhaitons compter le nombre d'occurrences de
chaque mot dans un corpus.

Deer Bear River

Car Car River
Deer Car Bear

Les mots Deer, Bear et River apparaissent 3 fois, et le mot Car apparaît 4 fois.

Comment pourrions-nous compter le nombre d’occurrences dans

un algorithme classique ?
MapReduce : comptage de mots
Dans un corpus relativement petit, pas besoin d’utiliser un calcul distribué : les
performances d’un ordinateur sont suffisantes.

Sur Wikipédia English, il y a environ 6,1m d’articles avec une moyenne de 1,5k mots
par article, il y a environ 9,15 milliards de mots.

Combien pèserait (environ) le fichier contenant tous ces mots ?

⇒ Compter le nombre d’occurrences sur un simple ordinateur/serveur prendrait
trop de temps.

Ainsi, paralléliser le calcul dans cette situation est donc un choix judicieux.
MapReduce : comptage de mots
Frameworks Big Data
Hadoop / Spark
MapReduce
Dans la plupart des cas, une seule phase MapReduce n’est pas suffisante.

Écrire toutes ces phases peut être laborieux à long terme, et certains algorithmes
ne peuvent pas être implémenté en MapReduce (algorithmes récursifs).

Il existe donc des outils plus “haut-niveau” simplifiant l’accès aux commandes
MapReduce.
Outils haut-niveau
Apache Hive

● Transforme des requêtes SQL en

phases MapReduce
● Autorise une gestion de
données structurées
● Plus axé sur la Data Analyse et le
reporting de données
Outils haut-niveau
Apache Pig

● Langage haut-niveau similaire au

SQL pour transformer les
requêtes en phases MapReduce
● Plus technique que Apache Hive
● S’adresse plutôt aux
développeurs
Système de fichiers distribués HDFS
Puisque plusieurs noeuds de calcul produisent des résultats, ils ne peuvent pas
être stockés en mémoire lors du reduce, mais dans un fichier.

HDFS (Hadoop Distributed File System) est un système de fichiers distribués

permettant de stocker et récupérer des fichiers de très grandes tailles entreposés
sur plusieurs disques.
Caractéristiques de HDFS
Chaque fichier HDFS est composé de blocs (souvent de taille 64MB) dans des
Datanodes.

⇒ Cela permet de fragmenter un fichier sur plusieurs disques.

Ces blocs sont répliqués sur plusieurs Datanodes pour la tolérance à la faute.

⇒ En général, le facteur de réplica est de 3.

Les noeuds de calcul accèdent directement aux fichiers HDFS via les Datanodes.
HDFS avec Hadoop/Spark
Pour rappel, avec Hadoop, les données ne sont pas stockées en mémoire.

Comment enchaîner plusieurs opérations sur un jeu de données ?

Dès qu’un calcul est effectué, le résultat d’un traitement est directement enregistré
dans un fichier HDFS.

Ces fichiers enregistrés, appelés RDD (Resilient Distributed Datasets), sont en

lecture-seule.

⇒ Cela permet de revenir à la i-ème opération en récupérant le RDD intermédiaire.

Resilient Distributed Datasets (RDD)
Sur Hadoop, chaque traitement implique un RDD enregistré en mémoire.

Sur Spark, il est possible de garder le RDD en mémoire s’il n’est pas trop
volumineux.
Datasets
Apparu avec Spark, un Dataset est une collection de données distribuée qui offre
l'avantage des RDD (fort typage par exemple) mais qui permet bénéficie également
du moteur d'exécution de Spark SQL.

C'est notamment avec cette dernière fonctionnalité que nous pourrons invoquer
des traitements SQL-like en parallèle.
DataFrames
Enfin, le DataFrame est un Dataset organisé sous forme de colonnes, équivalent à
une table dans un modèle relationnel.

Il s'agit du format le plus adapté pour manipuler des données tabulaires, et

ressemble fortement à ceux rencontrés sous R ou Python.
Pour résumer

● Calcul parallèle : exécution de plusieurs calculs séquentiels en parallèle

● MapReduce : modèle d’algorithme pour le calcul parallèle

● HDFS : système de fichiers distribués

● Hadoop : framework Big Data contenant MapReduce et HDFS

● Spark : framework Big Data basé sur Hadoop plus complet

● Hive et Pig : outils haut-niveau pour le traitement

TP Spark
● Installation de Spark en local avec Google Colab
● Comptage de mots avec MapReduce
● Algorithmes avec MapReduce (k-means, Frequent Items Set)
● Spark UI et interface YARN
● Spark SQL
Data Streaming avec Apache Kafka
Data Streaming
Avant d’introduire Kafka, il est important de comprendre le principe du Data Streaming.

Jusqu’ici, nous avons utilisé Spark pour l'extraction, la transformation et le chargement des données.

Les processus ETL fonctionnaient par batch.

Data Streaming
Dans un système de production, les données surviennent quasi-instantanément.

❓ Comment exploiter toutes ces données qui arrivent en flux continu dans notre processus ETL ?

➔ Le processus peut être exécuté de manière périodique (tâche CRON ou serveur stand-by).
Une fréquence trop faible perd le côté streaming, et une fréquence trop grande pourrait
surcharger le processus ETL.

➔ Le processus peut être exécuté dès qu'un certain nombre d'événements surviennent.
Une liste d'attente s'installe ce qui crée une dépendance entre les données : certaines peuvent
être bloquées si le nombre de message n'est pas constant (en heure de pointe, il y a
probablement plus de taxis que la nuit en milieu de semaine).

➔ Le processus peut être exécuté à partir de l'application qui génère ces données.
On devient dépendant du système qui génère ces données, empêchant ainsi un côté
indépendant entre les services.
Système d'agents de messages (brokers)
La solution la plus efficace pour cela est d'utiliser un système d'agents de messages (ou broker).

La pièce maîtresse d'un broker est la gestion d'une ou plusieurs files d'attentes.
Le modèle publish-subscribe
Dans le modèle publish-subscribe, il y a un mécanisme de publications et d'abonnements de messages.

Publisher
Broker Subscriber
Publisher
File d’attente 1
Subscriber
Publisher File d’attente 2

File d’attente 3 Subscriber

Publisher
File d’attente 4
Subscriber
Publisher

Un publisher est une application qui envoie des messages vers le broker sur une ou plusieurs files.

Un subscriber est une application qui récupère les messages depuis une ou plusieurs files.
Le modèle publish-subscribe
Beaucoup de cas d’usages du modèle publish-subscribe trouvent une même origine.

Serveur
Frontend

Serveur
Journaux
Backend

Base de données
Événements
(primary)

Base de données
DB Monitoring
(replica)

IAM
Le modèle publish-subscribe
Avec un broker, tous les messages sont envoyés vers un point central, limitant le couplage entre les
applications.

Serveur
Frontend

Serveur
Journaux
Backend

Base de données
(primary) Broker Événements

Base de données
DB Monitoring
(replica)

IAM
Le modèle publish-subscribe
Il y a deux principaux avantages au système publish-subscribe.

➔ Scalabilité : l'intérêt de pouvoir spécifier quelles applications vont publier ou s'abonner permet de
mettre à l'échelle plus facilement, et donc de pouvoir gérer à la fois de grandes quantités de
données à des fréquences très élevées.

➔ Couplage faible : en séparant les applications qui publient de celles qui s'abonnent permet de
penser à une architecture où les applications sont indépendantes, chose encouragée dans le
Cloud Computing.

Pourquoi s'orienter vers Apache Kafka et non pas RabbitMQ ou encore Spark Streaming ?

Le principal intérêt de Ka!a est sa scalabilité orientée Big Data, et son fonctionnement de continuous
streaming.
Apache Kafka
Apache Kafka est définit comme étant une plateforme distribuée de streaming de données.

L’écosystème Kafka, conçu chez LinkedIn, est pensée pour supporter de très grandes charges de travail.
Apache Kafka - Les API
Apache Ka!a contient 5 APIs principales.

● Producer API pour envoyer des données vers Ka!a.

● Consumer API pour intercepter les données depuis Ka!a.
● Streams API pour interagir directement sur les flux de données.
● Connector API pour lier automatiquement des bases de données/systèmes de stockage avec Ka!a.
● Admin API pour gérer les brokers.

Bien que Ka!a soit écrit en Java et Scala, la plupart des langages disposent de librairies ou packages
permettant l’interaction avec Ka!a.

À noter toutefois que certaines fonctionnalités spécifiques ne peuvent être codées qu’en Java ou Scala.

⇒ Voyons les éléments centraux dans Apache Ka!a.

Broker
Une exécution de Kafka sur un serveur est appelé un broker.

En pratique, pour des raisons de haute disponibilité et de tolérance à la faute, ce n’est pas un seul mais
plusieurs brokers qui sont exécutés.

⇒ Cela forme donc un cluster Kafka.

Par la suite, on considérera alors des clusters Kafka avec au moins 2 brokers.

En pratique, un cluster Kafka est également composés d’un ensemble ZooKeeper, nécessaire pour stocker
les métadonnées sur les éléments du cluster, que nous n’aborderons pas dans ce cours.

Commençons maintenant par voir l’élément principal : le topic.

Topics
Chaque message arrivant dans un broker Kafka est appelé un record.

Les records sont enregistrés dans des topics. Il s’agit des files publish-subscribe sous Kafka.

Topic
0 1 2 3 4 5 6 7 8 9 10 11 ...

Topic
0 1 2 3 4 5 6 7 8 9 10 11 ...

En pratique, il peut y avoir des dizaines de milliers de topics, tant que les ressources du cluster sont
suffisantes.
Topics - Partitions
Pour gérer l’afflux de records, chaque topic est constitué de partitions.

Il s’agit de piles (FIFO) où chaque record est identifié par sa position dans la partition, appelé offset.

Topic

Partition 0 0 1 2 3 4 5 6 7 8 9 10 11 ...

Partition 1 0 1 2 3 4 5 6 7 8 ...

Partition 2 0 1 2 3 4 5 6 7 8 9 10 ...

Cette notion de pile est importante, car elle permet de gérer l'ordonnancement des messages et donc leur
priorité de traitement.
Topics - Replicas
Enfin, pour être tolérant à la faute dans le cas où un broker Kafka viendrait à ne plus fonctionner, il est
conseillé de créer des replicas de topics.

Broker 1 Broker 2 Broker 3

Topic Topic Topic
Partition 0 0 1 2 3 4 5 ... Partition 0 0 1 2 3 4 5 ... Partition 0 0 1 2 3 4 5 ...

Partition 1 0 1 2 3 ... Partition 1 0 1 2 3 ... Partition 1 0 1 2 3 ...

Partition 2 0 1 2 ... Partition 2 0 1 2 ... Partition 2 0 1 2 ...

En définissant un facteur de replica, le topic et ses partitions seront dupliquées dans autant de brokers que
précisé.
Topics - Tolérance
La tolérance indique le nombre de brokers qui peuvent être en panne sans que les données d’un topic
soient perdues.

Cette tolérance est égale au facteur de réplica du topic moins 1.

Par exemple, dans un cluster à 4 brokers, avec un facteur de réplica à 3, la tolérance est de deux brokers en
panne simultanément.
Topics - Tolérance

Broker 1 Broker 2

Partition 0 Partition 1 Partition 1 Partition 2

Partition 2 Partition 3
● 4 brokers Kafka

● Un seul topic

● 4 partitions
Broker 3 Broker 4
● Facteur de réplica 3
Partition 0 Partition 1 Partition 0 Partition 2

Partition 3 Partition 3
Topics - Tolérance

Broker 1 Broker 2 Supposons qu’un des trois brokers

tombe en panne.
Partition 0 Partition 1 Partition 1 Partition 2

Seule la partition 2 est présente 3

Partition 2 Partition 3 fois.

Les autres partitions ne sont

répliquées qu’une seule fois.
Broker 3 Broker 4
Pour l’instant, le topic n’assume
Partition 0 Partition 1 Partition 0 Partition 2 aucune perte de données.

Partition 3 Partition 3
Topics - Tolérance

Broker 1 Broker 2 Si un deuxième broker tombe en

panne, alors nous avons atteint la
Partition 0 Partition 1 Partition 1 Partition 2 limite de tolérance pour pouvoir
assurer la disponibilité des
Partition 2 Partition 3 données.

En revanche, les partitions 1 et 3 ne

sont plus répliquées.
Broker 3 Broker 4
Si un autre broker tombe en panne,
Partition 0 Partition 1 Partition 0 Partition 2 alors des pertes de données
interviendront dans le topic.
Partition 3 Partition 3
Topics - Leader et Follower
Dans le cas d’un réplica de topics, chaque partition a un leader et 0 ou plusieurs followers.

Les partitions leaders sont réceptionner les requêtes de lecture/écriture.

Les partitions followers vont répliquer les écritures du leader et prendre le relai si la partition n’est plus
disponible (broker en panne par exemple).

Broker 1 Broker 2 Broker 3

Partition 0 Partition 1 Partition 0 Partition 1 Partition 0 Partition 1

Partition 2 Partition 2 Partition 2

Topics
Pour résumer sur les topics dans Ka!a.

➔ Chaque message envoyé sur un broker Ka!a est un record.

➔ Les records sont enregistrés dans des topics.

➔ Un topic dispose de plusieurs partitions.

➔ Chaque partition stocke les records dans une pile.

➔ Chaque record est identifié par sa position (offset) dans une partition.

➔ Les topics et ses partitions peuvent être dupliqués sur plusieurs brokers (replica).
Producers et Consumers
Les applications qui vont agir sur les topics sont les producers et les consumers.

➔ Les producers vont envoyer des records sur un ou plusieurs topics, avec le choix de la partition à
utiliser.

➔ Les consumers vont quant à eux consommer les records dans un ou plusieurs topics.

Les consumers sont multi-subscribers : ils peuvent consommer des records de plusieurs topics en même
temps.
Producers
Il y a de nombreux cas d’applications qui nécessitent d’envoyer des messages vers Kafka.

Dans la plupart des cas, se posent des questions essentielles.

● Pouvons-nous tolérer des pertes de messages ?

● Pouvons-nous tolérer des duplicatas de messages ?
● Comment peut-on s’assurer de la bonne réception d’un message ?
● Y a-t-il un risque au niveau de débit de messages engendré par un producer ?

Les réponses sont assez souples si, par exemple, on souhaite tracker l’activité d’un utilisateur anonyme sur
un site Internet.

Elles le sont beaucoup moins pour des ordres financiers par exemple.
Producers - Vue générale
Producers - Serialization
Les messages envoyés sur des topics Kafka sont au format binaire.

Dans certains cas, si l’on souhaite envoyer des données structurées, nous devons utiliser une technique de
sérialisation qui s’applique automatiquement avant l’envoi de chaque message.

Producer Broker

Donnée Donnée Topic

Serializer
structurée binaire

Parmi les exemples les plus classiques, on retrouve l’encodage depuis le format JSON ou la sérialisation
binaire avec Avro ou Protobuf.
Producers - Acknowledgment
Lorsqu’un producer envoie un message sur un topic Ka!a, il peut être en mesure d’attendre une réponse
pour vérifier que le message a bien été reçu : c’est l’acknowledgment.

Trois méthodes sont possibles sous Ka!a.

● Fire and Forget

● Envoi synchrone
● Envoi asynchrone
Producers - Fire and Forget

La méthode la plus simple pour envoyer un message vers un topic Kafka est le Fire and Forget.

Dans cette configuration, le producer n’attends pas la confirmation du broker.

Producer Broker
envoi du message réception

message stocké
Producers - Envoi synchrone
Lorsque l’on souhaite avec un acknowledgment du broker, on peut effectuer un envoie synchrone.

Dans ce contexte, le producer sera en attente et bloqué tant que le broker ne fournira pas de réponse
(positive ou négative).

Producer Broker
envoi du message réception
Le producer ne fait
rien d’autre tant qu’il
n’a pas reçu un
acknowledgment du
broker.
message stocké
acknowledgment
Producers - Envoi asynchrone
Pour éviter le blocage de l’exécution du producer, il est possible d’effectuer un envoi asynchrone.

Le producer va pouvoir envoyer d’autre message et utiliser des callbacks lors de l’acknowledgment des
précédents.

Producer Broker
envoi du message réception
Le producer peut
envoyer un autre
message (ou faire
d’autres calculs) sans
avoir Autre calcul fait par le producer
l’acknowledgment du
précédent.

acknowledgment
message stocké
Producers - Partitionnement
Chaque message envoyé vers un topic Kafka peut être associé d’une clé.

Il s’agit d’informations additionnelles sur le message, mais permet également de décider sur quelle partition
précisément écrire un message.

Ce cas de figure est intéressant en pratique lorsque les applications qui consomment les messages
(consumers), utilisent elles aussi des partitions spécifiques.
Consumers
Les consumers, à l’opposé des producers, vont lire les messages sur un ou plusieurs topics.

Là-aussi, plusieurs questions se posent.

● Comment être sûr qu’un message ne va pas être traité en doublon ?

● Comment s’assurer qu’un consumer a bien reçu le message ?
● Comment gérer le cas où plusieurs consumers sont sur un même topic ?
● Comment faire si un consumer tombe en panne ?

On comprends rapidement que les consumers sont un sujet plus sensibles et plus délicats que les
producers.

Pour cela, Ka"a implémente une notion de consumer group pour proposer des réponses à ces questions.
Consumers - Consumer Group
Chaque consumer fait parti d’un consumer group.

Ce groupe s’assure que chaque partition d’un topic est consommée par un seul de ses membres.

⇒ Chaque record d’un topic est donc consommé par un seul consumer dans un consumer group.

Topic Consumer Group

Partition 0 0 1 2 3 4 5 6 7 8 9 10 11 ...
Consumer 1

Partition 1 0 1 2 3 4 5 6 7 8 ... Consumer 2

Consumer 3
Partition 2 0 1 2 3 4 5 6 7 8 9 10 ...
Consumers - Consumer Group
L’avantage de ce système est qu’il permet de créer des configurations différentes selon les besoins.

Broker

Topic 1 Topic 2 Topic 3 Topic 4

Consumer 1 Consumer 2 Consumer 3

Consumer Group Consumer Group Consumer Group

Si chaque consumer est dans un consumer group, alors chaque record de chaque topic souscrit va être
envoyé à tous les consumers : on parle de broadcasting.
Consumers - Consumer Group

Broker

Topic 1 Topic 2 Topic 3 Topic 4

Consumer 1 Consumer 2 Consumer 3

Consumer Group

Si tous les consumers sont dans un seul et même consumer group, alors chaque record de chaque topic
souscrit va être envoyé à un des consumer : on parle de load balancing.
Consumers - Poll loop
Contrairement aux producers, les consumers sont en lien constant avec les brokers.

Ce lien constant peut être vu comme une boucle infinie sur laquelle le consumer “attends” des messages du
broker : c’est la poll loop.

try {
while (true) {
ConsumerRecords<String, String> records = consumer.poll(100);
for (ConsumerRecord<String, String> record : records)
{
// On traite les records ici
}
} finally {
consumer.close();
}

La partie la plus importante se trouver au niveau du consumer.poll(100)

Consumers - Poll loop
Cette fonction agit comme une fenêtre temporelle d’attente dans laquelle les messages entrants (s’il y en a)
vont s’accumuler.

L’idée est de contrôler la taille de la fenêtre temporelle, spécifiée par le paramètre (ici 100 millisecondes)
pour “attendre” l’arrivé des messages.

Le poll a également un rôle important puisqu’il va également procéder à l’assignation des partitions aux
consumers dans un groupe (cela va donc redistribuer les cartes au sein du consumer group).

De plus, le poll intervient dans le cas d’un rebalance, c’est-à-dire lorsque les partitions sont ré-assignés dans
un topic.
Consumers - Deserialization
Les messages lus par les consumers sont là-aussi au format binaire.

Lorsqu’une sérialisation a été appliquée en amont, une désérialisation est nécessaire en sortie pour les
consumers.

Broker Consumers

Donnée Donnée
Topic Deserializer
binaire structurée

La principale difficulté est de garder une consistante entre les producers et les consumers.

⇒ Une solution est d’utiliser les schémas de données, qui ne seront pas abordés dans ce cours.
Consumers - Commits
À la suite d’un poll, les messages de Kafka non lus sont retournés au consumer.

Ce qu’il y a de particulier, c’est que ce n’est pas Kafka lui-même qui gère directement l’acknownledgment
des messages par les consumers, mais ces derniers directement.

Dans le cas des consumers, il ne s’agit pas d’un acknowledgment mais d’un commit.

⇒ Un consumer va donc commit un offset : autrement dit, il va indiquer à Kafka qu’il a bien reçu et traité le
message du topic sur la partition et le offset spécifiés.

Si tout se passe bien (aucun consumer ne plante) alors tout fonctionne.

Mais si un des consumer tombe en panne, alors un décalage des commits va se produire.

Et deux situations peuvent apparaître.

Consumers - Commits
Si un consumer tombe en panne avant d’avoir pu commit les offsets depuis le précédent poll, il y aura des
doublons car les messages seront traités deux fois :

● Une première fois par le consumer avant qu’il tombe en panne pour pouvoir commit son message.

● Une deuxième fois par le consumer qui prend le relai sur la partition et qui repart du dernier commit.
Consumers - Commits
À l’inverse, si un consumer commit des offsets sans avoir eu le temps de traiter les messages associés
depuis le précédent poll, certains messages ne seront donc jamais traités.
Consumers - Commits
Face à cette situation, il y a plusieurs stratégies de commits proposées dans la Consumer API.

● Commit automatique
● Commit synchrone
● Commit asynchrone
● Combinaison synchrone et asynchrone
● Commit à un offset spécifique
Consumers - Commit automatique
La méthode la plus facile est d’utiliser une option de commit automatique.

Toutes les 5 secondes, le consumer va commit le plus haut offset qu’il a traité depuis le poll.

Cette valeur de 5 secondes est proposée par défaut et peut être configurée par le paramètre
auto.commit.interval.ms.

Dans ce cas, c’est le poll qui va directement commit les offsets.

⇒ Comprenons bien les conséquences : si pendant ces 5 secondes, le consumer tombe en panne au bout
de x secondes, tous les messages récupérés pendant ces x secondes seront traités en doublon.

Bien que cette solution soit facile, elle n’est efficace pour les cas d’utilisation où les doublons sont
impensables (ordres financiers par exemple).
Consumers - Commit synchrone
Dans le cas d’un commit synchrone, le consumer va explicitement commit le offset le plus élevé d’un poll.

try {
while (true) {
ConsumerRecords<String, String> records = consumer.poll(100);
for (ConsumerRecord<String, String> record : records)
{
// On traite les records ici
}
try {
consumer.commitSync(); // On effectue un commit synchrone du offset le plus élevé
} catch (CommitFailedException e) {
log.error("Commit failed", e)
}
} finally {
consumer.close();
}

Attention néanmoins, gardons en tête que si parmi les messages reçus via le poll, on traite n messages avant
de pouvoir commit si le consumer tombe en panne, ces n messages seront là-aussi traités en double !
Consumers - Commit asynchrone
Dans le cadre synchrone, le consumer est bloqué tant que le broker ne réponds pas positivement au commit.

Si l’on souhaite ne pas bloquer le consumer en attendant la réponse du serveur, nous pouvons utiliser à la
place le commit asynchrone.

try {
while (true) {
ConsumerRecords<String, String> records = consumer.poll(100);
for (ConsumerRecord<String, String> record : records)
{
// On traite les records ici
}
consumer.commitAsync(new OffsetCommitCallback() {
public void onComplete(Map<TopicPartition, OffsetAndMetadata> offsets, Exception exception) {
if (e != null)
log.error("Commit failed for offsets {}", offsets, e);
}
});
}
} finally {
consumer.close();
}
Consumers - Combinaison synchrone et asynchrone
En temps normal, l’échec d’un commit sans nouvelle tentative derrière n’est pas tant un problème que cela
dans un fonctionnement normal car le prochain poll permettra de commit un offset plus haut.

Mais s’il s’agit par exemple d’un dernier commit avant de stopper le consumer ou d’un rebalance, on
souhaite tout de même être sur et certain que ce dernier commit sera pris en compte.

Ainsi, de manière générale, rien ne nous interdit d’utiliser les deux méthodes synchrones et asynchrones
pour être sûr qu’aucun message ne passe entre les mailles du filet.

● On effectue un commit asynchrone à chaque poll.

● Dès que l’on sort de la boucle du poll ou si le code échoue, on effectue un dernier commit synchrone.
Consumers - Combinaison synchrone et asynchrone
try {
while (true) {
ConsumerRecords<String, String> records = consumer.poll(100);
for (ConsumerRecord<String, String> record : records)
{
// On traite les records ici
}
consumer.commitAsync(new OffsetCommitCallback() {
public void onComplete(Map<TopicPartition, OffsetAndMetadata> offsets, Exception exception) {
if (e != null)
log.error("Commit failed for offsets {}", offsets, e);
}
});
}
} catch (Exception e) {
log.error("Unexpected error", e);
} finally {
try {
consumer.commitSync();
} finally {
consumer.close();
}
}
Consumers - Commit à un offset spécifique
Les commits vont par défaut se baser sur le offset le plus élevé obtenu lors d’un poll.

Mais comment faire pour commit de manière plus fréquente ?

Pourquoi ne faut-il pas appeler commitSync ou commitAsync dans la boucle de traitement des messages ?

En réalité, nous avons la possibilité, dans le commit, de fournir un dictionnaire de partitions avec les offsets
associés pour nous permettre de commit plus spécifiquement.

Cela est plus complexe puisque en pratique, un consumer ne va pas forcément consommer qu’une seule
partition (pour rappel, les consumers sont multi-subscribers sous Kafka).
Consumers - Rebalance
Lorsqu’un consumer tombe en panne, un rebalance se met en place.

C’est sûrement l’un des fonctionnalités les plus critiques mais aussi la plus importante.

Bien que nous ne rentrerons pas dans les détails dans ce cours, les objectifs du rebalance sont multiples.

● S’assurer que toutes les partitions ont été correctement ré-assignées.

● Permettre aux consumers de reprendre là où leur commit s’était arrêté.
● Être robuste face aux pannes brèves pour éviter des rebalances trop fréquents.
● Permettre de faire de rebalances dans le cas où beaucoup de consumers sont dans un groupe.

Sous Kafka, cela passe notamment par le Static Membership et le Incremental Cooperative Rebalancing.
Consumers et producers
Pour résumer sur les consumers et les producers dans Ka!a.

➔ Un producer va envoyer des records sur un ou plusieurs topics.

➔ Un consumer peut s'abonner à un ou plusieurs topics.

➔ Chaque consumer group peut contenir plusieurs consumers.

➔ Les consumers de deux consumers groups différents recevront les mêmes records.

➔ Les consumers dans un même consumer group recevront les records chacun leur tour.
Orchestration
Orchestration

Avec la vitesse de déploiement et l’agilité offerte par le Cloud Computing, il a fallu

être capable de provisionner de nouvelles ressources et déployer des
applications très rapidement.

Automatiser ces processus n’est pas une tâche facile car elle demande beaucoup
d’interactions avec l’infrastructure.

L’orchestration offre une couche intermédiaire plus facile à utiliser et permet

d’automatiser le déploiement.
Orchestration

Les orchestrateurs gèrent une infrastructure dans laquelle ils peuvent provisionner
de nouvelles ressources.

L’administrateur n’a besoin que de définir des fichiers de configuration (en YAML
ou JSON) pour définir les tâches d’automatisations à effectuer.

Le concept élémentaire pour l’orchestration est l’utilisation de machines virtuelles.

Qu’est-ce qu’une machine virtuelle ?

Machines virtuelles

Le concept de machine virtuelle a été décisif dans la popularité du Cloud

Computing.

Une machine virtuelle (abrégé en VM) est une isolation logique d’un système
d’exploitation dans un serveur physique.

⇒ Cela permet de faire tourner, sur un seul ordinateur/serveur, plusieurs serveurs

virtuels qui sont indépendant les uns des autres.
Machines virtuelles

Le disque dur physique est partagé par toutes les VM, même si elles ne peuvent
pas accéder au contenu des autres.

Le système d’exploitation hôte, qui est souvent un système Linux, exécute

l’hyperviseur.

L’hyperviseur (VMware, KVM, Proxmox) gère les ressources des VM, en parallèle
avec d’autres applications systèmes (souvent de monitoring et d’administration).
Machines virtuelles
Quelques orchestrateurs
Orchestration de conteneurs

Un type d’orchestration assez répandu aujourd’hui est l’orchestration de

conteneurs.

Plus axé côté applicatif, l’orchestration de conteneurs est devenu en quelques

années une compétence indispensable pour les DevOps et les administrateurs
Cloud.

Qu’est-ce qu’un conteneur ?

Docker

Docker est une plateforme de conteneurs open source qui permet de créer des
environnements isolés sur un seul et même système. Il permet de faciliter le
déploiement et permet une mise à l'échelle au niveau applicatif.
Conteneurisation Docker

Docker apporte une nouveauté : la virtualisation n'est plus réalisée par

l'hyperviseur sur le système hôte, mais par Docker lui-même.

Ainsi, Docker permet de conteneuriser des applications et de les isoler au même

titre qu'un hyperviseur isole des systèmes d'exploitations.

⇒ En d'autres termes, nous pourrons exécuter plusieurs applications, isolés

logiquement, sur un seul et même système d’exploitation avec Docker.

(Il est donc possible d’exécuter plusieurs conteneurs sur une seule VM, elle même
exécutée en parallèle sur une même machine par un hyperviseur)
Conteneurisation Docker

Cette approche ouvre de nouvelles possibilités sur le déploiement applicatif.

● Les conteneurs fournissent un environnement isolé, permettant ainsi d'éviter

d'installer des composants sur le système cible.
● Les conteneurs étant facilement déployable à l'instar d'un système, il est
relativement facile de les utiliser pour des applications qui demandent une
scalabilité.
● La configuration des conteneurs est effectué par une succession de
commandes regroupées dans un Dockerfile.
Conteneurs
Orchestration de conteneurs

L’orchestration de conteneurs consiste à automatiser et mettre à l’échelle le

déploiement de conteneurs.

Deux acteurs sont principalement présent sur le marché :

● Kubernetes, développé et maintenu par Google

● Docker Swarm, développé par les créateurs de Docker

Les applications aujourd’hui ne sont plus monolithiques mais regroupe des

dizaines voir centaines de composants, d’où le vif intérêt des conteneurs ces
dernières années.
Quelques orchestrateurs de conteneurs