Hadoop na Nuvem

Os provedores de soluções Hadoop nos ambientes de nuvem pública ou privada evoluíram. Porém, algumas questões devem ser analisadas. O Hadoop é adequado para ser utilizado nestes ambientes? Estes pacotes de serviço são confiáveis? Estes serviços são úteis? Quais são os fornecedores? Neste artigo, apresentarei uma visão geral sobre a utilização do Hadoop na Nuvem.

(Nota: por nuvem privada, neste artigo, quero dizer nuvem privada virtual, fora do ambiente da empresa)

Mas o Hadoop não foi projetado para rodar em máquinas físicas?

Sim. Mais precisamente, os seus dois principais componentes, o HDFS, para armazenamento dos dados, e o Map-Reduce, responsável pelo processamento, foram pensados ​​para ambientes físicos muito específicos, pelas seguintes razões:

1. Novas restrições técnicas apareceram. Hoje o problema já não é a potência da CPU ou a capacidade do disco. Há parâmetros que não crescem tão rápido quanto os outros regidos pela Lei de Moore: são as latências de I/O, do disco e da rede. Por 100 reais a cada 18 meses, tem-se o dobro do espaço em disco, porém o crescimento do disco leva à necessidade de mais tempo para acessar este volume de dados. Uma solução é a paralelização do acesso. Tenta-se sempre paralelizar o canal CPU-disco. É por isso que recomenda-se a configuração do Hadoop com unidades internas em JBOD e um disco para cada núcleo do processador (ou um pouco mais). Também distribui-se o processamento em muitas máquinas para paralelizar a rede.
2. A lógica dos custos das configurações de hardware mudou. Em datacenters utilizados pelos Gigantes da Web (em francês), o uso de várias máquinas de baixo custo é mais eficiente do que máquinas high-end com várias redundâncias de hardware, mesmo considerando uma replicação de dados tripla. É por isso que HDFS (e antes dele o Google GFS) foi projetado para rodar em clusters com um grande número de nós não confiáveis ​​[1], replicando os dados de forma inteligente em diferentes máquinas, e em diferentes racks, de modo que uma falha em um determinado hardware não impacte sobre as demais cópias.

Estes dois elementos de design (discos internos e estratégia de replicação de dados baseadas em topologia física) são difíceis ou impossíveis de se reproduzir em um ambiente virtualizado com infraestrutura SAN. Em um ambiente de nuvem, é ainda pior, pois se tem pouca ou nenhuma informação sobre a topologia da infraestrutura.

Existem casos em que um ambiente virtual seria viável? Sim. Levando-se em conta estas limitações, isto é, tendo atenção sobre o I/O e as estratégias de replicação de dados, o Hadoop funciona bem em infraestrutura SAN compartilhada e em clusters de pequena ou média dimensões [2].

O que podemos esperar em termos de performance?

A VMWare fez um estudo do impacto da virtualização na performance dos processamentos. Em um benchmark, foram analisadas características básicas: CPU-bound, disk-bound, ou o uso intensivo de rede [3]. Os resultados são encorajadores e até mesmo surpreendentes, já que eles variam de uma diminuição de 4% em alguns processamentos, a uma melhora de até 14% de outros. Esta melhoria surpreendente deve-se à otimização do uso de CPU pelo hipervisor, a melhor estratégia em algumas situações específicas.

Deve-se notar que certas funções de gerenciamento de desempenho do cluster (speculative execution) foram desativadas, por serem claramente incompatíveis com o trabalho do hypervisor.

De qualquer maneira estes trabalhos básicos não representam necessariamente os processamentos encontrados no dia-a-dia. Uma vez na nuvem, deve-se considerar sempre uma performance um pouco menor (que você pode compensar através da alocação de mais máquinas), ou variável entre uma e outra execução [2] .

A relação preço / desempenho é boa?

A Accenture fez recentemente um estudo muito interessante [4] que compara o TCO (Total Cost of Ownership) de máquinas físicas e de uma configuração na nuvem (AWS). Esta comparação foi realizada com processamentos complexos e representativos de um projeto de big-data.

A conclusão deste estudo é que a relação preço / desempenho é melhor na AWS. Este estudo é questionável em alguns pontos -- como a dependência entre o resultado e várias hipóteses numéricas estabelecidas pelos autores; e a configuração subdimensionada do hardware escolhido -- apesar disso, pode-se concluir que as duas configurações tem a relação preço / desempenho na mesma ordem de grandeza.

A segunda conclusão deste estudo é que o trabalho de otimização do processamento é essencial, que no caso deles, trouxe um ganho na ordem de 8 vezes. Vale mais a pena usar a sua energia para melhorar a estrutura e a performance do processamento, do que gastar tempo buscando um desconto de 20% no preço do fornecedor!

Além do custo do cluster, outros custos relacionados com a nuvem devem ser considerados, em particular, os custos relacionados à transferência de dados para dentro e para fora da nuvem. A Apache recomenda cautela quanto à confiabilidade do armazenamento HDFS virtualizado na nuvem, e recomenda considerar o uso de um armazenamento auxiliar (tipo AWS S3, Azure Blob, etc.) [2]. Então, existirão outros custos extras.

Quais são as opções de pacotes de serviço na nuvem?

Existem várias ofertas de pacotes de serviço com características bastante diferentes, por isso proponho a seguinte classificação::

Nota: eu listei aqui provedores que oferecem produtos em nuvem pública, suficientemente claros e documentados, para começar a usar assim que você terminar de ler este artigo. Eu não avaliei fornecedores que oferecem somente nuvem privada (que exigem trabalhar com suas equipes), e fornecedores que estão mais para marketing de big-data do que para ofertas plug'n'play ;-)

Categoria IaaS

Nesta categoria, você tem produtos IaaS de prateleira, distribuições de Hadoop pré-montadas e prontas, na forma de imagens para utilizar nas suas VMs.

Você escolhe o tamanho da máquina que precisa, e instala a imagem fornecida. O resultado é um cluster de processamento + armazenamento, típico de Hadoop.

Minha opinião:

• Se é uma oferta de prateleira, então presume-se que você vá economizar tempo na configuração do cluster, e evitar algumas armadilhas de desempenho (isso merece um "benchmark", e poderá ser objecto de um artigo futuro).
• Pode-se começar com as imagens de VM fornecidas, e personalizá-las adicionando uma ou outra lib.
• Uma desvantagem é que, copmparando com próxima categoria, esta não é muito plug’n’play. Você tem que gerenciar por si mesmo name-nodes, task-trackers, etc.
• Outra restrição é que você não pode desligar o cluster para reduzir custos, já que os nós têm função dupla: processamento e armazenamento. Para reduzir os custos, é necessário remover máquinas, o que implica em mover antes os dados para outro armazenamento.

Possíveis fornecedores:

• Rackspace + Hortonworks (informação de configuração)
• Joyent + Hortonworks (informação de configuração)
• GoGrid + Cloudera CDH

Interessante notar que as máquinas do Rackspace parecem um pouco pequenas para o contexto Hadoop, tornando a oferta pouco competitiva. Alternativamente você pode escolher o provedor de IaaS e a distribuição Hadoop separadamente, o que eu recomendo apenas nos seguintes casos:

• você quer usar um provedor de IaaS específico (porque você já tem uma nuvem privada, ou você tem restrições regulamentares, como, por exemplo, a localização dos dados)
• você quer usar uma distribuição muito recente do Hadoop, ainda em versão beta, ou mesmo personalizada por você (neste caso não há nada para você neste artigo ;-)

Você corre o risco de ter que gastar muito tempo ajustando a distribuição e as configurações do cluster para essa nuvem, e para obter um bom desempenho.

Categoria "Hadoop-as-a-Service"

Aqui temos as soluções muito mais empacotadas e automatizadas. Não há necessidade de se gerenciar name-nodes, task-trackers & cia. Boa parte do trabalho já está feito, de forma bem transparente.

Opção 1: Você quer um cluster Hadoop "clássico" processamento + armazenamento. Pacotes:

• Azure HDInsight , com base na distribuição Hortonworks (descrição neste artigo - em francês)
• AWS Elastic -Map- Reduce, usando a distribuição MapR (versão M3 , M5 , M7 ou à sua escolha)
• VirtualScale Datazoomr na Cloudera, oferta recente, em crescimento na França.

Neste caso, você terá um cluster completo, com alguma flexibilidade, especialmente para o uso de dados de outro armazenamento (AWS S3, Azure Blob Storage), ou ainda para instanciar nós de computação (workers sem armazenamento).

Opção 2: Indo mais longe nesta abordagem PaaS, deveria ser possível utilizar apenas componentes específicos do universo Hadoop, que seriam cobrados pela utilização.

Por exemplo, use apenas o Map-Reduce num cluster transitório. De zero a dezenas de nós em questão de minutos, sem armazenamento persistente no HDFS. Com a oferta AWS Elastic Map-Reduce e sua próprio distribuição Hadoop ("standard Amazon"), ou com a distribuição do desafiante Joyent Manta, o uso típico é armazenar dados em um object-store (S3 ou Manta) e depois instanciar os nós de processamento Map-Reduce para um bloco de trabalho. Os dados são lidos diretamente do object-store, ou podem ser copiados para armazenamento local (HDFS) . No final do processamento, o resultado é retornado no object-store e os nós são removidos. Aqui você vai pagar de um lado o armazenamento (volume e transferências), e do outro lado o processamento, em tempo consumido de CPU.

Outro exemplo: usar somente o recurso de consulta SQL para volumes gigantes. A Google oferece o seu famoso Dremel - que a comunidade Hadoop está tentando recriar - no pacote Google BigQuery. Você pode injetar os dados em fluxo, e fazer uma análise interativa. Você paga para o armazenamento, e o volume manipulado nas suas análises.

Um último exemplo, ir para um armazenamento NoSQL e manipular os dados em operações de Map-Reduce. Ofertas como AWS e MapR, ou ainda InfoChimps, permitem construir esse tipo de arquitetura.

Em suma: Nesta categoria "Hadoop as a Service", há uma grande flexibilidade, e, dependendo de suas necessidades, muitos pacotes diferentes. Os preços são muito difíceis de comparar (para se convencer disto basta olhar para as tabelas de preços da AWS). O mercado está à pleno vapor!

Categoria "Analytics-as-a-Service"

Para completar este panorama de serviços na nuvem, devemos mencionar os pacotes de prateleira de serviços de análise. Você fornece os dados, e pode consumir os resultados dos algoritmos de análise, ou de machine learning.

Como exemplos temos o Intel Cloud Services que fornece um mecanismo de recomendação de itens personalizados, alimentado pelos dados que você fornece, ou seja, pelos dados de avaliação desses itens pelos usuários (compras ou opiniões); ou ainda o KXEN, que oferece serviços de apoio à venda integrados aos serviços dos aplicativos Salesforce.

No entanto, isso está além do escopo deste artigo, já que nestes casos a tecnologia Hadoop não é visível. Ela está escondida atrás das APIs, e totalmente gerenciada pelo provedor. Mais uma vez, o mercado ainda é muito jovem, mas já oferece pacotes ricos e variados.

Conclusão

Algumas empresas possuem restrições de hospedagem (espaço disponível, custos de provisionamento, habilidade) que não lhes permitem configurar rapidamente uma grande quantidade de máquinas necessárias para o Hadoop (hardware commodity, JBOD) para construir um cluster de pequeno ou médio porte.

Em outros casos, temos projetos de inovação para os quais não sabemos estimar com precisão o tamanho do cluster que será necessário, ou mesmo qual será a sua taxa de utilização.

Como vimos neste artigo, criar um cluster Hadoop na nuvem faz muito sentido, e as tecnologias oferecidas por esses provedores são confiáveis e estão ganhando mais maturidade. Tome cuidado com a questão da durabilidade dos dados, caso os dados não estejam presentes na nuvem, e com a performance de I/O do armazenamento na nuvem.

O ganho imediato é definitivamente a agilidade para começar seu projeto. Você pode começar amanhã! Haverá tempo para racionalizar e internalizar mais tarde, se isso fizer sentido, mas você já terá uma idéia melhor da sua real necessidade com o Hadoop.

Referências

[1] Apache Wiki - Virtual Hadoop

[2] VMWare - Benefts of Virtualizing Hadoop

[3] VMWare - Hadoop Performance vSphere5

[4] Accenture - Hadoop Deployment Comparison Study

Tradução e revisão : Sergio Fernandes, Vitor Monteiro Puente