Hortonworks vs cloudera 2016

Não vou responder a "qual distribuição", porque depende de olhar para todas as suas necessidades.

Em termos de Spark vs. Storm (por volta do final de 2014). O Spark é muito empolgante, oferece a promessa de usar o mesmo código para lote e streaming, promessa de processamento de gráficos também. Eu esperaria ver grandes coisas do Spark no futuro. Chalaça pretendida.

Storm é mais maduro e tem muito mais implantações de produção em seu nome e mais empresas estão apostando seus negócios nisso. Isso pode ou não mudar nos próximos 1-2 anos.

Escolher um sobre o outro depende novamente de seus requisitos específicos.

Pessoalmente, eu começaria com o Hortonworks, a menos que exista um recurso atraente (para você) oferecido pelo Cloudera ou pelo MapR que o Hortonworks não oferece.

Storm e Spark têm um alto grau de sobreposição. O Storm possui uma verdadeira API de streaming (foi projetada para atuar em uma única tupla), enquanto o Spark é um sistema de micr lote. Storm é independente de idioma e o Spark é restrito a Java, Python e Scala. O Spark é uma API de nível superior ao Storm, possui mais recursos e (sem dúvida) uma curva de aprendizado mais superficial.

A distribuição Hortonworks é a única distribuição executada nos servidores Linux e Windows e todos os componentes são de código aberto. Se você tiver servidores Linux e Windows, poderá executar o Hortonworks em qualquer plataforma.

O Cloudera é tão bom quanto o Hortonworks, mas alguns componentes como o Cloudera Manager não são de código aberto; portanto, se você não mina, o Cloudera é igualmente bom.

O MapR usa DFRs do MapR e não o HDFS padrão. O MapR alega que eles têm melhor segurança incorporada em sua distribuição. Portanto, se você tiver as principais preocupações de segurança, consulte o MapR.

Leia esta apresentação do Yahoo:

Yahoo compara Storm e Spark

No geral, direi que você deve examinar e tentar cada uma das distribuições e tomar sua decisão com base no que deseja realizar.

Sou funcionário da Cloudera e acho que você sabe qual seria minha resposta. Basta dizer que, de acordo com todas as métricas externas, a plataforma da Cloudera é a mais popular do mundo e a plataforma na qual mais clientes executam a produção do que qualquer outra alternativa - e isso por boas razões. Faça sua própria pesquisa!

Quanto ao Storm vs Spark Streaming especificamente: lembre-se de que o Spark oferece uma API única para processamento de dados e processamento de fluxo, enquanto que com o Storm, há outra API incremental envolvida. A capacidade de consolidar em uma única API sempre que possível é um grande negócio.

Escolha o que deseja, mas não o mapr. Eu explico o porquê:

  1. Um fórum e serviço de suporte ruins quando você precisar.
  2. Mesmo que a academia mapr seja gratuita, o gerenciamento de certificação é péssimo. Eu tive uma experiência ruim com eles: eu me registrei na certificação MCDA no período beta (exibido gratuitamente) quando me registrei, eles mudaram para 50 $. Aceitei e preparei os cursos e os laboratórios. Então, uma equipe de certificação me enviou uma mensagem dizendo que eu deveria passar no exame em 10 dias!
  3. Quando passei, nenhum coração batia com eles. Mesmo com várias mensagens no email oficial, nenhuma resposta.
  4. Recentemente, eles exibiram novamente este exame gratuitamente, então eu me registrei, alguns dias depois de me enviar uma mensagem de desculpas por me remover do registro, porque este exame agora custa 250 $ !!

Bem, isso pode mostrar um spoiler do não profissionalismo deles.

Evitar !

Sou um dos engenheiros de dados do MapR e essa é uma pergunta comum entre os clientes. Como Ted mencionou, a escolha do Hortonworks como a distribuição não oferecerá nenhum benefício específico em comparação com qualquer outra distribuição do Hadoop em termos de compatibilidade com o Storm, pois funciona no MapR da mesma forma que funciona em qualquer outra distribuição. Alguns dos pontos relevantes nesta conversa são sobre a linguagem de programação (ainda que menor), o esforço de codificação e os requisitos do seu aplicativo.

O projeto Storm está maduro em comparação com o streaming de Samza, Malhar (da Datatorrent) ou Spark e suporta uma infinidade de fontes de dados como bico e destino. O Storm não possui inerentemente uma única semântica, mas existem muitas maneiras de implementar isso com o uso do Trident. O Storm processa uma tupla de cada vez, o que pode ser ineficiente, mas é muito flexível, pois permite criar DAG ad-hoc usando bicos e parafusos. O Trident oferece processamento de mensagens transacional, mas com alguma penalidade de desempenho.

O Spark Streaming é o novo garoto no bloco e processa dados em microtestes, assim como o Storm Trident e permite a expressão do fluxo em termos de filtros e funções. Uma grande vantagem do Spark é que o mesmo código pode ser usado para o streaming Spark e Spark, uma vez que o Spark discretiza o fluxo e os envia ao mecanismo de processamento do Spark. A beleza do Spark também está no fato de ser um mecanismo de processamento na memória para que você possa misturar e combinar qualquer outro componente (executando uma junção na tabela, uma das quais é de Cassandra e outra pode ser do Hive usando SparkSQL).

Storm é escrito em Clojure e Java e Spark em Scala. Ambas as plataformas suportam Java 8 e Python, portanto a escolha da linguagem não é uma grande preocupação, mas é um ponto que vale a pena mencionar.

O sistema de arquivos MapR possui vantagens arquitetônicas inerentes que Ted mencionou em sua resposta como NFS, instantâneos, semânticas de gravação e leitura. Em suma, a escolha deve ser baseada nas suas necessidades. O Spark está evoluindo rapidamente e a comunidade de código aberto o adotou em vários projetos. O Hive está sendo portado para o Spark

Hive no Spark - Apache Hive - Apache Software Foundation

e Pig trabalha no Spark e no projeto Spork.

https://github.com/sigmoidanalytics/

spork

Isenção de responsabilidade: trabalho na Hortonworks; no entanto, tento responder da melhor maneira possível, sem usar meu chapéu de marketing

Primeiro, deixe-me dizer a diferença gritante entre Spark e Storm. Embora ambos sejam reivindicados para processar os dados de streaming em tempo real. Mas o Spark processa-o como micro-lotes; Considerando que o Storm processa por mensagem - ou seja, se você pretende processar dados como dados sociais, dados de log, etc., você pode aplicar o CEP (processamento de eventos complexos) por tuplas (por exemplo, cada mensagem social em seu exemplo). O Spark, por outro lado, é bom no processamento de pequenos blocos de dados, por exemplo, se você estiver transmitindo um monte de dados (por exemplo, arquivos enormes de registros médicos, por exemplo).

Então, obviamente, eu diria que, se você usa, o Storm pode se encaixar melhor às suas necessidades.

E, por último, entre as distribuições, achei o Hortonworks mais fácil de levantar e gerenciar o cluster do que outras distribuições (por favor, leve esse comentário com um pouco de sal, pois posso estar um pouco inclinado para o HWX, dada a minha zona de conforto de trabalho em torno desta distribuição mais do que outros)

Obrigado pela A2A.

Na verdade, eu perguntaria por que você precisa de uma distribuição Hadoop se o projeto é apenas processamento de fluxo em tempo real. O Spark é independente de armazenamento e não requer a execução de um sistema Hadoop, e embora eu não esteja tão familiarizado com o Flink, pelo que li no site deles

Apache Flink: Recursos

também não parece que o Hadoop é necessário.

Você também deve verificar a plataforma Bluemix da IBM, que fornece acesso a vários serviços, incluindo Twitter e dados climáticos, HDFS e armazenamento de objetos, além de serviços Watson baseados em cognição.

IBM Bluemix - Plataforma de Desenvolvimento de Aplicativos em Nuvem de Próxima Geração

. (Transparência total - trabalho para a IBM).

Agora, se você precisar de uma abordagem mais ecossistêmica, recomendo uma das distribuições ODPi (Hortonworks, Pivotal ou BigInsights). A distribuição subjacente para todos os três são os mesmos projetos e moeda; portanto, oferece uma opção mais ampla caso você precise adquirir suporte em um momento futuro.

Quanto ao Storm over Spark - o Storm é apenas um streaming, pois o Spark é um mecanismo de processamento de dados mais generalizado. O Flink também é um mecanismo de streaming muito interessante, e eu o veria sobre o Storm. Se você acha que vai fazer mais do que apenas transmitir, vá com o Spark. Se fosse apenas streaming, eu provavelmente ainda usaria o Spark Streaming, pois ele tem um grande apoio na comunidade, mas o Flink chegaria em um segundo próximo. Storm ainda tem atividade, mas não quase o nível que o Spark faz.

Sou um dos mentores do projeto Apache Storm (e colaborador de vários outros) e também sou funcionário do MapR.

Dito isto, a distribuição Hortonworks não oferece vantagens para o Storm. O Storm funciona bem no MapR, por exemplo. O fato de o Spark ser suportado na verdade oferece mais opções, o que é importante, pois ferramentas diferentes têm forças muito diferentes. O Storm já dura um pouco mais, mas há alguns problemas sérios quando você precisa ter quantidades significativas de estado em sua computação de streaming.

Se o seu aplicativo é realmente baseado em streaming em vez de computação em tempo real, o Spark é uma opção muito viável. Você provavelmente deveria conferir o Samza também.

Existem outros aspectos que também devem afetar sua escolha de distribuição. Por exemplo, se você precisar interagir com seu cluster com código legado de qualquer tipo, o MapR pode ser uma escolha muito melhor, pois fornece acesso a arquivos em estilo POSIX em tempo real via NFS, além de ser totalmente compatível com os aplicativos Hadoop.

Em geral, puxar o gatilho em uma decisão de design como essa com base em um único critério não é uma ótima idéia. Isso se aplica ainda mais quando o critério é um tanto ilusório ... para um projeto de pesquisa, você estará pagando pelo suporte?

Você tem a ideia certa. O Storm é a melhor opção para o processamento de fluxo, mas você precisa dar um passo adiante, pois há casos de uso sobrepostos para o Storm vs Spark Streaming.

Ao processar dados de alta velocidade, existem dois casos de uso diferentes;

1. Processamento de Fluxo Distribuído / Processamento de Fluxo de Eventos (ESP) 2. Processamento de Eventos Complexos Distribuídos (CEP)

Para obter mais detalhes sobre o que melhor se adequa ao seu projeto de Big Data, recomendo verificar o seguinte link.

Página no slideshare.net

...

Agora, para responder à sua pergunta sobre em qual das distribuições você deve usar, tudo depende da estratégia em que você acredita.

O MapR fornece uma ótima plataforma, mas possui alguns componentes proprietários (a camada de armazenamento de dados). O mercado já começou a avançar para um modelo de código aberto, então alguns afirmam que sua plataforma pode não ser capaz de inovar tão rapidamente.

A Cloudera possui um modelo de núcleo aberto que é parte de código aberto, parte proprietária. Eles foram os primeiros a comercializar, o que é uma vantagem, proporcionando uma forte presença da mídia. No entanto, você corre o risco de bloquear o fornecedor. Como eles partem do tronco, eles não têm a versão mais recente do Hadoop. Eles também oferecem um teste de 60 dias para sua distribuição, que não parece tão atraente quanto uma distribuição gratuita.

O Hortonworks fornece a única distribuição 100% de código aberto. Essa abordagem aberta é importante por causa da inovação rápida, profunda integração do ecossistema e baixo risco de aprisionamento do fornecedor. O Hortonworks fornece uma arquitetura centralizada construída no YARN. Isso enfatiza seu plano de uso de outros aplicativos no ecossistema, porque o YARN permite uma expansão fácil, pois novos aplicativos herdam serviços compartilhados e recursos de computação podem ser adicionados gradualmente ao cluster existente.

Se você deseja obter algumas informações específicas para seu caso de uso, recomendamos que você se conecte comigo no LinkedIn.

www.linkedin.com/in/jordanferrer/en

Muitas respostas foram dadas. Alguns deles têm mais anos de idade. Então, vamos ver o que mudou da perspectiva de 2016.

Razões para escolher o MapR: Se você deseja ter uma abordagem inovadora e um bom material de treinamento. O MapRFS e o MapRDB também são importantes, no entanto, para alguns casos de uso mais fáceis, talvez você não consiga usar a energia deles. Acessando o site de aprendizado do MapR, eles oferecem muito conteúdo gratuito e de alta qualidade. Trabalhe com ele e obtenha a certificação. De longe, é mais fácil e rápido do que com as outras distribuições (e eu deveria conhecê-lo como sou o Hortonworks Trainer). Um aspecto a ter em mente com o MapR é que, em termos de número de instalações, o MapR ainda é o número 3.

Razões para escolher Cloudera: Eu vejo duas razões. Se você deseja SQL rápido, pode amar o Impala. A outra razão é o Kudu, seu novo sistema de arquivos (mas lembre-se de que o MapR tem um sistema de arquivos melhor por um longo tempo). Pessoalmente, comparo o Hortonworks e o Cloudera de uma maneira que o Hortonworks é o verdadeiro produto de código aberto e o Cloudera nem tanto. Isso também tem algumas vantagens para o Cloudera. Tente instalar o Cloudera a partir da linha de comando e faça o mesmo com a instalação do Hortonworks Ambari. Você tem muito mais opções com o Hortonworks, mas as chances de falhar também são maiores. Uma instalação cloudera via linha de comando é rápida, mas a instalação do Hortonworks via Ambari tem suas armadilhas.

Razão para escolher a Hortonworks: Algumas razões que eu já mencionei nas razões para escolher o argumento Cloudera. Se você é totalmente open source, o Hortonworks é a melhor escolha. Lembre-se de que o Hortonworks tem uma nova abordagem: eles colocam o Ambari como seu aplicativo de interface do usuário universal que, a longo prazo, gerenciará mais clusters e descartam o Hue, que é o padrão para cloudera.

Como você estava perguntando também sobre o processamento de fluxo ... minha resposta é ... esqueça o Storm, esqueça o Spark ... Se você estiver realmente interessado em transmitir, investigue primeiro o Apache Flink.