anterior
Tweet about this on TwitterPin on PinterestShare on LinkedInShare on Google+Email this to someoneShare on Facebook
QR CODE

Big Data e ferramentas de Big Data

Conceito e história

O termo Big Data não é novo. Surgiu da necessidade de se nomear uma nova área de conhecimento que visa sistematizar os dados que coletamos das pessoas e dos serviços que elas utilizam, para aproveitá-los da melhor forma possível, não só em pesquisas e estatísticas, mas para melhoria da ergonomia e usabilidade dos mais diversos serviços.

O termo surgiu com o Google em 1995 e foi alavancado pelo Yahoo, que transformou a plataforma Hadoop em código aberto. A partir daí foi que as empresas passaram a entender que para conhecer os clientes é necessário saber como elas interagem com os seus produtos e serviços e passaram a recolher cada vez mais dados.

Com isto surgiu um boom de dados. Porém, só os dados puros não adianta: é necessário tratar para converter em informações úteis as organizações para que as mesmas possam se posicionar estrategicamente em relação ao mercado e seus concorrentes. Estes dados, se bem filtrados, são consistentes e de grande valia.

A proposta de uma solução de Big Data é a de oferecer uma abordagem ampla no tratamento do aspecto cada vez mais “caótico” dos dados para tornar as referidas aplicações e todas as outras mais eficientes e precisas. Para tanto, o conceito considera não somente grandes quantidades de dados, a velocidade de análise e a disponibilização destes, como também a relação com e entre os volumes.

Mas o Big Data por si só não é uma solução se não soubermos lidar com os dados, que se colhidos de forma errônea podem trazer transtornos as empresas. Se ao invés de serem usados forem somente armazenados, isto acarretará em custos de armazenamento e inutilidade dos dados. Além disso temos os 5 V do conceito que são:

  • Volume.
  • Velocidade.
  • Variedade
  • Veracidade
  • Valor

Vamos analisar os itens acima descritos.

  • Volume – se não houver um volume mínimo de dados como poderemos inferir estatisticamente se as tendências detectadas estão corretas?
  • Velocidade – a necessidade de obtermos dados, inclusive em tempo real, sua gravação, alteração ou substituição deve ser feito em tempo hábil para que gere ganhos reais. Imagine o transtorno que uma operadora de cartão de crédito teria – e causaria – se demorasse horas para aprovar uma transação de um cliente pelo fato de o seu sistema de segurança não conseguir analisar rapidamente todos os dados que podem indicar uma fraude.
  • Variedade – é outro aspecto importante. Os dados podem e devem ser tratados conforme sua origem – estruturados e não estruturados. Os dados estruturados são aqueles cuja origem é oriunda de bancos de dados relacionais ou não (Oracle, SQLSERVER, etc.) e de dados esparsos como, por exemplo, vídeos, e-mails, documentos, imagens, etc.
  • Veracidade – De nada obtermos um alto volume de dados se os mesmos não são confiáveis.
  • Valor – informação não é só poder, informação também é patrimônio. A combinação “volume + velocidade + variedade + veracidade”, além de todo e qualquer outro aspecto que caracteriza uma solução de Big Data, se mostrará inviável se o resultado não trouxer benefícios significativos e que compensem o investimento.

 

Soluções de Big Data

Além de lidar com volumes extremamente grandes de dados dos mais variados tipos, soluções de Big Data também precisam trabalhar com distribuição de processamento e elasticidade, isto é, suportar aplicações com volumes de dados que crescem substancialmente em pouco tempo.

O problema é que os bancos de dados “tradicionais”, especialmente aqueles que exploram o modelo relacional, como o MySQL, o PostgreSQL e o Oracle, não se mostram adequados a estes requisitos, já que são menos flexíveis.

Isso acontece porque bancos de dados relacionais normalmente se baseiam em quatro propriedades que tornam a sua adoção segura e eficiente, razão pela qual soluções do tipo são tão populares: Atomicidade, Consistência, Isolamento e Durabilidade. Esta combinação é conhecida como ACID, sigla para o uso destes termos em inglês: Atomicity, Consistency, Isolation e Durability. Vejamos uma breve descrição de cada uma:

  • Atomicidade: toda transação deve ser atômica, isto é, só pode ser considerada efetivada se executada completamente;
  • Consistência: todas as regras aplicadas ao banco de dados devem ser seguidas;
  • Isolamento: nenhuma transação pode interferir em outra que esteja em andamento ao mesmo tempo;
  • Durabilidade: uma vez que a transação esteja concluída, os dados consequentes não podem ser perdidos.

O problema é que este conjunto de propriedades é por demais restritivo para uma solução de Big Data. A elasticidade, por exemplo, pode ser inviabilizada pela atomicidade e pela consistência. É neste ponto que entra em cena o conceito de NoSQL, denominação que muitos atribuem à expressão em inglês “Not only SQL“, que em tradução livre significa “Não apenas SQL” (SQLStructured Query Language – é, em poucas palavras, uma linguagem própria para se trabalhar com bancos de dados relacionais).

O NoSQL faz referência às soluções de bancos de dados que possibilitam armazenamento de diversas formas, não se limitando ao modelo relacional tradicional. Bancos do tipo são mais flexíveis, sendo inclusive compatíveis com um grupo de premissas que “compete” com as propriedades ACID: a BASE (Basically Available, Soft state, Eventually consistency – Basicamente disponível, Estado Leve, Eventualmente consistente).

Não é que bancos de dados relacionais tenham ficado ultrapassados – eles são e continuarão por muito tempo sendo úteis a uma série de aplicações. O que acontece é que, geralmente, quanto maior um banco de dados se torna, mais custoso e trabalhoso ele fica: é preciso otimizar, acrescentar novos servidores, empregar mais especialistas em sua manutenção, enfim.

Via de regra, escalar (torná-lo maior) um bancos de dados NoSQL é mais fácil e menos custoso. Isso é possível porque, além de contar com propriedades mais flexíveis, bancos do tipo já são otimizados para trabalhar com processamento paralelo, distribuição global (vários data centers), aumento imediato de sua capacidade e outros.

Além disso, há mais de uma categoria de banco de dados NoSQL, fazendo com que soluções do tipo possam atender à grande variedade de dados que existe, tanto estrurados, quanto não estruturados: bancos de dados orientados a documentos, bancos de dados chave/valor, bancos de dados de grafos, enfim.

Exemplos de bancos de dado NoSQL são o Cassandra, o MongoDB, o HBase, o CouchDB e o Redis. Mas, quando o assunto é Big Data, apenas um banco de dados do tipo não basta. É necessário também contar com ferramentas que permitam o tratamento dos volumes. Neste ponto, o Hadoop é, de longe, a principal referência.

Exemplos de bancos de dados noSQL: Cassandra, MongoDB, HBase, CouchDB e Redis

 

O que é Hadoop?

O Hadoop é uma plataforma open source desenvolvida especialmente para processamento e análise de grandes volumes de dados, sejam eles estruturados ou não estruturados. O projeto é mantido pela Apache Foundation, mas conta com a colaboração de várias empresas, como Yahoo!, Facebook, Google e IBM.

Pode-se dizer que o projeto teve início em meados de 2003, quando o Google criou um modelo de programação que distribui o processamento a ser realizado entre vários computadores para ajudar o seu mecanismo de busca a ficar mais rápido e livre da necessidades de servidores poderosos (e caros). Esta tecnologia recebeu o nome de MapReduce.

Alguns meses depois, o Google apresentou o Google File System (GFS), um *sistema de arquivos especialmente preparado para lidar com processamento distribuído e, como não poderia deixar de ser no caso de uma empresa como esta, grandes volumes de dados (em grandezas de terabytes ou mesmo petabytes).

*Em poucas palavras, o sistema de arquivos é um conjunto de instruções que determina como os dados devem ser guardados, acessados, copiados, alterados, nomeados, eliminados e assim por diante.

Em 2004, uma implementação open source do GFS foi incorporada ao Nutch, um projeto de motor de busca para a Web. O Nutch enfrentava problemas de escala – não conseguia lidar com um volume grande de páginas – e a variação do GFS, que recebeu o nome Nutch Distributed Filesystem (NDFS), se mostrou como uma solução. No ano seguinte, o Nutch já contava também com uma implementação do MapReduce.

Na verdade, o Nutch fazia parte de um projeto maior: uma biblioteca para indexação de páginas chamada Lucene. Os responsáveis por estes trabalhos logo viram que o que tinham em mãos também poderia ser usado em aplicações diferentes das buscas na Web. Esta percepção motivou a criação de outro projeto que engloba características do Nutch e do Lucene: o Hadoop, cuja implementação do sistema de arquivos recebeu o nome de Hadoop Distributed File System (HDFS).

 

O Hadoop é tido como uma solução adequada para Big Data por vários motivos:

– É um projeto open source, como já informado, fato que permite a sua modificação para fins de customização e o torna suscetível a melhorias constantes graças à sua rede de colaboração. Por causa desta característica, vários projetos derivados ou complementares foram – e ainda são – criados;

– Proporciona economia, já que não exige o pagamento de licenças e suporta hardware convencional, permitindo a criação de projetos com máquinas consideravelmente mais baratas;

– O Hadoop conta, por padrão, com recursos de tolerância a falhas, como replicação de dados;

– O Hadoop é escalável: havendo necessidade de processamento para suportar maior quantidade de dados, é possível acrescentar computadores sem necessidade de realizar reconfigurações complexas no sistema.

É claro que o Hadoop pode ser usado em conjunto com bancos de dados NoSQL. A própria Apache Foundation mantém uma solução do tipo que é uma espécie de subprojeto do Hadoop: o já mencionado banco de dados HBase, que funciona atrelado ao HDFS.
A denominação Hadoop tem uma origem inusitada: este é o nome que o filho de Doug Cutting, principal nome por trás do projeto, deu ao seu elefante de pelúcia amarelo.

O Hadoop, é bom frisar, é a opção de maior destaque, mas não é a única. É possível encontrar outras soluções compatíveis com NoSQL ou que são baseadas em Massively Parallel Processing (MPP), por exemplo.

 

Finalizando

LIVROS SUGERIDOS:

Não podemos considerar as soluções de Big Data como um arsenal computacional perfeito: sistemas do tipo são complexos, ainda desconhecidos por muitos gestores e profissionais de TI e a sua própria definição ainda é passível de discussão.

O fato é que a ideia de Big Data reflete um cenário real: há, cada vez mais, volumes de dados gigantescos e que, portanto, exigem uma abordagem capaz de aproveitá-los ao máximo. Apenas para dar uma noção deste desafio, a IBM divulgou no final de 2012 que, de acordo com as suas estimativas, 90% dos dados disponíveis no mundo foram gerados apenas nos dois anos anteriores. Até o final de 2015, este volume todo terá aumentado pelo menos duas vezes. Diante deste ponto de vista, é um tanto precipitado encarar a expressão “Big Data” como um mero “termo da moda”.

Para saber mais sobre o assunto, você pode consultar os links que serviram de referência para este texto:

Matéria retirada parcialmente do http://www.infowester.com/big-data.php e originalmente escrita por: Emerson Alecrim e adaptada por Roberto Pastor.


 

pastor

Sobre o autor

Roberto Pastor – Instrutor na Penha, formado em Administração de Empresas e Mestre em Gestão Educacional. Dá aulas nos cursos de Informática, Hardware e Web Design e T.I.

Próximo

Postado por

Postagem Relacionada

capa
A História do Android
Olá pessoal! Meu nome é Lucas Silva e junto com o instrutor Victor Rodrigues fizemos uma pesquisa
  • Diego Barros

    Tenho apenas uma dúvida sobra o que foi publicado; o termo Big Data não foi criado pela NASA na década de 1990?

  • Jair Campos Amaro

    Bom dia. Queria o Contato do Roberto Pastor. Poderiam me passar no e-mail jaircampos@gmail.com trabalhamos um blog de uma grande empresa e estamos querendo escritores nesta linha de conteúdo.