Os provedores de soluções Hadoop, atualmente dentre as mais populares tecnologias de Big Data 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? Este artigo apresenta uma visão geral sobre a utilização do Hadoop na Nuvem.
(Nota: por nuvem privada, neste artigo, leia-se nuvem privada virtual, fora do ambiente da empresa)
Mas o Hadoop não foi projetado para rodar em máquinas físicas?
Sim. Especificamente, seus 2 principais componentes, o HDFS para armazenamento dos dados, e o Map-Reduce, responsável pelo processamento foram projetados para serem utilizados em ambientes físicos específicos pelas seguintes razões:
- Surgimento de novas restrições técnicas - Hoje o problema já não é a potência da CPU ou a capacidade do disco. Há um parâmetro que não cresce tão rápido quanto os outros regidos pela Lei de Moore: é a 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.
- Paralelização do acesso - Tenta-se sempre paralelizar o canal CPU/disco. Por esse motivo 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). E, além disso, distribui-se o processamento em muitas máquinas para paralelizar a rede.
- Mudança na lógica dos custos de configurações de hardware - Em datacenters utilizados pelos Gigantes da Web, 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, 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, ou seja, dando a atenção devida 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.
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. Os resultados são encorajadores e até mesmo surpreendentes, já que variam de uma diminuição de 4% em alguns processamentos, a uma melhora de até 14% de outros. Segundo o estudo da VMWare, esta melhoria deve-se à otimização do uso de CPU pelo hipervisor, e a uma 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.
A relação preço / desempenho é boa?
A Accenture fez recentemente um estudo 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 do estudo da Accenture é 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, e 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.
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 distintas, dentre as quais destacam-se:
Nota: estão aqui listados os provedores que oferecem produtos em nuvem pública, suficientemente claros e documentados, para serem utilizados assim que concluída a leitura deste artigo. Não foram avaliados fornecedores que oferecem somente nuvem privada (o que exigiria trabalhar junto as suas equipes), e fornecedores que estão mais para marketing de big-data do que para ofertas plug'n'play.
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.
- 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 objeto 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, comparando 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:
Observe 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ê.
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.
"Hadoop-as-a-Service"
Nesta categoria temos 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.
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!
"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, capacidade técnica do time) 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.
Criar um cluster Hadoop na nuvem é uma opção viável, 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.
Sobre o autor:
Mathieu é especialista em BigData na OCTO Technology. Ele é graduado (2001) em engenharia de software e computador pela ENSEIRB na França. Teve responsabilidade em contextos muito variados, como arquiteto sênior e consultor.
Ele possui interesse em arquiteturas escaláveis e de alto desempenho: Hadoop, NoSQL, sistemas transacionais distribuídas, processamento de fluxo de eventos, computação em nuvem e atua em atividades de Investigação e Desenvolvimento na OCTO.
Mathieu palestrou em várias conferências : TDC 2013 São Paulo, Agile France, Lean-Kanban France, Agile Tour Brussels.