Jetoile

Je toile ou J* au choix…

Hadoop Unit 1.3

left-small 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.1.6 de Hadoop Mini Cluster

A noter que pour utiliser Hadoop Unit en mode standalone, il est maintenant nécessaire de choisir entre Hadoop-Unit version SolR et Hadoop-Unit version ElasticSearch.

Cela est dû à un conflit de jars (Lucene pour ne pas le citer…) qui oblige à gérer ces composants indépendamment…

Pour les téléchargements, ça se passe ici :

Enjoy ;)

in Hadoop

Hadoop Unit

left-small 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.

Disclaimer : je tiens à repréciser que Hadoop-unit n’est qu’une solution de contournement permettant de simuler une partie de l’écosystème Hadoop afin de permettre de disposer en local d’un ersatz de distribution afin de fluidifier le développement mais proposant aussi d’effectuer des tests d’intégration dans un environnement dégradé. Cela peut également permettre d’éviter de monter un cluster Hadoop dédié aux tests d’intégration.

in Hadoop Read on →

Hadoop Ecosysteme Bootstrap

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

Ainsi, lorsqu’on fait du développement avec des composants “BigData”, on a souvent besoin d’un écosystème complet.

Alors, bien sûr, dans un monde idéal, il est possible de disposer de tout l’écosystème via Docker ou via une machine virtuelle. Pourtant, parfois, il n’est pas possible de disposer de la pleine puissance de son poste parce qu’on est, parfois (sic…), dans un contexte où disposer des droits administrateurs de son poste (et pire quand il s’agit d’un poste sous Windows…) est impossible.

Pour ce faire, il existe quelques solutions comme Hadoop-mini-clusters. Cependant, chaque composant doit alors être démarré dans le bon ordre et il faut avouer que c’est un peu verbeux…

En outre, les couches clientes fonctionnent principalement dans la même JVM.

L’objectif de ce post est de proposer une alternative beaucoup moins verbeuse et plus pratique.

Il ne s’agit que d’une simple surcouche à Hadoop-mini-clusters mais la solution proposée offre également d’autres possibilités qui ne sont pas offertes par la solution :

  • possibilité de disposer d’un SolR qu’il soit en mode embedded ou en mode cloud
  • possibilité d’avoir un oozie accessible par un client externe à la JVM

De plus, la solution proposée dans cet article (enfin plutôt sur mon github…) propose :

  • de démarrer l’écosystème nécessaire dans un contexte de Test d’intégration
  • de démarrer l’écosystème nécessaire en mode standalone avec une simple commande

in Hadoop Read on →

Loggons Beaucoup Mais Loggons Bien…

left-small 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é. Donc désolé si j’enfonce des portes ouvertes mais bref…

Dans une mouvance où on parle de plus en plus de BigData, l’un de ses enjeux est la récupération du maximum d’informations afin de pouvoir en retirer de la valeur. Parmi ces informations, le log en fait parti. En effet, il peut être très riche en indicateur et peut apporter une valeur inespérée pour le métier (actions utilisateurs, …) ou pour connaitre la santé du système (KPI, …).

Bien sûr, la notion de gestion et de traitement de logs n’est pas venu avec le BigData mais existe depuis le début de l’informatique. Cependant, l’arrivé d’architecture distribuée (ou cloud) a entrainé d’autres problématiques comme l’aggrégation des logs (avec les problématiques classiques d’ordonnancement et de NTP par exemple).

Aussi, dans cet article, je reviendrai sur certains points qui me semblent primordiaux (et qui sont souvent oubliés) et pour cela, j’aborderai différents notions :

  • Définition des différents type de log
  • Limitation des approches naîve
  • Préconisation

A noter que je ne parlerai pas ou peu technique et que je n’aborderai pas comment il est possible de transmettre les logs ou de les agréger.

in log Read on →

Hadoop Et Son écosystème

left-small 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.

Par exemple, plutôt que dire que Hadoop est mort et que Spark est son remplaçant, il serait plus juste de dire que l’écosystème Hadoop se voit rajouter le nouveau moteur d’exécution Spark (n’oublions pas que Spark s’intègre très bien avec HDFS en l’occurence pour la partie colocalisation des données/traitements ou même pour répondre aux besoins de checkpointing).

Dans la présentation ci-dessous, j’ai tenté, de manière non exhaustive, de lister et regrouper par usage quelques unes des technologies que je considère faire partie de l’écosystème Hadoop et qui, de mon point de vue, constitue l’environnement Hadoop que certains nomment également Data Platform.

in hadoop

Template De Projets REST

left-small Il y a déjà un long moment, j’avais posté une série d’article expliquant comment il était possible de faire des web service de type REST de manière simple via RestEasy-Netty ou via Undertow.

Dans la continuité de cette course au plus léger, je me suis dit que cela pouvait être intéressant de faire une petite étude un peu plus exhaustive des solutions légères qui existaient.

L’objectif étant extraire une sorte de bench un peu naïf et un peu out of the box. Parmi les solutions retenues, il y a :

  • Resteasy-Netty
  • Resteasy-Undertow
  • Restlet
  • SpringBoot
  • Resteasy sur Tomcat en utilisant ses connecteurs NIO
  • Resteasy sur Jetty

Cette article est là pour restituer mes résultats…

in java, microservice, rest Read on →