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)
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:
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].
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 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.
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 ;-)
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:
Possíveis fornecedores:
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ê 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.
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:
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!
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.
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.
[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