evento
Junte-se a nós na FabCon Vegas
31/03, 23 - 2/04, 23
O melhor evento liderado pela comunidade Microsoft Fabric, Power BI, SQL e AI. 31 de março a 2 de abril de 2025.
Registe-se hoje mesmoEste browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
Este artigo descreve os componentes de arquitetura do Synapse SQL. Ele também explica como o Azure Synapse SQL combina recursos de processamento de consultas distribuídas com o Armazenamento do Azure para obter alto desempenho e escalabilidade.
O Synapse SQL usa uma arquitetura de expansão para distribuir o processamento computacional de dados em vários nós. A computação é separada do armazenamento, o que permite dimensioná-la independentemente dos dados no sistema.
Para pool SQL dedicado, a unidade de escala é uma abstração do poder de computação que é conhecida como uma unidade de data warehouse.
Para o pool SQL sem servidor, sendo sem servidor, o dimensionamento é feito automaticamente para acomodar os requisitos de recursos de consulta. À medida que a topologia muda ao longo do tempo adicionando, removendo nós ou failovers, ela se adapta às alterações e garante que sua consulta tenha recursos suficientes e seja concluída com êxito. Por exemplo, a imagem a seguir mostra o pool SQL sem servidor usando quatro nós de computação para executar uma consulta.
Synapse SQL usa uma arquitetura baseada em nó. Os aplicativos se conectam e emitem comandos T-SQL para um nó Control, que é o único ponto de entrada para Synapse SQL.
O nó Controle SQL do Azure Synapse utiliza um mecanismo de consulta distribuído para otimizar consultas para processamento paralelo e, em seguida, passa operações para nós de computação para fazer seu trabalho em paralelo.
O nó Controle do pool SQL sem servidor utiliza o mecanismo DQP (Distributed Query Processing) para otimizar e orquestrar a execução distribuída da consulta do usuário, dividindo-a em consultas menores que serão executadas nos nós de computação. Cada pequena consulta é chamada de tarefa e representa a unidade de execução distribuída. Ele lê arquivo(s) do armazenamento, une resultados de outras tarefas, grupos ou ordena dados recuperados de outras tarefas.
Os nós de computação armazenam todos os dados de utilizador no Armazenamento do Microsoft Azure e executam as consultas paralelas. O Serviço de Movimento de Dados (DMS – Data Movement Service) é um serviço interno ao nível do sistema que move os dados em todos os nós, conforme necessário, para executar consultas em paralelo e devolver resultados precisos.
Com o armazenamento e a computação dissociados, ao usar o Synapse SQL, pode-se beneficiar do dimensionamento independente do poder de computação, independentemente das suas necessidades de armazenamento. Para o escalonamento do pool SQL sem servidor é feito automaticamente, enquanto para o pool SQL dedicado pode-se:
O Synapse SQL usa o Armazenamento do Azure para manter seus dados de usuário seguros. Como seus dados são armazenados e gerenciados pelo Armazenamento do Azure, há uma cobrança separada para seu consumo de armazenamento.
O pool SQL sem servidor permite que você consulte seus arquivos de data lake, enquanto o pool SQL dedicado permite que você consulte e ingira dados de seus arquivos de data lake. Quando os dados são ingeridos no pool SQL dedicado, os dados são fragmentados em distribuições para otimizar o desempenho do sistema. Pode escolher o padrão de fragmentação que será utilizado para distribuir os dados, ao definir a tabela. Estes padrões de fragmentação são suportados:
O nó de Controlo é o cérebro da arquitetura. É o front-end que interage com todas as ligações e aplicações.
No Synapse SQL, o mecanismo de consulta distribuído é executado no nó Control para otimizar e coordenar consultas paralelas. Quando você envia uma consulta T-SQL para um pool SQL dedicado, o nó Control a transforma em consultas que são executadas em cada distribuição em paralelo.
No pool SQL sem servidor, o mecanismo DQP é executado no nó Controle para otimizar e coordenar a execução distribuída da consulta do usuário, dividindo-a em consultas menores que serão executadas nos nós de computação. Ele também atribui conjuntos de arquivos a serem processados por cada nó.
Os nós de Computação conferem capacidade de computação.
No pool SQL dedicado, as distribuições são mapeadas para nós de computação para processamento. À medida que você paga por mais recursos de computação, o pool remapeia as distribuições para os nós de computação disponíveis. O número de nós de computação varia de 1 a 60 e é determinado pelo nível de serviço para o pool SQL dedicado. Cada nó de computação tem um ID de nó que é visível nas exibições do sistema. Você pode ver a ID do nó de computação procurando a coluna node_id nas visualizações do sistema cujos nomes começam com sys.pdw_nodes. Para obter uma lista dessas exibições do sistema, consulte Exibições do sistema Synapse SQL.
No pool SQL sem servidor, cada nó de computação recebe uma tarefa e um conjunto de arquivos para executar a tarefa. A tarefa é a unidade de execução de consulta distribuída, que na verdade faz parte da consulta enviada pelo usuário. O dimensionamento automático está em vigor para garantir que nós de computação suficientes sejam utilizados para executar a consulta do usuário.
O Data Movement Service (DMS) é a tecnologia de transporte de dados no pool SQL dedicado que coordena a movimentação de dados entre os nós de computação. Algumas consultas exigem movimentação de dados para garantir que as consultas paralelas retornem resultados precisos. Quando a movimentação de dados é necessária, o DMS garante que os dados certos cheguem ao local certo.
Uma distribuição é a unidade básica de armazenamento e processamento para consultas paralelas que são executadas em dados distribuídos em pool SQL dedicado. Quando o pool SQL dedicado executa uma consulta, o trabalho é dividido em 60 consultas menores que são executadas em paralelo.
Cada uma das 60 consultas menores é executada em uma das distribuições de dados. Cada nó de computação gerencia uma ou mais das 60 distribuições. Um pool SQL dedicado com o máximo de recursos de computação tem uma distribuição por nó de computação. Um pool SQL dedicado com recursos mínimos de computação tem todas as distribuições em um nó de computação.
Uma tabela distribuída com hash pode proporcionar o mais elevado desempenho de consulta para associações e agregações em tabelas grandes.
Para realizar a extensão de dados numa tabela distribuída por hash, o conjunto de SQL dedicado utiliza a função de hash para atribuir de forma determinista cada fila a uma distribuição. Na definição da tabela, uma das colunas será a coluna de distribuição. A função hash utiliza os valores da coluna de distribuição para atribuir cada linha a uma distribuição.
O diagrama seguinte ilustra como uma tabela não distribuída completa é armazenada como uma tabela distribuída por hash.
Há considerações de desempenho para a seleção de uma coluna de distribuição, como distinção, distorção de dados e os tipos de consultas que são executadas no sistema.
Uma mesa round-robin é a mesa mais simples de criar e oferece desempenho rápido quando usada como uma mesa de preparo para cargas.
As tabelas distribuídas com round robin distribuem uniformemente os dados por uma tabela, mas sem qualquer otimização adicional. Uma distribuição é primeiro escolhida aleatoriamente e, em seguida, buffers de linhas são atribuídos a distribuições sequencialmente. É rápido carregar dados em uma tabela round-robin, mas o desempenho da consulta geralmente pode ser melhor com tabelas distribuídas por hash. As junções em mesas round-robin requerem a reorganização dos dados, o que leva mais tempo.
As tabelas replicadas proporcionam o desempenho de consulta mais rápido para tabelas pequenas.
Uma tabela replicada armazena em cache uma cópia completa da tabela em cada nó de computação. Assim, replicar uma tabela elimina a necessidade de transferir dados entre nós de computação antes de uma junção ou agregação. Idealmente, as tabelas replicadas devem ser utilizadas com tabelas pequenas. É necessário armazenamento extra e há sobrecarga extra incorrida ao gravar dados, o que torna as tabelas grandes impraticáveis.
O diagrama abaixo mostra uma tabela replicada que é armazenada em cache na primeira distribuição em cada nó de computação.
Agora que você sabe um pouco sobre o Synapse SQL, saiba como criar rapidamente um pool SQL dedicado e carregar dados de exemplo. Ou comece a usar o pool SQL sem servidor. Se você é novo no Azure, pode achar o glossário do Azure útil à medida que encontrar uma nova terminologia.
evento
Junte-se a nós na FabCon Vegas
31/03, 23 - 2/04, 23
O melhor evento liderado pela comunidade Microsoft Fabric, Power BI, SQL e AI. 31 de março a 2 de abril de 2025.
Registe-se hoje mesmoFormação
Percurso de aprendizagem
Criar soluções de análises de dados com os conjuntos de SQL sem servidor do Azure Synapse - Training
Criar soluções de análises de dados com os conjuntos de SQL sem servidor do Azure Synapse
Certificação
Microsoft Certified: Azure Database Administrator Associate - Certifications
Administrar uma infraestrutura de banco de dados do SQL Server para bancos de dados relacionais de nuvem, locais e híbridos usando as ofertas de banco de dados relacional do Microsoft PaaS.
Documentação
O que é pool SQL dedicado (anteriormente SQL DW)? - Azure Synapse Analytics
O pool SQL dedicado (anteriormente SQL DW) no Azure Synapse Analytics é a funcionalidade de armazenamento de dados corporativos no Azure Synapse Analytics.
Início rápido: Use o conjunto SQL sem servidor - Azure Synapse Analytics
Neste guia de início rápido, você verá e aprenderá como é fácil consultar vários tipos de arquivos usando o pool SQL sem servidor.
Azure Synapse Analytics - Azure Synapse Analytics
O Azure Synapse é um serviço de análise ilimitado que junta o armazenamento de dados empresariais e a análise de macrodados. Dá-lhe a liberdade de consultar dados nos seus termos, através de recursos a pedido ou aprovisionados sem servidor, em escala.