IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Big Data Discussion :

DECOUVERTE BIG DATA : HELP // je suis perdu


Sujet :

Big Data

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2018
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2018
    Messages : 1
    Points : 1
    Points
    1
    Par défaut DECOUVERTE BIG DATA : HELP // je suis perdu
    Bonjour,

    Je vous explique, aujourd'hui j'ai une SGBD MySQL avec des tables de plusieurs dizaines de Go tout ça lié à un gros backoffice / CRM / CMS / site web : des scripts , je ne fais qu'optimiser pour éviter le mur .
    Je scinde, j'optimise les index, etc etc etc, du ménage merci la RGPD :-)

    J'ai de plus en plus de calculs, d'analyse et il faut que cela soit en temps réel et un temps de traitement se rapprochant de l'instantanné et on va monter en puissance donc ajouter encore plus de data.

    MAIS on me donne que le couple PHP / MySQL, je ne doute pas qu'il soit possible de travailler sur les serveurs, l'optimisation du MySQL lui même, mais je des doutes sur les possibilités de ce couple pour arriver à mes fins.

    J'ai commencé pour certaines tâches de fond à Utiliser RabbitMQ, mais ce que je cherche c'est des faire des analyses et avoir le résultat sur le champs.

    Comment le BIG DATA peut il m'aider ?

    Je suis imprégné par la SGBD et requêtage complexe, en gros comment passer certaines data d'une SGBD vers un solution Big Data ?

    On stocke la data OK, mais comment se passe l'analyse : le requêtage ?

    Comment faire des TESTS sans monter une usine à gaz, j'ai un hébergeur avec 7 serveurs, Cluster Galera etc etc.


    Voilà je n'y connais RIEN et je n'y comprend RIEN, c'est un peu comme demander à un PRO du HTML des années 2000 pour qui les DIV fut une révolution face à ses TABLE et Pixel transprents MDR

    MERCI par avance pour ceux qui auront lu jusqu'au bout et qui m'auront aidé ;-)

  2. #2
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Bonjour,

    Il est très difficile de répondre à tes interrogations, tellement le sujet du Big Data est vaste et complexe, et qu'il fait appel à des principes autres que ceux utilisés sur les SGBDR.

    Je vais cependant essayer de te tracer les grandes lignes.

    Tout d'abord, comme beaucoup d'entre nous, tu viens du monde des SGBDR où nous savons tous que :

    - les données sont stockées dans des tables, sous forme de lignes et de colonnes (données tabulaires). Cela implique que les données sont très structurées et fortement typées, et que pour peupler une table, il faut que les données entrantes respectent le schéma de la table, ce qui peut être vu comme une contrainte

    - au niveau stockage, les données sont stockées sous forme de lignes. Ainsi, lorsque l'on ne souhaite lire que quelques champs d'une ligne, il faut malheureusement récupérer tous les champs de la ligne. Si cela convient bien aux usages OLTP (pour récupérer un formulaire client par exemple), ce n'est pas du tout adapté à un usage analytique, lorsque l'on souhaite faire une agrégation de quelques données clientes par exemple

    - il faut que les données respectent le modèle relationnel, et donc ses contraintes d'unicité (PK et UK) et d'intégrité relationnelle (FK)

    - le moteur des bases de données relationnelles est transactionnel, et l'utilisateur se retrouve donc confonté aux propriétés ACID des transactions

    - hormis quelques rares éditeurs comme Oracle qui offre un SGBDR s'exécutant sur un cluster (un ensemble de machines), la plupart des SGBDR ne fonctionnent que sur un seul serveur. Cela ne facilite donc pas la distribution et la parallélisation des traitements

    - en terme de modélisation, les SGBDR sont principalement faits pour supporter des modèles de type OLTP, DWH (Datawarehouses), voir OLAP.
    Et même si cela s'est produit à une époque, on évite de nos jours de dénormaliser les données

    Voilà donc pour moi le tableau que l'on peut dresser des SGBDR, lesquels nous ont rendu de fiers services pendant des décennies (en gros sur la période des années 1970 à 2000) dans le domaine du transactionnel et de la BI.




    Mais à partir des années 2000, avec l’avènement du Web, les entreprises, notamment celles du monde Internet, se sont retrouvées face à de nouveaux défis technologiques.

    Des sujets comme les moteurs de recherche Internet, l'analyse des fichiers de log des serveurs Web, le pistage du parcours client des Internautes et autres ont fait que les entreprises se sont retrouvées confrontées :

    - à un déluge, encore appelé tsunami, de données (Volume)

    - à des données d'origine et de provenance diverses, avec des formats différents de données structurées, semi-structurées ou non structurées (Variété)

    - à un besoin de traiter les données à différents rythmes, soit en quasi temps réel, soit au fil de l'eau (Streaming), soit en différé par batchs (Vélocité)

    Ce sont ces 3V (Volume, Variété et Vélocité) qui sont à l'origine du Big Data.

    A cela tu peux ajouter les 2V suivants :

    - Véracité : c'est la capacité d’évaluer la qualité et la fiabilité de la donnée, et de la préserver tout au long de sa vie

    - Valeur : le fait d'être capable d’ajouter de la valeur à ses données, par agrégation et par combinaison des données entre elles




    Pour ces nouveaux usages, les SGBDR n'étaient pas du tout adaptés. Et même si certains se sont engagés sur les voies du HPC et des super-calculateurs pour tenter de trouver des solutions, il a fallu engager une véritable rupture technologique.

    C'est de là que sont nés ces 2 technologies que sont Hadoop et le NoSQL.

    Tout d'abord, les 2 :

    - fonctionnent sur un cluster de nœuds. En clair, un ensemble de serveurs, qu'ils soient physiques ou virtuels. Pour information, dans un cluster, un serveur est appelé un nœud

    - offrent une meilleure distribution et une meilleure parallélisation des traitements, ceci en envoyant les algorithmes de calcul des développeurs sur les différents nœuds.

    A suivre : un court article sur Hadoop

  3. #3
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Fin des années 90, début des années 2000, c'est l'avènement du World Wide Web, avec sa floraison de sites Web.

    Pour qu'un Internaute s'y retrouve parmi tous ces sites, il a besoin d'utiliser un moteur de recherche, d'où la guerre que l'on a connu entre les moteurs de recherche les plus célèbres, Alta Vista, Google et Yahoo.



    Techniquement, pour proposer un moteur de recherche, il y 2 principales étapes :

    1) concevoir et utiliser un Web Crawler (un robot d'indexation). En gros, son rôle consiste à explorer automatiquement le Web, en passant de site en site. Une fois sur un site, il part de la page d'accueil, et se balade de page en page via les hyperliens.

    Pour chaque page, il va mémoriser son URL, et collecter des ressources pertinentes comme le texte de la page, les images, les vidéos, les PDF, etc, etc

    Tu imagines donc là la quantité d'informations à stocker !

    C'est Google qui a alors eu l'idée de développer en interne un énorme espace de stockage distribué, appelé le GFS pour Google File System, un système de fichier distribué sur un cluster de machines.

    Prends un serveur qui accepte en local disons 12 disques SATA de 4 To chacun. Cela te fait donc 48 To.
    Au passage, je précise bien que les disques sont locaux à la machine. On appelle cela du DAS, pour Direct Attached Storage, ce qui n'est pas le cas du NAS et du SAN.

    Prends maintenant 100 serveurs identiques, et connecte les en cluster. Tu te retrouves maintenant avec 4.800 To, soit 4,7 Po !

    Maintenant, avec un cluster de 1.000 machines, l'espace de stockage unifié est de 47 Po !

    Et imagine que tu remplaces chaque disque de 4 To par le dernier disque d'entreprise de Seagate de 18 To, en SATA III, 3 pouces et demi, 7.200 tours / minute et moins de 600 € HT.

    Ton cluster de 100 machines passe alors à une capacité de stockage de 21 Po !!!

    Pour finir, GFS reste encore un système complétement propriétaire, mais Google a publié la théorie dans son fameux livre blanc :
    https://static.googleusercontent.com...s-sosp2003.pdf



    2) Maintenant que l'on dispose d'un énorme espace de stockage distribué, espace sur lequel les ressources du Web ont été déposées par le Crawler, il faut traiter ces ressources par un moteur d'indexation.

    Lors de l’indexation d’une page internet à partir des ressources qui y ont été collectées, le moteur donne une valeur à chaque terme significatif trouvé dans ces ressources.

    Cette valeur, ce poids, dépend de l’importance relative de ce mot clé dans le document (utilisation dans le titre, mise en évidence, fréquence d’utilisation, …, ancres des liens menant vers la page, popularité, signaux d’intérêt d’autres sites, …).

    La problématique d'un tel traitement d'indexation est que :
    - le nombre de données à traiter est gigantesque
    - ces traitements et calculs doivent se faire de manière distribué, sur des centaines ou des milliers de serveurs, pour finir en un temps raisonnable

    Là encore, c'est Google qui va trouver la solution est inventant un nouveau modèle de programmation : le MapReduce

    Ce modèle de programmation n'est pas simple à expliquer et appréhender, aussi je vous laisse consulter le livre blanc de Google sur MapReduce :
    https://static.googleusercontent.com...uce-osdi04.pdf




    C'est là que Hadoop entre en jeu : Doug Cutting, ancien employé de Google et en poste chez Yahoo, a lu les livres blancs, et, confronté aux mêmes défis que Google, s'est inspiré de ces publications pour développer Hadoop, un Framework de calculs distribués en Java.

    Concrètement, la première version d'Hadoop sortie en 2008, en open-source, repose sur :
    - HDFS, pour Hadoop Distributed File System, qui est similaire au GFS
    - MapReduce comme moteur de calcul

    Cette V1 d'Hadoop sera difficile à manipuler.

    En effet, les problèmes métiers à résoudre devront être scindés en algorithmes qui arrivent à s'inscrire dans la philosophie de développement MapReduce, laquelle repose sur des traitements de couples (clé / valeur) gérés par des fonctions map() et reduce().

    Les développeurs devront avoir un haut niveau de développent en Java, ainsi qu'une excellente maîtrise des algorithmes. Le seul avantage d'Hadoop est de les décharger de l'aspect parallélisation et distribution des traitements, ainsi que des problèmes de tolérance aux pannes.

    De plus, les traitements ne peuvent se faire qu'en batch. Pour tester son programme, il faut attendre que le batch se termine, ce qui peut être long.

    La situation va cependant s'arranger avec le temps, car de nombreux services vont arriver.

    En particulier, en 2008, Facebook va développer Hive, qui est une surcouche logicielle au dessus de MapReduce, et qui va permettre de faire du SQL. En effet, à cette époque, on ne parlait pas encore de Data Scientists, mais nombre d''analystes de données maitrisaient le langage SQL.

    Le rôle de Hive, qui est d'ailleurs toujours très utilisé aujourd'hui, est donc de traduire le HQL (Hive Query Language dont la syntaxe est très proche du SQL), en fonctions map() et reduce() en Java. Il masque donc toute la complexité du MapReduce.

    De même, chez Yahoo, on va inventer Pig qui, avec son langage PigLatin, va permettre de développer simplement des traitements de la donnée, un peu comme un ETL, et vous masquer ainsi la complexité de MapReduce.

    D'autres fonctionnalités vont peu à peu arriver comme :
    - l'utilisation du langage Python pour développer des MapReduce
    - le projet Apache Mahout pour implémenter des algorithmes de Machine Learning au dessus de MapReduce
    - la possibilité de faire du Streaming sur MapReduce, et donc de traiter les données au fur et à mesure de leur arrivée, alors qu'avant, on ne pouvait faire que du batch
    - un outil comme Sqoop qui permet de faire transiter des données depuis une base relationnelle vers le cluster HDFS, et vice-versa
    - un outil comme Flume pour collecter des données externes au cluster Hadoop, tel que des fichiers de Log, les agréger et les transmettre en streaming sur l'HDFS

  4. #4
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Ensuite va apparaître la version 2 d'Hadoop.

    Le gros défaut de la V1, c'est que MR1 (pour MapReduce V1) devait non seulement s'occuper du traitement de la donnée, mais était aussi en charge de la gestion des ressources du cluster, et de la planification des tâches.

    Pour résoudre ce problème, on a simplifié MapReduce (on parle de MR2 pour MapReduce V2) qui ne s'occupe plus maintenant que du traitement de la donnée, et on a développé YARN (Yet Another Resource Negotiator) qui est en charge de l'allocation des ressources.

    L'arrivée de YARN a permis d'introduire de nouveaux moteurs de traitement de la donnée, comme :

    - HBase, la base de données NoSQL orientée colonne et reposant sur HDFS pour le stockage distribué de la donnée

    - et surtout Spark qui est un autre Framework de calcul distribué.

    Spark, c'est le composant à retenir !

    En gros, Spark a de nombreux avantages :

    - développé en Scala, Spark accepte les langages Scala, Java, Python, R et SQL comme langage de dévelopement

    - les fichiers de données sont chargés à la base dans des RDD (Resilient Distributed Dataset) pour être traités ligne par ligne à l'aide de l'API Spark

    - si tes données sont tabulaires (fichier CSV par exemple), tu les charges dans un Dataframe, lequel est une surcouche du RDD

    - Spark sait traiter les données en mémoire. On dit que l'on fait de l'In-Memory. Pour info, j'ai travaillé en production sur un cluster Hadoop Hortonworks HDP 2.6.5, sur un cluster avec 22 nœuds de calcul. Un nœud, c'était un serveur physique HPE Bare Metal, avec 24 cœurs physiques, 14 To de disque SSD en local, et surtout 768 Go de RAM !

    - Spark est un moteur unifié car en plus, il sait faire du Streaming et du SQL. Il sait faire du Machine Learning avec la librairie MLlib, et gérer des bases NoSQL orientées graphes avec la librairie GraphX

    - sous Spark, tu peux "développer" en pas à pas, alors que MapReduce était cantonné au mode batch. Je ne peux t'en dire plus car là, il faut plonger dans le développement Spark avec les notions d'action et de transformation, et comprendre l'optimisation de ton pipeline de traitements grâce aux notions de DAG et de Lazy Evaluation

    - pour finir, Spark ne s'exécute pas seulement sur Hadoop, avec YARN pour le piloter.

    Spark fonctionne aussi avec Mesos qui est un autre négociateur de ressources, comme Yarn.

    Spark peut fonctionner aussi en standalone. En clair, il fonctionne sur une seule machine, comme votre PC, sous Linux et même sous Windows. Bien entendu, qui dit 1 machine dit que les traitements ne sont pas distribués. Mais c'est bien pour apprendre à développer sur Spark.

    Spark fonctionne aussi dans le Cloud, et sur un cluster K8s (Kubernetes).




    Pour finir sur Hadoop, il existe bien d'autres services, comme :
    - Oozie qui est l'ordonnanceur d'Hadoop
    - Zookeeper qui est le service pour mettre en place la haute disponibilité
    - SolR qui est un moteur d'indexation et de recherche
    - Tez qui est en gros un nouveau moteur d'exécution pour Hive, à la place de MapReduce, et qui permet d'améliorer les performances de Hive




    Et puis il existe une version 3 d'Hadoop qui a introduit entre autres :

    - le fait d'avoir plusieurs Namenodes en actif pour gérer l'HDFS

    - une réduction de l'occupation disque. En effet, avant, un fichier de données était découpé en blocs HDFS de 128 Mo, chaque bloc étant répliqué 3 fois par défaut. Ainsi un fichier de 512 Mo était découpé en 4 blocs de 128 Mo, puis les blocs envoyés sur les nœuds du cluster avec 12 blocs à cause de la réplication, ce qui fait 1536 Mo d'occupation disque total.

    Avec Hadoop 3, on utilise l'Erasure Coding (utilisation de bits de parité) et le fichier occupe 1,5 fois sa taille, donc environ 768 Mo

    - Hadoop 3 peut soumettre des applications dans des conteneurs Docker

    - Hadoop 3 : Yarn est maintenant capable de détecter les nœuds du cluster disposant de GPU (cartes graphiques) pour y exécuter des applications qui nécessitent ce type de ressource (GPU à la place de CPU pour des calculs de Deep Learning ou autres)

  5. #5
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Et pour finir notre de découverte du Big Data, il y a encore d'autres types de cluster.

    Comme le cluster Kafka qui permet de traiter des messages distribués en streaming.

    En gros, il y a des services Producers et des services Consumers.

    Les Producers sont les parties applicatives qui produisent des messages contenant des données, et les Consumers des applications qui s'abonnent pour recevoir certaines types de message.

    On pourrait imaginer par exemple la captation sur une base de données relationnelles des modifications des données, en utilisant du CDC (Change Data Capture) par exemple. Le Producer enverrait donc les modifications de données qui ont eu lieu sur la base, et un service de type Consumer les récupéreraient pour les traiter sur Hadoop.




    Et pour finir, en Big Data, il y a aussi les bases NoSQL qui fonctionnent sur des clusters et qui sont de 4 types :

    - orienté clé / valeur comme Redis. C'est une base de données très légère et montée en mémoire

    - orienté document (sous entendu document XML, et surtout JSON car moins volumineux que le XML) comme MongoDB ou CouchBase

    - orienté colonnes comme HBase et Cassandra

    - orienté graphe comme Neo4j

    Bien sur, pour chaque type de bases de données, il y a de nombreux éditeurs qui proposent leurs solutions, mais j'ai cité les plus courants et les plus connus.

    Sinon j'avais commencé mon premier message en rappelant les caractéristiques d'une base relationnelle. Et bien les bases NoSQL sont tous l'inverse :

    - les données ne sont pas forcément strucuturées,

    - le stockage peut se faire sous différents formats, dont le stockage en colonne. Les données peuvent être compressées suivant le format

    - pas de modèle relationne (donc pas de PK et de FK)l. Au contraire, on dénormalise à fond

    - à quelques exceptions près, pas de transaction. Par contre, MongoDB a introduit la notion de transaction dans sa V4

    - ces bases sont installées sur un cluster

  6. #6
    Membre éprouvé
    Homme Profil pro
    Architecte Décisionnel
    Inscrit en
    Février 2008
    Messages
    866
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte Décisionnel

    Informations forums :
    Inscription : Février 2008
    Messages : 866
    Points : 1 260
    Points
    1 260
    Par défaut
    Hello,
    Si le besoin c'est de la capacité d'analyse sur des volumes importants, peut-être envisager une base analytique ?
    Tu auras de meilleurs perfs avec moins de ressources.
    Vertica si tu veux du on premise, Snowflake ou Azure Synapse sur du cloud.

    Nicolas

Discussions similaires

  1. Carte son (creative) , help , je suis perdu..
    Par Sartou dans le forum Composants
    Réponses: 1
    Dernier message: 03/09/2009, 13h53
  2. [AJAX]Help je suis coincé :(
    Par Death83 dans le forum Général JavaScript
    Réponses: 10
    Dernier message: 12/03/2006, 10h40
  3. [Architecture] EJB ou pas EJB ? Je suis perdu ...
    Par n!co dans le forum Java EE
    Réponses: 18
    Dernier message: 26/01/2006, 18h21
  4. RAM DDR, PC3200, 333Mhz , 400Mhz je suis perdu
    Par ahage4x4 dans le forum Composants
    Réponses: 2
    Dernier message: 08/12/2005, 17h52
  5. DLL et MainForm je suis perdu !
    Par rudy2 dans le forum C++Builder
    Réponses: 28
    Dernier message: 02/01/2005, 18h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo