Hadoop in da Cloud
Les offres proposant d'utiliser Hadoop en environnement cloud, public ou privé, se développent. Hadoop est-il adapté à cet usage ? Ces offres sont-elles crédibles ? Intéressantes ? Quels sont les fournisseurs ? Petit tour d'horizon.
(note : par cloud privé, dans cet article j'entends cloud privé virtuel, off-premises)
Hadoop n'est-il pas conçu pour tourner sur des machines physiques ?
Si. Plus précisément, les 2 composants coeur de Hadoop, HDFS pour le stockage et Map-Reduce pour le traitement, ont été pensés pour des environnements physiques assez spécifiques, pour les raisons suivantes :
- De nouvelles contraintes techniques apparaissent. Le problème aujourd'hui n'est plus la puissance CPU brute ou la taille des disques. Il y a un paramètre qui n'a pas grandit aussi vite que les autres avec la loi de Moore, c'est la latence des I/O, disque et réseau. Pour 100€, j'ai chaque 18 mois deux fois plus d'espace disque, mais j'ai besoin de plus de temps pour accéder à ce volume de donnée. Une des solutions, c'est la parallélisation des accès. On cherche à paralléliser le canal CPU-to-disk, c'est pourquoi on préconise pour Hadoop des configurations avec disques internes en JBOD, et 1 disque pour chaque coeur de CPU (ou un peu plus). On distribue également les traitements sur de nombreuses machines pour paralléliser les accès réseau.
- Les structures de coût ont évolué. Dans les datacenters des Géants du Web, les machines low-cost sont plus efficientes que les machines haut-de-gamme dotées de nombreuses redondances matérielles, même en considérant une triple réplication des données. C'est pourquoi HDFS (et Google GFS avant lui) a été conçu pour fonctionner sur des clusters ayant de grands nombres de noeuds peu fiables [1], en répliquant intelligemment les données sur des machines différentes, et des racks différents, de sorte qu'une même panne matérielle n'impacte pas toutes les copies.
Ces 2 éléments de design (disques internes et stratégie de réplication des données basée sur la topologie physique) sont difficiles, voire impossibles à reproduire en environnement virtualisé avec infrastructure SAN. Dans un environnement cloud, c'est encore pire, puisqu'on a pas (ou peu) de connaissance sur la topologie de l'infrastructure.
Pour autant, y a-t-il des cas où un environnement virtualisé serait envisageable ? Oui. En prenant en compte ces contraintes, c'est-à-dire en étant vigilant sur les I/O et sur les stratégies de réplication des données, Hadoop fonctionne bien sur infrastructure SAN partagée, dans le cas de clusters petits ou de taille moyenne [2].
"Que peut-on attendre en terme de performance ?"
VMWare a étudié l'impact de la virtualisation sur la performance des traitements, dans un benchmark utilisant des travaux basiques caractéristiques : CPU-bound, disk-bound, ou avec de fortes sollicitation du réseau [3]. Les résultats sont encourageants et même surprenants, puisqu'ils s'échelonnent entre un ralentissement de 4% de certains traitements et une amélioration jusqu'à 14% d'autres ! Cette étonnante amélioration est due à la stratégie d'optimisation de l'utilisation du CPU par l'hyperviseur, gagnante dans certaines situations précises.
Il est à noter que certaines fonctions de gestion de la performance du cluster (speculative execution) ont dû être désactivées, car clairement incompatibles avec le travail de l'hyperviseur.
Toutefois, ces travaux basiques ne sont pas forcément représentatifs des traitements que vous aurez, vous. Une fois dans le cloud, considérez dans tous les cas une performance légèrement réduite (que vous pourrez compenser par l'allocation d'autres machines), ou variable d'une exécution à l'autre [2].
"Le ratio prix/performance est-il bon ?"
Accenture a récemment produit une étude très intéressante [4] pour comparer le TCO d'une configuration bare-metal avec celui d'une configuration cloud (AWS). Cette comparaison est faite sur des traitements complexes et représentatifs d'un projet big-data.
La conclusion de cette étude est que le ratio prix/performance est meilleur chez AWS. Si cette étude est discutable sur certains points -- notamment du fait que le résultat dépend de nombreuses hypothèses chiffrées fixées par les auteurs, et que la configuration bare-metal choisie est sous-dimensionnée -- on peut en retenir que les ratio prix/performance se tiennent dans les mêmes ordres de grandeur.
Une deuxième conclusion de cette étude est qu'un travail sur l'optimisation des traitements est primordial, puisque dans leur cas, cela a apporté un gain d'un facteur 8. Il vaut mieux donc utiliser son énergie sur la structure et la performance des traitements plutôt qu'à grapiller 20% sur les coûts du fournisseur !
Au-delà du coût du cluster à proprement parler, d'autres coûts liés au cloud sont à considérer, notamment celui du transfert de vos données dans et hors du cloud. Apache recommande également la prudence quant à la fiabilité du stockage HDFS virtualisé dans le cloud, et recommande de considérer l'utilisation de stockages annexes (type AWS S3, Azure Blob, etc) [2]. Il y aura donc des coûts associés.
"Quelles sont les offres cloud existantes ?"
De nombreuses offres aux caractéristiques bien différentes voient le jour, je vous propose la catégorisation suivante.
Note : j'ai listé ici des fournisseurs ayant une offre en cloud public suffisamment claire et documentée pour démarrer dès que vous avez fini la lecture de cet article. J'ai éludé les fournisseurs ne proposant que du cloud privé (ce qui nécessite de travailler avec une de leurs équipes en amont), et les fournisseurs qui font plus dans le marketing big-data que dans des offres plug'n'play ;-)
Catégorie IaaS
Dans cette catégorie, vous avez des offres sur étagère IaaS avec une distribution Hadoop pré-packagée en tant qu'image pour vos VMs.
Vous choisissez la taille de machine qui vous convient, et déployez l'image proposée par le fournisseur. Vous obtiendrez un cluster compute+storage, typique Hadoop.
Mon avis:
- Le côté offre "sur étagère" peut laisser supposer qu'on va s'épargner du temps au setup du cluster, et éviter quelques écueils sur la perf. (Ce point mériterait un benchmark, et sera peut-être l'objet d'un futur article.)
- On peut partir des images VM fournies et les customiser pour ajouter des libs ou autre
- Inconvénient : à comparer avec la catégorie suivante, ce n'est pas tout à fait plug'n'play. Il faut gérer soi-même les name-nodes, les task-trackers, etc.
- Autre contrainte : on ne peut pas éteindre le cluster pour réduire les coûts, car les noeuds ont les 2 fonctions compute+storage. Pour réduire les coûts, il faut "supprimer" les machines, et donc déplacer les données sur un autre stockage auparavant.
Des fournisseurs possibles :
- RackSpace + HortonWorks (infos setup)
- Joyent + HortonWorks (infos setup)
- GoGrid + Cloudera CDH
Il est à noter que les machines RackSpace semblent un peu petites dans un contexte Hadoop, ce qui rend l'offre pas franchement compétitive.
Alternative : Si vous souhaitez choisir fournisseur IaaS et distribution Hadoop indépendamment, c'est évidemment possible mais je ne le recommanderai que dans les cas suivants :
- vous voulez être chez un fournisseur IaaS bien précis (parce que vous y avez déjà un cloud privé, ou que vous avez des contraintes réglementaires, notamment de localisation des données)
- vous voulez jouer avec une distribution Hadoop très récente, voire en béta, voire même customisée par vos soins (auquel cas vous n'avez rien à faire sur cet article ;-)
Vous prendrez le risque d'avoir à passer du temps au tuning de cette distribution et des paramètres de votre cluster pour l'adapter à ce cloud précis, et obtenir une performance adéquate.
Catégorie "Hadoop-as-a-Service"
Ici on a des solutions beaucoup plus packagées et automatisées. Notamment, on ne s'occupe pas de gérer les name-nodes, task-trackers & co. Une bonne partie du travail est faite pour vous, c'est assez transparent.
Possibilité 1 : Vous souhaitez un cluster Hadoop "classique" compute+storage.
Offres :
- Azure HDInsight, basé sur une distribution HortonWorks (dont vous avez une description dans cet article)
- AWS Elastic-Map-Reduce, en utilisant une distribution de MapR (version M3, M5, ou M7 au choix)
- VirtualScale Datazoomr sur Cloudera, offre d'une jeune pousse française.
Dans ce cas, vous aurez un cluster complet, avec une certaine flexibilité, notamment pour utiliser de la donnée en provenance d'un autre stockage (AWS S3, Azure Blob Storage), ou encore instancier des noeuds de calcul (workers sans stockage).
Possibilité 2 : En allant encore plus loin dans cette approche PaaS, il devient possible de n'utiliser que certains composants particuliers de l'univers Hadoop, en étant facturé à l'usage.
Par exemple, n'utiliser que Map-Reduce sur un cluster transitoire. De 0 à des dizaines de noeuds en quelques minutes, sans persistance du stockage en HDFS. Avec l'offre AWS Elastic-Map-Reduce et leur distribution Hadoop historique ("amazon standard"), ou celle de Joyent Manta, un challenger, l'utilisation typique est le stockage de données dans un object-store (S3 ou Manta), puis l'instanciation de noeuds de traitements Map-Reduce pour un ensemble de travaux. Les données sont lues directement depuis l'object-store, ou peuvent être copiées en local (HDFS). A la fin du traitement, le résultat est renvoyé dans l'object-store et les noeuds sont supprimés. Ici vous paierez le stockage (volume et transferts) d'une part, et le traitement au temps CPU consommé de l'autre.
Autre exemple, n'utiliser qu'une fonctionnalité de requêtage SQL sur des volumes gigantesques. Google met à disposition son fameux Dremel -- que la communauté Hadoop essaie d'ailleurs de reconstruire -- dans son offre Google BigQuery. Vous pouvez injecter la donnée en flux, et en faire de l'analyse interactive. Vous paierez au stockage, et au volume manipulé dans vos analyses.
Un dernier exemple, s'orienter vers un stockage noSQL, et le manipuler par opérations Map-Reduce. Des offres comme celle d'AWS et MapR, ou encore avec celles d'InfoChimps vous permettront de construire ce type d'architecture.
En résumé :
Dans cette catégorie "Hadoop as a Service", beaucoup de flexibilité, et en fonction de vos besoins des réponses et des offres bien différentes. Les prix quant à eux sont bien difficiles à comparer (il suffit de regarder les grilles tarifaires d'AWS pour s'en convaincre). Le marché est en pleine ébullition !
Catégorie "Analytics-as-a-Service"
Pour terminer cet aperçu des offres cloud, il faut évoquer les services d'analyse sur étagère. Vous fournissez des données, et vous pouvez consommer en retour le résultat d'algorithmes d'analyse, ou de machine learning.
En guise d'exemple : Intel cloud services fournit un moteur de recommendation personnalisée d'items, qui s'alimente des données que vous lui fournissez, à savoir les données d'appréciation de ces items par les utilisateurs (achats ou avis). Ou encore KXEN qui propose des services d'aide à la vente couplés aux applications SalesForce.
On sort toutefois du cadre de cet article, puisque la technologie Hadoop n'est plus visible pour vous. Elle est masquée derrière des APIs, et gérée intégralement par le fournisseur. Là encore, le marché est très jeune, mais déjà riche d'offres très variées.
Conclusion
Certaines DSI ont des contraintes d'hébergement (place disponible, coût, approvisionnement, compétences) qui ne leur permettent pas de mettre en place rapidement un lot de machines adaptées à Hadoop (commodity hardware, disques JBOD) pour construire un cluster de petite ou moyenne taille.
Dans d'autre cas, il s'agit de projets d'innovation pour lesquels on ne sait pas déterminer précisément à l'avance la taille du cluster dont on aura besoin, ni quel sera son taux d'utilisation.
Comme on a pu le voir dans cet article, créer un cluster Hadoop dans un cloud fait clairement sens, et les technologies proposées par ces fournisseurs sont crédibles et gagnent toujours plus en maturité. Soyez vigilant aux questions de durabilité des données si elles ne sont présentes que dans le cloud, et aux performances I/O des stockages cloud.
Le gain immédiat est indéniablement le temps de démarrage de votre projet. Vous pouvez commencer demain ! Il sera toujours temps de rationaliser et d'internaliser plus tard, si cela fait sens, lorsque vous aurez une meilleure idée de votre utilisation réelle d'Hadoop.
Références
[1] Apache Wiki - Virtual Hadoop
[2] VMWare - Benefits of Virtualizing Hadoop