Hadoop : Comment réduire ses coûts HDInsight pour le développement

[アーティクル]
11/16/2015

Comme on le voit dans ce diagramme, HDInsight est au cœur de la plateforme Big Data de Microsoft.

L’offre Azure Data Lake Analytics et l’offre HDInsight ont un positionnement similaire. Suivant que vous préférez utiliser un code portable tout en bénéficiant d’un service géré, d’une part ou que vous voulez être dans un monde plus centré sur Microsoft d’autre part, vous choisirez plutôt HDInsight ou plutôt Azure Data Lake Analytics.

Dans le cas d’HDInsight, vous pouvez exécuter du code Hive, Pig, Java, Python, Scala, … sur Hadoop, Storm ou Spark… Cela n’est pas très coûteux puisque vous pouvez créer les ressources de calcul nécessaires uniquement pendant le temps d’exécution des batches, et ce de façon automatisée. Si on prend par exemple 2 heures de batch pendant 30 j par mois, cela donne un coût de moins de 500 € pour un cluster avec 2 nœuds principaux et 10 nœuds de calcul :

NB : cela inclut du support qui permet de poser des questions sur votre code. En effet, supposons que vous ayez un problème avec une requête HIVE par exemple; si c’est sur HDInsight, vous pouvez demander au support Microsoft.

Cela dit, si vous devez développer sur cet environnement HDInsight, c’est moins optimal puisque l’environnement va tourner plus régulièrement (ex : 8 à 10 h / jour). De plus, on peut créer ou détruire un cluster HDInsight qui va retrouver ses données, mais il peut être plus confortable de travailler sur une machine virtuelle que l’on personnalise un peu avec ses outils, qu’on éteint ou allume en fonction des besoins. Il n’est pas nécessaire d’avoir un cluster complet en développement tant qu’on n’en n’est pas à la phase d’optimisation.

On peut aussi vouloir tester des fonctionnalités nouvelles d’Hadoop.

Pour tout cela, il y a le bac à sable (Sandbox) d’Hortonworks, disponible dans la marketplace d’Azure.

Ce modèle de machine virtuelle comprend des tutoriels, exemples, des outils pour découvrir Hadoop, Spark et aussi l’utiliser comme VM de développement.

Au niveau du prix, cela coûte le prix de la VM. Le modèle de licence est du Bring Your Own License. Voir https://azure.microsoft.com/en-us/marketplace/partners/hortonworks/hortonworks-sandbox / pour plus d’informations.

Cette page contient un lien pour instancier une VM.

Il faut ensuite remplir un certain nombre de champs, comme pour la création d’une machine virtuelle standard. Dans les quelques copies d’écrans suivantes, on se place dans le cas de la création dans le mode « Resource Manager ».

Ce mode permet ensuite, lorsque la VM est créée, de configurer des règles de pare-feu depuis le portail (dans le mode « classic », il peut être nécessaire de passer par quelques lignes de commande).

Voici donc comment configurer les accès à votre VM :

Depuis le panneau (« blade ») de la VM dans le portail portal.azure.com, cliquez sur le groupe de ressources qui vous donnera accès au NSG (Network Security Group) du vNet. Là, vous avez accès aux différentes règles entrantes vers le réseau…

…

… auxquelles vous pouvez ajouter deux règles :

Une pour autoriser votre ou vos adresses IP à accéder à la VM et l’autre pour interdire toutes les autres adresses IP d’Internet. Remarquez le champ « Priority ».

Exemple :

Optionnellement, vous pouvez également donner un nom à l’adresse IP publique de votre VM, comme suit :

Par exemple, si vous avez déployé en North Europe et que vous avez donné comme nom hdp23sandbox, vous pouvez ensuite naviguer vers https://hdp23dansbox.northeurope.cloudapp.azure.com:8888 et voir une page d’accueil qui contient entre autres des tutoriels :

Il est bien sûr aussi possible de se connecter à votre VM en ssh.

Vous pouvez configurer l’accès aux comptes de stockage Azure en ajoutant des clefs valeurs dans le fichier /etc/hadoop/conf/hdfs-site.xml (sudo vi /etc/hadoop/conf/hdfs-site.xml)

- key: fs.azure.account.key.{storage account name}.blob.core.windows.net

- value: {{storage account name} account key (primary or secondary)}

Exemple: