Com o Hadoop 2.0 e o YARN, o Hadoop não está mais vinculado apenas às soluções de redução de mapa. Com esse avanço, quais são os casos de uso do Apache Spark vs Hadoop, considerando que ambos estão no topo do HDFS? Eu li a documentação de introdução do Spark, mas estou curioso para saber se alguém encontrou um problema mais eficiente e fácil de resolver com o Spark em comparação com o Hadoop.
Respostas:
Hadoop significa HDFS, YARN, MapReduce e muitas outras coisas. Você quer dizer Spark vs MapReduce ? Porque o Spark é executado no / com Hadoop, que é o ponto.
O principal motivo para usar o Spark é a velocidade, e isso vem do fato de que sua execução pode manter os dados na memória entre os estágios, em vez de sempre persistir no HDFS após um Mapa ou Redução. Essa vantagem é muito acentuada para cálculos iterativos, que têm dezenas de estágios, cada um dos quais tocando os mesmos dados. É aqui que as coisas podem ser "100x" mais rápidas. Para trabalhos simples de ETL de uma passagem para os quais o MapReduce foi projetado, geralmente não é mais rápido.
Outro motivo para usar o Spark é a linguagem de alto nível mais agradável em comparação com o MapReduce. Ele fornece uma visão funcional de programação que imita o Scala, que é muito melhor do que escrever código MapReduce. (Embora você precise usar o Scala ou adotar as APIs Java ou Python um pouco menos desenvolvidas para o Spark). O Crunch e o Cascading já fornecem uma abstração semelhante sobre o MapReduce, mas ainda é uma área em que o Spark é agradável.
Finalmente, o Spark tem subprojetos ainda jovens, mas promissores para ML, análise de gráficos e streaming, que expõem uma API coerente e semelhante. Com o MapReduce, você teria que recorrer a vários outros projetos para isso (Mahout, Giraph, Storm). É bom tê-lo em um pacote, embora ainda não esteja "cozido".
Por que você não usaria o Spark? Parafraseando- me:
Não tenho certeza sobre o YARN, mas acho que o Spark faz uma diferença real em comparação ao Hadoop (anunciado 100 vezes mais rápido) se os dados puderem se encaixar perfeitamente na memória dos nós computacionais. Simplesmente porque evita o acesso ao disco rígido. Se os dados não couberem na memória, ainda haverá algum ganho por causa do buffer.
Boas informações @Sean Owen. Gostaria de adicionar um adicional. O Spark pode ajudar a criar pipelines de dados unificados na arquitetura Lambda, abordando as camadas Lote e Streaming, com a capacidade de gravar na camada de veiculação comum. É uma enorme vantagem reutilizar a lógica entre lote e Streaming. Os algoritmos K-Means de streaming no Spark1.3 também são uma vantagem adicional ao ML, além do excelente monitoramento de tarefas e visualizações de processos na versão 1.4.
Seria justo comparar o Spark com a estrutura de processamento do MapReduce - Hadoop. Na maioria dos casos, o Spark pode superar o MapReduce. O primeiro permite o processamento de dados na memória, o que torna possível processar dados até 100 vezes mais rápido. Por esse motivo, o Spark é uma opção preferida se você precisar de informações rapidamente, por exemplo, se precisar
No entanto, o MapReduce é bom no processamento de conjuntos de dados realmente grandes (se você estiver bem com o tempo necessário para o processamento). Além disso, é uma solução mais econômica, pois o MapReduce lê / grava em um disco. E os discos geralmente são mais baratos que a memória.
O aprendizado de máquina é um bom exemplo de um tipo de problema em que as soluções baseadas em Spark estão anos-luz à frente das soluções baseadas em mapreduce, apesar da tenra idade do faísca no fio.