Otimização de desempenho do Azure Integration Runtime
Os fluxos de dados são executados em clusters Spark criados no tempo de execução. A configuração do cluster usado é definida no IR (Integration Runtime) da atividade. Há três considerações de desempenho a serem feitas ao definir seu runtime de integração: tipo de cluster, tamanho do cluster e vida útil.
Para saber mais sobre como criar um Integration Runtime, consulte Integration Runtime.
A maneira mais fácil de começar a usar os runtimes de integração de fluxo de dados é escolher pequeno, médio ou grande no seletor de tamanho de computação. Veja os mapeamentos para configurações de cluster para esses tamanhos abaixo.
Tamanho do cluster
Os fluxos de dados distribuem o processamento de dados em núcleos diferentes em um cluster do Spark para executar operações em paralelo. Um cluster do Spark com mais núcleos aumenta o número de núcleos no ambiente de computação. Um número maior de núcleos aumenta a potência de processamento do fluxo de dados. O aumento no tamanho do cluster geralmente é uma maneira fácil de reduzir o tempo de processamento.
O tamanho do cluster padrão é de quatro núcleos de driver e quatro núcleos de trabalho (pequeno). Ao processar mais dados, é recomendado usar clusters maiores. Veja abaixo as opções de tamanho disponíveis:
| Núcleos de Trabalho | Núcleos de Driver | Total de Núcleos | Observações |
|---|---|---|---|
| 4 | 4 | 8 | Pequena |
| 8 | 8 | 16 | Médio |
| 16 | 16 | 32 | grande |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
Os fluxos de dados são cobrados em vcore-hrs, incluindo o tamanho do cluster e o fator de tempo de execução. Ao escalar verticalmente, o custo do cluster por minuto aumenta, mas o tempo total é reduzido.
Dica
Há um valor máximo definindo quanto o tamanho de um cluster afeta o desempenho de um fluxo de dados. Dependendo do tamanho dos dados, há um ponto em que aumentar o tamanho de um cluster deixará de melhorar o desempenho. Por exemplo, se você tiver mais núcleos do que partições de dados, adicionar núcleos adicionais não ajudará. Uma prática recomendada é começar com um tamanho pequeno e escalar verticalmente para atender às suas necessidades de desempenho.
Partição aleatória personalizada
O fluxo de dados divide os dados em partições e os transforma usando diferentes processos. Se o tamanho dos dados em uma partição for maior do que pode ser contido na memória pelo processo, ele falhará com erros OOM (falta de memória). Se o fluxo de dados contiver grandes quantidades de dados com junções/agregações, tente alterar as partições aleatórias de maneira incremental. É possível configurá-lo de 50 até 2000 para evitar erros de OOM. As propriedades personalizadas de computação no runtime do fluxo de dados são uma maneira de controlar os requisitos de computação. O nome da propriedade é Partições aleatórias e o tipo é “inteiro”. Essa personalização só deve ser usada em cenários conhecidos, caso contrário, pode causar falhas desnecessárias no fluxo de dados.
Ao aumentar as partições aleatórias, verifique se os dados estão bem distribuídos. Um número aproximado seria ter cerca de 1,5 GB de dados por partição. Se os dados estiverem distorcidos, não será útil aumentar "Partições aleatórias". Por exemplo, se você tiver 500 GB de dados, uma solução possível seria um valor entre 400 e 500. O limite padrão para partições aleatórias é 200, o que funciona bem para cerca de 300 GB de dados.
- No portal do ADF, em Gerenciar, selecione um runtime de integração personalizado e acesse o modo de edição.
- Na guia de runtime do fluxo de dados, acesse a seção Propriedades personalizadas de computação.
- Selecione Partições aleatórias em “Nome da propriedade” e insira o valor desejado, como 250, 500 etc.
É possível fazer o mesmo editando o arquivo JSON do runtime com o acréscimo de uma matriz com o nome e o valor da propriedade após uma propriedade existente como limpeza.
Vida útil
Por padrão, cada atividade de fluxo de dados cria um cluster Spark com base na configuração do Azure IR. O tempo de inicialização do cluster frio leva alguns minutos e o processamento de dados não pode ser iniciado até que a inicialização seja concluída. Se seus pipelines tiverem vários fluxos de dados sequenciais, é possível habilitar um valor de vida útil (TTL). Especificar um valor de vida útil mantém o cluster ativo por determinado período de tempo após sua execução ser concluída. Se um novo trabalho começar a usar o IR durante o tempo de vida útil, ele reutilizará o cluster existente e o tempo de inicialização será muito reduzido. Após a conclusão do segundo trabalho, o cluster ficará ativo novamente durante o tempo de vida útil.
No entanto, se a maioria dos fluxos de dados é executada em paralelo, não é recomendável habilitar o TTL para o IR que é usado para essas atividades. Só é possível executar um trabalho por vez em um único cluster. Se houver um cluster disponível, mas dois fluxos de dados forem iniciados, apenas um usará o cluster ativo. O segundo trabalho criará seu próprio cluster isolado.
Observação
A vida útil não está disponível ao usar o runtime de integração de resolução automática (padrão).
Conteúdo relacionado
Consulte outros artigos sobre Fluxo de Dados relacionados ao desempenho: