Datalake comparaison - 3 Hadoop

Dans ce chapitre nous allons nous consacrer aux bases de données distribuées sur le système de
fichiers Hadoop distributed files system.

Si vous voyez des erreurs commises dans ce comparatif veuillez nous adresser un mail à
contact@domwee.com nous nous efforcerons de corriger le plus rapidement possible.

La liste des solutions étudiées est la suivante : 
- HBase/Hive
- MS Datalake / partie fichiers distribués
- Hortonworks
- Cloudera
- Google Dataproc

Microsoft a implémenté une solution de Datalake autour de l’architecture Hadoop qui est open source.
Comme Cloudera et Hortonworks il s’agit simplement d’un hébergement de solution déjà existante.
Il existe deux grandes familles à l’intérieur de cette solution pour l’analyse de données : Hive et Spark.
Ces deux solutions proposent un SQL like et permet d’utiliser des connecteurs du marché JDBC et ODBC.
Nous savons que cet écosystème regorge d’autres solutions mais nous n’avons pas les moyens ni le
temps de nous y attarder et personnellement nous ne misons pas (et c’est peut être à tort mais nous
avons fait un choix) sur des solutions NO SQL très difficiles à relire et donc à maintenir.

1. 

   Architecture simplifiée
   L’architecture Hadoop est une architecture distribuée c’est à dire que les données sont réparties sur plusieurs ordinateurs souvent appelés noeuds (Nodes).
   Plus les tables sont grandes plus le nombre de noeuds doit être conséquent et cela demande beaucoup de travail de déployer et de connecter entre eux tous ces serveurs.
   L’indexeur de données a pour rôle de répartir les données de manière cohérente sur tous les noeuds pour cela il se base sur un champ qui a été défini comme maître le champ porte bien son nom c’est l’index, comme ce choix est crucial et que la machine ne peut pas deviner à la création du modèle comment se comportera l’insertion des données ce choix est laissé à l’homme. Première conclusion mal répartir les données sera préjudiciable en effet l’intérêt de cette architecture est de répartir la charge entre le plus de noeuds possibles et si la majorité des requêtes n’utilise qu’un seul noeud à la fois on se retrouve avec très peu de collaboration et donc des résultats minables. Il sait aussi sur quel noeud se trouve quelle donnée lorsque le besoin d'interroger les données se fait sentir. Quand au chef d’orchestre il donne les ordres aux noeuds et attend que tous les noeuds aient fini leur travail pour consolider le résultat et le retourner à l’utilisateur.
   Sur le papier cette architecture est séduisante le bus de données utilisé étant le bus interne de l’ordinateur avec des disques locaux on a une très grande rapidité. Le temps d’accès à la donnée et la vitesse de lecture des disques dur sera la partie la plus faible de ce dispositif.
   
1. BigData
   C’est pourquoi ce système a été pensé pour le BigData et on voit bien qu’il est prévu pour : plus on divise les données sur un grand nombre d’ordinateurs plus le résultat sera rapide. L’idée est de faire réaliser le travail non pas par un seul ordinateur mais par beaucoup d’ordinateurs. Plus les données seront petites sur chaque nœud plus le temps de charger les données en mémoire et le temps de traitement de celles ci seront courts. Ce système a vraiment l’air d’être idéal et il l’est mais pas dans toutes les situations. Ce système montre ses limites quand : le résultat de la requête retourne des milliards de lignes car il faut les envoyer à l’utilisateur qui n’a malheureusement qu’un seul CPU et pas beaucoup de RAM, cela dit ce problème est général à toutes les solutions BigData et c’est à l’utilisateur de réfléchir à cela. Nous verrons par la suite que ce système n’est pas adapté pour faire des jointures entre les tables mais si on se contente de faire des grosses tables avec tout à l'intérieur alors le système est redoutable d’efficacité. Dans certains cas pour aller encore plus vite certaines solutions vous permettent de laisser charger en mémoire une table pour éviter le temps de lecture des données sur le disque dur. Cela ne peut pas se faire sur les immenses tables mais ce fonctionnement est terriblement efficace sur les tables de taille moyenne. Ce paragraphe confirme ce que nous vous expliquions dans l’introduction, il faut bien choisir son index, il faut bien choisir ses nœuds (plutôt privilégier plein de petits nœuds que 3 gros nœuds) et donc cela demande du temps pour tout mettre en place et faire cohabiter toutes ces machines, bref c’est un savoir faire, une expertise et donc pour comparer les performances et le coût de deux solutions distinctes c’est plutôt une comparaison de savoir faire et donc d’experts que de solutions propres. Méfiez vous des personnes qui comparent des choses sans donner de détail sur l’architecture utilisée (dans ce cas : nombre de nœuds, index utilisé, disques durs utilisés SSD ou HDD) bref sans savoir de quoi elles parlent.
2. Datawarehouse
   Difficile de faire un datawarehouse avec ce genre de solution parce que le schéma en étoile n’est pas adapté à cette architecture. Comme toujours la force d’une solution est souvent sa plus grande faiblesse, la force réside dans la séparation des données selon un index. Partons sur un exemple simple cela va aider à mieux cerner le problème, prenons une table des ventes et l’index de répartition choisi est le code article, nous imaginons que nous sommes dans un cadre idéal et que tous les articles sont vendus tous les mois de manières équitables ce qui en fait un super index de répartition. Donc maintenant nous allons vouloir faire une jointure avec la table produit qui est aussi réparti sur le code produit et nous avons les données sur les mêmes nœuds et tout se passe bien.
   
   

   

   Maintenant imaginons que nous souhaitions faire une jointure sur la table des pays :
   

   

   C’est vite le bazar et on comprend vite qu’il est nécessaire de faire communiquer des données entre les nœuds. Cela se fait bien sur des petites tables mais sur des très grosses tables vous perdez une grosse partie de l’intérêt de cette infrastructure. Sinon en terme de mise à jour de données le système de répartition de données (si les indexes sont bien choisis) fait le travail et permet de faire travailler beaucoup de disques durs en parallèle et cela est très efficace. Le streaming de données fonctionne aussi très bien avec cette infrastructure. Le seul bémol c’est que pour le moment peut d’ETL sont capables d’utiliser cette puissance car ceux ci ne proposent que très rarement des architectures distribuées, c’est pourquoi ils sont souvent couplés (pour l’ingestion de données) avec des solutions de gestion de messages de type kafka pour récupérer les données provenant d’autres systèmes. 
3. Reporting
   Ces bases de données ont des connecteurs ODBC et JDBC, elles ont aussi des architectures réparties ce qui est l’idéal pour faire des requêtes en parallèle et gère très bien les pics de charge. Cela dit le SQL utilisé n’est pas standard et tous les outils ne sont pas capables de le traiter, il faut donc vérifier que la solution utilisée soit compatible et apprendre le SQL SPARK ou HIVE pour pouvoir utiliser cette technologie en reporting. Les entreprises de reporting proposent des connecteurs SPARK ou HIVE mais cela ne veut pas forcément dire que ces solutions sont compatibles BigData, en effet nombre de ces solutions chargent les données des requêtes dans des mémoires tampons et donc ne sont pas vraiment capables de charger des tables de plusieurs dizaines de GO de données. Les solutions capables de tirer profit correctement des solutions BigData sont extrêmement rares.
4. Datalake
   Pour les données structurées ces bases de données font très bien le travail. Il existe des drivers ODBC et JDBC mais faîtes attention le langage SQL n’est pas forcément standard et peut donc poser des problèmes de compatibilité dans les outils qui génèrent nativement les requêtes SQL. Comme toujours nous vous déconseillons de stocker des fichiers en format blob dans les bases de données et nous préférons utiliser des espace de stockage dropbox ou autre pour cette partie là. Pas de stockage de JSON possible si on utilise les solutions SQL like. Spark permet de faire des workflow de machine learning en utilisant un langage de programmation mais rien pour HIVE. 
5. Base de données Applicative
   Dans le cas d’une application où tout serait dans une seule table et que le nombre de lignes de données seraient démesuré ce sont les solutions idéales, c’est ce qui est utilisé par Amazon et Twitter. Pour les applications plus petites le coût est trop élevé, la complexité trop grande et elles n’apportent rien par rapport à une base de données SGBDR.
2. Utilisateurs
   Le langage utilisé est un presque SQL les utilisateurs se feront vite à ce langage. Cependant aucune interface ne semble être disponible pour ces outils (Pour Hive elle a disparu depuis la version 2.2.0) et pour Spark la seule chose disponible semble être une interface pour suivre l'exécution des jobs, je n’ai pas trouvé non plus d’outil client natif, il faut se tourner vers des outils tiers souvent payant pour pouvoir avoir une interface digne de ce nom. Ces outils sont clairement destinés à des spécialistes et n’ont pas vocation à être ouverts à une grande population. 
3. Fonctionnalités additionnelles
   Ici ne seront traitées que les fonctionnalités natives présentent dans le moteur de la base de données, sinon ce tableau n’aura aucun sens puisqu’avec du développement ou des addons on pourrait tout faire avec n’importe quelle base de données.
   - Géographiques :
   - Graphes :
   - IP :
   - Window : Spark, Hive
   - ML : 
4. Administrateur
   Opter pour des solutions hébergées semblent indispensables pour ces outils car l’installation, la maintenance et le monitoring sont des tâches très lourdes pour ces solutions.
5. Experts quand pourquoi
   Nous pensons que tous les utilisateurs de ces outils doivent être des experts. Le développement est omniprésent et il est souvent nécessaire d’ajouter des addons. De plus le choix des index est crucial et ne s’improvise pas, il est nécessaire de bien comprendre ce que l’on fait.
6. Droits et sécurité
   Au niveau des droits Hive permet de donner des droits sur les vues et les tables, en revanche aucun droit ne peut être défini sur la base de données à part le propriétaire qui laisse le droit de faire certaines actions que les autres personnes ne peuvent pas réaliser. Spark n’a aucun droit ce qui renforce la sensation que cet outil est destiné à être utilisé par des spécialistes uniquement et ce qui relance l’intérêt de choisir un hébergeur SAAS qui ajoute cette fonctionnalité. Cloudera et Hortonworks ont l’air d’être compatibles SAML mais il semblerait que la configuration ne soit pas assistée et qu’il faille sortir la clé de douze pour que vos utilisateurs n’aient pas un autre mot de passe à retenir ou à noter sur un post-it collé sur l’écran.
7. Logs et alertes
   Par défaut les logs de Hive et Spark sont produits et stockés sur les clusters d’exécution, les logs sont donc éparpillés sur toutes les machines qui exécutent les tâches. Comment lire ces logs? Si on n’a pas accès aux dossiers. Cela dit il est possible de paramétrer chaque configuration de chaque cluster pour écrire ces logs sur un serveur centralisé. Nous vous conseillons de passer par des solutions managées qui proposent cela nativement.
8. Coût et gestion
   Ses solutions ont un coût d’accès très cher si on veut les mettre en place soit même car il faut avoir beaucoup de serveurs, des experts et passer beaucoup de temps d’installation avant qu’elles soient opérationnelles. Heureusement il existe des fournisseurs de services qui permettent d’utiliser des solutions toutes prêtes à l’utilisation (temps d’exécution du traitement) comme Azure, GCP, cloudera (Attention il y a un droit d’accès sur ce dernier, ) et bien que les secondes semblent chères elles sont finalement très accessibles pour traiter des tables de données gigantesques car elles sont ultra rapides et donc ne tourneront pas pendant des heures. Nous déconseillons quand même leur utilisation dans le cas de jointures entre des grosses tables.
9. Fin d’utilisation
   Il est possible d’extraire les données d’une table ou le résultat des requêtes directement en CSV. De plus il est possible d’exporter des tables en format AVRO. Bref il n’y a aucun problème pour récupérer les données de ces solutions.
10. Documentation et API
    Les documentations sont claires avec des exemples. Elles sont disponibles et mises à jour régulièrement sur le site d’apache qui est extrêmement réactif. Les API n’ont pas l’air très développées en tout cas la documentation associée n’est pas à la hauteur.
    

Les notes vont de 0 à 5 (5 étant la meilleure)

	1.1 B I G D A T A	1.2 DWH	1.3 R E P O R T	1.4 D A T A L A K	1.5 A P P S	2 U T I L I S A	3 F O N C T +	4 A D M	5 E X P E R T	6 D R O I T S	7 L O G S	8 C O U T	9 F I N	10 D O C
Hive on premise	5	2	3	4		1		0,5	2	3	0.5	0,5	4,5	3
Spark on premise	5	2	3	4		1		0,5	2	0	0.5	0,5	4,5	3
Spark Azure	5	2	3	4		1		4	2	2,5	3	4	4,5	3
GCP	5	2	3	4		1		4	2	2,5	3	4	4,5	3
Cloudera	5	2	3	4		1		4,5	2	2	3	2,5	4,5	3
Hortonworks	5	2	3	4		1		4,5	2	2	3		4,5	3

Conclusion : Ces solutions font très fortes sur le BigData composées d’une seule table. Cela fonctionne très bien pour des applications simples. Ils permettent aussi de faire des traitements sur un jeu de données plat très volumineux en un temps record cette solution est très appréciée des datascientists de la première heure puisque cette solution open source est sortie il y a longtemps et que cela leur a permis de gagner du temps dans leur travail à l’époque.

Plan :
1 introduction

2 SGBDR classiques

3 HADOOP (MS Datalake, Hortonworks, Cloudera, Google Dataproc)

4 MongoDb

5 SnowFlake

6 BigQuery
7 Redshift

8 SAP Hana
9 CloudSpanner
10 conclusion