Spark

Hadoop est la base d'un date lake avec son système de fichier distribué, HDFS. Pour info, il en existe d'autres comme CEPH ( open source ) ou GPFS ( IBM ). Il serait aussi intéressant de voir d'où forke celui de Scality dans la mesure où il est capable de traiter un nombre très considérable de vidéos.

Au dessus de ce shared data storage, d'autres moteurs peuvent être envisagés pour accélérer les traitements sur les données. Parmi ceux-là, j'ai été frappé par l'émergence et l'adoption ultra-rapide de Spark, un moteur parallèle in-memory disposant d'une API intéressante sur les RDD et d'options variées et multiples ( dataframes, streaming, machine learning ). Pour info, IBM est un gros contributeur de Spark.

Pour découvrir ce logiciel, j'ai lu le livre des "guys" de Databricks: Learning Spark.

En attendant l'opportunité de plonger dedans ...

Hadoop: architecture

Depuis sa création, Hadoop repose sur un modèle où chaque noeud du cluster est identique et où la scalabilité qui tend vers la linéarité est assurée par l'ajout de noeuds. Un noeud repose sur le principe de la colocalité des données et des traitements ce qui permet de soulager le réseau, élément primordial à la naissance de cette technologie. Enfin, il est préconisé comme pour les bases NoSQL d'installer le cluster sur du "bare metal", c'est à dire du dédié à l'opposé du virtuel.

Cependant, comme depuis sa naissance, l'IT a énormément évolué depuis plus de 10 ans et en particulier, les réseaux ont effectué un bond technologique ( Ethernet à 40 Gbs et Infiniband à 56 Gbs ). De plus, les grands comptes ont investi considérablement dans la virtualisation de leur infrastructure au détriment du dédié pour rationaliser leur coût et être capable d'offrir un provisioning beaucoup plus souple.

Vu ces évolutions, de nouvelles architectures Hadoop sont en train d'émerger. La première consiste à virtualiser l'architecture Hadoop. Pour les environnements bas ( développement, recette utilisateur, ... ), le pas est déjà franchi depuis quelques années. Reste à faire évoluer les environnements de production. Pour ce faire, les master nodes ( name nodes, admin nodes, appli nodes, edge nodes, ... ) sont complètement virtualisés, accès disque compris ( SAN ). Reste à préserver la colocalité des traitements et des données pour les data nodes, d'où un accès en mode DAS ou équivalent. Dans ce registre, VMware a fait de considérables travaux sur le sujet et propose désormais une alternative crédible au dédié : VMware big data. En particulier, je vous conseille la lecture du REX chez Skyscape.

Sur ce type d'architecture, le revers de la médaille est la perte de la haute disponibilité fournie par VMware au niveau des data nodes, les disques étant locaux. Il reste aux vendeurs de baies de disques de trouver des alternatives crédibles en terme d'HDFS et de sortir de leur modèle actuel privilégiant l'IOPS ( bases SQL en mode transactionnel  ) à la bande passante  ( clusters Hadoop en mode batch brassant de grandes quantités de données ). La solution d'EMC, Isilon, est déjà dans la liste des architectures certifiées par Cloudera et Adobe l'a mise en oeuvre.

Mais allons plus loin et considérant maintenant les progrès de la couche réseau. On peut alors envisager séparer la couche compute ( map-reduce ) de la couche storage ( hdfs ). Cela permettrait d'une part de pouvoir créer des pools de noeuds de type compute ( map-reduce, hive, spark, ... ) avec des configurations adaptées ( introduction possible de la GPU ) et non uniformes et d'autre part, de pouvoir spécialiser les noeuds de type storage en données chaudes/froides et ainsi de provisionner du disque magnétique, du SSD ou encore du disque flash en fonction du degré temporel de la donnée.

Dans ce domaine, HP a effectué un gros travail en laboratoire avec sa solution BDRA. Reste à l'éprouver dans le monde réel ...