Jetoile

Big Data et Scheduler : Reflexion

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…

Packaging, test et livraison pour Hadoop : Mode d'emploi

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.

Des tests d'intégration avec Cassandra

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.

Des tests d'intégration avec Redis

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.

Des tests d'intégration avec Elasticsearch

left-small La version 5.0.0-alpha4 a signé la fin du support du mode embedded d’Elasticsearch.

Cela a été annoncé 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.

Sqoop et Parquet : Mode d'emploi

left-small 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 ;)

Hadoop Unit 1.3

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.

Hadoop Unit

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.

Hadoop ecosysteme bootstrap

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).

Loggons beaucoup mais loggons bien...

Cela fait un moment que je n’ai rien écrit… Cependant, un sujet me taraude depuis un moment… et il s’agit de la gestion des logs dans les applications. J’ai déjà pesté dans des articles précédents sur le fait qu’une application devait toujours être monitorée et supervisée mais, en plus de cela, le comportement d’une application doit également être traçable. Le sujet n’est pas ce qu’on peut dire le plus sexy du monde mais j’ai souvent constaté que ce dernier était souvent assez mal maitrisé.