Quoi de neuf avec sqoop2 ?

  • -

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.