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 inu
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