nosql et big data
TRANSCRIPT
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