Skip to main content

Weave devient Apache Twill et entre en incubation



Ceux qui s'intéressent à YARN, le nouveau gestionnaire de ressources d'Hadoop, savent que son potentiel est énorme pour ceux qui font du BigData : spécifiez les ressources nécessaires à votre programme distribué (CPU, mémoires) et YARN se charge de trouver les nœuds de votre cluster possédant les ressources disponibles pour l’exécuter. Le tout bien entendu sur les pétaoctets hébergés par le système de fichier distribué d'Hadoop : HDFS.
Emporté par la dynamique Hadoop YARN est en train de devenir le socle de nombreux projets de traitement de gros volumes données : on retrouve le traditionnel Map/Reduce mais aussi Storm porté par Yahoo ! ou Stinger d'Hortonworks pour faire du SQL à (très) grande échelle

Cependant écrire un programme qui exploite les capacités de YARN n'est pas une sinécure, on se retrouve vite à copier / coller l'exemple du DistributedShell, à refaire les mêmes choses et à retomber dans les mêmes problématiques ... bref inutile d'être un génie pour comprendre qu'il y avait matière à factoriser.

Il y avait Kitten de chez Cloudera, voici celle de Continuuity, Weave, jusqu'ici hébergée chez Github qui vient d'être acceptée par la fondation Apache pour incubation. Au passage il change de nom et devient Twill histoire de ne pas le confondre avec Apache Wave (plateforme de travail collaborative, pas grand chose à voir avec le BigData)
L'idée derrière Weave Twill est donc bien de simplifier le développement d'applications distribuées qui reposent sur YARN en offrant par exemple une interface WeaveRunnable tel que le fait le JDK avec l'interface Runnable sauf qu'il ne s'agit plus de fonctionner au sein d'un pool de thread mais de passer à l'échelle supérieure : le pool de serveurs (physique).
Weave tente aussi de simplifier la gestion de l'application comme par exemple la gestion des logs qui est toujours délicate lorsque l'on a affaire à des applications qui s’exécutent sur plusieurs machines.

Si vous avez commencé à jouer avec YARN jetez un coup d’œil à Weave.

Les alternatives potentielles :
Kitten
Spring YARN

Comments

Popular posts from this blog

Orientée colonnes ?

Les bases NoSQL sont arrivées avec leur cortège de nouveautés et pour certaines d'entre elles une notion héritée de BigTable : celle de base de donnée orientée colonne. Cependant faire le lien entre l'article de Wikipedia et comprendre ce que permet réellement un base de donnée comme HBase n'est pas une chose évidente. En effet le simple fait de définir cette notion ne suffit pas toujours a bien comprendre quels sont les principes de conception du monde SQL qui peuvent être oubliés et ceux qui doivent être appris. Colonne or not colonne ? Prenons un modèle très simple de donnée et essayons de le transposer dans un modèle "orienté colonne": Comme on peut le voir on est passé d'un modèle à 2 dimensions (ligne x colonne) vers un modèle où une valeur est accédée au travers de 2  coordonnées qui sont ici (ligne, colonne) Cette notion de coordonnées est  importante  (c'est pour ça que je la met en gras 2 fois de suite) si l'on veut c

Row Count : HBase Aggregation example

With the coprocessors HBase 0.92 introduces a new way to process data directly on a region server. As a user this is definitively a very exciting feature : now you can easily define your own distributed data services. This post is not intended to help you how to define them (i highly recommend you to watch this presentation if you want to do so) but to quickly presents the new aggregation service shipped with HBase 0.92 that is built upon the endpoint coprocessor framework. 1. Enable AggregationClient coprocessor You have two choices : You can enable aggregation coprocessor on all your tables by adding the following lines to hbase-site.xml : <property> <name>hbase.coprocessor.user.region.classes</name> <value>org.apache.hadoop.hbase.coprocessor.AggregateImplementation</value> </property> or ...you can enable coprocessor only on a table throught the HBase shell : 1. disable the table hbase> disable ' mytable ' 2.

Zookeeper, Netflix Curator and ACLs

If you have one or more Zookeeper "multi-tenant" clusters you may want to protect znodes against unwanted modifications. Here is a very simple and short introduction to the ACL and custom authentication features. This post is not intended to give you best practices about security and Zookeeper, the only goal is to give you a complete example of a custom authentication handler. Complete source code with JUnit test is available here : https://github.com/barkbay/zookeeper-acl-sample/ Use case Let say that your Zookeeper cluster is used by several users. In order to restrict user actions you have decided that each user must prefix all paths with the first letter of his name. User foo is only allowed to create, read, delete and update znodes under the /f znode. User bar is only allowed to create, read, delete and update znodes under the /b znode. Get client authentication data on the server side Zookeeper client authentication can be easily customized , a