Avec Hadoop 2.0 et YARN, Hadoop ne serait plus lié uniquement aux solutions de réduction de carte. Avec cet avancement, quels sont les cas d'utilisation d'Apache Spark vs Hadoop considérant que les deux se trouvent au sommet de HDFS? J'ai lu la documentation d'introduction de Spark, mais je suis curieux de savoir si quelqu'un a rencontré un problème plus efficace et plus facile à résoudre avec Spark qu'avec Hadoop.
Réponses:
Hadoop signifie HDFS, YARN, MapReduce et bien d'autres choses. Voulez-vous dire Spark vs MapReduce ? Parce que Spark fonctionne sur / avec Hadoop, ce qui est plutôt le point.
La principale raison d'utiliser Spark est la vitesse, et cela vient du fait que son exécution peut conserver les données en mémoire entre les étapes plutôt que de toujours persister dans HDFS après une carte ou une réduction. Cet avantage est très prononcé pour les calculs itératifs, qui comportent des dizaines d'étages dont chacun touche les mêmes données. C'est là que les choses pourraient être "100x" plus rapides. Pour les travaux simples ETL en un seul passage pour lesquels MapReduce a été conçu, ce n'est généralement pas plus rapide.
Une autre raison d'utiliser Spark est son langage de haut niveau plus agréable que MapReduce. Il fournit une vue fonctionnelle similaire à la programmation qui imite Scala, ce qui est bien plus agréable que d'écrire du code MapReduce. (Bien que vous deviez utiliser Scala ou adopter les API Java ou Python légèrement moins développées pour Spark). Crunch et Cascading fournissent déjà une abstraction similaire au-dessus de MapReduce, mais c'est toujours un domaine où Spark est agréable.
Enfin, Spark propose des sous-projets encore jeunes mais prometteurs pour le ML, l'analyse de graphiques et la diffusion en continu, qui présentent une API similaire et cohérente. Avec MapReduce, vous devrez vous tourner vers plusieurs autres projets différents pour cela (Mahout, Giraph, Storm). C'est agréable de l'avoir dans un seul emballage, bien qu'il ne soit pas encore «cuit».
Pourquoi n'utiliseriez-vous pas Spark? me paraphrasant :
Je ne suis pas sûr du YARN, mais je pense que Spark fait une réelle différence par rapport à Hadoop (annoncé comme 100 fois plus rapide) si les données peuvent parfaitement s'intégrer dans la mémoire des nœuds de calcul. Tout simplement parce qu'il évite l'accès au disque dur. Si les données ne correspondent pas à la mémoire, il y a encore un gain à cause de la mise en mémoire tampon.
Bonne information @Sean Owen. Je voudrais en ajouter un de plus. Spark peut aider à créer des pipelines de données unifiées dans l'architecture Lambda adressant à la fois les couches Batch et Streaming avec une capacité d'écriture sur la couche de service commune. C'est un énorme avantage de réutiliser la logique entre le batch et le streaming. De plus, les algorithmes de streaming K-Means dans Spark1.3 sont un atout supplémentaire pour ML, à part une excellente surveillance des tâches et des visualisations de processus dans 1.4.
Il serait juste de comparer Spark avec MapReduce - le cadre de traitement de Hadoop. Dans la majorité des cas, Spark peut surpasser MapReduce. Le premier permet le traitement des données en mémoire, ce qui permet de traiter les données jusqu'à 100 fois plus rapidement. Pour cette raison, Spark est une option préférée si vous avez besoin d'informations rapidement, par exemple, si vous devez
Cependant, MapReduce est bon pour traiter des ensembles de données vraiment énormes (si vous êtes d'accord avec le temps requis pour le traitement). En outre, c'est une solution plus économique, car MapReduce lit / écrit sur un disque. Et les disques sont généralement moins chers que la mémoire.
L'apprentissage automatique est un bon exemple d'un type de problème où les solutions à base de Spark ont des années-lumière d'avance sur les solutions à base de mapreduce, malgré le jeune âge de l'étincelle sur fil.