Como escolher uma 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 idéia é que os vários componentes foram integrados em um único produto, poupando-lhe o esforço de ter que 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 adequado 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ócio que você quer resolver?
Que 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ê deseja integrar 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 você está pensando em satisfazer 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 distribuição mais recente 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ê quiser a estabilidade que você não quer emoção. Para a estabilidade, procure um ramo versão mais antiga que tem sido disponível 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, dar um momento de reflexão (ou talvez o 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 de código aberto dos quais 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 código aberto para o próprio desenvolvimento de software é uma parte importante da sua Hadoop planeja 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 profunda piscina 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 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 backported (na sua forma beta) por um número de distribuições em suas ofertas baseados 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 idéia.

A maioria das distribuições Hadoop incluem código proprietário de algum tipo, que muitas vezes vem na 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 resumida desta forma: “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” 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 fornecedores construindo capacidades que estendem as capacidades 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 o rótulo de “fork” 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 de propriedade ou HDFS. No entanto, nesta abordagem, a compatibilidade é crítica, e o fornecedor deve manter-se atualizado com interfaces em evolução. Os clientes precisam saber que os fornecedores podem ser invocadas para sustentar suas extensões.