Du Big Data vers le SMART Data : Scénario d'un processus

DU BIG DATA VERS LE SMART DATA
SCENARIO D’UN PROCESSUS
ANALYSE
TEMPS-REEL
CHAKER ALLAOUI

TABLE DE MATIERES
• Données • Big Data • Format JSON • Apache Zookeeper
01 02 03 04INTRO
• Apache Storm • Apache Kafka • Apache Cassandra • Apache Spark
05 06 07 08
• SparkSQL • SparkUI • D3 • SMART DATA
09 10 11 12
Scénario du processus

SCENARIO D’UN PROCESSUS
Big Data vers SMART Data

Creative
process
Analytical
process
le Big data, désigne l’explosion
du volume des données
numérisées, collectées par des
particuliers, des acteurs
publics, des applications
informatiques qui regroupent
des communautés
d’utilisateurs à l’échelle de la
planète. Il suffira de citer
quelques exemples plus ou
moins connus de tous : Google,
son moteur de recherche et ses
services ; les réseaux dit
sociaux : Facebook et son
milliard d’utilisateurs qui
déposent des images, des
textes, des échanges ; les sites
de partage et de diffusion
d’images et de photos (FlickR) ;
les sites communautaires
(blogs, forums, wikis) ; les
services administratifs et leurs
Scénario du processus: Analytique & Créative
échanges numérisés. Au centre de tous ces
aspirateurs de données, on trouve Internet,
le Web, et sa capacité à fédérer dans
l’espace numérisé des milliards
d’utilisateurs, mais également la profusion
de capteurs de toutes sortes, accumulant des
données scientifiques à un rythme inédit
(images satellites par exemple). Pour en
rester au Web, tous les messages, tous les
documents, toutes les images et vidéos sont
captés par des applications qui, en échange
des services fournis, accumulent
d’immenses banques de données.
On parle en millions de serveurs pour
Google, Facebook ou Amazon, stockés
dans d’immenses hangars qui, par
ailleurs, consomment une part non
négligeable de l’électricité produite. Et le
mouvement semble aller s’accélérant.
D’où la nécessité de présenter un système
de combinaison de ces multiples sources.
Donc l’idée est de créer un scénario
complet d’un processus de transformation
des ces données de masse en données
exploitable et présentatives pour faciliter
leurs gestion et faire implémenter
l’informatique décisionnelle pour
analyser et fédérer ces données.
La solution comporte des softwares open
source dont la majorité sont issues des
projets de la fondation Apache.

Message
MapReduceDashboard
JSON
Kafka Cassandra
SparkD3
Storm
WebSockets
Streaming
Topic ORM
Aggregation
Big Data
Tuples/Zookeeper
Queue/Zookeeper Cassandra Driver
RDD/SparkSQL
RAM/FILE SYSTEM
TCP/UDP
DataBase Storage
Business Intelligence
InputStream
BIG DATA VERS SMART DATA LE SCENARIO D’UN PROCESSUS
Analytical transformations

Données
WebSockets
TCP/UDP
InputStream


Data
WebSockets
Le protocole WebSocket vise à
développer un canal de
communication full-duplex sur un
socket TCP pour les navigateurs et
les serveurs web. L'interactivité
croissante des applications web,
consécutive à l'amélioration des
performances des navigateurs, a
rapidement rendu nécessaire le
développement de techniques de
communications bidirectionnelles
entre l'application web et les
processus serveur. Des techniques
basées sur l'appel par le client de
l'objet « XMLHttpRequest »
et utilisant des requêtes HTTP avec
un long TTL stockées par le
serveur pour une réponse
ultérieure au client ont permis de
pallier ce manque par Ajax.
TCP/UDP
UDP est un protocole orienté
"non connexion« , lorsqu'une
machine A envoie des paquets
à destination d'une machine B,
ce flux est unidirectionnel. En
effet, la transmission des
données se fait sans prévenir le
destinataire (la machine B), et
le destinataire reçoit les
données sans effectuer
d'accusé de réception vers
l'émetteur (la machine A).
TCP est orienté "connexion".
Lorsqu'une machine A envoie
des données vers une machine
B, la machine B est prévenue
de l'arrivée des données, et
témoigne de la bonne
réception de ces données par
un accusé de réception.
InputStream
Les flux d’entrées permettent
d'encapsuler ces processus
d'envoi et de réception de
données. Les flux traitent
toujours les données de façon
séquentielle. Les flux peuvent
être divisés en plusieurs
catégories: les flux de traitement
de caractères et les flux de
traitement d'octets.
Les flux d’entrées peuvent être
des webservices, un flus de
données venant des réseaux
sociaux tels: twitter API etc...
Données: WebSockets-TCP/UDP-InputStream
Binary Data
Structured Data
Unstructured Data
API Interface
http://fr.wikipedia.org

Lire un contenu: cURL
Pour lire le contenu d’une source web, on va
manipuler: « cURL » (Client URL Request Library ), c’est
une interface en ligne de commande destinée à
récupérer le contenu d'une ressource accessible par un
réseau informatique. La ressource est désignée à l'aide
d'une URL et doit être d'un type supporté par le logiciel,
il peut ainsi être utilisé en tant que client REST.
La bibliothèque supporte notamment les protocoles FTP,
FTPS, HTTP, HTTPS, TFTP, SCP, SFTP, Telnet, DICT, FILE
et LDAP. L'écriture peut se faire en HTTP en utilisant les
commandes POST ou PUT.
cURL est une interface générique nous permettant de
traiter un flux de données.
L’exemple ci-joint présente la lecture d’un contenue
d’un fichier JSON présent sur un serveur en local.
L’idée est de savoir comment les logiciels de streaming
traite les requêtes de lecture, modification, ajout ou
suppression de données distantes.
Une requête de lecture peut se faire de cette façon:
> curl –i –H « Accept: application/json » -H « Content-
Type:application/json » http://www.host.com/data.json
Commande cURL : lire un flux JSON

BIG DATA
Volume-Valeur
Vélocité-Variété

La définition initiale donnée
par le cabinet McKinsey and
Company en 2011 s’orientait
d’abord vers la question
technologique, avec la célèbre
règle des 3V :
un grand Volume de données,
une importante Variété de ces
mêmes données et une Vitesse
de traitement s’apparentant
parfois à du temps réel.
Ces technologies étaient
censées répondre à l’explosion
des données dans le paysage
numérique (le « data deluge »).
Puis, ces qualificatifs
ont évolué, avec une vision
davantage économique portée
par le 4ème V:
Le Big Data s'accompagne du
développement d'applications à
visée analytique, qui traitent les
données pour en tirer du sens. Ces
analyses sont appelées Big Analytics
ou «broyage de données». Elles
portent sur des données
quantitatives complexes avec des
méthodes de calcul distribué. En
2001, un rapport de recherche du
META Group définit les enjeux
inhérents à la croissance des
données comme étant tri-
dimensionnels :
les analyses complexes
répondent en effet à la règle
dite «des 3V» (volume, vélocité
et variété). Ce modèle est
encore largement utilisé
aujourd'hui pour décrire ce
phénomène.
Le taux de croissance annuel
moyen mondial du marché de
la technologie et des services
du Big Data sur la période
2011-2016 devrait être de
31,7%. Ce marché devrait ainsi
atteindre 23,8 milliards de
dollars en 2016 (d'après IDC
mars 2013).
Le Big Data devrait également
représenter 8% du PIB
européen en 2020.
Oragnisation
des données
Centralisation
des données
Combinaison
des données
Support
aux décisions
Big Data
http://recherche.cnam.fr/equipes/sciences-industrielles-et-technologies-de-l-information/big-data-decodage-et-analyse-des-enjeux-661198.kjsp
Le Valeur

Volume: C'est une dimension relative : le Big Data
comme le notait Lev Manovitch en 2011 définissait
autrefois « les ensembles de données suffisamment
grands pour nécessiter des super-ordinateurs »,
mais il est rapidement devenu possible d'utiliser des
logiciels standards sur des ordinateurs de bureau
pour analyser ou co-analyser de vastes ensembles
de données. Le volume des données stockées est en
pleine expansion : les données numériques créées
dans le monde seraient passées de 1,2 Z-octets par
an en 2010 à 1,8 Z-octets en 2011
Vélocité: représente à la fois la
fréquence à laquelle les données
sont générées, capturées et
partagées et mises à jour. Des flux
croissants de données doivent être
analysés en quasi-temps réel pour
répondre aux besoins des
processus chrono-sensibles. Par
exemple, les systèmes mis en place
par la bourse et les entreprises
doivent être capables de traiter ces
données avant qu’un nouveau
cycle de génération n’ait
commencé, avec le risque pour
l‘homme de perdre une grande
partie de la maîtrise du système
quand les principaux opérateurs
deviennent des "robots" capables
de lancer des ordres d'achat ou de
vente de l'ordre de la
nanoseconde, sans disposer de
tous les critères d'analyse pour le
moyen et long terme.
puis 2,8 Z-octets en 2012 et
s'élèveront à 40 Z-octets en 2039.
Par exemple Twitter générait en
janvier 2013, 7 Téraoctets/jour.
Variété: Le volume des Big Data
met les data-centers devant un
réel défi : la variété des données. Il
ne s'agit pas de données
relationnelles traditionnelles, ces
données sont brutes, semi-
structurées voire non structurées.
Ce sont des données complexes
provenant du web, au format
texte et images (Image Mining).
Elles peuvent être publiques
(Open Data, Web des données),
géo-démographiques par îlot
(adresses IP), ou relever de la
propriété des consommateurs. Ce
qui les rend difficilement
utilisables avec les outils
traditionnels de gestions de
données pour en sortir le meilleur.
http://fr.wikipedia.org/wiki/Big_data

Format JSON
JavaScript
Object
Notation

Format JSON
JSON (JavaScript Object Notation) est un format léger
d'échange de données. Il est facile à lire ou à écrire pour
des humains. Il est aisément analysable ou généré par
des machines. Il est basé sur un sous-ensemble du
langage de programmation JavaScript. JSON est un
format texte complètement indépendant de tout langage,
mais les conventions qu'il utilise seront familières à tout
programmeur. JSON se base sur deux structures :
Une collection de couples key/value. Divers langages la
réifient par un objet, un enregistrement, une structure.
Ou un dictionnaire, une table de hachage, une
liste typée ou un tableau associatif. Une liste de
valeurs ordonnées. La plupart des langages la
réifient par un tableau, un vecteur, une liste ou
une suite. Ces structures de données sont
universelles. Pratiquement tous les langages de
programmation modernes les proposent sous
une forme ou une autre. Il est raisonnable
qu'un format de données interchangeable avec
des langages de programmation se base aussi
sur ces structures. En JSON, elles prennent les
formes suivantes : Un objet, qui est un ensemble
de couples key/value non ordonnés. Un objet
commence par « { » et se termine par « } ».
Chaque nom est suivi de « : » et les couples
key/value sont séparés par « , ».
Un tableau est une collection de valeurs
ordonnées. Un tableau commence par « [ »et se
termine par « ] ». Les valeurs sont séparées par
« , », les champs du tableau sont séparés par
« : », et peuvent contenir des valeurs de type de
base, comme les entiers, les chaines de
caractères ou des types complexe: objets…
Données
structurées
Universel
Traitement rapide
Riche en
composants
http://www.json.org/jsonfr.html

APACHE ZOOKEEPER
Travaillons avec les systèmes distribués

APACHE ZOOKEEPER ZooKeeper
Apache Zookeeper est un
framework pour fédérer les
communications entre des systèmes
distribués, il fonctionne en
fournissant un espace mémoire
partagé par toutes les instances
d’un même ensemble de serveurs.
Cet espace mémoire est
hiérarchique, à la manière d’un
système de fichier composé de
répertoires et de fichiers. Il est
distribué, consiste en plusieurs
machines connectées entre elles et
qui résolvent ensemble un
problème, par opposition avec un
système centralisé, donc une grosse
machine unique qui prend tout à sa
charge. Le cas de Google, pour
lequel aucune machine unique ne
saurait traiter toutes les requêtes. Le
simple fait d’avoir plusieurs
machines qui doivent travailler
ensemble est une source de
problèmes, parmi lesquelles:
La résistance aux pannes : si
une machine tombe en panne
dans le réseau, que faire. Si elle
est la seule à porter des
informations importantes,
celles-ci sont perdues. Dans ce
cas, on règle la question avec la
redondance des informations,
dupliquées sur plusieurs
machines. La consistance de
l’information, en particulier si
elle est dupliquée. Le but est
d’offrir une indépendance de la
valeur de la donnée par rapport à
sa source : on veut éviter que
chaque machine porte une version
différente, d’une information dont
on a besoin. La répartition de la
charge : comment bien gérer ses
ressources pour éviter qu’une seule
machine ne soit trop sollicitée, alors
que les autres sont inactives.
Comment une requête émise par un
client est-elle traitée, Qui le fait ? Et
comment garantir que le résultat
est le bon, indépendamment de la
machine qui a traité la question.
C’est le problème dit du consensus :
on dit qu’il y a consensus si deux
machines ayant les mêmes données
initiales donnent le même résultat
pour le même traitement.
Distibué
Implémentation
en local
Implémentation
dans le Cloud
Orchestrateur
http://blog.zenika.com/index.php?post/2014/10/13/Apache-Zookeeper-facilitez-vous-les-systemes-distribues2

Systèmes distribués
La communication entre les
instances ou machines se passe en
mode asynchrone. Par exemple,
vous voulez envoyer un message à
un ensemble d’instances (un
cluster) pour lancer un traitement.
Vous avez aussi besoin de savoir si
une instance est opérationnelle.
Pour bien communiquer, une
méthode utilisée consiste en une
queue. Celle-ci permet d’envoyer
des messages directement ou par
sujet, de les lire de manière
asynchrone. La communication en
mode cluster se passe exactement
comme une communication, en
mode local avec plusieurs
processus, et passe par la
coordination dans l’usage des
ressources. Concrètement, quand
un nœud écrit sur un fichier, il est
préférable qu’il pose un verrou,
visible par tous les autres
nœuds, sur le dit fichier.
Un système de fichiers distribué
ne souhaite pas savoir que tel
fichier est sur l’instance
machin. Il veut avoir l’illusion
de manipuler un unique
système de fichiers, exactement
comme sur une seule machine.
La gestion de la répartition des
ressources, avec ce qu’il faut
faire si une instance ne répond
pas, n’est pas utile à savoir.
Un service de nommage : pour
le présenter, certes de manière
approximative, on aimerait une
sorte de Map<String,Object>
qui soit répartie sur le réseau,
que toutes les instances
puissent utiliser. Un exemple
type serait JNDI. Le but du
service de nommage consiste à
avoir un système distribué d’accès aux objets.
Un système robuste de traitement des requêtes est une
architecture répartie qui accueille des données en
temps réel. Dans le cas d’une structure avancées, on se
souhaite pas perdre la moindre données tels que: les
ordres boursiers, l’idée est de faire un traitement qui
récupère les données d’une instance avant qu’elle
tombe en panne ou sort du réseaux. La démarche de
Zookeeper est d’élir un leader à chaque mise en
marche de système, et ce dernier qui assure le partage
de l’information et les cadres dans les quels une
information doit être persister dans le système pour en
garder la trace, en prenant compte de l’avis de chaque
Znodes ou exactement la réponse pour faire
sauvegarder une information, ainsi un nombre
supérieur à n/2 où n est le nombre de nœuds ayant
reçus et accepter l’ordre de l’écriture, ainsi l’opération
d’écriture sur tous les nœuds est lancée.

ZOOKEEPER: ZNodes
> .binzkServer.cmd
> .binzkCli.cmd 127.0.0.1:2181
Liste des noeuds Zookeeper
Instance Zookeeper

APACHE STORM
Streaming temps-réel

Apache Storm est un système
de calculs temps réel distribué
et tolérant aux pannes,
développé à l’origine par la
société BackType. Le projet est
devenu open-source après
l’acquisition de la société par
Twitter. Il est disponible sous
licence Eclipse Public License
1.0. De plus, Storm est entré
depuis quelques mois dans le
processus d’incubation de la
fondation Apache. Pour traiter
en continu plusieurs flux de
données, Storm repose sur la
définition d’une topologie.
Une topologie prend la forme d’un
graphe orienté acyclique dans lequel :
Les streams, symbolisés par les arcs,
sont des séquences illimitées de tuples.
Un tuple est une liste de valeurs
nommées qui représente le modèle de
données utilisé par Storm.
Les spouts, nœuds racine du graphe,
désignent les sources de streams. Il
peut s’agir par exemple d’une
séquence de tweets émis via l’API
Twitter, d’un flux de logs ou encore de
données lues directement depuis une
base de données.
Et enfin, les bolts sont les nœuds qui
consomment ces séquences de tuples
émis par un ou plusieurs nœuds. Ils
ont pour rôle de réaliser différentes
opérations (filtres, agrégations,
jointures, lecture/écriture vers et
depuis une base de données, etc.) et si
besoin d'émettre à leur tour une
nouvelle séquence de tuples.
Storm: Les concepts
Analyse
Big Data
Distribué
Concept de
Topologie
http://blog.zenika.com/index.php?post/2014/01/31/Storm-Ajouter-du-temps-reel-a-votre-BigData

Le regroupement de flux
répond à la question suivante:
lorsqu’un tuple est émis, vers
quels bolts doit-il être dirigé.
En d’autres termes, il s’agit de
spécifier la manière dont les
flux sont partitionnés entre les
différentes instances d’un
même composant spout ou
bolt. Pour cela, Storm fournit
un ensemble de
regroupements prédéfinis,
dont voici les principales
définitions :
- Shuffle grouping : Les tuples
sont distribués aléatoirement
vers les différentes instances
bolts de manière à ce que
chacune reçoive un nombre
égal de tuples.
Streams: grouping, worker, executor
- Fields grouping : Le flux est
partitionné en fonction d’un ou
plusieurs champs.
- All grouping: Le flux est
répliqué vers l’ensemble des
instances. Cette méthode est à
utiliser avec précaution
puisqu'elle génère autant de flux
qu’il y a d’instances.
- Global grouping: L’ensemble du
flux est redirigé vers une même
instance. Dans le cas, où il y en a
plusieurs pour un même bolt, le
flux est alors redirigé vers celle
ayant le plus petit identifiant.
Lorsqu’une topologie est soumise à Storm, celui-ci
répartit l’ensemble des traitements implémentés par
vos composants à travers le cluster. Chaque
composant est alors exécuté en parallèle sur une ou
plusieurs machines.
Storm exécute une topologie composée d’un spout et
de deux bolts. Pour chaque topologie, Storm gère un
ensemble d’entités distinctes:
Un « worker process » est une JVM s’exécutant sur
une machine du cluster. Il a pour rôle de coordonner
l'exécution d'un ou plusieurs composants (spouts ou
bolts) appartenant à une même topologie. Ainsi le
nombre de workers associés à une topologie peut
changer au cours du temps.
Un « executor » est un thread lancé par un « worker
process ». Il est chargé d'exécuter une ou plusieurs
« task » pour un bolt ou spout spécifique. Ainsi le
nombre d’exécuteurs associés à un composant peut
changer au cours du temps.
Les « tasks » effectuent les traitements à appliquer sur
les données. Chaque « task » représente une instance
unique d'un bolt ou d’un spout.

Storm cluster: les propriétés

Storm: analyse d’une Topologie

Storm: Traitement du JSON avec les spouts
Parsing du flux JSON avec Storm Java API

APACHE KAFKA
Producteur-Consommateur de Contenu

Apache a publié Kafka 0.8, la
première version majeure de Kafka,
depuis que le projet est devenu un
projet de top niveau de la Fondation
Logicielle Apache. Apache Kafka est
un système orienté message de type
publication-souscription implémenté
comme système de traces
transactionnel distribué, adapté pour
la consommation de messages en-
ligne et hors ligne. Il s'agit d'un
système orienté message développé à
l'origine à LinkedIn pour la collection
et la distribution de volumes élevés
d'évènements et de données de trace à
latence faible. La dernière version
comprend la réplication intra-cluster
et le support de multiples répertoires
de données. Les fichiers de trace
peuvent être permutés par âge, et les
niveaux de trace peuvent être
valorisés dynamiquement par
JMX. Un outil de test de
performance a été ajouté, pour
aider à traiter les inquiétudes et à
chercher les améliorations
concernant les performances.
Kafka est un service de commit de
traces distribué, partitionné et
répliqué.
Les producteurs publient des
messages dans des sujets Kafka,
les consommateurs
s'abonnent à ces sujets et
consomment les
messages. Un serveur dans
un cluster Kafka est appelé
un intermédiaire. Pour
chaque sujet, le cluster Kafka
maintient une partition pour
la montée en charge, le
parallélisme et la résistance
aux pannes.
Temps-réel
Distibué
Gestion
de la mémoire
Tracabilité
http://www.infoq.com/fr/news/2014/01/apache-afka-messaging-system
Apache Kafka

La remédiation est contrôlée
par le consommateur. Un
consommateur typique traitera
le message suivant dans la
liste, bien qu'il puisse
consommer les messages dans
n'importe quel ordre, car le
cluster Kafka conserve tous les
messages publiés pour une
période de temps configurable.
Cela rend les consommateurs
très économiques, car ils vont
et viennent sans beaucoup
d'impact sur le cluster, et
autorisent les consommateurs
déconnectés comme les
clusters Hadoop. Les
producteurs sont capables de
choisir le sujet, et la partition
au sein du sujet, dans lequel
publier le message. Les
consommateurs s'auto-
affectent un nom de groupe de
consommateur, et chaque
message est distribué à un
consommateur dans chaque
groupe de consommateurs
abonnés. Si tous les
consommateurs ont des
groupes différents, alors les
messages sont diffusés à
chaque consommateur. Kafka
peut être utilisé comme un
middleware de message
traditionnel. Il offre un débit
élevé et dispose de capacités de
partionnement natif, de
réplication et de résistance aux
pannes, ce qui en fait une
bonne solution pour les
applications de traitement de messages de grande
ampleur. Kafka peut également être employé pour le
suivi de sites web à fort volume. L'activité du site peut
être publiée et traitée en temps réel, ou chargée dans
système d'entrepôt de données Hadoop ou hors-ligne.
Kafka peut également être utilisé comme solution
d'agrégation de traces. Au lieu de travailler avec des
fichiers, les traces peuvent être traitées comme des flux
de messages. Kafka est utilisé à LinkedIn et il gère plus
de 10 milliards d'écritures par jour avec une charge
soutenue qui avoisine 172 000 messages par seconde. Il
y a une utilisation massive de support multi-abonnés
Topic Kakfa

APACHE KAFKA: producteur - topic - consommateur
> bin/zookeeper-server-start.sh config/zookeeper.properties
> bin/kafka-server-start.sh config/server.properties
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --
replication-factor 1 --partitions 1 --topic test
> bin/kafka-topics.sh --list --zookeeper localhost:2181
> bin/kafka-console-producer.sh --broker-list localhost:9092 --
topic test
toto
Hello World
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --
topic test --from-beginning
toto
Hello World

APACHE KAFKA: Transmission d’un flux JSON
import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;
import kafka.producer.KeyedMessage;
import kafka.producer.ProducerConfig;
public class KafkaProducer {
private static kafka.javaapi.producer.Producer<Integer, String> producer = null;
private static String topic = "topic_message";
private static Properties props = new Properties();
public KafkaProducer() { }
public void sendMessage() {
try {
props.put("serializer.class", "kafka.serializer.StringEncoder");
props.put("metadata.broker.list", « 127.0.0.1:9092");
producer = new kafka.javaapi.producer.Producer<Integer, String>(new ProducerConfig(props));
BufferedReader br = null;
String sCurrentLine;
br = new BufferedReader(new FileReader(« ./data.json"));
while ((sCurrentLine = br.readLine()) != null) {
producer.send(new KeyedMessage<Integer, String>(topic, sCurrentLine));
}
producer.send(new KeyedMessage<Integer, String>(topic, new String(content)));
} catch (IOException e) {
e.printStackTrace();
}
finally {
try {
if (br != null)
br.close();
} catch (IOException ex) {
ex.printStackTrace();
}}
}}

APACHE CASSANDRA
Base de données NoSQL

réplication désigne le nombre de
nœuds où la donnée est
répliquée. Par ailleurs,
l'architecture de Cassandra
définit le terme de cluster comme
étant un groupe d'au moins deux
nœuds et un data-center comme
étant des clusters délocalisés.
Cassandra permet d'assurer la
réplication à travers différents
data-center. Les nœuds qui sont
tombés peuvent être remplacés
sans indisponibilité du service.
• Décentralisé : dans un cluster
tous les nœuds sont égaux. Il n'y
pas de notion de maitre, ni
d'esclave, ni de processus qui
aurait à sa charge la gestion, ni
même de goulet d'étranglement
au niveau de la partie réseau. Le
protocole
Apache Cassandra est une base de
données de la famille NoSQL très
en vogue. Elle se classe parmi les
bases orientées colonnes tout
comme HBase, Apache Accumulo,
Big Table. Cette base a été
développée à l'origine par des
ingénieurs de Facebook pour leurs
besoins en interne avant d'être
mise à la disposition du grand
public en open-source.
CARACTERISTIQUES
• Tolérance aux pannes : les
données d'un nœud (un nœud est
une instance de Cassandra) sont
automatiquement répliquées vers
d'autres nœuds (différentes
machines). Ainsi, si un nœud est
hors service les données présentes
sont disponibles à travers d'autres
nœuds. Le terme de facteur de
GOSSIP assure la découvert, la
localisation et la collecte de toutes
les informations sur l'état des
nœuds d'un cluster.
• Modèle de données riche : le
modèle de données proposé par
Cassandra basé sur la notion de
key/value permet de développer
de nombreux cas d'utilisation
dans le monde du Web.
• Élastique : la scalabilité est
linéaire. Le débit d'écriture et de
lecture augmente de façon
linéaire lorsqu'un nouveau
serveur est ajouté dans le cluster.
Par ailleurs, Cassandra assure
qu'il n'y aura pas d'indisponibilité
du système ni d'interruption au
niveau des applications.
Analyse
Stockage
Distribué
Gestion
de la mémoire
APACHE Cassandra
http://www.infoq.com/fr/articles/modele-stockage-physique-cassandra-details

Dans le monde des bases de données
NoSQL, on entend souvent parler du
Théorème CAP. Ce théorème établit
3 paramètres sur lesquels on peut
jouer pour configurer une base de
données distribuée
- La cohérence ( C pour
Consistency)
- La disponibilité ( A pour
Availability)
- La tolérance aux pannes et aux
coupures réseaux ( P pour Partition-
tolerance)
Le théorème postule que pour toute
base de données distribuée, on ne
peut choisir que 2 de ces 3
paramètres, jamais les 3 en même
temps. En théorie, on peut donc
choisir les couples suivants :
a. Cohérence et disponibilité ( CA )
donc non résistante aux pannes ( P )
b. Cohérence et tolérance aux
pannes ( CP ) donc non
disponible à 100% ( A )
c. Disponibilité et tolérance
aux pannes ( AP ) donc non
cohérente à 100% ( C )
Ceci est la théorie. En pratique,
on se rend compte que le
paramètre P est plus ou moins
imposé. En effet, les coupures
réseaux cela arrive, c'est
inévitable. Du coup, le choix se
résume en fin de compte à CP
ou AP. Cassandra fait clairement le choix de AP pour
une tolérance aux pannes et une disponibilité absolue.
En contrepartie, Cassandra sacrifie la cohérence
absolue (au sens ACID du terme) contre une
cohérence finale, c'est à dire une cohérence forte
obtenue après une convergence des données ou AP.
Cassandra fait clairement le choix de AP pour une
tolérance aux pannes et une disponibilité absolue. En
contrepartie, Cassandra sacrifie la cohérence absolue
(au sens ACID du terme) contre une cohérence finale,
c'est à dire une cohérence forte obtenue après une
convergence des données ou AP. Cassandra fait
clairement le choix de AP pour une tolérance aux
pannes et une disponibilité absolue. En contrepartie,
Cassandra sacrifie la cohérence absolue (au sens
ACID du terme) contre une cohérence finale, c'est à
dire une cohérence forte obtenue après une
convergence des données ou AP. Cassandra fait
clairement le choix de AP pour une tolérance aux
pannes et une disponibilité absolue. En contrepartie,
Cassandra sacrifie la cohérence absolue (au sens
ACID du terme) contre une cohérence finale, c'est à
dire une cohérence forte obtenue après une
convergence des données
Théorème CAP
http://www.infoq.com/fr/articles/cap-twelve-years-later-how-the-rules-have-changed

CQLSH
CQL veut dire Cassandra
Query Language, et nous
sommes à la version 4. La
première version a été une
tentative expérimentale
d'introduire un langage de
requête pour Cassandra. La
deuxième version de CQL a été
conçue pour requêter les wide
rows mais n'était pas assez
flexible pour s'adapter à tous
les types de modélisation qui
existent dans Apache
Cassandra. Cependant, il est
conseillé d'utiliser plutôt une
deuxième clé d'indexation
positionnée sur la colonne
contenant les informations
voulues. En effet, utiliser la
stratégie Ordered Partitionners
a les conséquences suivantes :
l'écriture séquentielle peut
entraîner des hotspots : si
l'application tente d'écrire ou
de mettre à jour un ensemble séquentiel de lignes,
alors l'écriture ne sera pas distribuée dans le cluster ;
un overhead accru pour l'administration du load
balancer dans le cluster : les administrateurs doivent
calculer manuellement les plages de jetons afin de les
répartir dans le cluster ; répartition inégale de charge
pour des familles de colonnes multiples.
L’interface de CQLSH est écrite en python, donc
nécessite l’installation de l’utilitaire python pour une
version supérieure à 2.7 pour pouvoir bénéficier de
cette interface de communication directe avec la base
de données Cassandra. Le langage de requête en
version 4 est très semblable au SQL2. Ainsi plusieurs
termes sont les mêmes, mais leurs utilités est
différentes, par exemple une clé primaire dans
Cassandra n’est pas équivalente à celle dans SQL2.
Exemple:
CREATE TABLE developer(
developer_id bigint,
firstname text,
lastname text,
age int,
task varchar,
PRIMARY KEY(developer_id));
Interface python de la CQLSH 4.1

Apache Cassandra est un
système permettant de gérer
une grande quantité de
données de manière distribuée.
Ces dernières peuvent être
structurées, semi-structurées
ou pas structurées du tout.
Cassandra a été conçu pour
être hautement scalable sur un
grand nombre de serveurs tout
en ne présentant pas de Single
Point Of Failure (SPOF).
Cassandra fournit un schéma
de données dynamique afin
d'offrir un maximum de
flexibilité et de performance.
Mais pour bien comprendre
cet outil, il faut tout d'abord
bien assimiler le vocabulaire
- Cluster : un cluster est un
regroupement des nœuds qui
se communiquent pour la
gestion de données.
- Keyspace : c'est l'équivalent
d'une database dans le monde
des bases de données
relationnelles. À noter qu'il est
possible d'avoir plusieurs «
Keyspaces » sur un même
serveur.
- Colonne (Column) : une
colonne est composée d'un
nom, d'une valeur et d'un
timestamp.
- Ligne (Row) : les colonnes
sont regroupées en Rows. Une
Row est représentée par une
clé et une valeur.
Il est possible de configurer le partitionnement pour
une famille de colonnes en précisant que l'on veut que
cela soit géré avec une stratégie de type Ordered
Partitioners. Ce mode peut, en effet, avoir un intérêt si
l'on souhaite récupérer une plage de lignes comprises
entre deux valeurs (chose qui n'est pas possible si le
hash MD5 des clés des lignes est utilisé). Il est possible
de configurer le partitionnement pour une famille de
colonnes en précisant que l'on veut que cela soit géré
avec une stratégie de type Ordered Partitioners. Ce
mode peut, en effet, avoir un intérêt si l'on souhaite
récupérer une plage de lignes comprises entre deux
valeurs (chose qui n'est pas possible si le hash MD5 des
C*: Cluster-Keyspace-Column-Row

C* cluster: configuration des noeuds
Configuration d’un cluster Cassandra avec l’interface OpsCenter

C* Stockage des données: Le Model
import java.io.Serializable;
import java.util.Date;
import java.util.UUID;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
import org.apache.commons.lang3.builder.ToStringBuilder;
import org.apache.commons.lang3.builder.ToStringStyle;
import org.easycassandra.Index;
@Entity(name = "tweet")
public class Tweet implements Serializable {
@Id
private UUID id;
@Index
@Column(name = "nickName")
private String nickName;
@Column(name = "message")
private String message;
@Column(name = "time")
private Date time;
public UUID getId() {return id; }
public void setId(UUID id) {this.id = id;}
public String getNickName() {return nickName; }
public void setNickName(String nickName) {
this.nickName = nickName;}
public String getMessage() {return message;}
public void setMessage(String message) {
this.message = message;}
public Date getTime() {return time;}
public void setTime(Date time) {this.time = time; }
@Override
public boolean equals(Object obj) {if(obj instanceof Tweet) {
Tweet other = Tweet.class.cast(obj);
return new EqualsBuilder().append(id, other.id).isEquals();}
return false;}
@Override
public int hashCode() {
return new HashCodeBuilder().append(id).toHashCode();}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
ToStringStyle.SHORT_PREFIX_STYLE);
}}

C* Stockage des données: Repository-Requête
import java.util.List;
import org.easycassandra.persistence.cassandra.Persistence;
public class TweetRepository {
private Persistence persistence;
public List<Tweet> findByIndex(String nickName) {
return persistence.findByIndex("nickName", nickName,
Tweet.class);
}
{
this.persistence =
CassandraManager.INSTANCE.getPersistence();
}
public void save(Tweet tweet) {
persistence.insert(tweet);
}
public Tweet findOne(UUID uuid) {
return persistence.findByKey(uuid, Tweet.class);
}
}
import java.util.Date;
public class App{
public static void main( String[] args ){
TweetRepository personService = new
TweetRepository();
Tweet tweet = new Tweet();
tweet.setNickName("allaoui chaker");
UUID uuid = UUID.randomUUID();
tweet.setId(uuid);
tweet.setNickName("allaoui chaker");
tweet.setMessage("test cassandra mapping");
tweet.setTime(new Date());
tweet.setId(UUID.randomUUID());
personService.save(tweet);
Tweet findTweet=personService.findOne(uuid);
System.out.println(findTweet);
}
}

C* Stockage et recherche des données avec l’ORM

Mapping des données dans Cassandra avec EasyCassandra

APACHE SPARK
L’éco-Système Big Data

Apache Spark est un framework de
traitements Big Data open source
construit pour effectuer des
analyses sophistiquées et conçu
pour la rapidité et la facilité
d’utilisation. Celui-ci a
originellement été développé par
AMPLab, de l’Université UC
Berkeley, en 2009 et passé open
source sous forme de projet Apache
en 2010. Spark présente plusieurs
avantages par rapport aux autres
technologies big data et
MapReduce comme Hadoop et
Storm. D’abord, Spark propose un
framework complet et unifié pour
répondre aux besoins de
traitements Big Data pour divers
jeux de données, divers par leur
nature (texte, graphe, etc.) aussi
bien que par le type de source.
Ensuite, Spark permet à des
applications sur clusters Hadoop
d’être exécutées jusqu’à 100 fois
plus vite en mémoire, 10 fois plus
vite sur disque. Il vous permet
d’écrire rapidement des
applications en Java, Scala ou
Python et inclut un jeu de plus de
80 opérateurs haut-niveau.
De plus, il est possible de
l’utiliser de façon interactive
pour requêter les données
depuis un shell. Enfin, en plus
des opérations de Map et
Reduce, Spark supporte les
requêtes SQL et le streaming
de données et propose des
fonctionnalités de ML.
Analyse
Distibué
Implémentation
En local
Implémentation
dans le Cloud
Apache Spark: SQL, Streaming, ML, GraphX
http://www.infoq.com/fr/articles/apache-spark-introduction

RDD
Les Resilient Distributed
Datasets (basés sur la
publication de recherche de
Matei), ou RDD, sont un
concept au cœur du
framework Spark. Vous
pouvez voir un RDD comme
une table dans une base de
données. Celui-ci peut porter
tout type de données et est
stocké par Spark sur
différentes partitions. Les RDD
permettent de réarranger les
calculs et d’optimiser le
traitement. Ils sont aussi
tolérants aux pannes car un
RDD sait comment recréer et
recalculer son ensemble de
données. Les RDD sont
immutables. Pour obtenir une
modification d’un RDD,
Il faut y appliquer une
transformation, qui retournera
un nouveau RDD, l’original
restera inchangé. Les RDD
supportent deux types
d’opérations: les
transformations et les actions.
Il faut y appliquer une transformation, qui
retournera un nouveau RDD, l’original restera
inchangé. Les RDD supportent deux types
d’opérations: les transformations et les actions
il faut y appliquer une transformation, qui

Actions/Transformations
Les transformations : les
transformations ne retournent
pas de valeur seule, elles
retournent un nouveau RDD.
Rien n’est évalué lorsque l’on
fait appel à une fonction de
transformation, cette fonction
prend juste un RDD et
retourne un nouveau RDD. Les
fonctions de transformation
sont par exemple
Les actions : les actions
évaluent et retournent une
nouvelle valeur. Au moment
où une fonction d’action est
appelée sur un objet RDD,
toutes les requêtes de
traitement des données sont
calculées et le résultat est
retourné. Les actions sont par
exemple reduce, collect, count,
first, take, countByKey
Transformations: Les deux transformations les plus
communes que vous utiliserez probablement sont la
map() et filter(). La transformation prend dans une
fonction et l'applique à chaque élément dans le RDD
avec le résultat de la fonction étant la nouvelle valeur
de chaque élément dans RDD résultant. La
transformation prend dans une fonction et rend un
RDD qui a seulement les éléments qui passent le
résultat à la fonction.
Actions: L'action la plus commune sur RDDS de base
que vous utiliserez probablement est reduce(), qui
prend une fonction qui opère sur deux éléments du
type dans votre RDD et rend un nouvel élément du
même type. Un exemple simple d'une telle fonction est
« + », que nous pouvons utiliser pour additionner notre
RDD. Avec reduce(), nous pouvons facilement
additionner les éléments de notre RDD, compter le
nombre d'éléments et exécuter d'autres types
d'accumulations. La fonction aggregate() nous libère
de la contrainte d'avoir le retour être le même type que
le RDD sur lequel nous travaillons. Avec aggregate(),
comme le fold(), nous fournissons une valeur zéro
initiale du type que nous voulons rendre.

Spark: cluster manager
Un cluster Spark se compose d’un master et d’un ou plusieurs
workers. Le cluster doit être démarré et rester actif pour pouvoir
exécuter des applications.
Le master a pour seul responsabilité la gestion du cluster et il
n’exécute donc pas de code MapReduce. Les workers, en revanche,
sont les exécuteurs. Ce sont eux qui apportent des ressources au
cluster, à savoir de la mémoire et des cœurs de traitement.
Pour exécuter un traitement sur un cluster Spark, il faut soumettre
une application dont le traitement sera piloté par un driver. Deux
modes d’exécution sont possibles :
- mode client : le driver est créé sur la machine qui soumet
l’application
- mode cluster : le driver est créé à l’intérieur du cluster.
Communication au sein du cluster
Les workers établissent une communication bidirectionnelle avec le
master : le worker se connecte au master pour ouvrir un canal dans
un sens, puis le master se connecte au worker pour ouvrir un canal
dans le sens inverse. Il est donc nécessaire que les différents nœuds
du cluster puissent se joindre correctement (résolution DNS…).
La communication entre les nœuds s’effectue avec le framework
Akka. C’est utile à savoir pour identifier les lignes de logs traitant
des échanges entre les nœuds.
Les nœuds du cluster (master comme workers)
exposent par ailleurs une interface Web permettant de
surveiller l’état du cluster ainsi que l’avancement des
traitements. Chaque nœud ouvre donc deux ports :
- un port pour la communication interne : port 7077
par défaut pour le master, port aléatoire pour les
workers.
- un port pour l’interface Web : port 8080 par défaut
pour le master, port 8081 par défaut pour les workers.
La création d’un cluster Spark permet d’exploiter la
puissance de traitement de plusieurs machines. Sa mise
en place est relativement simple. Il faudra simplement
prendre garde à rendre le master résilient en utilisant
ZooKeeper.
Par ailleurs, l’exécution d’une application ne requiert
pas de modification du code de traitement. La
contrainte principale est de s’assurer que les données
sont lues et écrites depuis/vers des systèmes distribués.

http://www.infoq.com/fr/articles/apache-spark-introduction

SparkSQL: SchemaRDD
Spark travail avec des données structurées et semi-structurées. Les
données Structurées sont n'importe quelles données qui ont un
schéma c'est-à-dire un ensemble connu de champs(domaines) pour
chaque rapport(record). Quand vous avez ce type de données, le
SQL d'Étincelle le fait tant plus facile que plus efficace charger et
questionner. Particulièrement le SQL d'Étincelle fournit trois
capacités principales.
• Il peut charger des données d'une variété de sources structurées:
JSON, Hive, etc…
• Il vous laisse questionner les données utilisant le SQL, tant à
l'intérieur d'un programme Spark que de les outils externes qui
unissent(connectent) au SQL d'Étincelle par des connecteurs de
base de données standard (JDBC/ODBC), comme outils de veille
économique comme Tableau.
• Quand utilisé dans un programme Spark, le SparkSQL fournit
l'intégration riche entre le SQL et Python / Java / Scala, y compris
la capacité de joindre RDDs et des tables de SQL, exposer la
coutume fonctionne dans le SQL et plus. Beaucoup d'emplois
sont plus faciles d'écrire l'utilisation de cette combinaison. Pour
mettre en œuvre ces capacités, le SparkSQL fournit un type
spécial de RDD appelé SchemaRDD.
Une étape de préparation des données est nécessaire
pour permettre à l’interpréteur SQL de connaître les
données. Le concept de RDD est réutilisé et nécessite
simplement d’être enrichi d’un schéma. La classe
manipulée devient un SchemaRDD. Deux options
existent pour construire un SchemaRDD :
- En utilisant le type générique Row et en décrivant le
schéma manuellement.
- En utilisant des types personnalisés et en laissant
Spark SQL découvrir le schéma par réflexion.

val sqlContext = new org.apache.spark.sql.SQLContext(sc)
val people = sqlContext.jsonFile("./data/data.json")
people.printSchema()
people.registerTempTable("people")
people.count()
people.first()
val r=sqlContext.sql("select * from people where nom='allaoui'").collect()
SparkSQL/UI: statistiques des jobs du SqlContext
SQLContext: Scala

SparkSQL/UI: statistiques des stages du SqlContext

import org.apache.commons.lang.StringUtils;
import org.apache.spark.SparkConf;
import org.apache.spark.api.java.JavaRDD;
import org.apache.spark.api.java.JavaSparkContext;
import org.apache.spark.api.java.function.Function;
import static com.datastax.spark.connector.japi.CassandraJavaUtil.*;
import com.datastax.spark.connector.japi.CassandraRow;
public class FirstRDD {
public static void main(String[] args) {
SparkConf conf = new SparkConf(true).set("spark.cassandra.connection.host", "127.0.0.1")
.setAppName("CassandraConnection").setMaster("local[*]");
JavaSparkContext sc = new JavaSparkContext("local[*]", "test", conf);
JavaRDD<String> cassandraRowsRDD = javaFunctions(sc).cassandraTable("java_api","products")
.map(new Function<CassandraRow, String>() {
@Override
public String call(CassandraRow cassandraRow) throws Exception {
return cassandraRow.toString();
}});
System.out.println("--------------- SELECT CASSANDRA ROWS ---------------");
System.out.println("Data as CassandraRows: n" + StringUtils.join(cassandraRowsRDD.toArray(), "n"));
}}
SparkSQL avec cassandraRDD

Aggrégation des données avec cassandraRDD et sparkSQL

SparkConf conf = new SparkConf(true).set("spark.cassandra.connection.host", "127.0.0.1").setAppName("SparkCassandra")
.setMaster("local[*]");
JavaSparkContext sc = new JavaSparkContext("local[*]", "CassandraActionsSpark", conf);
JavaRDD<String> cassandraRowsRDD = javaFunctions(sc).cassandraTable("network", "storage")
.map(new Function<CassandraRow, String>() {
@Override
public String call(CassandraRow cassandraRow) throws Exception {
return cassandraRow.toString();
}});
System.out.println("StringUtils.join(cassandraRowsRDD.toArray()));
System.out.println(cassandraRowsRDD.first());
System.out.println(cassandraRowsRDD.collect());
System.out.println(cassandraRowsRDD.id());
System.out.println(cassandraRowsRDD.countByValue());
System.out.println(cassandraRowsRDD.name());
System.out.println(cassandraRowsRDD.count());
System.out.println(cassandraRowsRDD.partitions());
Spark Actions avec CassandraRowRDD

Les Actions avec cassandraRowsRDD et sparkSQL

package scala.example
object Person {
var fisrstname:String="CHAKER"
var lastname:String="ALLAOUI"
def show(){
println(" Firstname : "+ firstname
+" Lastname : "+ lastname
)}}
def main(args: Array[String]){
Person p=new Person()
println("Show Infos")
p.show()
}
}
SparkUI: Monitoring
val textFile = sc.textFile("DATA.txt")
textFile.count()
textFile.first()
val linesWithSpark = textFile.filter(line => line.contains("Spark"))
textFile.filter(line => line.contains("Spark")).count()
Il y a plusieurs façons de contrôler des applications Spark : dont SparkUI
est le pilier de monitoring et instrumentation externe. Chaque
SparkContext lance un Web(tissu) UI, par défaut sur le port 4040, qui
affiche des informations utiles sur l'application. Ceci inclut :
Une liste d'étapes de planificateur et tâches
Un résumé de tailles RDD et utilisation de mémoire(souvenir)
Informations environnementales.
Informations sur les exécuteurs courants
Vous pouvez avoir accès à cette interface en ouvrant simplement
« http://hostname:4040 » dans un navigateur Internet. Si des multiples
SparkContext qui s’exécutent sur le même hôte, ils seront disponibles en
écoutent sur les ports successifs commençant par 4040, 4041, 4042
SparkContext: Scala
Notez que ces informations sont seulement
disponibles pour la durée de vie de
l'application par défaut. Pour voir le rendu de
SparkUI et profiter de l’interface de
monitoring, mettez « spark.eventLog.enabled »
à « true ». Ceci configure Spark pour
enregistrer les événements qui contiennent
les informations nécessaires pour monitorer
les évènnement de Spark dans SparkUI et
visualiser les données persistées.

SparkUI: statistiques des jobs du SparkContext

SparkUI: statistiques des stages du SparkContext

import java.lang.Math
val textFile = sc.textFile("DATA.txt")
textFile.map(line => line.split(" ").size).reduce((a, b) => Math.max(a, b))
val wordCounts = textFile.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey((a, b) => a + b)
wordCounts.collect()
MapReduce: map, key, value, reduce
Spark offre une alternative à MapReduce car il exécute les jobs dans des micro-lots avec des intervalles de cinq secondes ou
moins. Soit une sorte de fusion entre le batch et le temps réel ou presque. Il fournit également plus de stabilité que d'autres
outils de traitement temps réel, comme Twitter Storm, greffés sur Hadoop. Le logiciel peut être utilisé pour une grande variété
d'usages, comme une analyse permanente des données en temps réel, et, grâce à une bibliothèque de logiciels, des emplois plus
nombreux pour les calculs en profondeur impliquant l'apprentissage automatique et un traitement graphique. Avec Spark, les
développeurs peuvent simplifier la complexité du code MapReduce et écrire des requêtes d'analyse de données en Java, Scala
ou Python, en utilisant un ensemble de 80 routines de haut niveau. Avec cette version 1.0 de Spark, Apache propose désormais
une API stable, que les développeurs peuvent utiliser pour interagir avec leurs propres applications. Autre nouveauté de la
version 1.0, un composant Spark SQL pour accéder aux données structurées, permettant ainsi aux données d'être interrogées
aux côtés de données non structurées lors d'une opération analytique. Spark Apache est bien sûr compatible avec le système de
fichiers HDFS (Hadoop's Distributed File System), ainsi que d'autres composants tels que YARN (Yet Another Resource
Negotiator) et la base de données distribuée HBase. L'Université de Californie, et plus précisément le laboratoire AMP
(Algorithms, Machines and People) de Berkeley est à l'origine du développement de Spark que la fondation Apache a adopté en
tant que projet en juin 2013. Des entreprises IT comme Cloudera, Pivotal, IBM, Intel et MapR ont déjà commencé à intégrer
Spark dans leur distribution Hadoop.
SparkContext MapReduce: Scala
http://www.lemondeinformatique.fr/actualites/lire-la-fondation-apache-reveille-hadoop-avec-spark-57639.html

SparkUI: statistiques du MapReduce

Data-Driven Documents
Présentation graphique des données

Présentation
Big Data
Design
Riche
en composants
La production exponentielle de données par les systèmes
informatiques est un fait bien établi. Cette réalité nourrit
le phénomène Big data. L’analyse statistique ou prédictive
doit faire appel à l’art de la représentation visuelle des
données afin de leur donner du sens et de mieux les
comprendre. La Visualisation des données ou Data
visualization est appelée à prendre une place grandissante
et ce, en proportion du volume de données produites par
les systèmes d’information.
A ce titre, nous sommes absolument convaincus que la
librairie D3, objet de cet article, y prendra toute sa place
et ce, pas uniquement en raison de ses qualités
esthétiques. Créée par Mike Bostock, D3 est souvent
présentée comme une librairie graphique alors que son
acronyme - D3 pour Data Driven Documents - montre
qu’elle est d’abord, à l’instar de jQuery, une librairie
JavaScript facilitant la manipulation d’un arbre DOM. D3
implémente des routines permettant de charger des
données externes dont les formats JSON, XML, CSV ou
texte sont nativement supportés. Le développeur écrit la
logique de transformation des données en éléments HTML
ou SVG afin d’en avoir une représentation.
Ainsi, la représentation peut tout aussi bien
prendre la forme d’un tableau (éléments
HTML) que d’une courbe (éléments SVG). D3
permet donc de produire des Documents
Orientés Données. Dont plusieurs modèles
sont disponibles sur le site www.d3js.org.
Présentation en DENDOGRAM du JSON

D3.js (D-D-D pour Data-
Driven Documents) est une
bibliothèque graphique
JavaScript qui permet
l'affichage de données
numériques sous une forme
graphique et dynamique. Il
s'agit d'un outil important
pour la conformation aux
normes W3C qui utilise les
technologies courantes SVG,
JavaScript et CSS pour la
visualisation de données. D3
est le successeur officiel du
précédent Framework
Protovis1. Contrairement aux
autres bibliothèques, celle-ci
permet un plus ample contrôle
du résultat visuel final2. Son
développement se popularisa
en 20113, à la sortie de la
version 2.00 en août 2014. En
août 2012, la bibliothèque
avait atteint la version 2.10.05.
Intégrée dans une page web
HTML, la bibliothèque
JavaScript D3.js utilise des
fonctions préconstruites de
JavaScript pour sélectionner
des éléments, créer des objets
SVG, les styliser, ou y ajouter
des transitions, des effets
dynamiques ou des infobulles.
Ces objets peuvent aussi être
stylisés à grande échelle à
l'aide du célèbre langage CSS.
De plus, de grandes bases de
données avec des valeurs
associées peuvent alimenter les
fonctions JavaScript pour
générer des documents
graphiques conditionnels et/ou
riches. Ces documents sont le
plus souvent des graphiques.
Les bases de données peuvent
être sous de nombreux
formats, le plus souvent JSON,
CSV, GeoJSON.
Ainsi, l'analyse des données est le processus qui consiste
à examiner et à interpréter des données afin d'élaborer
des réponses à des questions. Les principales étapes du
processus d'analyse consistent à cerner les sujets
d'analyse, à déterminer la disponibilité de données
appropriées, à décider des méthodes qu'il y a lieu
d'utiliser pour répondre aux questions d'intérêt, à
appliquer les méthodes et à évaluer, résumer et
communiquer les résultats.
Représentative graphique du flux de données

Possibilités de représentations graphiques avec D3

SMART DATA
La force d’une décision


SMART Data
SMART DATA
Présentation
Design
Support
aux décisions
Intélligente
Aujourd’hui, le Big Data est pour les responsables marketing à la fois une incroyable source de données sur
les consommateurs et, dans le même temps, un incroyable challenge à relever. Les stratégies de marketing «
digitales » prennent désormais en compte textes, conversations, comportements, etc. dans un environnement
ou le volume de ces informations à traiter croissent de façon exponentielle. Il serait donc totalement
illusoire de s’imaginer gérer l’intégralité de ces données. et L’enjeu du marketing digital est donc désormais
la gestion intelligente du Big Data afin d’identifier, de classer et d’exploiter les informations consommateur
significatives permettant aux professionnels du marketing de mettre en place leurs stratégies.
Le Smart Data est le processus qui permet de passer des données brutes à des informations ultra qualifiées
sur chacun des consommateurs. L’objectif est d’avoir une vision à 360° des clients, reposant sur des
informations collectées à travers des mécanismes marketing adaptés, qu’ils soient classiques ou innovants
(jeux concours, réseaux sociaux, achats lors des passages en caisse, utilisation des applications mobiles,
géolocalisation, etc.). Pour y parvenir, les entreprises se dotent de plates-formes marketing cross-canal
capables de stocker et d’analyser chaque information afin de « pousser » le bon message au meilleur
moment pour chaque consommateur. L’objectif final est non seulement de séduire de nouveaux clients mais
surtout d’augmenter leur satisfaction et leur fidélité en anticipant leurs éventuels besoins.
Cela signifie, entre autres, instaurer un véritable dialogue avec chacun de ses clients et mesurer
efficacement les performances marketing et commerciales de la marque.
Cibler de manière fine selon plusieurs critères tout en respectant les préférences clients, gérer la
personnalisation, la pertinence et la cohérence des messages cross canal délivrés par e-mail, courrier, web
et call center sont devenus des impératifs que le Smart Data permet enfin de tacler de façon efficace.
Oublions le "Big" et intéressons-nous sur le "Smart" car la pertinence des stratégies marketing dépendra
toujours de la qualité des données clients.

SMART DATA: Data Transformations
Data Sources: WebSockets, TCP/UDP, InputStream
Data Movement: Apache Storm, Apache kafka
Data Storage: Apache Cassandra, Apache Spark
Data Presentation: Data-Driven Documents
Principaux éléments de la qualité du SMART Data : pertinence,
intelligibilité, exactitude, accessibilité. Un produit analytique est
pertinent s'il y a un public qui s'intéresse aux résultats de l'étude. Pour
que le degré d'intelligibilité d'un article analytique soit élevé, le style de
rédaction doit être adapté au public cible. En outre, l'article doit
fournir suffisamment de détails pour permettre à une autre personne à
laquelle l'accès aux données serait accordé de reproduire les résultats.
SMART DATA: notre cas
Synthèse

Mots clés
WebSockets – HTTP – TCP/UDP – InputStream – TwitterStream – WebServices – JSON – Data - Big Data – SMART DATA -
Process Big Data – Business Iintelligence – Data Storage – Data Sources – Data Presentation – Data Mining - Data
Exploration - Apache Storm – Apache Zookeeper – Apache Kafka – Apache Cassandra – Apache Spark – SparkSQL –
SparkUI – D3 - Data-Driven Documents – Storm cluster – StormUI – Storm Topology – Zookeeper cluster – Distrubuted
server – Topics – Message – Queue – Data Transmit – OpsCenter – EasyCassandra- Keyspace – Column – CQLSH -
CassandraColumn – CassandraRow- Cassandra cluster – Storage Data – Aggregation – RDD – SchemaRDD - Spark Actions
– Spark Transformations – Spark cluster - MapReduce – Jobs – Stages – Excutors – Data Transformations –SMART – Apache

Liens utiles
Apache Storm
https://storm.apache.org
Apache Zookeeper
https://zookeeper.apache.org
Apache Kafka
http://kafka.apache.org/
Apache Cassandra
https://spark.apache.org
http://d3js.org/
Apache Spark
http://cassandra.apache.org

Idea Create Refine
Contact
Visitez mon profil sur LinkedIn
Visitez mon site web
http://tn.linkedin.com/in/chakerallaoui
http://allaoui-chaker.github.io

Du Big Data vers le SMART Data : Scénario d'un processus

Contenu connexe

Tendances

En vedette

Similaire à Du Big Data vers le SMART Data : Scénario d'un processus

Du Big Data vers le SMART Data : Scénario d'un processus