Como escolher um Distribuição Hadoop

distribuições Hadoop Commercial oferecem várias combinações de componentes de código aberto da Apache Software Foundation e em outros lugares - a ideia é que os vários componentes foram integrados em um único produto, poupando-lhe o esforço de ter de montar o seu próprio conjunto de componentes integrados. Além de software de fonte aberta, os fornecedores costumam oferecer software proprietário, apoio, serviços de consultoria e treinamento.

Como você ir sobre como escolher uma distribuição Hadoop das inúmeras opções que estão disponíveis? Quando se trata de criação de seu próprio ambiente, você é o único que tem que escolher, e essa escolha deve ser baseada em um conjunto de critérios destinados a ajudá-lo a tomar a melhor decisão possível.

Nem todas as distribuições Hadoop tem os mesmos componentes (embora todos eles têm capacidades centrais do Hadoop), e não todos os componentes em uma distribuição em particular são compatíveis com outras distribuições.

Os critérios para escolher a distribuição mais adequada pode ser articulada como este conjunto de questões importantes:

  • O que você quer alcançar com o Hadoop?

  • Como você pode usar o Hadoop para obter insights de negócios?

  • Que problemas de negócios que você quer resolver?

  • O que os dados serão analisados?

  • Você está disposto a usar componentes proprietários, ou você prefere ofertas de código aberto?

  • É a infra-estrutura Hadoop que você está considerando flexível o suficiente para todos os seus casos de uso?

  • Que existente ferramentas que você vai querer integrar-se com Hadoop?

  • Será que os seus administradores precisam de ferramentas de gestão? (Distribuição do núcleo do Hadoop não inclui ferramentas administrativas.)

  • Será que a oferta que você escolher lhe permitem mover-se para um produto diferente, sem obstáculos, tais como vendor lock-in? (Código do aplicativo que não é transferível para outras distribuições ou dados armazenados em formatos proprietários representam bons exemplos de lock-in.)

  • Será que a distribuição está a considerar atender às suas necessidades futuras, na medida em que você é capaz de antecipar essas necessidades?

Uma abordagem para distribuições comparando é criar um matriz de recurso - uma tabela que detalha as especificações e características de cada distribuição que você está pensando. Sua escolha pode depender do conjunto de características e especificações que melhor atende às exigências em torno de seus problemas de negócios específicos.

Por outro lado, se suas exigências incluem prototipagem e experimentação, a escolha do Apache última distribuição oficial Hadoop pode vir a ser a melhor abordagem. Os lançamentos mais recentes certamente têm os mais novos recursos mais interessantes, mas se você quer estabilidade você não quer emoção. Para a estabilidade, procure um ramo de versão mais antiga que tem sido disponível o tempo suficiente para ter algumas versões incrementais (estes normalmente incluem correções de bugs e recursos menores).

Sempre que você pensa sobre distribuições Hadoop de código aberto, dê um momento de reflexão (ou talvez pensamento de muitos momentos) para o conceito de fidelidade de código aberto - o grau em que uma distribuição particular, é compatível com os componentes abertos dos quais ele depende. Alta fidelidade facilita a integração com outros produtos que são projetados para serem compatíveis com os componentes de código aberto. Baixa fidelidade? Não muito.

A abordagem de fonte aberta para o próprio desenvolvimento de software é uma parte importante da sua Hadoop planos porque promove a compatibilidade com uma série de ferramentas de terceiros que você pode aproveitar em sua própria implementação Hadoop. A abordagem de fonte aberta também permite que o envolvimento com a comunidade Apache Hadoop, que lhe dá, por sua vez, a oportunidade de tocar em uma piscina mais profunda de habilidades e inovação para enriquecer a sua experiência Hadoop.

Porque Hadoop é um ecossistema em rápido crescimento, algumas partes continuam a amadurecer como a comunidade se desenvolve ferramentas para atender às demandas da indústria. Um aspecto desta evolução é conhecido como Backporting, onde você aplicar uma nova modificação do software ou patch para uma versão do software que é mais velho do que a versão a que o patch é aplicável.

Um exemplo é failover NameNode: Esta capacidade é uma parte do Hadoop 2, mas foi portado (na sua forma beta) por um número de distribuições em suas ofertas baseadas em Hadoop-1 para tanto quanto um ano antes Hadoop 2 tornou-se geralmente disponíveis.

Nem toda a distribuição envolve ativamente em backporting novo conteúdo com a mesma intensidade, embora a maioria fazê-lo para itens como correções de bugs. Se você quiser uma licença de produção de tecnologia de ponta, esta é certamente uma opção-de estabilidade, no entanto, não é uma boa ideia.

A maioria das distribuições Hadoop incluem código proprietário de algum tipo, que muitas vezes vem sob a forma de instaladores e um conjunto de ferramentas de gestão. Essas distribuições geralmente emergem de diferentes modelos de negócios.

Por exemplo, um modelo de negócio pode ser resumido da seguinte forma: # 147 Estabelecer-se como um líder de código aberto e pioneiro, o mercado de sua empresa como tendo a melhor experiência, e vender essa experiência como um serviço. # 148- Red Hat, Inc. é um exemplo de um fornecedor que usa esse modelo.

Em contraste com esta abordagem, o e-estender abraço modelo de negócio tem vendedores construindo capacidades que estendem os recursos do software de fonte aberta. MapR e IBM, que ambos oferecem sistemas de arquivos alternativos para o Hadoop Distributed File System (HDFS), são bons exemplos.

As pessoas às vezes erroneamente jogar a # 147-garfo # 148- rótulo estas inovações, fazendo uso do jargão usado por programadores de software para descrever situações em que alguém toma uma cópia de um programa de código aberto como o ponto de partida para o seu próprio desenvolvimento (independente).

Os sistemas de arquivos alternativos fornecidos pela MapR e IBM são completamente diferentes sistemas de arquivos, e não um fork do código aberto HDFS. Ambas as empresas permitem que seus clientes para escolher seu sistema de arquivos distribuídos proprietárias ou HDFS. No entanto, nesta abordagem, a compatibilidade é crítico, e o fornecedor deve manter-se atualizado com interfaces em evolução. Os clientes precisam saber que os fornecedores podem ser invocados para sustentar suas extensões.

menu