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
em um pipeline, as operações são executadas em paralelo. A primeira etapa de uma
JOIN
é embaralhar os dados para que todos os registros com a mesma chave JOIN
sejam enviados
para o mesmo executor. Depois que todos os dados são embaralhados, são unidos e a
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 chamada
Purchases
e Items
. Cada registro de compra contém um nome e um número de item.
comprado. Cada registro de item contém o nome e o preço do item. Um
A função JOIN
é usada 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
registros com o mesmo ID acabam no mesmo executor.
Quando as chaves JOIN
são distribuídas de maneira uniforme, as operações JOIN
são executadas
porque elas podem ser executadas em paralelo.
Como qualquer embaralhamento, o desvio de dados afeta negativamente a performance. Na seção
exemplo, os ovos são comprados com muito mais frequência do que frango ou leite, o que
significa que o executor que ingressa nas compras de ovos tem mais trabalho que o outro
executores. Se você notar que uma JOIN
está distorcida, há duas maneiras de melhorar
desempenho.
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 partições muito maiores que outras, elas são
divididos em outros 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, em seguida, transmitida para cada executor. O conjunto de dados grande não é embaralhado
removendo as partições desiguais geradas ao embaralhar na
Tecla JOIN
.
No exemplo anterior, o conjunto de dados de itens é carregado primeiro na memória Driver do Spark. Em seguida, ele é transmitido para cada executor. Agora, os executores podem participar sem embaralhar o conjunto de dados de compra.
Essa abordagem exige que você forneça memória suficiente para o driver do Spark e
executores 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 isso como o executor e a memória do driver. Por exemplo, se o conjunto de dados "items"
tinha 1 GB de tamanho, precisaríamos definir o executor e a memória do driver como no
pelo menos 4 GB. Conjuntos de dados maiores que 8 GB não podem ser carregados na memória.
Distribuição de chaves
Quando ambos os lados da JOIN
são muito grandes para caber na memória, um
a técnica pode ser usada para dividir cada chave de JOIN
em várias chaves para aumentar
o nível de paralelismo. Essa técnica pode ser aplicada a INNER JOIN
e
LEFT OUTER JOIN
. Ele não pode ser usado para FULL OUTER JOIN
as operações.
Nesta abordagem, o lado distorcido é sal com uma nova coluna de números inteiros com uma
número aleatório de 1 a N. O lado não torto é 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, exceto o novo
é adicionada como parte da chave JOIN
. Dessa forma, todos os dados usados
para acessar uma única partição agora é distribuída para até N
partições diferentes.
No exemplo anterior, o fator de distribuição N
está definido como 3
. A
os conjuntos de dados originais são mostrados à esquerda. As versões com sal e explodidas
do conjunto de dados são mostrados no meio. Os dados embaralhados são mostrados à direita,
Três executores diferentes juntando compras de ovos, em vez de um.
Para alcançar um maior paralelismo, aumente as distribuições. No entanto, isso
ao custo da explosão de um lado da JOIN
, resultando em mais dados embaralhados
em todo o cluster. Por isso, o benefício diminui, pois 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.