Author Archives: wordpress

  • -

Déploiement de clusters Hadoop

Category : cluster manager

N’hésitez pas à nous confier cette tâche.

Quelque soit votre choix de déploiement de cluster dans un cloud privé ou hébergé (AWS / Azure)

Nous prenons en compte vos besoins en terme de surveillance de cloud, de dimensionnement de cluster et d’installation de composants.

Nous sommes capables de pouvoir déployer voter cluster Big Data dans la journée.


  • -

Gestionnaire de fichiers cluster HDFS

Category : Non classé

Cette application s’appuie sur l’APIs rest webhdfs qui permet de procéder à la gestion des fichiers du cluster Hadoop.

Nous avons mis au point une application comportant dans cette première version opérationnelle de naviguer dans l’arborescence des fichiers mais aussi de charger des fichiers dans le cluster ou de télécharger localement un fichier stocké, répliqué dans le cluster.

De plus l’interface rest permet de restituer des informations techniques telles que la taille des fichiers dans un format lisible, les permissions UGO, temporelles.

Nous avons aussi implémenté le calcul total de la taille des fichiers dans le dossier sélectionné, la moyenne de réplication.

webhdfs


  • -

Les IHMs

Category : IHM , interface graphique

La manipulation de données dans un environnement Big Data n’est pas chose aisée. Aussi le besoin devient pressant d’avoir une interface homme-machine plus intuitive.

Les distributions telles Cloudera et Hortonworks proposent HUE, acronyme de Hadoop User Experience.

HUE (Hadoop User Experience)

Hue permet d’interfacer un bon nombre de composant de l’écosystème Big Data open source et qui a pour vocation, comme son nom l’indique de fournir une expérience utilisateur complète.

Il a pour ambition est de fournir les outils de traitement de données, de transformation, d’indexation et d’analyse graphique.

Le menu principal de Hue est organisé en 4 catégories :

  • Query editors :
    • On y trouvera, Pig, Impala (distrib. Cloudera), Hive en natif, mais on peut configurer son propre SGBD Postgres ou Mysql.
  • Data Browser:
    • Les gestionnaires de données  : Metastore, HBase, Sqoop, Zookeeper.
  • Workflow
    • Tout ce qui concerne le monitoring et l’édition de jobs.
  • Search
    • Indexation de données propulsé par Solr – Lucene et possibilité de créer des dashboards.

Zeppelin

Zeppelin est avant tout un logiciel qui s’adresse aux data scientists qui s’appuie sur Spark, et un nombre important d’autres interpréteurs.

Il est possible de créer plusieurs notebooks.

Un notebook type est constitué de plusieurs blocs.

On peut considérer d’implémenter un bloc principal dont la tâche principale est de charger les données en mémoire.

D’un simple clic on peut créer d’autres blocs qui seront des requêtes SQL (paramétrée ou non) et qui seront automatiquement illustrées d’un graphique.

Une fois le graphique affiché on peut passer d’un graphe histogramme à un graphe en secteurs, en lignes, en points, de permuter les lignes avec les colonnes, changer le critère de regroupement.

Le comparatif

Pour être pleinement opérationnel, Hue nécessite l’installation et la configuration de plusieurs composants alors que Zeppelin, peut s’appuyer sur Spark et optionnellement sur d’autres interpréteurs pour fonctionner.

Hue a pour vocation de s’amender de l’apprentissage des langages de programmation ou d’interrogation de données (SQL).
Son ambition est de permettre aux utilisateurs de charger, transformer, combiner les données entre elles avec les Query Editors et Data Browsers pour ensuite générer des jobs dont le résultat pourra être indexé par Solr – Lucene. Enfin la fonctionnalité de Dashboad permettra de faire des analyses graphiques.

Zeppelin quant à lui affiche la couleur : scala obligatoire. Mais en contrepartie, le résultat ne se fait pas attendre dans la mesure où on paramètre correctement le dimensionnement mémoire de la machine virtuelle, du Driver et de Workers.

Hue est certes très complet et met en oeuvre le cluster Big Data cependant il demeure nécessaire de faire appel à la ligne de commande pour avoir des explications précises sur les erreurs de compilation ou d’indexation ou tout simplement gagner en efficacité d’exécution.


  • -

Spark 1.4.6

Faisons le point sur Spark.

Qu’est ce donc?

Spark est un moteur de calcul générique pour le traitement de données volumineuses…

Que faire avec Spark?

Si on s’intéresse de près au traitement de données hétérogènes, Spark permet de les unifier, de les mémoriser et de les interroger en s’appuyant sur une connectivité standard (jdbc, odbc).
Par exemple si l’on dispose de fichiers .cvs et de différents systèmes de bases de données, il est rapide et facile de les mettre en œuvre en utilisant les APIs, notamment les propriétés de l’objet DataFrame et d’en sortir un résultat d’analyse au format json.

Spark s’utilise au travers du langage Scala, Python ou Java.

En plus des APIs dédiés à la manipulation de données, il existe des APIs pour le machine learning, le streaming, l’analyse graphique.

Il existe également une quantité importante de packages pour Spark.

Architecture

Quand on évoque Spark on se dit avoir affaire à la solution “in memory open source” de Hadoop et on peut faire rapidement l’amalgame de penser que l’on s’appuie sur les ressources du cluster hadoop.

En fait, Spark se déploie selon différents modes:

  • Amazon EC2
  • Standalone
  • Mesos
  • Yarn

Au regard de ces options de déploiement, on constate que l’implémentation de Spark dans un environnement Hadoop peut utiliser tout ou partie (ou aucune) des ressources du cluster Hadoop.

Spark peut être déployé sur un cluster ou en standalone indépendamment d’autres composants.

Oui mais Hadoop dans tout cela?

Au même titre que H-Base, Hive, Cassandra et autres composants reposant sur HDFS, Spark sait accéder les données du cluster Hadoop.

… Mais c’est bien sûr !

Selon le mode de déploiement qui a été choisi, Spark a la capacité d’exploiter le cluster manager qu’on lui indique :

  • Yarn, dans le contexte d’un cluster Hadoop
  • Mesos, dans un contexte d’un cluster Mesos
  • Spark dans son contexte standalone (approche q & d).

Le cluster manager se charge d’allouer les ressources auprès des nœuds du cluster.

Au lancement, Spark identifie les noeuds du cluster qui lui sont alloués et leur distrubue le code et les données de l’application. Le “Driver” distribue la matière nécessaire au traitement auprès de “Workers”.

Recommandations

Pour préserver des performances élevées et éviter de perturber la planification du Driver, il est recommandé d’utiliser Spark en mode standalone et de faire en sorte que les Workers soient au plus “près” du Driver, sur le même réseau local par exemple.

Si on envisage de déployer Spark en mode Yarn sur un cluster distribué, réparti dans différentes régions, on devra s’assurer de la fiabilité des communications réseaux et de la stabilité des nœuds du cluster.

Pendant une phase de calcul de Spark on évitera d’enclencher une opération de maintenance sur un ou plusieurs nœuds en les rendant inaccessibles ou en les amputant de leurs ressources.


  • -

LBDC In-Memory

Category : Produits

Vous pourrez découvir le détail dans la rubrique “Produits”.

Contactez-nous pour en savoir plus.


  • -

Quoi de neuf avec sqoop2 ?

Category : ETL , Sqoop

S’abonner à la page.

Sqoop est l’outil Big Data indispensable pour transférer des données structurées depuis et vers Hadoop.

Avec Sqoop 1 (dernière version stable 1.4.6), on a déjà affaire à un outil très efficace en ligne de commande.

L’avertissement sur le site dédié : Note that 1.99.6 is not compatible with 1.4.6 and not feature complete, it is not intended for production deployment. interpelle quelque peu, et mérite de s’y intéresser de plus près.

Juste après avoir décompressé l’archive des binaires, un se rend vite compte de la présence de Catalina. On peut en déduire que l’ETL repose désormais sur une architecture client-serveur.

Compatibilité de Sqoop 1 avec Hadoop 2.0
Un oeil fixé sur la page de monitoring du cluster Hadoop, on s’apercevra que pour une opération de listage de tables, Sqoop1 n’a pas besoin de la puissance de calcul et de stockage du cluster Hadoop pour la mener à bien. En revanche dès qu’il s’agit de faire un import de donnés, sqoop1 lance un job.

Un point d’attention particulier réside ici : le binaire sqoop 1 ayant été développé pour la version Hadoop 1, sqoop s’attache à créer un job MapReduce.

Autrement dit, si votre cluster fonctionne avec la version Hadoop 2 et exploite par conséquent Yarn plutôt que Mapreduce, vous rencontrerez quelques difficultés de compatibilités. Malgré les possibilité de configurer le cluster Hadoop avec l’option “classic” ou “local” plutôt que “yarn”, l’incompatibilité persistera. Fondamentalement, le choix d’utiliser Hadoop 2 réside sur l’architecture Yarn plus performante que MapReduce aussi, un tel paramétrage serait contre-productif.

Pour simplifier les choses, il est préférable de s’affranchir d’une étape de compilation des sources et on optera pour rechercher le binaire adapté à sa version d’Hadoop ici et plus précisément le binaire Sqoop 1 compatible Hadoop 2.0.

Conversion / transfert de données dans Hive
Par défaut Sqoop 1 importe les données dans le cluster Hadoop.
Pour un import dans Hive, il faut bien entendu utiliser les options adéquates et au préalable configurer Hive.
Le composant Hcatalog est sollicité par sqoop, il est d’autant plus important de s’assurer au préalable que Hive interagit correctement avec le cluster.

Est-ce que l’on y perd au change finalement ?
On peut effectivement se poser la question car le changement est assez radical.
Qu’on se rassure : le tableau comparatif met en lumière des solutions de contournement pour chaque cas d’utilisation.

Entre les deux versions on peut penser perdre en souplesse d’utilisation mais après une période d’adaptation, il n’y paraîtra plus.

Qu’est ce qu’on y gagne?
Et bien du point de vue de l’administrateur systèmes on saluera l’effort d’homogénéisation et de la rigueur qui accompagne cette nouvelle version.
On peut (et on doit) organiser les connecteurs jdbc (Postgres, Mysql, Oracle, ODBC, …) dans le dossier qui porte bien son nom “connectors”.

Une fois l’étape d’administration terminée, on peut ensuite se consacrer à l’utilisation.

Alors que sous Sqoop1 il fallait attendre que le job Yarn / mapreduce soit terminé (ou en erreur) pour vérifier le résultat (ou la log), Sqoop2 propose un processus interactif qui installe implicitement une phase préparatoire et une étape d’exécution.

Le processus se déroule en 2 étapes majeures :
On “tisse les liens” entre les connecteurs.
On définit un job qui met en œuvre un lien et une source de données.

Sqoop2 contrôle chaque étape et donne de la visibilité sur les paramètres obligatoires, incompatibles.
On peut alors ajuster le paramétrage des liens et des jobs avant l’étape d’exécution.

Comme pour Sqoop1, en phase d’exécution on se tournera vers sa console d’administration des jobs Hadoop pour en surveiller l’avancement.

A noter la persistance des liens créés ainsi que les jobs. Sous sqoop1, on aura soit une bonne mémoire pour lancer une ligne de commande exempte d’erreurs ou de bons scripts bien propres, bien rangés en lieu sûr et  documentés.

Architecture client-server ?
L’architecture client-server apporte :
– une interface REST.
– toujours le CLI qui se permet de se connecter au serveur depuis une console indépendante du cluster.
– une meilleure intégration dans HUE et donc une meilleure intégration avec les autres outils de l’écosystème Hadoop. Même si cette dernière interface reste très sommaire et peu intuitive, elle a toutefois le mérite d’exister.

Doit-on délaisser Sqoop 1 ?
Le choix de l’un vis à vis de l’autre réside en fait sur les critères de sécurité, de la charge que représente la mise en œuvre d’un workaround à la sauce Sqoop 2 par rapport à Sqoop 1.

Si vous avez déjà tous vos scripts Sqoop 1 et que vous en être satisfaits, il est préférable d’étudier la charge de travail afférentes à cette migration… (Note that 1.99.6 is not compatible with 1.4.6).

A noter que la distribution Cloudera continue de faire coexister les deux versions.

Et la sécurité dans tout cela?
Il n’est pas question ici de théoriser sur les notions d’autorisation intra / extra cluster mais d’en évoquer succinctement les aspects pratiques.

Avec Sqoop 1, sont utilisés les accès de l’utilisateur qui lance la commande.
Attention donc à créer un utilisateur “sqoop” qui ait bien les accès suffisants aux sources de données (SGBRD, fichers, …) mais aussi les accès en lecture/écriture dans le cluster.

En effet si vous pensiez pouvoir faire un import de toutes vos données Mysql en tant que root, il n’est pas convenu d’avance que l’opération réussisse en raison d’accès, dans le cluster Hadoop le user root n’est pas connu.

Si nous devions retenir une ligne de conduite, l’adage “qui peut le plus, peut le moins” n’est pas applicable au Big Data et à la sécurité.
Il est nécessaire de bien étudier la stratégie de sécurité, cette tâche dans le projet d’implémentation est indispensable.

Dans le cas d’une réalisation “quick & dirty”, utilisez l’utilisateur qui gère votre cluster.

Avec Sqoop 2, on distingue désormais 2 rôles :

  • Database administrators
  • Developers

La gestion des utilisateurs reste classique dans le contexte Tomcat.

En conclusion:
Sqoop 2 est une évolution majeure du projet Sqoop et le risque lié à implémenter cette version plutôt que la précédente reste somme toute minime : les fonctionnalités essentielles sont maîtrisées.

Le bénéfice lié au gain de temps de mise à au point des opérations d’ETL, l’intégration dans Hue et l’interface Rest, font de cette version de Sqoop 2 un élément essentiel de votre stack Big Data open source.