Trocas entre Storm e Hadoop (MapReduce)

Alguém pode me informar sobre as compensações envolvidas na escolha entre o Storm e o MapReduce no Hadoop Cluster para processamento de dados? Obviamente, além do óbvio, o Hadoop (processamento via MapReduce em um Hadoop Cluster) é um sistema de processamento em lote e o Storm é um sistema de processamento em tempo real.

Eu trabalhei um pouco com o Hadoop Eco System, mas não trabalhei com o Storm. Depois de analisar várias apresentações e artigos, ainda não consegui encontrar uma resposta satisfatória e abrangente.

Nota: O termo tradeoff aqui não se destina a comparar com coisas semelhantes. Pretende-se representar as consequências de obter resultados em tempo real ausentes de um sistema de processamento em lote.

MapReduce : uma estrutura computacional distribuída tolerante a falhas. O MapReduce permite que você opere em grandes quantidades de dados - com muito trabalho para evitar falhas devido ao hardware. O MapReduce é uma má escolha para calcular resultados em tempo real porque é lento. (Um trabalho típico do MapReduce leva da ordem de minutos ou horas, não microssegundos)

Um trabalho MapReduce pega um arquivo (ou algum armazenamento de dados) como entrada e grava um arquivo de resultados. Se você deseja que esses resultados estejam disponíveis para um aplicativo, é de sua responsabilidade colocar esses dados em um local acessível. Provavelmente é lento e haverá um atraso entre os valores que você pode exibir e os valores que representam seu sistema em seu estado atual.

Uma distinção importante a ser feita ao considerar o uso do MapReduce na construção de sistemas em tempo real é treinar seu modelo e aplicá-lo. Se você acha que os parâmetros do seu modelo não mudam rapidamente, você pode ajustá-los com o MapReduce e, em seguida, ter um mecanismo para acessar esses parâmetros de pré-ajuste quando desejar aplicar seu modelo.

Storm : um sistema computacional de streaming em tempo real. Storm é uma estrutura on-line, significando, nesse sentido, um serviço que interage com um aplicativo em execução. Ao contrário do MapReduce, ele recebe pequenos dados (não um arquivo inteiro) à medida que são processados ​​em seu aplicativo. Você define um DAG de operações para executar nos dados. Um caso de uso comum e simples do Storm é rastrear contadores e usar essas informações para preencher um painel em tempo real.

O Storm não tem nada (necessariamente) a ver com a persistência dos seus dados. Aqui, o streaming é outra maneira de dizer mantendo as informações importantes e jogando o resto fora. Na realidade, você provavelmente tem uma camada de persistência em seu aplicativo que já registrou os dados e, portanto, essa é uma separação boa e justificada de preocupações.

Se você quiser saber mais ... Se você gostaria de aprender mais sobre sistemas em tempo real que ajustam os parâmetros ao MR e aplicar os modelos de uma maneira diferente, aqui estão os slides de uma palestra que dei sobre a criação de mecanismos de recomendação em tempo real no HBase.

Um excelente artigo que combina a contagem e a persistência em tempo real de uma maneira interessante é a Personalização do Google Notícias: Filtragem colaborativa on-line escalável

Outro casamento interessante entre MR e Storm é o SummingBird . O Summingbird permite definir operações de análise de dados que podem ser aplicadas via Storm ou MR.

É como perguntar sobre as trocas entre a frigideira e a gaveta de talheres. Na verdade, não são duas coisas que você compara. Você pode usá-los juntos como parte de um projeto maior.

O Hadoop em si não é uma coisa, mas um nome para uma federação de serviços, como HDFS, Hive, HBase, MapReduce, etc. Storm é algo que você usa em alguns desses serviços, como HDFS ou HBase. É uma estrutura de processamento de fluxo. Existem outros no ecossistema estendido do Hadoop, como o Spark Streaming.

Quando você escolheria uma estrutura de processamento de fluxo? quando você precisar reagir a novos dados quase em tempo real. Se você precisar desse tipo de ferramenta, implante esse tipo de ferramenta também.