Arquitetura de um cluster Spark

Lorena de Souza
4 min readFeb 6, 2019

Seguindo as publicações de como foi nosso primeiro Bootcamp de dados de Belo Horizonte em 2019.

Enquanto no sábado trabalhamos com uma quantidade de dados mais modesta e suas diversas formas de manipular e extrair possíveis conhecimentos, no domingo avançamos para técnicas quando a escala de dados é muuuuuiiitooo maior. A partir do dia 2, as práticas foram bem conectadas com o que empresas como - Globo.com, OLX, ifood e tantas outras praticam quando há um alto volume de dados. Daqui em diante iniciamos as práticas com nosso amigo Spark.

Spark é uma ferramenta com alguns mecanismos e estruturas para suportar processamento de dados em larga escala.

O que seria essa larga escala 50mil? 500mil? 5 milhões de dados? Aqui não existe uma resposta definitiva, mas avalie alguns critérios: a quantidade de dados que deseja processar não cabe na memória de um único computador? Preciso de um ou vários clusteres? A necessidade de processamento só aumenta com o passar do tempo? Se a resposta é sim, provável que nesse caso precise distribuir armazenamento e processamento dos dados, e nisso o Spark consegue atuar. A lição que ficou pra nós foi que dependendo do processamento e memória necessário nosso amigo Pandas ❤ fará seu trabalho muito bem, especialmente se for uma POC para validar algum modelo ou alguma análise estatística mais simples. Não precisará matar um mosquito com uma bazuca (o Spark pode ser muito para certas análises).

Se o Spark é uma ferramenta para distribuir dados e processamento via cluster, como isso funciona?

Antes de responder a pergunta é importante falar sobre o RDD e a natureza da arquitetura. O RDD — Resilient Distributed Datasets se trata do mecanismo que torna os Datasets tolerantes a falha, por meio do particionamento e da distribuição de um gigante dataset entre várias máquinas. Isto quer dizer que os datasets/RDD são particionados, distribuídos e armazenados na memória de outos computadores, conhecidos no Spark como Workeres nodes. A origem do conceito de RDD nasceu desse artigo Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing.

Dataset sendo particionado e cada partição deve ter uma task

A imagem abaixo pode nos dar uma ideia da natureza da arquitetura de um Cluster do Spark:

Arquitetura de um cluster Spark

Como pode observar na imagem, a natureza da arquitetura é ser Master/Slave, ou seja, só é possível ter um único Driver Program e vários Workers Nodes em um cluster.

Para fins de entendimento do funcionamento, cada componente merece uma atenção:

  • Driver Program: este é o entry point do Spark. É onde o Spark Context é criado e é onde se define o fluxo de execução, bem como o RDD e o que deve ser executado em paralelo pelos Executores.
  • Spark Context: Estabelece configurações de memória e processamento dos Workers Nodes. Além disso é capaz de conectar com os diferentes tipos de Cluster Manager (além do próprio Spark Cluster Manager) como Apache Mesos ou Yarn do Hadoop.
  • Cluster Manager: esse é responsável por agendar e alocar um recurso computacional através do cluster.
  • Worker Node: é uma máquina que contém executores e recebe as tasks do Driver Program.
  • Executor: é o responsável por executar as tasks.
  • Task: é qualquer conjunto de operações (select, joing, filter, algorítimo de machine learning, e.t.c) sobre os dados.

Essa foi uma das visões de arquitetura que tivemos no Bootcamp de dados que rolou aqui na TW nos dias 02 e 03 de Fevereiro!

Felipe explicando a arquitetura de Driver e Wokeres node

Um outro momento importante foi quando o Felipe nos apresentou como o Spark executa o fluxo das operações sobre os RDDs.

No próximo post teremos detalhes sobre esse fluxo.

=D

Qualquer feedback ou dúvida manda aí pra gente!

--

--