A evolução das plataformas de computação para Big Data

Entre os anos 2012 a 2018, o Hadoop era considerado uma plataforma de Big Data praticamente hegemônica. Em um projeto típico de Big Data, além dos aspectos do pipeline de engenharia de dados, era comum os processos de aquisição de hardware para nós (nodes) do Hadoop, implantação e administração da infraestrutura.

A criação de um cluster Hadoop foi bastante facilitada nos últimos anos, mas o gerenciamento e a administração geral de um ambiente de cluster de vários nós ainda é muito desafiadora e pode se tornar confusa às vezes. Existem variáveis que precisam ser consideradas e uma delas é o gerenciamento do sistema operacional dos nós: ajustes de desempenho, segurança e atualizações. Graças aos avanços do Hadoop, como por exemplo, o suporte à alta disponibilidade de Namenode (HDFS) e ao Resource Manager (YARN), houve certo alívio. O Hadoop trabalha com o princípio de escalonabilidade horizontal, mas adicionar novos nós nem sempre é uma tarefa tão prática. Adicionar novos nós é fácil apenas se existir hardware suficiente para isso.

Outras variáveis importantes a serem consideradas são: suporte para novos frameworks de análise de dados e de Machine Learning: esses frameworks mais avançados como Spark, RAPIDS e alguns outros, exigem muita memória. À medida que novas estruturas como o Spark começaram a evoluir, a necessidade de CPU e memória tornou-se cada vez mais forte. A teoria que dizia que com o Hadoop se poderia usar hardware “commodity” já não era tão verdadeira assim.

Com o advento da Computação em Nuvem, a maioria dos desafios acima foi resolvido quase que automaticamente. Este tipo de abordagem minimizou a preocupação com atualizações, patches e escalonabilidade. A natureza da nuvem facilitou a inclusão de novos nós sob demanda em questão de minutos. A adoção da Computação em Nuvem para Big Data começou com profissionais usando as ofertas de máquinas virtuais dos provedores de nuvem, como EC2 da AWS. Com estas máquinas virtuais, instalava-se o Hadoop e o Spark usando distribuições como Cloudera, Hortonworks ou simplesmente usando a versão de código aberto.

Outra forma de trabalhar com Big Data em nuvem é usar serviços integrados como Amazon EMR, Azure HDInsight ou Google Cloud Dataproc. O uso de serviços de Big Data de provedores de nuvem é um pouco mais caro em comparação com as máquinas virtuais tradicionais, mas oferece vários benefícios. Implementações mais rápidas, necessidade mínima de habilidades de administração de infraestrutura, fácil escalonabilidade e recursos de monitoramento embutidos são alguns dos benefícios que valem o preço extra. Por outro lado, alguns clientes não gostam da ideia de depender fortemente de um provedor de nuvem específico.

Em outros casos, há clientes que optam por uma abordagem híbrida. Por exemplo, pode-se criar um cluster Hadoop com centenas de nós fazendo a combinação de máquinas virtuais da AWS e da Azure. É uma tendência, pois permite testar os serviços destas empresas mantendo todas as opções abertas para o caso de um provedor oferecer preços mais em conta que outro. Devido à natureza flexível dos recursos de computação em nuvem, é possível agora reestruturar pipelines de dados de forma que a necessidade de clusters Hadoop e Spark permanentes diminua rapidamente.

Na maioria dos casos, o modelo de nuvem tradicional de Data Lake é composto por uma camada de armazenamento permanente e de uma camada de computação efêmera. Mover plataformas de computação para a nuvem definitivamente resolve uma série de problemas com provisionamento de recursos, escalonabilidade e atualizações. No entanto, uma vez que o cluster tenha sido provisionado, todos os trabalhos computacionais são iniciados usando o mesmo cluster. Uma vez que as tarefas computacionais podem ser iniciadas em momentos diferentes durante o dia, o cluster precisa estar disponível 24 horas por dia, 7 dias por semana. Manter um cluster permanentemente ativo é uma proposta muito cara.

No modelo de nuvem tradicional para um Data Lake, todas as tarefas computacionais usam o mesmo cluster. A menos que os trabalhos sejam bem espaçados ao longo do dia, isso pode levar à contenção de recursos, degradação do desempenho e tempos de conclusão imprevisíveis. Daí surge uma questão: existe uma abordagem melhor?

Recentemente, os clientes estão preferindo o uso de pipelines de dados sem servidor usando serviços nativos da nuvem, como AWS Glue ou clusters efêmeros do Hadoop ou Spark. Isso significa que cada trabalho computacional pode ser executado em um espaço de cluster predefinido ou em um cluster criado especificamente para a finalidade de executar apenas um trabalho. As vantagens desta abordagem são:

  • Redução de custos: ter a flexibilidade de usar recursos de nuvem sob demanda quando necessário e liberá-los imediatamente quando ocioso é uma grande economia de custos. Pague apenas pelo que usar;
  • Desempenho previsível: ter um trabalho executado com recursos predefinidos garante a conclusão oportuna do trabalho.

É importante afirmar que o emprego de clusters temporários requer automação. Isso pode ser alcançado por meio de técnicas DevOps. Em geral, a computação sem servidor é uma boa escolha para clientes que têm um número limitado de tarefas computacionais, não querem se incomodar com o gerenciamento de servidores e são capazes de tolerar alguns atrasos.

A evolução das plataformas de Big Data foi positiva para pequenas e médias empresas, pois aumentou o número de ofertas em nuvens como AWS, Azure e Google Cloud Plataform. Para pequenas e médias empresas, as soluções de Big Data em nuvem são mais ágeis e acessíveis pois praticamente anula os custos com infraestrutura e o trabalho com aquisição de hardware além de permitir o armazenamento de dados por longa duração e computação sob demanda, o que permite controlar custos. Para grandes empresas ou órgãos governamentais a solução on premise ou em nuvem híbrida é mais adequada devido a diversos fatores como regulações, sensibilidade dos dados e aproveitamento contínuo dos recursos de computação uma vez que esse tipo de organização costuma ter muitas aplicações que demandam constantemente deste poder de armazenamento e processamento de dados.

Um ponto negativo foi a diminuição de fornecedores das distribuições comerciais de Hadoop. A Hortonworks se fundiu, recentemente, com a Cloudera e, atualmente, não tem concorrentes. Hoje temos a Cloudera e profissionais independentes que prestam suporte ao Hadoop usando a versão comunitária. A alta adoção de Big Data em nuvem e, consequentemente, a dependência de clientes aos fornecedores em Cloud tende a aumentar os preços de fornecedores como AWS, Azure e Google Cloud Plataform. Vale ressaltar que a solução do Hadoop on premise em versão comunitária ainda é a solução mais barata para ingestão e armazenamento de dados.

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA

Anterior Conhecendo o kernel Linux pelo /proc (parte 5) – Recursos da memória virtual
Próxima ChatBot: Weni e Rocket.chat para atendimento ao cliente omnichannel com soluções open source.

About author

Leonardo Afonso Amorim
Leonardo Afonso Amorim 7 posts

Bacharel em Engenharia de Computação pela PUC-GO. Mestre em Ciência da Computação pela UFG com foco em Inteligência Computacional. Doutor em Ciência da Computação pela UFG com pesquisa sobre Processamento de Alto Desempenho (HPC) com aplicações em Processamento de Linguagem Natural (NLP). Também na UFG fez pesquisa sobre aplicação de Machine Learning para Reparo Automatizado de Software. Lecionou sobre Inteligência Artificial/Computacional para Engenharia de Computação na Universidade Federal de Goiás. Atualmente atua como Engenheiro de Dados na 4Linux e Engenheiro de Machine Learning na Rankdone. É professor de graduação e pós-graduação em Big Data e Machine Learning/Inteligência Artificial nas seguintes faculdades: PUC Goiás, Faculdade Sul Americana e IPOG. Possui as seguintes certificações em TI: LPIC-1, LPIC-2 e LPIC-3 Security (Linux Professional Institute), Novell Certified Linux Administrator (Suse Linux Enterprise) e Hortonworks HDPCD (Hadoop Developer).

View all posts by this author →

Você pode gostar também

Big Data

Implementando Point-in-time Recovery (PITR) em PostgreSQL 9.6

  Neste artigo você aprenderá: como implementar um simples sistema de replicação através dos xlog. como recuperar o seu banco PostgreSQL em qualquer ponto no tempo. Sobre backups PITR Quando

Treinamentos

4Linux inova mais uma vez e lança curso de Continuos Monitoring DEVOPS.

Será o nono curso ofertado na carreira DEVOPS. A mais abrangente oferta do Brasil. A 4linux anuncia hoje o lançamento de mais um curso para enriquecer a sua oferta de

Infraestrutura

SpamAssassin Reverso: bloqueio eficiente de spams

Um dos maiores ou até mesmo o maior problema quando falamos de e-mail é o recebimento de spam e vírus, um incomodo enorme tanto para o cliente final como a