Otimizando o desempenho do Tempo de Execução de Integração do Azure
Os fluxos de dados são executados em clusters do Spark que são girados em tempo de execução. A configuração para o cluster usado é definida no tempo de execução de integração (IR) da atividade. Há três considerações de desempenho a serem feitas ao definir o tempo de execução da integração: tipo de cluster, tamanho do cluster e tempo de vida.
Para obter mais informações sobre como criar um Integration Runtime, consulte Integration Runtime.
A maneira mais fácil de começar a usar os tempos de execução de integração de fluxo de dados é escolher pequeno, médio ou grande no seletor de tamanho de computação. Consulte os mapeamentos para configurações de cluster para esses tamanhos abaixo.
Tamanho do cluster
Os fluxos de dados distribuem o processamento de dados por diferentes núcleos em um cluster do Spark para executar operações em paralelo. Um cluster Spark com mais núcleos aumenta o número de núcleos no ambiente de computação. Mais núcleos aumentam o poder de processamento do fluxo de dados. Aumentar o tamanho do cluster é geralmente uma forma fácil de reduzir o tempo de processamento.
O tamanho padrão do cluster é quatro núcleos de driver e quatro núcleos de trabalho (pequenos). À medida que você processa mais dados, clusters maiores são recomendados. Abaixo estão as opções de dimensionamento possíveis:
| Núcleos de trabalho | Núcleos de driver | Total de núcleos | Notas |
|---|---|---|---|
| 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 precificados em vcore-hrs, o que significa que tanto o tamanho do cluster quanto o tempo de execução contribuem para isso. À medida que você aumenta a escala, o custo do cluster por minuto aumenta, mas o tempo geral diminui.
Gorjeta
Há um limite de 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 pequeno e escalar 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 é maior do que o processo pode manter na memória, o processo falha com erros OOM(falta de memória). Se o fluxo de dados contiver grandes quantidades de dados com junções/agregações, convém tentar alterar partições aleatórias de forma incremental. Você pode configurá-lo de 50 até 2000, para evitar erros OOM. Compute Custom properties in dataflow runtime, é uma maneira de controlar seus requisitos de computação. O nome da propriedade é Partições aleatórias e é do 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, certifique-se de que os dados estão bem espalhados. Um número aproximado é ter aproximadamente 1,5 GB de dados por partição. Se os dados estiverem distorcidos, aumentar as "partições aleatórias" não será útil. Por exemplo, se você tiver 500 GB de dados, ter um valor entre 400 e 500 deve funcionar. O limite predefinido para partições aleatórias é 200, o que funciona bem para aproximadamente 300 GB de dados.
- No portal do ADF em Gerenciar, selecione um tempo de execução de integração personalizado e vá para o modo de edição.
- Na guia tempo de execução do fluxo de dados, vá para a seção Propriedades personalizadas de computação.
- Selecione Ordenar partições em Nome da propriedade, valor de entrada de sua escolha, como 250, 500 etc.
Você pode fazer o mesmo editando o arquivo JSON de tempo de execução adicionando uma matriz com nome e valor da propriedade após uma propriedade existente, como a propriedade cleanup .
Time to live
Por padrão, cada atividade de fluxo de dados gera um novo cluster do Spark com base na configuração de IR do Azure. O tempo de inicialização do cluster a frio leva alguns minutos e o processamento de dados não pode ser iniciado até que esteja concluído. Se seus pipelines contiverem vários fluxos de dados sequenciais , você poderá habilitar um valor TTL (time to live). A especificação de um valor de tempo de vida mantém um cluster ativo por um determinado período de tempo após a conclusão de sua execução. Se um novo trabalho começar a usar o IR durante o tempo TTL, ele reutilizará o cluster existente e o tempo de inicialização será muito reduzido. Após a conclusão do segundo trabalho, o cluster permanecerá ativo novamente pelo tempo TTL.
No entanto, se a maioria dos seus fluxos de dados for executada em paralelo, não é recomendável que você habilite o TTL para o IR que você usa para essas atividades. Apenas um trabalho pode ser executado em um único cluster de cada vez. Se houver um cluster disponível, mas dois fluxos de dados forem iniciados, apenas um usará o cluster ativo. O segundo trabalho irá girar seu próprio cluster isolado.
Nota
O tempo de vida não está disponível ao usar o tempo de execução de integração de resolução automática (padrão).
Conteúdos relacionados
Veja outros artigos do Data Flow relacionados ao desempenho: