Con Hadoop 2.0 y YARN, Hadoop supuestamente ya no está vinculado solo a soluciones de reducción de mapas. Con ese avance, ¿cuáles son los casos de uso para Apache Spark vs Hadoop teniendo en cuenta que ambos se sientan encima de HDFS? He leído la documentación de introducción de Spark, pero tengo curiosidad por saber si alguien ha encontrado un problema que fuera más eficiente y fácil de resolver con Spark en comparación con Hadoop.
Respuestas:
Hadoop significa HDFS, YARN, MapReduce y muchas otras cosas. ¿Te refieres a Spark vs MapReduce ? Porque Spark se ejecuta en / con Hadoop, que es más bien el punto.
La razón principal para usar Spark es la velocidad, y esto viene del hecho de que su ejecución puede mantener los datos en la memoria entre etapas en lugar de persistir siempre en HDFS después de un Mapa o Reducir. Esta ventaja es muy pronunciada para los cálculos iterativos, que tienen decenas de etapas, cada una de las cuales toca los mismos datos. Aquí es donde las cosas podrían ser "100x" más rápido. Para trabajos simples, de un solo paso tipo ETL para los que se diseñó MapReduce, en general no es más rápido.
Otra razón para usar Spark es su mejor lenguaje de alto nivel en comparación con MapReduce. Proporciona una vista funcional similar a la programación que imita Scala, que es mucho mejor que escribir código MapReduce. (Aunque debe usar Scala o adoptar las API de Java o Python un poco menos desarrolladas para Spark). Crunch and Cascading ya proporcionan una abstracción similar en la parte superior de MapReduce, pero esta sigue siendo un área donde Spark es agradable.
Finalmente, Spark tiene subproyectos aún jóvenes pero prometedores para ML, análisis de gráficos y transmisión, que exponen una API similar y coherente. Con MapReduce, tendrías que recurrir a varios proyectos diferentes para esto (Mahout, Giraph, Storm). Es bueno tenerlo en un paquete, aunque aún no esté 'horneado'.
¿Por qué no usarías Spark? parafraseándome a mí mismo:
No estoy seguro sobre el YARN, pero creo que Spark hace una diferencia real en comparación con Hadoop (anunciado como 100 veces más rápido) si los datos pueden caber bien en la memoria de los nodos computacionales. Simplemente porque evita el acceso al disco duro. Si los datos no se ajustan a la memoria, todavía hay algo de ganancia debido al almacenamiento en búfer.
Buena información @Sean Owen. Me gustaría agregar uno adicional. Spark puede ayudar a construir canalizaciones de datos unificados en la arquitectura Lambda que aborden las capas Batch y Streaming con la capacidad de escribir en la capa de servicio común. Es una gran ventaja reutilizar la lógica entre lote y Streaming. También los algoritmos Streaming K-Means en Spark1.3 son una ventaja adicional para ML, aparte de una excelente supervisión del trabajo y visualizaciones de procesos en 1.4.
Sería justo comparar Spark con MapReduce , el marco de procesamiento de Hadoop. En la mayoría de los casos, Spark puede superar a MapReduce. El primero permite el procesamiento de datos en memoria, lo que hace posible procesar datos hasta 100 veces más rápido. Por esta razón, Spark es una opción preferida si necesita información rápida, por ejemplo, si necesita
Sin embargo, MapReduce es bueno para procesar conjuntos de datos realmente enormes (si está bien con el tiempo requerido para el procesamiento). Además, es una solución más económica, ya que MapReduce lee / escribe en un disco. Y los discos son generalmente más baratos que la memoria.
El aprendizaje automático es un buen ejemplo de un tipo de problema en el que las soluciones basadas en Spark están a años luz de las soluciones basadas en mapreduce, a pesar de la corta edad de la chispa en hilo.