Porn Data

Explorant depuis quelques mois le sentier du Big Data, j'avoue pour le moment rester sceptique à plusieurs niveaux et ceci amenant ce titre. Je ne nie pas cependant l'intérêt de Big Data pour certains cas d'usage.

Les points ci-dessous sont un point à date, avec ma connaissance actuelle de l'écosystème ; il y a forcément des choses ajustables / améliorables ; que les personnes plus avancées que moi dans le domaine se fasse un plaisir de commenter pour partager leurs visions.

Commodity hardware (ou pas)

Pour moi, du Commodity Hardware, c'est plutôt une VM du genre 2 vCPU/ 4 Go RAM et dans les versions les plus gourmandes, 4 vCPU / 8 à 16Go RAM.

Dans leur livre blanc sur le Big Data (dont je recommande la lecture par ailleurs), OCTO, pour une configuration moyenne, annonce:

Master node : 4 CPU / 96 Go RAM / n To / 2 NIC

Slave node : 6 CPU / 96 Go RAM / n To / 2 NIC

Quand ont sait qu'un cluster Hadoop, c'est un minimum de 10 machines environ. Si on prend les couts AWS pour des profils autour de 64 Go de RAM, nous sommes vite à un minimum de 500$ / mois / machine, soit 5.000$ / mois ou 60.000$ / an pour le cluster. A comparer avec un profil moyen (2 vCPU/4 Go RAM) autour de 40$ / mois / VM.

Il est heureux de savoir qu'avec une infra qui te coute jusqu'à / voire a minima 10 fois plus cher par VM, tu es en mesure d'analyser beaucoup plus de choses. Certes, on peut démarrer avec des profils plus modestes mais on tombe vite à 4 à 5 fois le prix d'une VM moyenne.

Enlarge your infrastructure

J'ai déjà abordé le point précédemment, mais avec le nombre de composants à installer et le jeu des quorum pour garantir la résilience des données et assurer la distribution des jobs, on se retrouve vite avec :

  • 2 Master nodes
  • 3 Data nodes
  • 4 workder nodes (replication factor des data nodes +1)
  • 1 Edge node pour les IHM d'admins, etc.
  • 1 à n nodes pour d'autres composants.

Il y a plusieurs typologies possibles (on peut mutualiser Worker node et data node pour avoir des traitements au plus près des données, mais la scalabilité est moins évidente par ex) mais globalement, en dessous de 10 VMs ; point de salut.

Un écosystème complexe

Je fais l'impasse sur le coté mature, ne m'attachant pas particulièrement à ce que les projets soient en version 1.0+ pour les utiliser. Je préfère une solution en 0.x qui est utilisée massivement par un ou plusieurs gros acteurs  (ex de Kafka 0.x avec LinkedIn et plus de 1000 milillars de message par jour) qu'une version 1.0+ moins éprouvée.

On peut certes monter sa plateforme hadoop soit-même en prenant les composants à droite et à gauche en fonction de ses besoins. Néanmoins, cela demande une certaine maturité. Pour pallier à cela il existe des distributions, qui à l'image des dristributions linux, font un packaging complet et une intégration permettant un déploiement rapide. On peut d'ailleurs saluer l'éditeur Hortonworks qui fournit une solution opensource de bout en bout, bien packagée et avec des composants très à jour.

I want more data / all your data

Le principe du datalake veut que l'on stocke tout dans le format le plus brut possible et décider plus tard du mode d'utilisation. Il arrive même qu'on redécoupe les données reçues en plus petites données pour une manipulation ultérieure. Outre le fait que l'on duplique les données de système existants, peut-on aller vers un SI où toutes les données de toutes les applications sont dans le datalake et consommé par les applications ? Cela me parait plus aller vers un SPOF (malgré la réplication et distributions des données) qu'autre chose. Cette tendance à remettre tous ses oeufs dans le même panier ne va pas de soi pour moi ; surtout quand on voit l'émergence des architectures microservices en parallèle.

A l'inverse, faire n datalake en fonction de domaines et des usages me parait prohibitif du fait de l'infrastructure sous-jacente requise.

Par ailleurs, plutôt qu'une donnée brute, je serai plutôt à la structuer à minima pour qu'elle soit plus facilement exploitable ensuite. Par exemple, une ligne brute de log devient un "objet" log avec des attributs.

Ok, mais le cluster Hadoop traite vite les données

Pour être totalement cynique, c'est bien le minimum que il puisse faire en fait. Si 1 seul job spark s'alloue minimum 4 Go de RAM, il a bien intérêt à être rapide et il peut bien envisager de faire du temps réel.

Jusqu'à présent, je n'ai rien à dire à ce sujet ; ça fait bien le job, il faut le reconnaître mais nous n'en sommes qu'à nos premiers cas d'usages et sur des volumétaires encore faibles.

Licences Editeur qui ne sont pas élastiques

Dans un modèle qui veut favoriser l'autoscaling, les éditeurs proposent des licences qui est fonction du nombre de VM. Si je reconnais qu'il n'est pas évident de trouver un modèle de licensing, avoir un modèle à la VM est plutôt dissuasif (mais dans l'intérêt de l'éditeur) puisque si tout se passe bien, votre cluster Hadoop doit forcément s'aggrandir...

Conclusion partielle

A ce stade :

  • Je me demande si dans bon nombre de cas, en occtroyant à une application une architecture simplement plus puissante ou bien en achetant les options qui vont bien pour des solutions propriétaires, on ne fera pas tout aussi bien pour moins cher. Se pose la question de la volumétrie réelle à partir de laquelle une plateforme big data est vraiment nécessaire et en vaut le coût.
  • Quand on compare un cluster hadoop à l'essai sur "Digital technology and infrastructure for the post growth time" qui promeut plutôt une logique minimaliste voire frugale, on peut se poser la question de la cohabitation de ces deux mondes.
  • Au regard de l'approche "microservices", on pourrait certes voir un cluster hadoop comme une plateforme microservice. Cela peut se valider de part la multitude des composants utilisables et la relative indépendance des composants. C'est peut être un peu abusif depart la complexité de l'ensemble et de Yarn comme ordonnanceur global et point de passage obligé (ainsi que Zookeeper).
  • L'omniprésence de Java ; Cela peut être vu comme une force (toute grosse entreprise a des compétences Java) mais aussi comme une faiblesse. Il y a certes des API en Python, R, Scala, etc mais n'empêche que le socle reste en Java et demande des compétences à ce niveau. Cela exclut de fait beaucoup de petites/moyennes entreprises je pense d'un tel projet.
  • Une approche encore trop piloté par la technologie et pas assez par les usages. Les enthousiastes de Big Data mettent en avant leur solution pour trouver de nouveaux terrains de jeux et justifier leur existence. Pour autant, est-ce vraiement la bonne solution ou bien un tank pour tuer un moucheron ?

Reste à voir si cette perception va perdurer avec le développement des usages ou si au contraire, les usages grandissant vont me permettre de voir cette plateforme rentabilisée, utile et adaptée aux besoins.

A suivre...

[Edition du 31/3] Big Data 2.0: Open Source Becomes A Converged Product : présentation intéressante sur les mutuations possibles autour de l'écosystème big data avec une approche plus orientée produit et moins plateforme. Avec pour conséquence une mutuation nécessaire pour les éditeurs des distributions Hadoop généralistes comme MapR, Hortonworks et Cloudera.

Haut de page