Gerenciar computação para pool SQL dedicado (anteriormente SQL DW) no Azure Synapse Analytics
Saiba mais sobre como gerenciar o pool SQL dedicado de recursos de computação (anteriormente SQL DW) no Azure Synapse Analytics. Reduza os custos pausando o pool SQL dedicado ou dimensione o pool SQL dedicado para atender às demandas de desempenho.
O que é o gerenciamento de computação?
A arquitetura do pool SQL dedicado (anteriormente SQL DW) separa armazenamento e computação, permitindo que cada um seja dimensionado de forma independente. Como resultado, pode dimensionar a computação para satisfazer as necessidades de desempenho independentemente do armazenamento de dados. Também pode colocar em pausa e retomar recursos de computação. Uma consequência natural dessa arquitetura é que o faturamento para computação e armazenamento é separado. Se você não precisar usar seu pool SQL dedicado (anteriormente SQL DW) por um tempo, poderá economizar custos de computação pausando a computação.
Computação de dimensionamento
Pode aumentar horizontalmente ou reduzir a computação ao ajustar a definição de unidades de armazém de dados para o conjunto de SQL dedicado (anteriormente, SQL DW). O desempenho de consulta e de carregamento pode aumentar de forma linear à medida que adiciona mais unidades de armazém de dados.
Para conhecer as etapas de expansão, consulte o portal do Azure, PowerShell ou inícios rápidos do T-SQL. Você também pode executar operações de expansão com uma API REST.
Para executar uma operação de dimensionamento, o conjunto de SQL dedicado (anteriormente, SQL DW) primeiro interrompe todas as consultas de entrada e, em seguida, reverte as transações para garantir um estado consistente. O dimensionamento só ocorre depois de concluída a reversão de transação. Para uma operação de escala, o sistema separa a camada de armazenamento dos nós de computação, adiciona nós de computação e, em seguida, reconecta a camada de armazenamento à camada de computação. Cada pool SQL dedicado (anteriormente SQL DW) é armazenado como 60 distribuições, que são distribuídas uniformemente para os nós de computação. Adicionar mais nós de computação adiciona mais poder de computação. À medida que o número de nós de computação aumenta, o número de distribuições por nó de computação diminui, fornecendo mais poder de computação para suas consultas. Da mesma forma, a diminuição das unidades de data warehouse reduz o número de nós de computação, o que reduz os recursos de computação para consultas.
A tabela a seguir mostra como o número de distribuições por nó de computação muda à medida que as unidades de data warehouse mudam. O DW30000c fornece 60 nós de computação e alcança um desempenho de consulta muito maior do que o DW100c.
| Unidades do armazém de dados | # de nós de computação | # de distribuições por nó |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
Encontrar o tamanho certo das unidades de armazém de dados
Para ver os benefícios de desempenho da expansão, especialmente para unidades de data warehouse maiores, você deseja usar pelo menos um conjunto de dados de 1 TB. Para encontrar o melhor número de unidades de data warehouse para seu pool SQL dedicado (anteriormente SQL DW), tente dimensionar para cima e para baixo. Execute algumas consultas com números diferentes de unidades de armazém de dados depois de carregar os dados. Como o dimensionamento é rápido, você pode tentar vários níveis de desempenho em uma hora ou menos.
Recomendações para encontrar o melhor número de unidades de armazém de dados:
- Para um pool SQL dedicado (anteriormente SQL DW) em desenvolvimento, comece selecionando um número menor de unidades de data warehouse. Um bom ponto de partida é DW400c ou DW200c.
- Monitore o desempenho do seu aplicativo, observando o número de unidades de data warehouse selecionadas em comparação com o desempenho observado.
- Suponha uma escala linear e determine quanto você precisa aumentar ou diminuir as unidades de data warehouse.
- Continue fazendo ajustes até atingir um nível de desempenho ideal para seus requisitos de negócios.
Quando expandir
A expansão das unidades de data warehouse afeta estes aspetos do desempenho:
- Linearly melhora o desempenho do sistema para verificações, agregações e instruções CTAS.
- Aumenta o número de leitores e gravadores para carregar dados.
- Número máximo de consultas simultâneas e slots de simultaneidade.
Recomendações para quando expandir as unidades de data warehouse:
- Antes de executar uma operação pesada de carregamento ou transformação de dados, dimensione-se para disponibilizar os dados mais rapidamente.
- Durante o horário comercial de pico, dimensione para acomodar um número maior de consultas simultâneas.
E se a expansão não melhorar o desempenho?
Adicionar unidades de armazém de dados aumentando o paralelismo. Se o trabalho for dividido uniformemente entre os nós de computação, o paralelismo adicional melhorará o desempenho da consulta. Se a expansão não está mudando seu desempenho, há algumas razões pelas quais isso pode acontecer. Seus dados podem estar distorcidos nas distribuições ou as consultas podem estar introduzindo uma grande quantidade de movimentação de dados. Para investigar problemas de desempenho de consulta, consulte Solução de problemas de desempenho.
Pausar e retomar computação
Pausar a computação faz com que a camada de armazenamento se desanexe dos nós de computação. Os recursos de computação são liberados da sua conta. Você não será cobrado pela computação enquanto a computação estiver pausada. Retomar a computação reconecta o armazenamento aos nós de Computação e retoma os encargos para a Computação. Quando você pausa um pool SQL dedicado (anteriormente SQL DW):
- Os recursos de computação e memória são retornados ao pool de recursos disponíveis no data center
- Os custos unitários do armazém de dados são zero durante a pausa.
- O armazenamento de dados não é afetado e os seus dados permanecem intactos.
- Todas as operações em execução ou enfileiradas são canceladas.
- Os contadores do Detran são redefinidos.
Quando você retoma um pool SQL dedicado (anteriormente SQL DW):
- O pool SQL dedicado (anteriormente SQL DW) adquire recursos de computação e memória para sua configuração de unidades de data warehouse.
- Retome as cobranças de computação para suas unidades de data warehouse.
- Os seus dados ficam disponíveis.
- Depois que o pool SQL dedicado (anteriormente SQL DW) estiver online, você precisará reiniciar suas consultas de carga de trabalho.
Se você sempre quiser que seu pool SQL dedicado (anteriormente SQL DW) seja acessível, considere reduzi-lo para o menor tamanho em vez de pausar.
Para obter as etapas de pausa e retomada, consulte o portal do Azure ou os inícios rápidos do PowerShell. Você também pode usar a API REST de pausa ou a API REST de currículo.
Drenar transações antes de colocar em pausa ou dimensionar
Recomendamos permitir que as transações existentes sejam concluídas antes de iniciar uma operação de pausa ou dimensionamento.
Quando você pausa ou dimensiona seu pool SQL dedicado (anteriormente SQL DW), nos bastidores suas consultas são canceladas quando você inicia a solicitação de pausa ou dimensionamento. Cancelar uma consulta SELECT simples é uma operação rápida e quase não tem impacto sobre o tempo que demora a colocar em pausa ou a dimensionar a sua instância. No entanto, as consultas transacionais que modificam os seus dados ou a estrutura dos mesmos, podem não ser paradas rapidamente. As consultas transacionais, por definição, têm de ser concluídas na sua totalidade ou têm de reverter as alterações. A reversão do trabalho concluído por uma consulta transacional pode demorar tanto tempo, ou mais, como a alteração original que a consulta aplicou. Por exemplo, se cancelar uma consulta que estava a eliminar linhas e que já estiva a ser executada há uma hora, o sistema pode demorar uma hora a inserir novamente as linhas que foram eliminadas. Se colocar em pausa ou dimensionar enquanto as transações estiverem a decorrer, a colocação em pausa ou o dimensionamento podem demorar muito tempo, uma vez que a colocação em pausa e o dimensionamento têm de aguardar que a reversão esteja concluída para poderem continuar.
Consulte também Noções básicas sobre transações e Otimização de transações.
Automatizar a gestão de computação
Para automatizar as operações de gerenciamento de computação, consulte Gerenciar computação com funções do Azure.
Cada uma das operações de escalamento horizontal, pausa e retoma pode demorar vários minutos a concluir. Se você estiver dimensionando, pausando ou retomando automaticamente, recomendamos implementar a lógica para garantir que determinadas operações tenham sido concluídas antes de prosseguir com outra ação. Verificar o estado do pool SQL dedicado (anteriormente SQL DW) por meio de vários pontos de extremidade permite que você implemente corretamente a automação de tais operações.
Para verificar o estado do pool SQL dedicado (anteriormente SQL DW), consulte o início rápido do PowerShell ou T-SQL . Você também pode verificar o estado do pool SQL dedicado (anteriormente SQL DW) com uma API REST.
Permissões
O dimensionamento do pool SQL dedicado (anteriormente SQL DW) requer as permissões descritas em ALTER DATABASE. Pausar e Retomar exigem a permissão de Colaborador do Banco de Dados SQL , especificamente Microsoft.Sql/servers/databases/action.
Próximos passos
Veja o guia de como gerenciar computação Outro aspeto do gerenciamento de recursos de computação é a alocação de diferentes recursos de computação para consultas individuais. Para obter mais informações, consulte Classes de recursos para gerenciamento de carga de trabalho.