Hadoop et son écosystème est un monde complexe où beaucoup de nos paradigmes de développeur Java / JavaEE (EE4J?) sont chamboulés.
D’une part les technologies utilisées diffèrent mais, en plus, d’autres questions telles que l’architecture, les tests (unitaires, intégrations, …), la gestion des logs (debug, audit, pki, …), les procédures de livraison, la gestion de la configuration de l’application, etc. viennent s’y ajouter.
Cet article va montrer comment il est possible de concilier simplement les tests d’intégration mais aussi le déploiement afin de tendre vers la philosophie de continuous deployment.
Dans le monde du BigData (en l’occurence avec Hadoop), il est parfois utile de pouvoir importer le contenu d’une base de données dans son Datalake.
Pour ce faire, Apache Sqoop est une des alternatives pour le faire (peut être pas la meilleure mais bon…).
En effet, Sqoop permet d’importer (et exporter également) les données d’une base de données dans :
- hdfs au format plain text, sequencefile, avro ou parquet
- hive
- hbase
En outre, il permet d’avoir un mode incrémental afin de gérer le mode delta.
Cependant, comme on le verra dans cet article, Sqoop n’est pas aussi trivial qu’il peut le paraitre.
C’est ce qui sera détaillé dans cet article : à savoir une sorte de mini retour d’expérience… et heureux en plus ;)
Si vous êtes un lecteur assidu (ou pas ;)), vous avez pu vous rendre compte que j’avais posté précédemment sur un composant au doux nom d’Hadoop-Unit.
J’ai le plaisir de vous annoncer qu’il a été releasé en version 1.3 et qu’il est également disponible sur maven central.
Il intègre dans sa nouvelle version :
support d’ElasticSearch 5.0.0-alpha2 correction de bugs : la variable d’environnement HADOOP_UNIT n’est plus nécessaire que pour les utilisateurs de Windows (merci Florent ;)) passage en version 0.
Dans mon dernier post, j’avais parlé d’une surcouche que j’avais développé afin de faciliter l’utilisation de quelques-uns des composants de l’écosystème Hadoop, à savoir :
Hdfs, Zookeeper, HiveMetastore, Hiveserver2, SolR, SolRCloud, Oozie, Kafka, HBase, MongoDB [New \o/ ], et Cassandra [New \o/ ]. Il s’appelait alors Hadoop-Bootstrap mais il s’agissait aussi d’une première version qui a, bien sûr, évolué.
Cet article présentera donc quels ont été les améliorations qui ont été apportées.
Comme je l’ai déjà dit dans un article précédent, la force d’Hadoop n’est plus dans Hadoop en lui-même mais plutôt dans son écosystème.
Du coup, même lorsqu’on développe avec Spark, il est courant de vouloir s’interfacer avec le métastore de Hive ou encore avec SolR si l’objectif est de vouloir indexer dans ce dernier.
Parfois encore, l’objectif est de lire ou d’écrire de Kafka via Spark (ou en Spark Streaming).
Avec l’arrivé de Apache Spark, Hadoop est souvent vu comme désuet et legacy. Il est vrai que le monde BigData est en perpétuelle évolution et qu’un produit peut être déprécié en quelques mois.
Cependant, restreindre le terme Hadoop aux seuls technologies MapReduce, HDFS et YARN est, pour moi, une erreur.
Déjà parce que ces technologies peuvent être décorrélées et ensuite car, souvent, la très grande majorité des nouvelles technologies issues du monde BigData s’appuient sur les couches existantes et s’intègrent avec ces dernières.
