NoSQL et Big DataArnaud Cogoluègnes - Zenika

ADIRA - 8 octobre 2014

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

NoSQL

Hadoop

MapReduce

HDFS

Théorème CAP

Eventual consistency

Hive

Pig

Architecturelambda

Cascading

MongoDB

Cassandra

Big Data

Agenda

Que faire du NoSQLHadoop et moiNoSQL et Hadoop en action

NoSQL

Retour vers le futur : les SGDBR

Les garanties ACID

Standard, portable

SQL-86 ... SQL:2011

select * from Book

Un point d’intégration

Image : http://www.eaipatterns.com/SharedDataBaseIntegration.html

ORM : les premières tensions

Une fausse bonne idée ?

?

Service : les tensions continuent

Services

Application A Application B Application C

Le web : comment “scaler” ?

SGBDR : généraliste

NoSQL

Moins de fonctionnalitésPlus spécialisés

Garanties relachéesPrincipes des “pipes” Unix

NoSQL viable, les aggrégats

CommandeClient

Ligne

Produit

1 *

1

*

*1

"commandes" : [ { "id" : 32, "clientId" : 2, "lignes" : [ { "articleId" : 79, "prix" : 29, "nom" : "Spring in Action" } ] }]

Les aggrégats

+

Unité atomiqueDonnées co-localisées

-

Usage uniqueVues à créer par usage

Partition (Sharding)

AlanBob...Zoe

Alan Bob Zoe

<< A >> << B >> << Z >>

…

Pas de sharding

Sharding

Réplication

Alan…

Alan Alan

Partition et réplication

Alan Bob Zoe

…Zoe Alan BobBob Zoe Alan

Relacher la durabilité

commit()

fsync()

store()

fsync()

Stockage mémoire et réplication

Alan…

Alan Alan

Théorème CAP

Alan Alan

Partition réseau

Choisir disponibilité ou cohérence

Disponibilité = update autorisé

Cohérence = update interdit

Bases de données NoSQL

ClusteringOpen source

ScalabilitéPas de schéma

Clé/valeur

Pas bien pour…

Requêtes sur les donnéesTransactions sur plusieurs objetsRelations complexes

Bien pour…

SessionProfilCache

Implémentations

RedisRiakHazelcast

"user1" => "login : alan ; gender : M"

"user2" => "login : zoe ; gender : F"

Orientées colonnes

Pas bien pour…

RequêtesAgrégations

Bien pour…

MesuresLogsExpiration

Implémentations

CassandraHBase

stationID : 1234 =>

date : 20140914 value : 12

date : 20140915 value : 22

value : 18date : 20140916

stationID : 6789 =>

date : 20140914 value : 25

date : 20140915 value : 28

value : 27date : 20140916

Orientées documents

Pas bien pour…

Transactions sur plusieurs collectionsRequêtes avec jointures

Bien pour…

LogsCMSE-commerce

Implémentations

MongoDBCouchBase

"commandes" : [ { "id" : 32, "clientId" : 2, "lignes" : [ { "articleId" : 79, "prix" : 29, "nom" : "Spring in Action" } ] }]

Orientées graphes

Pas bien pour…

Grosse volumétrieMises à jour massives

Bien pour…

Données “connectées”Routage, données localiséesRecommandations

Implémentations

Neo4jArnaud

Spring Batch in Action

Zenika

Alanauteur

employé

lecteur

Moteur d’indexation

Pas bien pour…

Transactions

Bien pour…

IndexationRecherche plain/text

Implémentations

ElasticSearchSolr

Hadoop

Hadoop, un système distribué

● Système de fichiers distribué : HDFS● API de programmation : MapReduce, YARN

Hadoop

HDFS

MapReduce, YARN

Votre application

HDFS

HDFS

MapReduce, YARN

Votre application

Tolérant aux pannes

Scalable

Formats de fichiers

Compression

Blocs, datanodes, namenode

file.csv B1 B2 B3 fichier composé de 3 blocs (taille par défaut d’un bloc : 128 Mo)

B1 B2 B1 B3

B1 B2 B2 B3

DN 1 DN 2

DN 4DN 3les datanodes stockent les blocs(le bloc 3 est ici sous-répliqué)

B1 : 1, 2, 3 B2 : 1, 3, 4B3 : 2, 4

Namenode

le namenode gère les méta-données et s’assure de la réplication

HDFS, les limitations

Fichiers “append-only”Bien pour “write once, read many times”

Peu de gros fichiers, bienPlein de petits fichiers, pas bien

MapReduce

HDFS

MapReduce

Votre application

Simple

Batch

Scalable

Jointure, distinct, group by

MapReduce

file.csv B1 B2 B3

Mapper

Mapper

Mapper

B1

B2

B3

Reducer

Reducer

k1,v1

k1,v2

k1 [v1,v2]

Le code va à la donnée

file.csv B1 B2 B3

Mapper

Mapper

Mapper

B1

B2

B3

Reducer

Reducer

k1,v1

k1,v2

k1 [v1,v2]

B1 B2 B1 B3

B1 B2 B2 B3

DN 1 DN 2

DN 4DN 3

DN 1

DN 3

DN 4

Hadoop 1

HDFS

MapReduce

Hadoop 2

HDFS

YARN

MapReduce Votreapplication

MapReduce, les limitations

Code bas niveauRé-utilisation difficile

Préférer les abstractions comme Cascading

Comment stocker ?

Formats de fichiers

Compression

Parquet

SequenceFile

Texte

Avro

Pas de compression

Snappy

Deflate

GZIP

La panoplie

MapReduce

CascadingAPI Java

HiveSQL

PigScript ETL

Votre application

Spark

Spark

Votre application

Tez

Apache TezMapReduce nouvelle génération

CascadingAPI Java

HiveSQL

PigScript ETL

Votre application

NoSQL et Hadoop en action

Architecture lambda : objectifs

● Tolérant aux pannes● Latence faible● Scalable● Générique

● Extensible● Requêtes “ad hoc”● Maintenance minimale● Debuggable

Layers

Speed layer

Serving layer

Batch layer

Batch layer

Speed layer

Serving layer

Batch layer

Stockage des données.Création des vues.

Serving layer

Speed layer

Serving layer

Batch layer

Accès aux vues batch.

Speed layer

Speed layer

Serving layer

Batch layer

Accès temps réel.

Batch layer

Speed layer

Serving layer

Batch layer

Hadoop (MapReduce, HDFS).Thrift, Cascalog.

Serving layer

Speed layer

Serving layer

Batch layer

ElephantDB, BerkeleyDB.

Speed layer

Speed layer

Serving layer

Batch layer

Cassandra, Storm, Kafka.

Jointure flux et référentiel

Hadoop

Traitement(jointures, transformation)

FluxReporting

Données de référence

Gestion de données

Données brutes Données parsées

Traitement et insertion

Archives Vues Transformations

Avro, GZIPRétention permanente

Parquet, SnappyRétention 2 ans glissants Traitement (Cascading)

HDFS BD temps réel

Cinématique avec Spring Batch

Archivage

Traitement Traitement Traitement

Nettoyage

Java, API HDFS

Cascading

MapReduce

Hive, Pig, Cascading

UDF : User Defined Function

Hive

+SQL (non-standard)Prise en main rapideExtensible avec UDF

-Testabilité médiocreRéutilisabilité médiocrePas de contrle du flotLogique disséminéeProgrammation par UDF

Pig

+Pig LatinPrise en main rapideExtensible avec UDF

-Testabilité médiocreRéutilisabilité médiocreLogique disséminéeProgrammation par UDF

Cascading

+API JavaTestable unitairementContrôle du flotBonne réutilisabilité

-Programmation nécessaire

Comment commencer

● Identifier les cas d’utilisation● Caractériser les données

○ volume, fraîcheur nécessaire, append-only● En déduire les produits adaptés● Virtualiser ou pas● Penser au déploiement et à la maintenance● Penser au cloud pour le prototypage

Conclusion

NoSQL : de nouveaux outils ciblésBig Data : de nouvelles possibilités

Des architectures, des patterns émergents