Here is one of the use cases of Hadoop on Azure: you have a few applications accumulating data over time and you need to execute batches against this data a few times a month. You need many machines in an Hadoop cluster, but most of the time, you don’t need the cluster, just the data. Voici un des cas d’utilisation d’Hadoop sur Azure: Quelques applications accumulent des données au fur et à mesure et on doit exécuter des batches sur ces données quelques fois dans le mois. On a besoin de machines dans un cluster Hadoop, mais la plupart du temps, on n’a pas besoin du cluster, juste des données.
One possible way is shown in the following diagram, that we will explain in this post. Une des façons d’organiser les choses est décrite ci-dessous dans ce diagramme que nous allons expliquer au cours de ce billet:

image

Hadoop Hadoop
Hadoop is a framework that implements map/reduce algorithm to execute code against big amounts of data (Terabytes). Hadoop est un framework qui met en oeuvre l’agorithme map/reduce pour exécuter du code sur un grand ensemble de données (on compte typiquement en teraoctets).
On an Hadoop cluster, data is typically spread across the different data nodes of the Hadoop Distributed File System (HDFS). Even one big file can be spread across the cluster in blocks of 64 Mb (by default). Sur un cluster Hadoop, les données sont typiquement distribuées sur plusieurs noeuds de données du système de fichiers distribué Hadoop (HDFS). Même pour un gros fichier, il peut y avoir une répartition en blocs de 64 Mo (par défaut).
So data nodes play two roles at the same time: they are a processing role and they are also hosting the data itself. This means that removing processing power removes HDFS storage at the same time. Les noeuds de données jouent donc deux rôles différents en même temps: ils font du calcul et stockent les blocs de données. Cela signifie aussi qu’en supprimant la puissance de calcul, on supprime en même temps le stockage HDFS.

 

Persistent storage Stockage persistant
In order to make data survive cluster removals, it is possible to have the data to persistent storage. In Windows Azure, the candidate is Windows Azure Blobs, because it is what corresponds the most to files, which is what HDFS stores. De façon à faire en sorte que les données survivent à la suppression du cluster, il est possible d’avoir les données dans un stockage persistant. Dans Windows Azure, le candidat naturel est Windows Azure Blobs, puisque c’est ce qui correspond le plus à des fichiers, ce qu’HDFS stocke aussi.
NB: other Windows Azure persistent storages also include Windows Azure Tables (non relationnal) and SQL Azure (relationnal, with sharding capabilities called federations). NB: Il y a également d’autres stockages persistants Windows Azure tels que les tables Windows Azure (non relationnelles) et SQL Azure (base de données relationnelle, avec des capacités de partitionnement appelées fédérations).

 

Pricing on Windows Azure Tarification sur Windows Azure
Officiel pricing are described here and you should refer to that URL in order to have up to date pricings. Les prix officiels sont fournis ici. Il est recommandé de se référer à cette URL officielle pour avoir les prix les plus à jour.
While I’m writing this article, current pricing are the following: A l’heure où j’écris cet article, les prix sont les suivants (je les donne en $, mais ils sont facturés en € avec une parité reflétant la parité du marché):
- using Windows Azure blobs costs
* $0.14 per GB stored per month based on the daily average – There are discounts for high volumes. Between 1 and 50 TB, it’s $0.125 / GB / month.
* $1.00 per 1,000,000 storage transactions
- l’utilisation des blobs Windows Azure coûte
* 0,14$ par Go stocké par mois en se basant sur l’utlisation quotidienne – Il y a des réductions pour les gros volumes. Entre 1 et 50 To, c’est 0,125$ / Go / mois.
* 1,00$ par 1.000.000 de transactions de stockages
- An Hadoop cluster uses an 8-CPU head node (Extra large) and n 2-CPU data nodes (Medium).
* nodes are charged $0.12 per hour and per CPU. An 8 node + 1 head node cluster costs (8x2CPU+1x8CPU)x$0.12x750h=$2160/month.
- Un cluster Hadoop utilise un noeud principal à 8 coeurs (très grande taille) et n noeuds de données à 2 coeurs (taille moyenne).
* Les noeuds sont facturés 0,12$ par heure et par coeur. Un cluster composé de 8 noeuds bi-coeurs + 1 noeud principal (8x2coeurs+1x8coeurs)x0,12$x750h=2160$/mois.
- There are also data transfer in and out of the Windows Azure DataCenter.
* Inbound data transfer are free of charge
* Outbound data transfer: North America and Europe regions: $0.12/GB, Asia Pacific Region: $0.19/GB
- il y a aussi les transferts de données depuis et vers le centre de calcul Windows Azure.
* les transferts de données vers le centre de calcul sont gratuits
* Pour les transferts de données depuis le centre de calcul: Régions Amérique du Nord et Europe: 0,12$/Go, région Asie/Pacifique: 0,19/Go
   
Disclaimer: in this post, I don’t take into account any additional cost that may come for Hadoop as a service. For now, current version is in CTP (Community Technology Preview) and no price was announced. I personnaly have no idea of how this could be charged, or even if this would be charged. I just suppose the relative comparisons between costs would keep roughly the same.

Avertissement: dans ce billet, je me base uniquement sur les prix des ressources Azure et ne tiens pas compte du prix additionnel éventuel pour l’utilisation d’Hadoop en tant que service. La version actuelle est une pré-version (CTP) et aucun prix n’a été annoncé. Je n’ai d’ailleurs personnellement aucune idée de la façon dont ce sera facturé, ni même si cela le sera. Je suppose simplement que les coûts relatifs devraient rester à peu près les mêmes.

   
In current Hadoop on Azure CTP (community Technology preview) the following clusters are available (they are offered at no charge to a limited number of testers). Dans la version CTP actuelle d’Hadoop sur Azure, les clusters suivants sont proposés (ils sont proposés gratuitement à un nombre limité de testeurs).

image

In order to store 1 TB of storage one needs at least a cluster with 3 TB  because HDFS replicates data 3 times (by default). So medium cluster is OK. Note that for computation moving to a large cluster may be needed as additional data will be generated by computation. Pour stocker 1 To de stockage, il est nécessaire d’avoir un cluster qui dispose d’au moins 3 To parce qu’HDFS réplique les données 3 fois (par défaut). Un cluster de taille moyenne (Medium) est donc satisfaisant. On notera tout de même que lors des calculs il peut être nécessaire de passer à un cluster de plus grande taille puisque des données complémentaires peuvent être générées pendant les calculs.
In order to store 1 TB of storage in Windows Azure blobs, one needs 1 TB of Windows Azure blob storage (replication on 3 different physical nodes is included in the price). De façon à stocker 1 To de données dans les blobs Windows Azure, on a besoin d’1 To de stockage Windows Azure (la réplication sur 3 machines physiques différentes est incluse dans le prix).
So storing 1 TB of data in an Hadoop cluster with HDFS costs $2160/month while storing 1 TB of data in Windows Azure storage blobs costs 1024x$0.125=$128/month. Ainsi, stocker 1 To de données dans un cluster Hadoop avec HDFS coûte 2160$/mois alors que stocker ce même To de données dans des blobs Windows Azure coûte 1024x0,125$=128$/mois.
Copying 1 TB of data to or out of Windows Azure blobs inside the datacenter will incur storage transactions. As an approximation let’s count a storage transaction / 1 MB. (per MSDN documentation a PUT storage transaction on a block blob may contain up to 4 MB of data). So copying 1 TB of data would roughly cost $1. Pour copier 1 To de données depuis ou vers les blobs Windows Azure au sein du même centre de calcul il faut prendre en compte les transactions de stockage. En première approximation, comptons une transaction de stockage / 1 Mo (comme indiqué dans la documentation MSDN, une transaction de stockage PUT sur un blob de type bloc peut contenir jusqu’à 4 Mo de stockage). Il en résulte que la copie d’1 To de données coûte à peu près 1$.
Let’s now suppose we need the Hadoop cluster 72 hours (3 x 24h) a month for computation. We would use an extra large cluster to have the result faster and to get extra storage capacity for intermediary data. That cluster costs (32x2CPU+1x8CPU)x$0.12x72h=$622.08. Supposons maintenant qu’on a besoin d’un cluster Hadoop 72 heures par mois (3 x 24h) pour effectuer des calculs. On utiliserait alors un cluster à 32 noeuds pour avoir le résultat plus vite et pour avoir également plus de capacité de stockage pour des données intermédiaires. Ce cluster coûterait (32x2coeurs+1x8coeurs)x0,12$x72h=622,08$.
So using an extra large cluster 3 times 24 h a month would cost the following per month:
- permanently store 1 TB of data in Windows Azure Storage: $128.00.
- copy 1 TB of data to and from Windows Azure storage 3 times = 3x2x$1=$6
- Hadoop Extra Large cluster: $622.08
==> $756,08
Ainsi, utiliser un cluster à 32 noeuds 3 fois 24 heures dans le mois coûte par mois:
- stocker 1 To de données de façon permanente dans le stockage Windows Azure: 128,00$
- copier 1 To de données depuis et vers les blobs Windows Azure 3 fois = 3x2x1$=6,00$
- Un cluster Hadoop 32 noeuds: 622,08$
==> 756,08$

 

So it is ~2.9 times cheaper to store 1 TB of data in Windows Azure Storage and have 3 times a 32 node cluster for 24 hours rather than permanently having an 8 node Hadoop cluster storing permanently 1 TB of data. Cela est donc à peu près 2,9 fois moins cher de stocker 1 To de données dans le stockage Windows Azure et d’avoir 3 fois un cluster 32 noeuds pendant 24 heures que d’avoir en permanence un cluster à 8 noeuds qui stocke ce To.

 

Interactions between storage and applications Interactions entre le stockage et les applications
An additional consideration is the way applications may interact with the storage. On doit également prendre en compte la façon dont les applications interagissent avec le stockage.
HDFS would mainly be accessed thru a Java API, or a Thrift API. It may also be possible to interact with HDFS data thru other stacks like HIVE and an ODBC driver like this one or this one. HDFS peut principalement être accédé depuis les API Java, ou Thrift. Il est également possible d’interagir avec les données HDFS à travers des couches complémentaires telle que HIVE et un pilote ODBC tel que celui-cicelui-ci.
Windows Azure blobs may also be accessed thru a number of ways like .NET, REST, Java, and PHP APIs. Windows Azure storage may also offer security and permissions features that are more suited for remote access like shared access signatures. Les blobs Windows Azure peuvent aussi être accédés par des moyens divers comme des APIs .NET, REST, Java, et PHP. le stockage Windows Azure peut aussi offrir des fonctionnalités de sécurité et de permissions qui sont plus adaptées à un accès à distance telles que les signatures d’accès à distance.
Depending on the scenarios, it may be easier to access Windows Azure Storage rather than HDFS. Suivant les scénarios, cela peut être plus simple d’accéder au stockage Windows Azure plutôt qu’à HDFS.

 

How to copy data between Windows Azure Blobs and HDFS Comment copier les données entre le stockage Windows Azure et HDFS
Let’s now see how to copy data between Windows Azure Storage and HDFS. Voyons maintenant comment copier des données entre le stockage Windows Azure et HDFS.

 

asv:// asv://
First of all, you need to give your Windows Azure storage credentials to the Hadoop cluster. From the www.hadooponazure.com portal, this can be done in the following way Avant tout, il faut donner ses crédentités du compte de stockage Windows Azure au cluster Windows Azure. A partir du portail www.hadooponazure.com, cela peut être fait de la façon suivante

image

 

image

 

image

Then, the asv:// scheme can be used instead of hdfs://. Here is an example: Ensuite, le préfixe asv:// peut être utilisé à la place d’hdfs://. Voici un exemple:

image

image

This can also be used from the JavaScript interactive console Cela peut aussi être utilisé depuis la console interactive JavaScript

image

 

Copying as a distributed job Copier avec un job distribué
In order to copy data from Windows Azure Storage to HDFS, it is interesting to have the whole cluster participating in this copy instead of just one thread of one server. While the
hadoop fs –cp
command will do the 1 thread copy, the
hadoop distcp
command will generate a map job that will copy the data.
De façon à copier les données du stockage Windows Azure vers HDFS, il est intéressant de faire en sorte que tout le cluster copie des données plutôt qu’un seul thread d’une seule machine. Alors que la commande
hadoop fs –cp
fera la copie à un thread, la commande
hadoop distcp
génèrera un job qui copiera les données.
Here is an example En voici un exemple

image

image

 

Here are a few tips and tricks: Voici quelques trucs et astuces:
Hadoop on Azure won’t list the content of an Windows Azure Blob container (the first level folder, just after /). You just need to have at least a second level folder so that you can work on folders (in other words for Azure blob purists, the blob names needs to contain at least one /). Trying to list a container content would result in Hadoop sur Azure ne donne pas la liste d’un conteneur de blob Windows Azure (le premier niveau de dossier, juste après /). Il suffit de créer un dossier de second niveau pour pouvoir travailler sur des dossiers (en d’autres termes pour les puristes de blobs Windows Azure, les noms de blobs doivent contenir au moins un /). Si l’on essaie de lister le contenu d’un conteneur, on a l’erreur suivante:

ls: Path must be absolute: asv://mycontainer
Usage: java FsShell [-ls <path>]

ls: Path must be absolute: asv://mycontainer
Usage: java FsShell [-ls <path>]

Here is an example

Voici un exemple

image

That’s why I have a fr-fr folder under my books container in the following example: C’est pourquoi j’ai un dossier fr-fr sous mon conteneur books dans l’exemple suivant:

image

 

A distributed copy (distcp) may generate a few more storage transactions on the Windows Azure storage than needed because of Hadoop default strategy which uses idle nodes to execute several times the same tasks. This mainly happens at the end of the copy. Remember we calculated that 1 TB of data would cost ~$1 in storage transactions. That may be ~$1.20 because of speculative execution. Une copie distribuée (distcp) peut générer quelques transactions de plus sur le stockage Windows Azure que ce qui est nécessaire à cause de la stratégie par défaut d’Hadoop qui utilise des noeuds inoccupés pour exécuter des mêmes tâches plusieurs fois. Cela arrive principalement à la fin de la copie. Souvenons-nous qu’on a calculé que la copie d’1 To de données coûtait à peu près 1$ en transactions de stockage. Cela pourrait en fait plutôt être de l’ordre de 1,20$ à cause de l’exécution spéculative.

 

Why not bypass HDFS, after all? Pourquoi ne pas contourner HDFS, après tout?
It is possible to use asv: instead of hdfs: including while defining the source or the destination of a map reduce job. So why use HDFS? Il est possible d’utiliser asv: à la place d’hdfs: y compris pendant qu’on définit la source ou la destination d’un job map/reduce. Pourquoi donc utiliser HDFS?
Here are a few drawbacks with this non HDFS approach: Voici quelques inconvénients avec cette approche sans HDFS:
- you won’t have processing close to the data which will generate network traffic which is slower than interprocess communication inside a machine. - on n’a pas le traitement près des données et cela génère du trafic réseau qui est plus lent que de la communication inter process au sein de la même machine.
- you will generate many storage transactions against Windows Azure storage (remember: 1 million of them costs $1 real money). In particular Hadoop may run a single task several times from multiple nodes just because it has available nodes and that one of those tasks may fail. - on va générer beaucoup de transactions de stockage sur le stockage Windows Azure (se souvenir qu’1 million de ces transactions coûte 1$ en argent réel). En particulier, Hadoop peut exécuter une même tâche depuis plusieurs noeuds juste parce qu’il a des noeuds disponibles et qu’une de ces tâches pourrait échouer.
- HDFS has a default behavior of spreading files in chunks of 64 MB and this will automatically spread map tasks to those blocks of data. Running directly against Windows Azure Storage may need additional tuning (like explicitly defining a number of tasks). - HDFS a un comportement par défaut qui consiste à éclater les fichiers en blocs de 64 Mo et cela répartit naturellement et par défaut les tâches sur ces blocs de données. En exécutant directement un job sur du stockage Windows Azure, on peut avoir besoin de  réglages manuels complémentaires (comme par exemple définir manuellement le nombre de tâches).

 

Conclusion Conclusion
In a case where you need to work three days a month on 1 TB of data, it is roughly three times cheaper to have a 32 node cluster that takes its data from and to Azure Blobs Storage each time it is created and destroyed than having an 8 node cluster that keeps the 1 TB data  full time. Copying data between Windows Azure storage and HDFS should be done thru distcp which generates a map job to copy in a distributed way. Dans un cas où l’on a besoin de travailler trois jours par mois sur 1 To de données, il est à peu près trois fois moins cher d’avoir un cluster de 32 noeuds qui prend et dépose ses données depuis et vers le stockage Windows Azure à chaque fois qu’il est créé et détruit que d’avoir un cluster à 8 noeuds qui garde 1 To de données tout le temps. Copier les données entre le stockage Windows Azure et HDFS doit plutôt être fait avec distcp qui génère un job map de façon à copier de façon distribuée.
This leverages Hadoop as well as Windows Azure elasticity. Cela tire parti d’Hadoop ainsi que de l’élasticité de Windows Azure.

 

Smile

Benjamin