09 Mar 2016, 17:01

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.

10 Feb 2016, 09:30

Around the Data - February 2016 - ELK, Kafka, Flink, Spark

Elasticsearch

Kafka

Flink

Spark

  • Spark 2015 year in review : Databricks (core developper of Spark) made a review of 2015 : the 4 release, the features, how spark is used, etc. I was surprised to see that majority of spark usage was as a standadlone cluster and not in an Hadoop context.

14 Oct 2015, 09:30

Around the Data - October 2015 - SQL, OLAP and Entreprise Data Hub

Quite a buzzy month ; so a single but long article on Big Data Ecosystem :

  • The Evolution of Zoosk’s Analytic Platform: The Continued Marriage of Hadoop and OLAP : Interesting feedback on how a company improves its usage of Hadoop and OLAP solutions over the last 3 years. Beyond the mixed world, we can see some improvements on Hadoop side :
    • Hadoop replaced some RDBMS and became the Entreprise Data Hub in some contexts as scaling was easier than RDBMS and Hadoop more mature
    • Hadoop adopted SQL and thus make data easier to query,
    • Efficient data storage (both in terms of size and performance when manipulating them)

24 Jun 2015, 09:30

Around the Web - June 2015 - Microservices & Big Data

Microservices

  • A complete description of what are microservices, its challenge, etc.
  • Another well illustrated introduction to microservices.
  • Pinricples of micro-services : introduction (in french) to micro-services but slides are in english.
    • Microservices are defined as small autonomous services that work together.
    • 7 principles for microservices : Culture of automation, Hide implementation designs, Decentralise all the things, Deploy independantly, Isolate failure, Highly observable, Modelled around business domain.
  • Xebian published a series of articles on microservices (in French) : Microservices: the concepts ; Microservices : architectures and the most interesting is about pitfall and/or antipatterns of microservices.
  • Summary of Microxchg Day 1 : Microxchg was a conference about microservices. This is a summary of Day 1 with lots of insights. So I'll not sum up there.
  • Domain service aggregator: a structured approach to microservice composition (par Caoilte O’Connor) : Summury from a developer from ITV (VoD in UK) about how they rewirte part of the services using microservices and the issue they met.
  • Micro-services at BlaBlaCar : Tech team introduces the principles used to switch from a single monolithic application to microservices by using "Event sourcing", "Specialised Layers" and "Think API".
    • I found interesting the idea that data layers are not to communicate among them ; it's about the business layer to fetch and aggregate data to be autonomous.
    • Event sourcing requires a broker/messaging system ; seems a kind of new SPOF to some extend (what happens if this system is down) and also how to manage application awareness regarding messages and related behaviour.
  • Microservices – The One with Polyglot Portfolio ; a summary in French about the journey of a company from a monolythic application to microservices architecture and the challenges they met.
    • Microservices architecture "enforce" the paradigm "the right tool to do the job" but with the challenge of havingthe right skills on the long term.
    • CQRS paradigm which distinguish the way you insert/update content and the way you read it. You no longer have a single model for all your CRUD operations. Interesting but challenging also in terms of coherence.
  • Adopting Microservices at Netflix: Lessons for Architectural Design - a feedback from Netflix about their best practices regarding microservices.

Big Data

  • Summary (in French) about the Strata+Hadoop World in London back in May with two insights :
    • Seems there is a switch in the way data are provided from batch to real-time
    • Spark seems the new product of the year in the hadoop ecosystem to ease data manipulation
  • Summary of the Spark meetup in Paris (in French) which covered an "introduction" to Spark, 2 ways to use Spark for data scence purpose and last the link between search and recommendation.