Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

MBDS 2016 - 2017 Hadoop / Big Data Benjamin Renaut <renaut.benjamin@tokidev.fr>

MBDS 2016 - 2017 Hadoop / Big Data Benjamin Renaut <renaut.benjamin@tokidev.fr> Programme – Planning – Objectifs – TP/Évaluations Introduction 1 Introduction 1-1 Benjamin Renaut Tokidev SAS - Bureau d'étude - Développement - Consulting http://www.tokidev.fr/ 1-2 Avant de commencer ●Posez des questions. Si un point n'est pas clair, n'hésitez pas à poser des questions à tout moment. ●Point de contact: ben@tokidev.fr Vous pouvez m'envoyer toute question par e-mail concernant le cours, les TDs ou le partiel. ●Google est votre ami ! Si vous rencontrez un problème, prenez le réflexe d'effectuer une recherche – dans une majorité de cas, quelqu'un d'autre aura eu le même problème que vous :-) ●Cours en ligne: http://cours.tokidev.fr/bigdata/ Disponible à cette adresse: la machine virtuelle utilisée pour les TPs, les slides des cours. 1-4 Objectifs ●Découvrir la méthodologie map/reduce. ●Apprendre à installer et utiliser Hadoop. ●Apprendre à rédiger et exécuter des programmes pour Hadoop. ●Découvrir diverses solutions complémentaires liées à Hadoop et aux problématiques « Big Data » en général (Pig, MongoDB, etc.). ●Apprendre à utiliser Apache Spark. ► Apprentissage basé sur la pratique. Le calcul distribué / Historique Hadoop 2 2-1 Le calcul distribué Désigne l'exécution d'un traitement informatique sur une multitude de machines différentes (un cluster de machines) de manière transparente. Problématiques: ●Accès et partage des ressources pour toutes les machines. ●Extensibilité: on doit pouvoir ajouter de nouvelles machines pour le calcul si nécessaire. ●Hétérogénéité: les machines doivent pouvoir avoir différentes architectures, l'implémentation différents langages. ●Tolérance aux pannes: une machine en panne faisant partie du cluster ne doit pas produire d'erreur pour le calcul dans son ensemble. ●Transparence: le cluster dans son ensemble doit être utilisable comme une seule et même machine « traditionnelle ». 2-2 Le calcul distribué Ces problématiques sont complexes et ont donné lieu à des années de recherche et d'expérimentation. On distingue historiquement deux approches/cas d'usage: ●Effectuer des calculs intensifs localement (recherche scientifique, rendu 3D, etc.) - on souhaite avoir un cluster de machines local pour accélérer le traitement. Solution qui était jusqu'ici coûteuse et complexe à mettre en oeuvre. ●Exploiter la démocratisation de l'informatique moderne et la bonne volonté des utilisateurs du réseau pour créer un cluster distribué via Internet à moindre coût. Solution qui suppose qu'on trouve des volontaires susceptibles de partager leur puissance de calcul. 2-3 Exemple : Blue Gene (1999) Supercalculateur « classique ». Connecte 131072 CPUs et 32 tera-octets de RAM, le tout sous un contrôle centralisé pour assurer l'exécution de tâches distribuées. L'architecture est ici spécifiquement construite pour le calcul distribué à grande échelle. Il s'agit d'un cluster « local » (ne passant pas par Internet). Premier supercalculateur à être commercialisé et produit (par IBM) en plusieurs exemplaires. Utilisé pour des simulations médicales, l'étude de signaux radio astronomiques, etc. 2-4 Exemple : GPUGRID.net (2007) Projet de l'université Pompeu Fabra (Espagne) permettant à des volontaires partout dans le monde de mettre à disposition le GPU de leur carte graphique pour le calcul distribué (via NVIDIA CUDA). Il s'agit d'un cluster « distant » : distribué via Internet. Le GPU est nettement plus performant que le CPU pour certaines tâches comme le traitement du signal ou les calculs distribués sur les nombres flottants. Utilisé pour la simulation de protein folding (maladies à prion), la simulation moléculaire, et d'une manière générale des applications médicales. 2-5 Exemple: clusters Beowulf (1998) Architecture logique définissant un moyen de connecter plusieurs ordinateurs personnels entre eux pour l'exécution de tâches distribuées sur un réseau local. Une machine maître distribue les tâches à une série de machines esclaves. Généralement concrétisé via plusieurs machines sous GNU/Linux utilisant des interfaces standardisées. L'ensemble du cluster ainsi formé apparaît au niveau du serveur maître comme une seule et même machine. Permet à tout un chacun d'obtenir un système de calcul distribué à hautes performances à partir d'un matériel peu onéreux. La NASA utilise ainsi un cluster Beowulf. 2-6 Exemple: SETI@Home/BOINC A l'origine, un des premiers logiciels à permettre le calcul distribué via l'utilisation des ordinateurs de volontaires tout autour du monde. Objectif : détecter d'éventuels signes de civilisations extra-terrestres en analysant des signaux radios reçus par l'observatoire Arecibo au Porto Rico. Architecture et protocoles de communication ensuite standardisés et mis à disposition sous la forme d'un framework, BOINC, donnant lieu à de nombreux autres projets (Einstein@Home, Folding@Home, etc.). Remarque: GPUGRID utilise désormais lui aussi le framework BOINC. 2-7 Conclusions Pour l'exécution de tâches distribuées distantes via la mise à disposition de machines tout autour du monde par des volontaires, la création du framework BOINC a apporté une réponse efficace – de nombreux projets universitaires et scientifiques exploitant aujourd'hui la technologie. Cependant, de nombreuses universités et entreprises ont des besoins d'exécution locale de tâches parallélisables sur des données massives. Les solutions qui étaient disponibles jusqu'ici: ●Des super calculateurs « classiques » comme Blue Gene: très onéreux, souvent trop puissants par rapport aux besoins requis, réservés aux grands groupes industriels. ●Des solutions développées en interne: investissement initial très conséquent, nécessite des compétences et une rigueur coûteuses. ●Architecture Beowulf: un début de réponse, mais complexe à mettre en œuvre pour beaucoup d'entreprises ou petites universités, et nécessitant là aussi un investissement initial assez conséquent. 2-8 Le problème Le problème qui se posait jusqu'ici pour ce cas d'usage: Avoir un framework déjà disponible, facile à déployer, et qui permette l'exécution de tâches parallélisables – et le support et le suivi de ces tâches – de manière rapide et simple à mettre en œuvre. L'idée étant d'avoir un outil « off the shelf » qui puisse être installé et configuré rapidement au sein d'une entreprise/d'une université et qui permettre à des développeurs d'exécuter des tâches distribuées avec un minimum de formation requise. L'outil en question devant être facile à déployer, simple à supporter, et pouvant permettre la création de clusters de taille variables extensibles à tout moment. 2-9 La solution: Apache Hadoop Avantages: ●Projet de la fondation Apache – Open Source, composants complètement ouverts, tout le monde peut participer. ●Modèle simple pour les développeurs: il suffit de développer des tâches map-reduce, depuis des interfaces simples accessibles via des librairies dans des langages multiples (Java, Python, C/C++...). ●Déployable très facilement (paquets Linux pré-configurés), configuration très simple elle aussi. ●S'occupe de toutes les problématiques liées au calcul distribué, comme l’accès et le partage des données, la tolérance aux pannes, ou encore la répartition des tâches aux machines membres du cluster : le programmeur a simplement à s'occuper du développement logiciel pour l'exécution de la tâche. 2-10 Historique (1/2) - 2002: Doug Cutting (directeur archive.org) et Mike Cafarella (étudiant) développent Nutch, un moteur de recherche Open Source exploitant le calcul distribué. L'implémentation peut tourner seulement sur quelques machines et a de multiples problèmes, notamment en ce qui concerne l'accés et le partage de fichiers. - 2003/2004: le département de recherche de Google publie deux whitepapers, le premier sur GFS (un système de fichier distribué) et le second sur le paradigme Map/Reduce pour le calcul distribué. - 2004: Doug Cutting et Mike Cafarella développent un framework (encore assez primitif) inspiré des papers de Google et portent leur projet Nutch sur ce framework. - 2006: Doug Cutting (désormais chez Yahoo) est en charge d'améliorer l'indexation du moteur de recherche de Yahoo. Il exploite le framework réalisé précédemment... 2-11 Historique (2/2) … et créé une nouvelle version améliorée du framework en tant que projet Open Source de la fondation Apache, qu'il nomme Hadoop (le nom d'un éléphant en peluche de son fils). A l'époque, Hadoop est encore largement en développement – un cluster pouvait alors comporter au maximum 5 à 20 machines, etc. - 2008: le développement est maintenant très abouti, et Hadoop est exploité par le moteur de recherche de Yahoo Ainsi que par de nombreuses autres divisions de l'entreprise. - 2011: Hadoop est désormais utilisé par de nombreuses autres entreprises et des universités, et le cluster Yahoo comporte 42000 machines et des centaines de peta- octets d'espace de stockage. 2-12 Qui utilise Hadoop … et des centaines d'entreprises et universités à travers le monde. 2-13 Une technologie en plein essort ●De plus en plus de données produites par des systèmes d'information de plus en plus nombreux. Ces données doivent toutes être analysées, corrélées, etc. et Hadoop offre une solution idéale et facile à implémenter au problème. ●Pour le public, l'informatisation au sein des villes (« smart cities ») et des administrations se développe de plus en plus et va produire des quantités massives de données. … le domaine de recherche/industriel autour de la gestion et de l'analyse de ces données – et de Hadoop et les technologies associées – est communément désigné sous l'expression « Big Data ». Estimations IDC: croissance de 60% par an de l'industrie « Big Data », pour un marché de 813 millions de dollars en 2016 uniquement pour la vente de logiciels autour de Hadoop. Le modèle Map/Reduce 3 3-1 Présentation ●Pour exécuter un problème large de manière distribué, il faut pouvoir découper le problème en plusieurs problèmes de taille réduite à exécuter sur chaque machine du cluster (stratégie algorithmique dite du uploads/Management/ mbds-big-data-hadoop-cours-1.pdf