Spark: a nova modinha⌗

Spark [1] se tornou, nos últimos anos, a ferramenta preferida de todo cientista de dados que precisava processar uma quantidade absurda de dados utilizando hardware comum. Essa nova tecnologia surfou na oportunidade de poder processar dados em memória. O acesso lento ao disco foi um um gargalo que o Hadoop encontrou muitos anos atrás, mas que só nos últimos anos conseguiu ser resolvido, vista a queda no preço do gigabyte de memória RAM. Hoje nos deparamos com máquinas com centenas de gigabytes de memória, e instanciar máquinas virtuais nunca foi tão fácil. Esse alinhamento das estrelas foi o que possibilitou uma nova revolução no processamento de dados.

O Hadoop, ainda que ainda seja muito utilizado, está cada vez mais caindo em desuso, dada a capacidade do Spark de processar workloads MapReduce compatíveis e utilizar sistemas de arquivo distribuído como o HDFS.

Implantação⌗

Para fins de consistência entre uma variedade de aplicações, era necessária a implantação da aplicação utilizando Docker. O Spark tem uma imagem oficial [2], mas ela não tem a melhor das documentações. A Bitnami faz uma melhor implementação do Spark em Docker [3], com uma documentação mais simples e fácil de entender. Munido da imagem, desenvolvi um arquivo compose para implantação em uma arquitetura de máquinas virtuais. O Spark, assim como o Hadoop, busca distribuir a execução de aplicações entre máquinas em uma arquitetura distribuída. Dessa forma, não existe a dependência em uma única máquinas extremamente resiliente, afinal, a única certeza que temos é que toda máquina um dia falhará.

A implementação propõe implantar um contêiner Spark master em uma máquinas manager e N contêineres Spark worker em máquinas worker do Swarm. A aplicação realizada por mim possui limitações, dado que minha máquina virtual tem limitações de memória e CPUs. Foi possível realizar a implantação do Docker Swarm dessa forma:

  • 1 máquina manager;
  • 2 máquinas worker.

Essa arquitetura não é ideal, visto que a falha da máquinas manager incorre em queda de serviço no cluster Spark. Uma arquitetura mais próxima do ideal envolve:

  • 3 máquinas manager;
  • 2 ou máquinas máquinas worker.

O uso de um número ímpar de managers é a política recomendada na documentação oficial, visto que o Swarm utiliza o algoritmo de consenso RAFT para eleição de um novo master [4]. Dessa forma, a queda de (N-1)/2 managers não impacta o funcionamento do cluster.

Resultados⌗

Após a implantação, verificamos que foi possível executar programas Python, utilizando a bilioteca PySpark[5] em um ambiente JupyterHub (também dockerizado) e com comunicação pelas redes do Docker. Essa arquitetura apresenta maior segurança visto que não é necessário trafegar dados possivelmente sensíveis entre Spark e Jupyter. Foi possível realizar o processamento paralelo de um dataset de teste contendo algumas centenas de entradas em um arquivo csv. O tamanho do dataset não permitiu ver o grande potencial desse tipo de tecnologia.

Pensamentos finais⌗

Ainda que a prova de conceito tenha sido bem sucedida em mostrar que a nova arquitetura de servidores que colocamos no ar funciona também para esse caso de uso, o projeto ficou meio largado às traças. Não existe muito incentivo para a execução de processamento distribuido dada a falta de maturidade tecnológica do meu ambiente de trabalho.

Ainda assim, espero que o enorme potencial desse cluster não seja desperdiçado com mais sistemas Wordpress.

Happy hacking.

Referências⌗

[1]: Apache Spark
[2]: apache/spark-docker
[3]: bitnami/spark
[4]: Raft consensus in swarm mode | Docker docs
[5]: PySpark
[6]: JupyterHub