Motivadores para ler esse artigo.
- Experiência própria e vivenciada em momentos de caos e momentos de analise tranquila.
- O que busquei para me aprofundar.
- O que aprendi sobre como o spark funciona para otimização.
- O que o Databricks tem de 'plus' para otimização.
- Boas práticas que podem evitar necessidade de tunning e refatoração.
Introdução
Eu sempre tive um grande contato com banco de dados relacional e posteriormente com sistemas distribuídos como o Spark. Inicialmente me aprofundei mais nos SGBD tanto para montar query complexas como administração e principalmente como montar um script performatico para o SGBD. Quando comecei a trabalhar mais com Spark e posteriormente com Databricks inicialmente não tive problemas de performance para os cenários que tive que construir, mas conforme a área de bigdata foi realmente se tornando bigdata já comecei a ter problemas de performance em rotinas que aumentava 30% a cada semana e isso me fez buscar como o spark funciona 'por baixo dos panos', principalmente por que eu já conhecia como um SGBD funcionava e isso ajudou a compreender alguns conceitos que vou trazer aqui.
Breve explicação dos componentes do Apache Spark
Vamos ser breves já que quero que este artigo foque nos cenários de análise de performance, técnicas e boas práticas.
Spark Core:
Esse componente é a base do Spark, ele é responsável pelo gerenciamento de memória, tarefas, recover de falhas, gerenciamento I/O, ou seja ele manipula o RDD. Portanto, é um cara que tem boa parte do cluster.
Executors:
Esse componente é o trabalhador real do ecosistema do spark (cluster), ele quem recebe as ordens (tarefas) de escrita ou leitura, que pode ser em disco, memória ou ambos (vou explicar mais à frente por que isso entra em cenários de performance).
Workers:
Os workers são literalmente o que é para quem já esta familiarizada com computação distribuída, são os nós do cluster, portanto é ele que 'hospeda' os executors que mencionei acima, cada worker pode conter um ou mais executors. Ele é o responsável por gerenciar os recursos alocados aos executors, como se o executor fosse um auxiliar e o worker o almoxarifado. E se ele é o almoxarifado a quem ele se reporta?
Cluster Manager:
Esse é o gerente, ele gerencia recursos (Memória e CPU) para os workers, ele quem decide quantos executors será para cada aplicação e o quanto de recurso vai ser alocado, gerencia as tarefas enviadas pelo 'chefe' dele que vou explicar mais abaixo, e por ser um cargo mais elevado de responsabilidade ele monitora também o estado do cluster para recover de falhas, redistribuir tarefas conforme necessário. (OBS: existem vários tipos de gerenciadores de cluster: Yarn, mesos, kubernetes e o mais simples que é standalone).
SparkContext:
Bom esse é dígamos assim o chefão ou a porta de entrada, digo porta de entrada por que qualquer aplicação Spark vai passar por ele, ele que permite que a aplicação interaja com o cluster, ou seja, os workers e executors, ele que permite e gerência as tarefas entre os workers e desta forma ele gerencia toda a aplicação a nível de configuração, quantidade de executors e recursos como memoria. Precisa saber como está a execução das tarefas? fala com esse chefe aqui.
Portanto, de forma ilustrativa:
Algoritimos do Spark e como saber quem são os ofensores de tunning:
Primeiramente, vou explicar os principais algorítimos que são demonstrados tanto na interface do Spark UI como no plano de execução, seja o lógico ou o plano físico:
OBS: Lembrando que datasets é o mesmo aqui que uma tabela Spark ;)
1. Vamos começar com o mais famoso Scan:
- FileScan: Lê dados de arquivos de entrada. Pode ser otimizado para diferentes formatos de arquivo como parquet, ORC, CSV, JSON e sei la quais outros.
2. Join (Esse da uns B.O):
Broadcast Hash Join: Utilizado quando um dos datasets é pequeno o suficiente para ser transmitido para todos os nós do cluster, evitando o Shuffle (vou explicar mais sobre esse danado, mas resumidamente é uma operação de embaralhamento dos dados para junção final).
Shuffle Hash Join: Ambos os datasets (tabelas se preferir) são embaralhos para que as chaves correspondentes fiquem na mesma partição. É usado quando os datasets são grandes e não podem ser transmitidos para outros nós.
Sort Merge Join: Requer que ambos os datasets sejam ordenados antes do Join. É eficiente para grandes datasets que já estão particionados e ordenados, ou seja o join esta sendo feito por colunas particionadas e também ordenadas (ex:
df.write.partitionBy("coluna1").sortBy("coluna2").parquet("caminho/para/salvar/particionado")
3. Aggregation (sum, count, group by etc...):
HashAggregate: utiliza uma tabela hash para agregar dados. É eficiente para grande conjunto de dados que cabem na memória.
SortAggregate. Agrega dados após ordená-los. É usado quando os dados não cabem na memória.
4. Shuffle (Atenção nesse cara):
- Shuffle: Redistribui dados entre partições para operações que exigem reorganização, como joins e agregações. É uma operação cara em termos de I/O e rede.
5. Exchange:
- Muda a distribuição dos dados entre as partições. Pode ser usado para balancear a carga de trabalho entre os nós do cluster. (uma estratégia para balancear e fugir do shuffle)
Como o shuffle atua e por que ele é custoso:
Me segue lá no LinkedIn dá uma força, gosto de feedbacks também sou totalmente aberto para melhorar o compartilhamento de conhecimento.
Se você leu até aqui, parabéns!!! Espero que domine todos os problemas de performance. Próximo artigo, vou abordar as vantagens com o Databricks então segue lá no LinkedIn para ficar sabendo. Obrigado!!
SOCIAL SHARE CARD GENERATOR