Otimizar os sinks
Quando os fluxos de dados gravam em coletores, qualquer particionamento personalizado acontece imediatamente antes da gravação. Como a fonte, na maioria dos casos, é recomendável que você mantenha Usar particionamento atual como a opção de partição selecionada. Os dados particionados gravam muito mais rápido do que os dados não particionados, mesmo o seu destino não é particionado. A seguir estão as considerações individuais para vários tipos de pia.
Coletores do Banco de Dados SQL do Azure
Com o Banco de Dados SQL do Azure, o particionamento padrão deve funcionar na maioria dos casos. Há uma chance de que seu coletor possa ter muitas partições para seu banco de dados SQL manipular. Se você estiver se deparando com isso, reduza o número de partições geradas pelo coletor do Banco de dados SQL.
Práticas recomendadas para excluir linhas no coletor com base em linhas ausentes na origem
Aqui está um vídeo passo a passo de como usar fluxos de dados com transformações existentes, alterar linhas e coletores para alcançar esse padrão comum:
Impacto da manipulação de linhas de erro no desempenho
Quando você habilita a manipulação de linha de erro ("continuar no erro") na transformação do coletor, o serviço dá uma etapa extra antes de gravar as linhas compatíveis na tabela de destino. Esta etapa extra tem uma pequena penalidade de desempenho que pode estar na faixa de 5% adicionada para esta etapa com um acerto de desempenho extra pequeno também adicionado se você definir a opção de também gravar as linhas incompatíveis em um arquivo de log.
Desativando índices usando um script SQL
Desabilitar índices antes de uma carga em um banco de dados SQL pode melhorar muito o desempenho da gravação na tabela. Execute o comando abaixo antes de gravar no coletor SQL.
ALTER INDEX ALL ON dbo.[Table Name] DISABLE
Após a conclusão da gravação, reconstrua os índices usando o seguinte comando:
ALTER INDEX ALL ON dbo.[Table Name] REBUILD
Ambos podem ser feitos nativamente usando scripts Pré e Post-SQL em um coletor do Banco de Dados SQL do Azure ou Synapse no mapeamento de fluxos de dados.
Aviso
Ao desabilitar índices, o fluxo de dados está efetivamente assumindo o controle de um banco de dados e é improvável que as consultas sejam bem-sucedidas no momento. Como resultado, muitos trabalhos de ETL são acionados no meio da noite para evitar esse conflito. Para obter mais informações, saiba mais sobre as restrições de desabilitar índices SQL
Ampliando seu banco de dados
Agende um redimensionamento da origem e colete o Banco de Dados SQL e o DW do Azure antes da execução do pipeline para aumentar a taxa de transferência e minimizar a limitação do Azure quando atingir os limites da DTU. Após a conclusão da execução do pipeline, redimensione os bancos de dados de volta à taxa de execução normal.
Coletores do Azure Synapse Analytics
Ao escrever no Azure Synapse Analytics, certifique-se de que Ativar preparo está definido como true. Isso permite que o serviço escreva usando o comando SQL COPY, que efetivamente carrega os dados em massa. Você precisará fazer referência a uma conta do Azure Data Lake Storage gen2 ou do Armazenamento de Blob do Azure para o preparo dos dados ao usar o Preparo.
Além do Preparo, as mesmas práticas recomendadas se aplicam ao Azure Synapse Analytics como o Banco de Dados SQL do Azure.
Coletores baseados em arquivo
Embora os fluxos de dados suportem vários tipos de arquivos, o formato Parquet nativo do Spark é recomendado para tempos ideais de leitura e gravação.
Se os dados estiverem distribuídos uniformemente, Usar particionamento atual é a opção de particionamento mais rápida para gravar arquivos.
Opções de nome de arquivo
Ao escrever arquivos, você pode escolher entre as opções de nomenclatura que afetam o desempenho.
Selecionar a opção Padrão grava o mais rápido. Cada partição equivale a um arquivo com o nome padrão do Spark. Isso é útil se você estiver apenas lendo a partir da pasta de dados.
A definição de um padrão de nomenclatura renomeia cada arquivo de partição para um nome mais amigável. Esta operação acontece após a gravação e é um pouco mais lenta do que escolher o padrão.
Por partição permite que você nomeie cada partição individual manualmente.
Se uma coluna corresponder à forma como você deseja produzir os dados, você pode selecionar Arquivo de nome como dados de coluna. Isso reorganiza os dados e pode afetar o desempenho se as colunas não forem distribuídas uniformemente.
Se uma coluna corresponder à forma como você deseja gerar nomes de pastas, selecione Nomear pasta como dados de coluna.
A saída para um único arquivo combina todos os dados em uma única partição. Isso leva a longos tempos de gravação, especialmente para grandes conjuntos de dados. Essa opção é desencorajada, a menos que haja uma razão comercial explícita para usá-la.
Coletores do Azure Cosmos DB
Quando você está gravando no Azure Cosmos DB, alterar a taxa de transferência e o tamanho do lote durante a execução do fluxo de dados pode melhorar o desempenho. Essas alterações só entram em vigor durante a execução da atividade de fluxo de dados e retornarão às configurações de coleta originais após a conclusão.
Tamanho do lote: Normalmente, começar com o tamanho de lote padrão é suficiente. Para ajustar ainda mais esse valor, calcule o tamanho aproximado do objeto dos dados e certifique-se de que o tamanho do objeto * tamanho do lote seja inferior a 2MB. Se for, você pode aumentar o tamanho do lote para obter melhor rendimento.
Taxa de transferência: defina uma configuração de taxa de transferência mais alta aqui para permitir que os documentos gravem mais rapidamente no Azure Cosmos DB. Tenha em mente os custos mais altos de RU com base em uma configuração de alto rendimento.
Orçamento de taxa de transferência de gravação: use um valor menor do que o total de RUs por minuto. Se você tiver um fluxo de dados com um alto número de partições do Spark, definir uma taxa de transferência de orçamento permitirá mais equilíbrio entre essas partições.
Conteúdos relacionados
- Visão geral do desempenho do fluxo de dados
- Otimizar origens
- Otimizar as transformações
- Usando fluxos de dados em pipelines
Veja outros artigos do Data Flow relacionados ao desempenho: