Pour cet article je vais vous parler de ce qui se cache derrière le terme redcoat (alias polos rouges) couramment utilisé lors de DevoxxFr. En fait, en TL;DR, derrière ce terme se cache une équipe de petites mains qui intervient lors de l’événement (ainsi qu’un peu avant/après) le tout sous la houlette de la core team Nicolas, Zouheir et Antonio ainsi que de l’équipe de 321 idCom avec Karine, Athalane, Jean-François et Maryne.
Dans le monde Big Data, rapidement se pose un certain nombre de besoins. Besoins qui, pris unitairement, sont déjà complexes à résoudre mais qui, mis bout à bout, s’avèrent encore plus difficiles à intégrer. Parmi ces besoins, on peut citer, par exemple, les besoins de qualité de données ou de linéage (problématiques qui peuvent être regrouper sous le terme de data governance). Cet article n’a pas pour objectif de fournir une solution clé en main ni de parler d’outils déjà existant mais plutôt de poser différentes réflexions que j’ai pu avoir afin de savoir si elles avaient un sens…
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.
Parce que je suis parti sur ma lancée des articles des tests d’intégration avec …, à la demande de Duyhai, voilà que je me retrouve à faire un article pour Apache Cassandra… ;) Plus sérieusement, faire des tests d’intégration avec Apache Cassandra est beaucoup plus simple qu’avec Redis ou Elasticsearch mais il existe cependant 2 projets qui simplifient énormément les tests d’intégration avec Cassandra : cassandra-unit créé par Jérémy Sevellec achille créé par Duyhai Doan Ce petit article résume comment utiliser ces 2 solutions.
Redis est écrit en C et faire des tests d’intégration en Java peut s’avérer compliquer. En outre, le fait que Redis doive être compilé lors de son installation rend les choses encore moins aisées. Bien sûr, il est possible d’utiliser Docker ou de l’installer préalablement sur son poste mais cette deuxième option casse un peu les bonnes pratiques des tests. Il existe également de nombreux projets permettant de faire des tests avec Redis mais, souvent, les solutions proposées embarquent le binaire de Redis ou on besoin qu’il soit déjà présent et installer/compiler sur le poste (https://github.
La version 5.0.0-alpha4 a signé la fin du support du mode embedded d’Elasticsearch.
Cela a été annoncé là et la classe NodeBuilder permettant de démarrer un noeud programmatiquement a été supprimée.
Cependant, même si la raison de l’arrêt du support de ce mode est compréhensible, cela pose le problème des tests d’intégration puisqu’il n’est plus possible de démarrer un Elasticsearch pendant la phase de test.
Oui, Elastic propose officiellement une alternative via l’utilisation de ESIntegTestCase mais personnellement, je ne suis pas très fan de cette approche…
Cet article va tenter de dresser un panorama non exhaustif de ce que j’ai pu trouver d’intéressant pour permettre de réaliser des tests d’intégration avec Elasticsearch.
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 :
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).
