(Ou comment adapter les bases de données aux "nouveaux" usages de la donnée)
Avoir un gros volume de données : rassurant pour les utilisateurs.
- On porte trop peu d'intérêt au ratio pertinence / volume
- Confusion entre quantité de données et information contenue.
Big data : a partir du moment où les données ne peuvent plus être traitées en temps "raisonnable" ou utile par un seul serveur.
=> Lié à la taille + vitesse de traitement => 3V : volume, vitesse, variété.
Moteur de recherche : 80% de la réponse attendue est déjà présente dans le cerveau de l'utilisateur.
1er problème : quand doublement volume => temps traitement x100, x1000 ...
Abstraction haut niveau de mapreduce :
- langages de script type PIG
- pseudo SQL comme HiveQL
Problématique : comment faire une passerelle souple et flexible entre le SI legacy et le SI "big data" ?
Du CRM au VRM (Vendor relationship management) : Le client détermine qui a le droit de le contracter, et sur quel type de produits. => Publicité ciblée, non invasive.
Base des BDDR : publication de E.F. Codd en 1970:
- Fondement de l'algèbre des relations : algèbre avec selection, projection, agrégation, union, jointure : Table x Table -> Table
- Normalisation des données
- Analyse de la rquete pour optimiser.
Transaction SGBDR : ACID
- Atomicité, cohérence, Isolation, Durabilité
Fort investissement des DSI dans les SGBDR
- a entravé l'avènement de d'autres solutions parfois plus rationnelles / performantes.
Exemple : bases de données objet pour sauvegarder des grappes d'objets (apparues en 1990).
- Développement de frameworks complexes comme Hibernate
Contraintes des applis web a très grande échelle :
- Difficulté de maintenir l'intégrité des données sur une BDR distribuée sur plus de quelques dizaines de machines.
- Cohérence des données n'est plus une priorité : pas besoin de tous voir tout de suite un post FB
- Il coute souvent moins cher de gérer une incohérence (double réservation d'une même chambre) que d'essayer d'avoir de grosses DB cohérentes (et peu fiables ou peu disponibles).
On remplace la cohérence permanente par
- La cohérence a terme : le système distribué cv vers un system cohérent.
- Contrainte de variabilité des données
Caractéristiques d'un système distribué:
- Distribué, cohérence et résistance au morcellement (perte temporaire d'un noeud)
- Théorème CAP : seul 2 des 3 caractéristiques peuvent être simultanément assurées
- Cohérence et temps de latence sont 2 variables continues et dépendantes.
Objectif du NoSQL
- Distribuer traitements et stockage
- Priorité aux performances et à la disponibilité
- Traiter efficacement les données non structurées
- Clusterisables : montée en charge (presque) linéaire
- Dépourvu de schéma
- Dépourvu de transactions
- Non relationnels: pas de jointures
Cas typique d'utilisation :
- stockage d'une session utilisateur
- session_id => (profil utilisateur, panier, ...)
Paramètres :
- N facteur de réplication : nombre de noeuds utilisés pour répliquer les données
- W Quorum d'écriture : nombre de noeuds sur lequels on écrit à chaque sauvegarde
- R Quorum de lecture : nombre de noeuds à lire pour chaque lecture
- Consistance forte si R + W > N
Montée en charge :
- Par du sharding : Partition horizontale
- Stockage des données différentes sur noeuds différents
- La clé permet de savoir sur quel noeud aller chercher / sauvegarder l'information
Exemples de DB :
- Riak, Redis, MemCached DB, Dynamo DB (AWS)
- ECV pour lequel les valeurs sont des documents semi-structurés comme un fichier XML, JSON
- Possible de lire / écrire une partie du document sans tout charger
- Généralement répartition par un schéma de type maître - esclave
- Exemples : Mongo DB, Couch DB, Raven DB, Lotus Notes
- ECV dont les valeurs ont une structure particulière, avec des noms statiques ou dynamiques
- Colonne < super colonne < famille de colonnes
- Famille de colonnes -> table
- Keyspace -> base de données
- Cluster -> instance de base de données
- Exemples : cassandra, HBase, Hypertable (BigTable), AWS Simple DB
- Les SGBDR ne permettent pas de réaliser des opérations simples sur un graph, comme parcourir un graph ou trouver un chemin entre 2 noeuds (cf réseaux sociaux)
- Éclate les données au maximum, contrairement aux BDOA. Mais pose des pb pour assurer la cohérence des données
- Elles sont particulièrement utiles dans des situation ou différentes catégories de liens expliment des appartenances à certains groupes sociaux ou géographiques. Les systemes de recommandation ou de détection de fraude qui ont à tenir compte d'une certaine proximité géographique, sociale ou autre, pourront tirer profit d'une BDOG
- Exemples : Neo4J, Infinite graph, Orient DB
Algo map-reduce : inspiré par les travaux de Google en 2004 + prog fonctionnelle
- De nombreux servers contiennent des données stockées sous forme de clé - valeur. La valeur pouvant regrouper beaucoup d'informations différentes
- On applique un map (k, v) => (k', v') avec v' généralement un sous ensemble de value
- Shuffle : on répartit les (k', v') sur les différents serveurs pour regrouper les données avec les mêmes clés
- Reduce : agglomération des données sur chaque serveur pour calculer les résultats finaux (somme, produit, ...)
Opération de jointure couteuse en ressources
- Certains systèmes NoSQL les évitent complètement : colocaliser les données dans un même enregistrement
- Si jointure nécessaire : utilisation de map-reduce
Cas d'application de map-reduce
- Jointure sur des tables
- Produit de grandes matrices (creuses)
Chaque tâche map ou reduce est lancée dans une nouvelle JVM pour gérer les plantages / exceptions. Ce process embarque avec un "task Tracker" qui notifie l'ordonnanceur des taches de l'avancement de sa tâche.
=> Tolérange aux pannes et relancement auto d'un calcul qui a planté.
HDFS : Hadoop distributed file system : stockage sur plusieurs serveurs.
Si une tâche est trop lente, l'ordonnanceur peut la dupliquer sur d'autres serveurs. Une fois un résultat obtenu, il kill les autres
Les 3 V :
- MapRéduce gère bien un grand volume de données
- Variété de données : aucune solution miracle pour l'instant
- Vitesse : d'autres solutions / frameworks sont plus performants : Apache Mahout plus récent, perf x100 dans certains cas
Hadoop : stockage des données = HDFS
MapRéduce : Framework de calcul
Hadoop ne va pas tout de suite être remplacé par des systemes plus récents, très bonne compatibilité avec de nouveaux systemes qui supportent HDFS.
MapReduce sera progressivement remplacé par d'autres, plus fléxibles.
Hadoop est un excellent ETL et pourrait rester en tant que système de pré-traitement.
MapRéduce pas adapté aux traitements interractifs en temps réel
Voir les ETL Talend et Informatica
Conçu pour fournir un environnement distribué pour MapRéduce.
Hadoop se diversifie aujourd'hui pour gagner en fonctionnalités et vitesse exécution + proposer un système compatible SQL standard.
Ecosystème Hadoop :
- Complexe a configurer, les briques ne sont pas toutes compatibles entre elles
- Utiliser une distribution Hadoop comme Cloudera, Hortonworks, MapR
- En mode cloud, référence = Elastic MapRéduce (EMR) de Amazon
- On utilise un package Big Data : plugins de dev, générateurs de code, connecteurs pour les I/O (SQL SGBDR, fichier, réseaux sociaux, ...)
Compromis sur :
- Temps de réponse, flexibilité du modèle de données
- Compatibilité du langage de requêtes, compatibilité avec l'existant
HDFS conçu pour héberger des fichiers de très grande taille avec accès en lecture seule. Noeud maître s'appelle NameNode, les DataNodes gèrent les opérations locales a leur machine.
YARN = Hadoop 2.0. Composé de :
- gestionnaire de ressources (Ressources Manager) partagé a toutes les applis
- Application Master : client du Ressources Manager pour chaque application
Inspiré de Google BigTable, utilise HDFS
- NoSQL distribué orienté colonnes
- Scalabilité linéaire
- Pas d'indexation, enregistrements ordonnés suivant leur clé
- Peut s'exécuter en standalone sur une machine
Augmenter le niveau d'abstraction pour décrire des process de traitement
- Composé de PigLatin : langage de scripts + environnement d'exécution. Les scripts sont compilés en une succession de jobs MapReduce
- PigLatin : proche de SQL. Langage procédural de description d'un flot de données. Pas de temps réel. Script PigLatin plus proche d'un plan d'exécution SQL que d'une requête SQL. Beaucoup d'extensions, de librairies
Comme Pig, infrastructure de datawarehouse construit au dessus de Hadoop
- Langage HiveQL : très proche de SQL
- Pas adapté au temps reel
- Très performant pour traiter un grand volume de données imutables (ex : logs)
Distributions Hadoop :
- Cloudera : la plus utilisée. Gestionnaire de stockage spécifique : Impala.
- Hortoworks : crée chez Yahoo, 100% open source
- MapR : fondée par des anciens de Google en 2009
- Se veut facile d'utilisation. 3 versions : M3, M5 et M7
- Utilise MapR FS au lieu de HDFS + implémentation propriétaire de MapReduce : MapR MapReduce
- Choisie par Amazon pour Elastic MapReduce
- Amazon Elastic MapReduce : souplesse de Amazon sur la capacité de stockage et nb de serveurs. Latence plus élevée pour les E/S S3
- MapReduce pas adapté aux traitements itératifs (en ML), ni aux opération interactives (plusieurs requêtes sur un même échantillon)
- Pour ces opérations, MapReduce ré-écrit les données sur le disque.
- Nécessite une duplication des données pour éviter les pannes
- Développement du RDD : Résilient Distributedd Dataset
- stockage en RAM, tolérent aux erreurs.
- Pas de stockage sur le DD des données, pas de recalcul d'une étape utilisée par plusieurs étapes suivantes -> jusqu'a 100x plus rapide
- Manipulation des données par des DataFrames
- Langage Spark SQL pour manipuler des DataFrames, en plus des fonctions des DataFrames
Modes de cluster Spark
- Local : sur une machine
- Standalone : Spark gère la répartition des données sur les serveurs. Moins efficace que avec un cluster Hadoop
- Yarn : ressources peuvent être partagées entre plusieurs users
- Mesos : utilise Mesos, un autre gestionnaire de ressources
Impala vs Stinger :
- Pig et Hive, avec PigLatin et Hive QL, ne sont pas adaptés aux requetes interractives.
- Projet Impala par Cloudera : moteur SQL massivement parallèle, sans MapReduce
- Projet Stinger : modernisation de Hive par Hortonworks
- SQL conforme ANSI pour traitements sur des milliers de serveurs.
- Inspiré de Google BigQuery
- Nécessite ZooKeeper, pas forcément avec Hadoop
- Utilise un modèle de données hierarchique orienté colonnes
- Librairie Java intégrant les principaux algos de ML
- Mahout a abandonné en Avril 2014 MapRéduce pour YARN
- Librairie ML
- Plus scalable que scikit-learn & co
- API scala, java et python
- Très utile pour analyse de texte, online learning, filtrage collaboratif
Apache Storm
- Mettre en place des solutions Big Data pour des traitements réels, sur un volume arbitraire de données
- Pré calcul des résultats, avec mise a jour au fil de l'eau avec les nouvelles données
- 3 couches : vitesse (speeding), de service (serving) et la couche batch
- Couche Batch : lancement périodiques : toutes les heures, tous les jours ...
- Couche de service : Traitement des résultats de la couche batch. Base de données Elephant DB développée pour stocker les résultats de la couche de service : lecture très efficace, écriture moins efficace, robuste et scalable
- Couche vitesse : fonctionne en continu. Mise a jour en continu de sa base de données