A segunda sessão da TechXperience foi organizada por nosso colega Francisco Javier SalvadoEngenheiro de Grandes Dados na Bosonit, com o tema "Experiências em projetos de Grandes Dados", no qual ele reviu os fundamentos de Grandes Dados. Grandes Dados, e suas diferentes aplicações para mais tarde contextualizá-las em sua experiência de cliente. Uma conversa enriquecedora que trazemos hoje para coletar os pontos mais interessantes e para conhecer o estado da arte dos dados.
Quem é Francisco Javier Salvado?
Antes de tudo, devemos apresentar-lhes o protagonista da sessão: Francisco Javier Salvado. Nascido em Chiclana, Cádiz, e teletrabalhando lá desde o início da pandemia. Ele é formado em Engenharia de Tecnologias de Telecomunicações pela Universidade de Sevilha e tem mestrado em Análise e Visualização de Dados Maciços pela UNIR.
As posições em que trabalhou são Big Data Engineer, Big Data Developer e, nos meus primeiros dias, Full Stack Developer. Em termos de clientes, sua primeira experiência foi trabalhar para a Junta de Andaluzia em Fujitsu, que certamente você conhece por fabricar aparelhos de ar condicionado, mas também é uma consultoria tecnológica bastante grande. Lá ela fazia parte de uma equipe que trabalhava para a Fundação Progreso y Salud, iniciando na programação web com Java.
Seu objetivo era se dedicar ao mundo de Grandes dadosQuando teve a oportunidade, ele se juntou a Bosonit para treinar primeiro em Logroño e depois aplicar seus conhecimentos e talentos aos projetos dos clientes.
Estado da Arte dos Dados
Antes de mergulhar no estado da arte dos dados, estou certo de que a maioria de vocês terá feito algumas pesquisas sobre o que é Big Data em algum momento e com uma probabilidade muito alta terá chegado ao que são os "Vs" de Big Data, uma série de 5 características que são as seguintes Volume, Variedade, Velocidade, Variedade e Valor. Mas a realidade é que tudo isso pode ser resumido em um único V: Volume. E, como a própria palavra indica, se estamos a falar de Grandes dados estamos falando de grandes dados e grandes volumes de dados.
Vale notar também que o que nos parece grande hoje será pequeno no futuro, e no passado parecia muito maior. Para ver isto, basta pensar no que um Gigabyte significa para nós hoje em comparação com o que significava para nós há uma década atrás. Portanto, podemos concluir que Big Data é um termo ambíguo e evolutivo até o momento. Para dar uma figura real e colocar em perspectiva o volume apoiado por um desses sistemas, posso dizer que no projeto em que estou trabalhando atualmente temos 100GB de memória disponível na pré-produção e 350GB no ambiente de produção. Esta memória é o que a Spark usa para fazer o trabalho de processamento dos dados.
Com isto em mente, se falamos de Grandes Dados, devemos falar também de computação distribuída, pois os sistemas tradicionais não são capazes de realizar a tarefa com a agilidade necessária para se adaptar às exigências do momento.
Mas a computação distribuída não deve ser confundida com a computação paralela. Na computação distribuída, a memória é separada entre os diferentes processadores, enquanto na computação paralela, a memória é compartilhada por todos os processadores. Isto é algo fundamental já que, na computação distribuída, quando trabalhamos com Spark, ocorre um fenômeno chamado "Shuffle"; uma transferência de informação entre as diferentes memórias de cada nó e uma parte fundamental na programação.
Ambientes de trabalho para gerenciamento de grandes dados
Se olharmos para trás no tempo, a World Wide Web foi desenvolvida nos anos 90, o Google apareceu no final dos anos 90 e o Facebook foi fundado em 2004. Sem perceber, pode-se dizer que estávamos inventando o carro antes da roda, pois o aumento exponencial do número de internautas tornou necessário o desenvolvimento de tecnologias que fornecessem soluções eficientes para gerenciar uma quantidade tão volumosa de dados.
2006 viu o lançamento de Apache Hadoop. Uma estrutura de computação distribuída que todos nós conhecemos hoje e que foi inspirada no MapReduce e no Sistema de Arquivos Google. Oito anos depois, em 2014, nasceu a Apache Spark. Seu nascimento significou um salto radical na qualidade ao aumentar cem vezes o desempenho, entre outras coisas, porque consegue trabalhar em memória em vez de em disco.
Em conexão com este evento, não é coincidência que em 2013 tenha sido publicado um relatório sobre o conceito de Indústria 4.0 ou a quarta revolução industrial, que se baseia, entre outras tecnologias disruptivas, no Grandes Dados.
Dentro do projeto Apache Hadoop e ligando-se ao que foi dito anteriormente sobre a criação do Facebook e a ascensão das redes sociais, vale a pena mencionar, por exemplo, o HBase. Um banco de dados de valores-chave, orientado por colunas, lançado em 2006 e modelado no Google BigTable. Em 2010, o Facebook faria uso do HBase para implementar novos serviços de mensagens.
Por outro lado, usei o HBase dentro de projetos bancários onde as exigências do próprio projeto exigiam uma atualização aleatória dos registros. Para este fim, a HBase é muito mais eficiente do que a típica mesa da colmeia em formato de parquet sobre HDFS.
Linguagens de programação suportadas pela Spark
Como linguagens de programação suportadas pela Spark, temos Scala, Python, Java e R. Entre as 4 mencionadas, vou falar um pouco sobre Scala porque além de ser a linguagem com a qual trabalho, eu pessoalmente diria que é a mais característica, uma vez que a própria Spark é escrita principalmente nessa linguagem.
Scala é uma linguagem de programação multiparadigma. Ele suporta tanto características de programação orientadas a objetos quanto funcionais, para que possamos aproveitar o melhor dos dois mundos para nossas aplicações. As principais características da programação funcional são as seguintes:
- Funções de ordem superior.
- Funções puras.
- Avaliação não restritiva.
- Uso de recursividade.
Entre estes quatro, destacaria o uso de funções puras (funções que para a mesma entrada darão sempre a mesma saída), o que proporcionará ao nosso código uma limpeza superior, melhorando os testes de código. Finalmente, se falamos sobre o estado da arte dos dados em sua projeção futura, já estamos dando o salto de on-premise a nuvem. Minha opinião é que teremos arquiteturas híbridas com claras tendências para microsistemas e serverless sob demanda.
