Partilhar via


O que é a arquitetura SQL do Azure Synapse?

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.

Componentes da arquitetura Synapse SQL

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.

Screenshot da arquitetura Synapse SQL.

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:

  • Aumente ou diminua o poder de computação, dentro de um pool SQL dedicado, sem mover dados.
  • Colocar a capacidade de computação em pausa, mantendo os dados intactos, pelo que só paga pelo armazenamento.
  • Retomar a capacidade de computação durante as horas de funcionamento.

Armazenamento do Azure

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:

  • Hash
  • Round Robin
  • Replicar

Nó de controlo

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ó.

Nós de computação

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.

Serviço de Movimento de Dados

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.

Distribuições

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.

Tabelas distribuídas com hash

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.

Captura de tela de uma tabela armazenada como uma distribuição de hash.

  • Cada linha pertence a uma distribuição.
  • Um algoritmo hash determinista atribui cada linha a uma distribuição.
  • O número de linhas da tabela por distribuição varia conforme mostrado pelos diferentes tamanhos das tabelas.

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.

Tabelas distribuídas por round robin

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.

Tabelas replicadas

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.

Captura de tela da tabela replicada 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.