Nesta página, explicamos o ajuste de desempenho para operações JOIN
no Cloud Data Fusion.
As operações JOIN
podem ser a parte mais cara de um pipeline. Como tudo o mais em um pipeline, as operações são executadas em paralelo. A primeira etapa de um
JOIN
é embaralhar os dados para que cada registro com a mesma chave JOIN
seja enviado
ao mesmo executor. Depois que todos os dados são embaralhados, eles são combinados e a saída continua pelo pipeline.
Exemplo de processamento paralelo em operações JOIN
Por exemplo, suponha que você execute uma operação JOIN
em conjuntos de dados chamados Purchases
e Items
. Cada registro de compra contém um nome e um número de item
comprados. Cada registro de item contém o nome e o preço do item. Um
JOIN
é executado no nome do item para calcular o preço total de cada
compra. Quando os dados são mesclados, eles são embaralhados no cluster para que
os registros com o mesmo ID acabem no mesmo executor.
Quando as chaves JOIN
são distribuídas de maneira uniforme, as operações JOIN
têm um bom desempenho, porque podem ser executadas em paralelo.
Como qualquer embaralhamento, o desvio de dados afeta negativamente a performance. No exemplo
anterior, os ovos são comprados com muito mais frequência do que os de frango ou leite, o que
significa que o executor que participa das compras de ovos faz mais trabalho do que os outros
executores. Se você perceber que uma JOIN
está distorcida, há duas maneiras de melhorar
a performance.
Dividir automaticamente partições distorcidas
Com a execução adaptável de consultas, desvios muito pesados serão tratados automaticamente.
Assim que uma JOIN
produz algumas partições muito maiores que outras, elas são
divididas em menores. Para confirmar se a execução de consulta adaptável está ativada,
consulte Ajuste automático.
Usar um JOIN
na memória
Uma JOIN
na memória poderá ser realizada se um lado da JOIN
for pequeno o suficiente
para caber na memória. Nessa situação, o pequeno conjunto de dados é carregado na memória
e transmitido para cada executor. O conjunto de dados grande não é embaralhado, removendo as partições desiguais geradas ao embaralhar na
chave JOIN
.
No exemplo anterior, o conjunto de dados de itens é carregado primeiro na memória do driver do Spark. Em seguida, ele é transmitido para cada executor. Os executores agora podem mesclar os dados sem embaralhar nenhum dos conjuntos de dados de compra.
Essa abordagem exige que você forneça memória suficiente ao driver e aos
executores do Spark para permitir que eles armazenem o conjunto de dados de transmissão na memória. Por padrão, o Spark reserva um pouco menos de 30% da memória para armazenar esse tipo de dados. Ao usar JOIN
s na memória, multiplique o tamanho do conjunto de dados por quatro e
defina-o como o executor e a memória do driver. Por exemplo, se o conjunto de dados de itens
tinha 1 GB, precisaríamos definir o executor e a memória do driver como
pelo menos 4 GB. Conjuntos de dados maiores que 8 GB não podem ser carregados na memória.
Distribuição de chaves
Quando os dois lados da JOIN
são muito grandes para caber na memória, uma
técnica diferente pode ser usada para dividir cada chave JOIN
em várias chaves e aumentar
o nível de paralelismo. Esta técnica pode ser aplicada a operações INNER JOIN
e
LEFT OUTER JOIN
. Ele não pode ser usado para operações FULL OUTER JOIN
.
Nessa abordagem, o lado distorcido é salgado com uma nova coluna de números inteiros com um número aleatório de 1 a N. O lado não distorcido é explodido, com cada linha existente gerando N
novas linhas. Uma nova coluna é adicionada ao lado explodido, preenchida com cada número de 1 a N. Um JOIN
normal é executado, mas a nova
coluna é adicionada como parte da chave JOIN
. Dessa forma, todos os dados que costumavam
ir para uma única partição agora são distribuídos para até N
partições diferentes.
No exemplo anterior, o fator de distribuição N
está definido como 3
. Os conjuntos de dados originais são mostrados à esquerda. As versões com sal e explodida do conjunto de dados
são mostradas no meio. Os dados embaralhados são mostrados à direita, com
três executores diferentes mesclando compras de ovos, em vez de um.
Para alcançar um maior paralelismo, aumente as distribuições. No entanto, isso custa
a explosão de um lado do JOIN
, resultando em mais dados embaralhados
no cluster. Por isso, o benefício diminui à medida que a distribuição
aumenta. Na maioria das situações, defina como 20 ou menos.
A seguir
- Saiba mais sobre o processamento paralelo no Cloud Data Fusion.