Na primeira parte deste artigo vimos como a tempestade perfeita de dados formou-se e que ela colocava à prova a tecnologia e as técnicas disponíveis no mercado até então. O termo “Big Data” estava no “hype” e significava a esperança de domar o “tsunami” de dados que nosso mundo moderno e interconectado estava a gerar todos os dias.
Agora vamos retomar o assunto de onde paramos e, caso o leitor não conheça a primeira parte desta história, o convido a passar brevemente por ela antes de continuar, embora não seja um pré-requisito.
O desafio do Big Data
As novas empresas de internet (portais, comércios, redes sociais, motores de busca, provedores de e-mails, etc) precisavam de escalabilidade com custos sob controlo. A filosofia “Open Source” veio como uma necessidade para estas empresas e, sua natureza interconectada, gerou projectos apoiados por comunidades virtuais com grande conhecimento académico e problemas em comum.
Os projectos nasciam dentro destas empresas e logo eram “liberados para a comunidade” em formato de “papers”, para que todos os interessados ajudassem na resolução dos problemas em comum ou, simplesmente, como forma de contribuir por alguma outra informação obtida.
Um bom exemplo do caso de dificuldades na escalabilidade é do projecto Apache Nutch, de 2002. Seus desenvolvedores tinham como objectivo desenvolver um motor de busca na internet que fosse “open source” e conseguisse indexar 1 bilhão de páginas. Feito um estudo sobre o que era necessário para isso funcionar, a conclusão era de que seriam necessários 500 mil dólares em equipamento para servidores e, como custo de funcionamento, seriam necessários cerca de 30 mil dólares por mês. Isso mostrou que a solução precisaria ser outra, uma que reduzisse os custos totais e os desafios de armazenamento e processamento da informação, ou seja, tornasse o projecto viável.
No ano seguinte, 2003, o Google publicou um “paper” sobre o GFS (Google File System) e como ele resolvia o desafio de armazenar grandes volumes de dados. Já, em 2004, veio um outro documento, sobre “Map Reduce”, que vinha solucionar como processar aqueles grandes volumes de dados armazenados com o GFS. Estes documentos, porém, eram teoria e o Google não os tinha implementado. Os desenvolvedores do Apache Nutch, Mike Cafarella e Doug Cutting, resolveram arregaçar as mangas e colocar estes recursos no projecto deles.
Em 2005 a solução foi testada em uma rede de computadores com entre 20 e 40 nós, ou seja, até 40 computadores trabalhando em rede. Os desenvolvedores perceberam que nem com este número seria possível executar a tarefa, sendo necessários mais computadores para dar conta desta missão. Além disso, viram que sozinhos não chegariam muito longe. A dupla procurou uma empresa que mantivesse o projecto e os ajudasse a seguir e, em 2006, a Yahoo aceitou. O projecto então seguiu com o nome que o deixou conhecido no mundo: Hadoop.
Neste meio tempo, começaram a ganhar força as soluções em nuvem, que nada mais são que “data centers” ligados à internet e distribuídos pelo mundo replicando informações, como faz a AWS (Amazon Web Services), empresa criada pela Amazon para suportar seu negócio de vendas online.
Em 2007, com mil nós activos, a Yahoo testou com sucesso o Hadoop e começou a utilizá-lo. Assim, no ano seguinte, o projecto foi colocado na Apache Foundation para ser compartilhado com a comunidade e a plataforma correu com 4000 nós activos de forma bem-sucedida. Em 2009, um “cluster” Hadoop conseguiu ordenar 1 Pb (peta byte) de dados em menos de 17 horas (o que envolveu mais de um bilhão de buscas e milhões de páginas) e venceu um concurso de ordenação Gray Sort onde, pela primeira vez, uma solução Open Source ganhou e foi a mais veloz. Apesar disso tudo, a versão considerada como “1.0” do Hadoop só foi lançada em 2011.
Por muitos anos, Hadoop e “Big Data” foram fortemente associados e, junto com ele, uma avalanche de ferramentas não tradicionais ganharam força, entre elas as bases de dados “No-SQL”, cujo significado quer dizer “Not Only SQL”, indicando que não seguem a lógica relacional. O Hadoop, por sua vez, gerou soluções completas para administrar clusters de processamento de dados distribuídos, sendo as mais conhecidas criadas pelas empresas Cloudera (para onde Doug Cutting foi em 2009) e HortonWorks – empresas que se fundiram em 2019.
Ilustração sobre as bases de dados “No-SQL” e as bases relacionais, que utilizam a linguagem “SQL”.
Conclusão – o desaparecimento do “Big Data”
Mas após o “boom” do “Big Data” e toda a sua revolução, o que aconteceu? Na verdade, tudo ainda está por aí, mas transformado… Os elementos da revolução “Big Data” se espalharam e fazem parte de uma infinidade de outras soluções e tecnologias. Fazendo uma última visita aos 3 “Vs” iniciais, podemos verificar o seguinte:
- Variedade: a diversidade de tipos de dados e possibilidades de lidar com eles deram impulso às bases de dados “No-SQL”. As 3 mais bem-sucedidos desta família são o MongoDB (base de documentos), o Redis (base chave-valor) e o Elasticsearch (motor de busca). Só que este movimento “No-SQL” também gerou uma revolução nas bases SQL que, agora, continuam relacionais, mas suportam modelos não-relacionais. A Oracle, campeã de mercado, manteve sua base relacional, mas suporta outros modelos não tradicionais – entre eles os modelos de grafos (os mais adequados para marcar pontos de um caminho).
- Volume: para dar conta do volume veio a “escalabilidade horizontal” (criar uma rede de servidores) e o trabalho em “cluster” (grupos de computadores). Desta forma é possível partilhar o processamento entre várias máquinas e obter resultados mais rapidamente e de forma mais barata do que antes, pois pode-se utilizar hardware “comum” para melhorar o processamento do servidor, que se torna um grupo de servidores que pode sempre ser ampliado. Apesar disso, a capacidade de processamento dos computadores continua crescendo, inclusive de forma flexível e em nuvem. O “data warehouse” deu lugar ao “data lake” (sem ter desaparecido), um conceito onde nem sempre há a necessidade de se transformar os dados antes de lê-los.
- Velocidade: a solução para o volume também aumentou a velocidade, mas aqui acrescentou-se o processamento dos dados em memória. A “evolução do Hadoop” veio em outro projecto Apache, chamado Spark. Mas actualmente até mesmo as bases de dados tradicionais podem colocar informação em memória para processamento analítico mais rápido e o barateamento dos dispositivos de armazenamento em memória têm facilitado esta tarefa.
Várias das soluções que compunham um framework baseado em Hadoop.
Quanto ao uso do termo, onde se falava em “Big Data”, hoje fala-se em “Data Science” (Ciência dos Dados), e a conversa se especializou de acordo com o uso dos dados que se pretende… Se o volume de dados é para comunicação entre servidores, sensores e equipamentos, então tratamos de Internet das Coisas (IoT). Se queremos utilizar dados para “Analytics” avançada provavelmente seguiremos para Machine Learning e/ou Inteligência Artificial. Se queremos analisar textos, imagens e vídeos, pode ser que queiramos entrar em processamento de Linguagem Natural e “Computer Vision”. Mas talvez isso também nos leve à Realidade Aumentada ou à Realidade Virtual. Se queremos deixar a análise fácil, provavelmente o termo “hype” será “Citizen Data Scientist” ou “Advanced Analytics com entrega Self-Service”. Para organizar os processos vamos falar mais em “data pipelines” e “gestão dos dados”.
E aí fica mais do que óbvio o motivo do desaparecimento do termo: “big data”. Ele era uma expressão genérica para anunciar uma transformação. Agora estamos adaptados a esta nova realidade e isso é o “novo normal”, está em todos os lugares e áreas. Sua essência agora é parte do dia-a-dia de todos nós.