Introduction au Big Data - Atelier Apache Spark

l'insertion de la donn e, contrairement aux donn es structur es (se trouvant

typiquement dans des bases de donn es relationnelles) qui, si elles ne

respectent pas la structure d nie, sont consid r es fausses et ne sont pas

autoris es tre enregistr es. On estime que seules 15% des donn es dans

une entreprise sont des donn es structur es, contre 85% qui ne le sont pas!

Dans une optique centr e sur les donn es, dont le but est de gagner le

maximum de vision partir des donn es, perdre autant de sources

d'information est un vrai probl me. Il est donc important que les syst mes

Big Data sachent interpr ter ces donn es et en extraire le maximum de

valeur.

Toutes les d cisions, choix et propri t s prises au niveau des architectures et

infrastructures Big Data sont r gies par ces trois caract ristiques, ce qui va

compl tement changer la vision "relationnelle" que tout informaticien qui se

respecte a acquis tout au long de ses ann es d' tude et de travail.

Cela dit, ce ne sont pas les seules propri t s. D'autres V ont vu le jour, mais sans

jamais avoir autant d'impact sur l'infrastructre, plut t dans la fa on de d nir les

processus, la gouvernance et les approches m tier adopter. Nous citons par

exemple :

V racit : c'est la conance que nous devons avoir en nos donn es. Cette

propri t est inversement proportionnelle au volume et la vari t : plus nos

donn es sont ables, moins elles sont diversi es et volumineuses!

Valeur : c'est la capacit d'extraire de la valeur m tier partir des donn es.

Variabilit : une extension de la vari t , qui indique quel point nos donn es

peuvent avoir des dimensions diff rentes partir des sources de donn es

disparates.

Visualisation : c'est la capacit de nos donn es tre repr sent es par les

outils de visualisation classiques.

etc.

Infrastructure Big Data : Besoins

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

4/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

Les caract ristiques des donn es Big Data cit es ci-dessus, entra nent des

besoins particuliers en termes d'infrastructure et d'architecture.

Volume

La caract ristique de volume, qui implique que la taille des donn es augmente

de fa on r guli re, fait qu'on ne peut plus se contenter d'un syst me centralis

classique. Car dans un syst me centralis (donc bas sur une seule machine),

augmenter les ressources de stockage au besoin implique ce que nous appelons

une scalabilit verticale ou un scale up, qui veut dire une augmentation des

capacit s du serveur de stockage en rajoutant des processeurs, de la RAM ou

des disques.

Cependant, cette solution, bien qu'elle soit intuitive, rapide et ne requiert pas de

changement architecturaux cons quents, implique en g n ral un temps d'arr t

pendant l'installation, ainsi qu'une d pense assez cons quente pour faire

l'acquisition d'un serveur puissant. De plus, une machine unique atteindra

rapidement une limite mat rielle, car il vous est impossible d'augmenter ses

ressources ind niment.

En contrepartie, il est possible de penser que, face un volume de donn es

toujours en augmentation, il serait plus judicieux de rajouter des machines au

besoin, cr ant ainsi un cluster de machines interconnect es, ou syst me r parti,

dont la taille et la capacit sont virtuellement illimit es. Nous sommes donc face

un autre type de scalabilit : la scalabilit horizontale ou le scale out.

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

5/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

Donc Volume =>

Scalabilit Horizontale

V locit

La v locit est une propri t qui, coupl e au volume, rend la gestion de

l'infrastructure un vrai cauchemar. En effet, g rer des donn es en continuelle

arriv e implique qu'il y'a un risque norme de perte de donn es, si elles ne sont

pas manipul es temps. C'est pour cette raison qu'un syst me Big Data se doit

d' tre continuellement disponible : toute requ te de lecture ou d' criture doit tre

trait e en un temps raisonnable, et le syst me doit tre continuellement alerte

pour saisir toutes les donn es, sans risquer de les perdre.

Ainsi V locit =>

Disponibilit

Vari t

La vari t de donn es implique non seulement que nous sommes en pr sence

de donn es structur es, semi-structur es et non structur es, mais galement

que ces donn es peuvent parvenir de sources diff rentes, avec des formats

diff rents, et que m me partir d'une m me source, ce format peut changer d'un

moment un autre. Dans les syst mes classiques, tout ce qui est variable doit

passer par une couche d'homog n isation qui transformera chaque entr e ou

enregistrement dans la forme souhait e, en remplissant par des valeurs NULL

les donn es manquantes. Rajouter cette couche d'homog n isation aura un

double impact n gatif sur notre syst me : (1) cause de la v locit , cette

op ration risquera de ralentir la collecte et saisie des donn es entrantes, et (2)

on pourra subir une perte de donn es suite ces transformations.

C'est pour ces raisons qu'un syst me Big Data se doit de supporter des types de

donn es changeants, sans pour autant requ rir des subterfuges qui

alourdissent ou contournent le syst me de stockage.

D'o Vari t =>

Flexibilit

Th or me CAP

Les besoins de scalabilit , disponibilit et exibilit , obligatoires pour avoir un

syst me Big Data en bonne et due forme, se trouvent confront s une

contrainte de taille... et qu'en est-il de la coh rence (commun ment appel e

aussi consistence, par anglicisme)?

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

6/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

La coh rence repr sente en effet un must pour les syst mes relationnels

classiques, et une base sur

laquelle sont prises toutes

les d cisions

conceptuelles et techniques. Elle repr sente le fait que les donn es stables

doivent respecter toutes les contraintes d'int grit d nies la cr ation de la

base de donn e. Par exemple, si un champ est d cr t "Not Null", il doit le rester

quelque soit la situation, et aucun moment une requ te ne doit surprendre ce

champs avec une valeur nulle, m me si c'est juste une valeur interm diaire. La

coh rence est un principe tr s rigide dans les bases de donn es relationnelles,

et repr sente le crit re de base pour la gestion des transactions : le C de ACID.

Cela dit, dans les syst mes Big Data, nous nous trouvons confront s un

probl me de taille : nous devons tre en pr sence d'une infrastructure r partie et

hautement disponible. Or, il existe un th or me appel CAP pour Consistency /

Availability / Partition tolerance, qui stipule que ces trois propri t s (notamment

la coh rence, la disponibilit et la tol rance au partitionnement), ne peuvent

jamais avoir lieu en m me temps. Seules deux d'entre elles peuvent tre

respect es la fois.

Essayons d'expliquer pourquoi.

Un syst me r parti est dit coh rent si tous ses noeuds voient les m mes

donn es en m me temps. C'est dire que, si nous r alisons une op ration de

lecture sur un syst me consistant, il devrait toujours retourner la valeur la plus

r cente qui ait t crite, quel que soit l'endroit partir duquel la lecture est

effectu e. Ainsi, si une donn e est modi e sur un noeud particulier, pour

conserver la coh rence demand e, aucune op ration de lecture ne doit tre

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

7/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

permise avant d'avoir mis jour toutes les r pliques (copies) de cette donn es.

Or, les diff rents noeuds d'un cluster sont en g n ral distants, parfois m me

g ographiquement, il est donc n cessaire d'attendre que la propagation de la

modication se fasse sur le r seau, pour effectuer n'importe quelle op ration,

m me une lecture. Ceci va rendre nos donn es indisponibles la lecture

pendant tout le temps que durera l'op ration de synchronisation, qui est un

temps incertain puisque... r seau. Assurer donc une coh rence forte dans un

syst me distribu est en contradiction avec le besoin de disponibilit du

syst me et des donn es. D'ailleurs, c'est ce que font les bases de donn es

relationnelles r parties, qui conservent les propri t s ACID tout en distribuant les

donn es, mais qui souffrent d'un manque notoire de performance.

Les syst mes Big Data, subissant les contraintes des V pr c demment cit s,

doivent donc faire un choix. Or ce choix est loin d' tre facile : qui voudra acheter

un syst me qui pr ne haut et fort qu'il est incoh rent ? L'id e serait donc de

partir sur le principe de coh rence ventuelle ou parfois de coh rence ajustable.

Ainsi, un syst me Big Data est un syst me principalement disponible,

fondamentalement r parti, et qui assure une coh rence ventuelle au bout d'un

temps g n ralement n gligeable, avec la possibilit de congurer les niveau de

coh rence parfois m me dynamiquement.

Les experts les appellent donc les syst mes BASE (admirez le jeux de mot..

ACID, BASE =):

Basically Available

Soft-state

Eventual consistency

La propri t de Soft State ou d' tat "mou" veut dire que l' tat du syst me peut

changer dans le temps, m me sans qu'il y ait une nouvelle entr e, cause du

principe de coh rence ventuelle expliqu pr c demment.

Maintenant que vous tes plus familiaris s avec les caract ristiques d'un

syst me Big Data, listons quelques principes, appel s ici MOTTOS, qui vont r gir

nos futures d cisions dans ce domaine.

Principes de base du Domaine des Big Data

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

8/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

Il est important, avant d'entamer n'importe quel travail sur les syst mes Big Data,

de consid rer certains principes, qui sont parfois en enti re contradiction avec

les principes classiques de d veloppement d'application. Ce n'est pas si

tonnant : le domaine des Big Data n'est pas cens prendre la place des

domaines relationnel et d cisionnel, mais plut t les enrichir et les agr menter.

MOTTO 1 : Stocker d'abord, r chir ensuite

cause de la v locit , il est important de consid rer qu'il nous sera parfois

dicile, voire impossible, de nettoyer les donn es ou de faire un traitement

quelconque dessus, avant de les stocker. Cela risque dans bien des cas de nous

faire perdre des donn es, le cauchemar de tout scientique des donn es!

Nous devons donc envisager la possibilit de d nir des syst mes de stockage

qui contiennent des donn es non nettoy es, en vrac (appel es raw data), pour

ensuite lancer des traitements dessus.. l'horreur pour un gestionnaire de bases

des donn es! =1

Bien entendu, ces "bases" ne sont pas con ues pour tre directement exploit es

par des applications externes, mais plut t pour conserver le plus longtemps

possibles les donn es brutes, sans perte, qui pourraient eventuellement tre

r utilis es pour d'autres ns.

MOTTO 2 : Absolument TOUTES les donn es sont importantes!

D'o l'int r t du MOTTO 1. Il nous est parfois dicile, au tout d but de la

conception des syst mes Big Data, de cerner toutes les possibilit s offertes par

ces syst mes et par les donn es que nous avons notre disposition. Nous

sommes donc en g n ral tent s de supprimer les donn es dont nous n'avons

pas besoin une fois extraite l'information imm diatement utile. Cela dit, gr ce

l'accessibilit des syst mes de stockage magn tiques et leur prix de plus en

plus bas, nous consid rons qu'il est largement plus b n que de stocker des

donn es qu'on n'utilisera peut- tre jamais, plut t que de gagner de la place et

perdre un potentiel pouvoir concurrentiel.

MOTTO 3 : Ce sont les donn es qui pilotent le traitement

Dans un syst me op rationnel classique, ainsi que dans la plupart des syst mes

d cisionnels, ce sont les besoins m tier qui pr valoient : le responsable m tier

commence par d nir les besoins (ou les KPIs : Key Performance Indicators dans

le cas d'un syst me d cisionnel), puis le responsable technique con oit les

structures de donn es pour r pondre ces besoins.

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

9/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

Par essence, un syst me Big Data fonctionne diff remment : les donn es sont

collect es tout d'abord partir de toutes les sources possibles; des traitements

de fouille et d'exploration de ces donn es sont lanc s ensuite, pour extraire de la

valeur partir de ces donn es. L'objectif est toujours le m me : chercher l'effet

WOW!

D'o l'int r t de ce MOTTO : d nir le traitement r aliser d pend des donn es

que nous avons r ussi collecter, et pas le contraire. Cela implique donc

l'utilisation d'autres types de syst mes de traitement et d'algorithmes d'analyse.

MOTTO 4 : Co-localisation des donn es et du traitement

Un syst me classique plusieurs couches, tel que le syst me trois tiers par

exemple, se base sur le principe de s paration des donn es et du traitement. On

trouve en g n ral des donn es sur un serveur de bases de donn es s par , et

les traitement complexes sur un serveur d'application qui se charge de

l'aggr gation et de l'achage de ces donn es. Ceci est agr ment d'un langage

de requ tage d claratif (typiquement SQL) pour r aliser des op rations de

ltrage, parfois assez lourdes et complexes, au niveau de la base de donn es.

Cela dit, dans un contexte Big Data, le volume des donn es peut s'av rer assez

cons quent, trop m me pour envisager de le d placer chaque fois vers un

autre syst me pour en extraire une vraie valeur. De plus, compter sur un langage

comme SQL pour diminuer le volume ou faire de simples agr gations au niveau

de la base de donn es pourra la rendre indisponible pendant un moment (car

n'oublions pas que nous parlons d'un syst me r parti), ce qui va l'encontre du

principe de v locit , qui exige une disponibilit toute preuve du syst me de

stockage.

C'est pour cette raison que, pour r aliser les traitements voulus en un temps

raisonnable et sans avoir trimballer les donn es sur le r seau, il est question

dans les syst mes Big Data de d placer le traitement vers les donn es

massives, au lieu de d placer les donn es vers le traitement.

MOTTO 5 : La redondance, c'est bien

Dans les bases de donn es relationnelles, le plus grand ennemi combattre

dans la conception de la structure de donn es est la redondance, et ce pour

deux raisons. La premi re, vidente, est le gain d'espace : notre espace de

stockage est pr cieux, et nous devons viter de le gaspiller sans raison pr cise.

La deuxi me est un besoin de coh rence : si nous dupliquons une m me

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

10/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

information plusieurs endroits dans la base, nous devrons par la suite faire

attention, parfois par des m canismes compliqu s et co teux, ce que cette

information soit mise jour instantan ment sur la totalit de ses copies.

Ce besoin d' viter la redondance a cr la n cessit d'utiliser plusieurs

techniques, telles que les jointures et clefs trang res, et entra ne parfois la

cr ation d'un tr s grand nombre de tables. Ceci rajoute une complexit pour le

requ tage, et une lourdeur d'ex cution des t ches sur la base.

Un syst me Big Data qui, non seulement est caract ris par un gros volume de

donn es, mais galement une grande v locit , et qui doit donc tre

imm diatement disponible, ne peut pas se permettre de gaspiller ses ressources

en requ tes inutiles. On tol re donc un certain point les risques dus la

redondance, pour gagner en disponibilit , primordiale dans ce type de syst mes.

D'autre part, un syst me Big Data est un syst me r parti par excellence, et dans

un syst me r parti, il est primordial d'assurer une bonne tol rance aux fautes en

cr ant des r pliques des donn es, diss min es partout sur le cluster. Ces

r pliques assurent qu'aucune machine n'est compl tement indispensable, et

diminue le risque d'indisponibilit des donn es. Un autre signe de redondance.

MOTTO 6 : Vive le Polyglottisme!

tre polyglotte, c'est tre capable de parler plusieurs langues. Et les syst mes

Big Data encouragent le polyglottisme. En effet, ce sont des syst mes

complexes qui impliquent en g n ral plusieurs traitements et plusieurs types de

donn es diff rentes (donn es brutes, donn es nettoy es, donn es trait es), ce

qui fait qu'il existe deux principes importants encourager :

Polyglot Programming : Une application peut comporter plusieurs langages

et paradigmes de programmation, chacun assurant un besoin particulier, de

fa on proter des avantages de chacun sa juste valeur.

Polyglot Persistence : Dans une m me application, il est possible d'utiliser

plusieurs syst mes de stockage diff rents (relationnels, NOSQL, syst mes

de chiers, etc.).

Gr ce ces deux principes, on pourra cr er des applications complexes mais

compl tes, qui permettent d'assurer tous les besoins en terme de stockage et de

traitement.

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

11/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

Technologies et Paradigmes

Les op rations r aliser sur les syst mes Big Data consistent principalement en

:

Ingestion des donn es : repr sente les phases de collecte et d'importation

des donn es pour tre stock es ou trait es la vol e. Cela peut se faire en

"temps r el", c'est dire que les donn es sont import es au moment o

elles sont mises par leur source, ou bien "par lots", ce qui veut dire que les

donn es sont import es par portions intervalles r gulier.

Exemples de technologies

Apache

Kafka

,

Amazon

Kinesis

,

Apache

Flume

, Sqoop , etc.

Stockage des donn es : Les syst mes de stockage de donn es respectant

les propri t s le Big Data se distinguent principalement en syst mes de

chiers

distribu s,

tel

que

Hadoop

HDFS

ou Google GFS

, ou bases de donn es NOSQL, tel que

MongoDB

,

Cassandra

,

Redis

ou Neo4J

.

Traitement des donn es : Plusieurs types de traitement de donn es sont

possibles, nous citons :

Traitement par lot (Batch Processing) : c'est le traitement des donn es au

repos (data at rest) qui se fait sur l'ensemble des donn es stock es,

sans avoir besoin d'une interaction avec l'utilisateur. Le traitement par

lot est adapt principalement aux op rations ayant lieu la n d'un

cycle, permettant d'avoir une vision globale sur la totalit des donn es,

par exemple pour avoir un rapport global ou une analyse mensuelle. Les

op rations de traitement par lots sont en g n ral lanc es des p riodes

r guli res, car elles sont connues pour avoir une grande latence (temps

total de traitement).

Exemples de technologies

Hadoop

Map

Reduce

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

12/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

et

Spark Batch .

Traitement en Streaming (Stream Processing) : c'est le traitement des

donn es en transit (data in motion), ou en d'autres termes, le traitement

des donn es pendant qu'elles sont produites ou re ues. Les donn es

tant en g n ral cr es en tant que ux continu ( v nements de

capteurs, activit des utilisateurs sur un site web, ux vid o, etc.), elles

sont captur es comme une s rie d' v nements continus dans le temps.

Avant la cr ation des traitements en streaming, ces donn es taient

stock es dans une base de donn es, un syst me de chier ou tout autre

forme de stockage en masse. Les applications appelleront ensuite les

donn es au besoin. Gr ce ce nouveau paradigme, les donn es

peuvent maintenant tre trait es la vol e, ce qui permet la couche

applicative d' tre toujours sur coute et jour.

Exemples de technologies

Apache

Flink

et Apache

Storm

.

Traitement par Micro-Lot (Micro-Batch Processing) : c'est la pratique de

collecter les donn es en petits groupes (appel s des micro-lots ou des

micro-batchs) pour les traiter. Contrairement au traditionnel traitement

par lot, cette variante fait en sorte que le traitement des donn es soit

plus fr quent, et que les r sultats soient produits avec une latence

beaucoup plus petite. Les donn es sont collect es par intervalles selon

un seuil pr d ni, limit par un temps (par exemple toutes les

secondes), ou par un nombre (tous les 20 l ments). Ce traitement est

en g n ral une alternative au traitement en streaming, o les donn es

sont trait es la vol e, mais risquent d' tre perdues si le temps de

traitement est sup rieur la fr quence de g n ration des donn es. Le

micro-batching permet, par contraste, de sauvegarder les donn es dans

un buffer, ralentissant ainsi le ux g n r . D'autre part, les donn es

tant trait es par micro-lots, il est possible d'avoir une visibilit sur ce

petit lot de donn es, contrairement au traitement en streaming qui n'a de

visibilit que sur la derni re donn e g n r e, moins de proc der des

m canismes parfois co teux. En contrepartie, le traitement en micro-

batch donne des r sultats moins r cents que le "vrai" streaming, et

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

13/14

3/20/2021

P1 - Introduction au Big Data - Atelier Apache Spark

s'ex cute sous forme de bursts r guliers, qui peuvent parfois tre

g nants pour le syst me sous-jacent.

Exemples de technologies

Spark Streaming

et

Logstash

.

Traitement Interactif (Interactive Processing) : Dans les syst mes Big

Data, la notion de transaction n'est plus exactement la m me que pour

les syst mes classiques: nies les sacro-saintes propri t s ACID dont le

premier objectif est d'avoir des donn es correctes et coh rentes, et

bonjour les propri t s BASE, qui favorisent un acc s moins rigide aux

donn es. On parle donc rarement de traitement transactionnel en Big

Data, mais de traitements plut t interactifs : une requ te est envoy e par

le client, trait e imm diatement par le syst me qui renverra un r sultat

dans un temps raisonnable. On parle alors d'interaction entre l'utilisateur

et le syst me. Les traitements en batch et en streaming ne sont pas

cens s communiquer avec un utilisateur de l'autre c t . En g n ral, les

r sultats de ces traitements sont enregistr s dans un syst me de

stockage, qui sera, lui, par la suite interrog par l'utilisateur. Le

traitement interactif est donc le r sultat d'une requ te de l'utilisateur,

faite en g n ral sur une base de donn es (relationnelle ou NOSQL).

Exemples de technologies

Apache

Drill

,

Cloudera

Impala

ou

Apache

Zeppelin

.

https://liliasfaxi.github.io/Atelier-Spark/p1-big-data/

14/14