Arquitetura do SQL do Azure Synapse

Este artigo descreve os componentes de arquitetura do SQL do Synapse. Ele também explica como o SQL do Azure Synapse combina capacidades de processamento de consulta distribuída com o Armazenamento do Azure para obter escalabilidade e alto desempenho.

Componentes de arquitetura do SQL do Synapse

O SQL do Synapse usa uma arquitetura de expansão para distribuir o processamento computacional dos dados em vários nós de expansão. A computação é separada do armazenamento, o que permite que você dimensione a computação independentemente dos dados em seu sistema.

Para o pool de SQL dedicado, a unidade de escala é uma abstração de poder de computação que é conhecida como unidade de data warehouse.

Para o pool de SQL 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 sucesso. Por exemplo, a imagem abaixo mostra o pool de SQL sem servidor utilizando quatro nós de computação para executar uma consulta.

O SQL do Synapse usa uma arquitetura baseada em nó. Aplicativos conectam e emitem comandos T-SQL para um nó de Controle, que é o ponto único de entrada para SQL do Synapse.

O nó de controle do SQL do Azure Synapse utiliza um mecanismo de consulta distribuída para otimizar consultas para processamento paralelo e, em seguida, passa as operações para nós de computação para realizar seu trabalho em paralelo.

O nó de controle do pool de SQL sem servidor utiliza o mecanismo DQP (processamento de consultas distribuídas) 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 consulta pequena é chamada de tarefa e representa a unidade de execução distribuída. Ela lê arquivos do armazenamento, une resultados de outras tarefas, agrupa ou solicita os dados recuperados de outras tarefas.

Os nós de Computação armazenam todos os dados de usuário no Armazenamento do Azure e executam as consultas paralelas. O serviço de movimentação de dados (DMS) é um serviço de nível de sistema interno que move dados entre os nós, conforme necessário para executar consultas em paralelo e retornar resultados precisos.

Com o armazenamento e a computação separados, ao usar o SQL do Synapse, é possível se beneficiar de um dimensionamento independente da potência de computação, independentemente das suas necessidades de armazenamento. Para o pool de SQL sem servidor, a colocação em escala é feita automaticamente, enquanto que no pool de SQL dedicado, é possível:

• Aumentar ou reduzir a potência de computação em um pool de SQL dedicado sem mover os dados.
• Pause a capacidade de computação ao deixar dados intactos para que você só pague pelo armazenamento.
• Retomar a capacidade de computação durante horas operacionais.

Armazenamento do Azure

O SQL do Synapse usa o armazenamento do Azure para manter os dados do usuário protegidos. Como os dados são armazenados e gerenciados pelo armazenamento do Azure, é gerada uma cobrança separada para o consumo de armazenamento.

O pool de SQL sem servidor permite consultar os arquivos do data lake, enquanto o pool de SQL dedicado permite consultar e ingerir dados dos arquivos do data lake. Quando os dados são ingeridos no pool de SQL dedicados, eles são divididos em distribuições para otimizar o desempenho do sistema. Você pode escolher qual padrão de fragmentação usar para distribuir os dados quando você define a tabela. Esses padrões de fragmentação são compatíveis com:

• Hash
• Round Robin
• Replicar

Nó de controle

O nó de controle é o cérebro da arquitetura. É o front-end que interage com todos os aplicativos e todas as conexões.

No SQL do Synapse, o mecanismo de consulta distribuída é executado no nó de controle para otimizar e coordenar consultas paralelas. Quando você envia uma consulta T-SQL ao pool de SQL dedicado, o nó de Controle a transforma em consultas que são executadas em cada distribuição paralelamente.

No pool de SQL sem servidor, o mecanismo DQP é executado no nó de controle para otimizar e coordenar a execução distribuída da consulta do usuário, dividindo-a em consultas menores que serão executadas em nós de computação. Também atribui conjuntos de arquivos a serem processados por cada nó.

Nós de computação

Os nós de computação fornecem capacidade de computação.

No pool de SQL dedicado, 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 intervalos de nós de 1 a 60 de computação e é determinado pelo nível de serviço para o pool de SQL dedicado. Cada nó de computação tem uma ID de nó que está visível nas exibições do sistema. Você pode ver a ID do nó de Computação olhando para a coluna node_id nas exibições do sistema cujos nomes começam com sys.pdw_nodes. Para obter uma lista das exibições de sistema, confira Exibições do sistema SQL do Synapse.

No pool de SQL sem servidor, a cada nó de computação é atribuída uma tarefa e um conjunto de arquivos para executar a tarefa. A tarefa é uma unidade de execução de consulta distribuída, que na verdade faz parte do usuário de consulta enviada. 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 movimentação de dados

O Serviço de movimentação de dados (DMS) é a tecnologia de transporte de dados no pool de SQL dedicado que coordena a movimentação de dados entre os nós de computação. Algumas consultas exigem a movimentação de dados para garantir que as consultas paralelas retornem resultados precisos. Quando a movimentação de dados é necessária, DMS garante que os dados corretos cheguem ao local correto.

Distribuições

Uma distribuição é a unidade básica de armazenamento e processamento para consultas paralelas que são executadas em dados distribuídos no pool de SQL dedicado. Quando o pool de 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 um ou mais de 60 distribuições. Um pool de SQL dedicado com recursos de computação máximos tem uma distribuição por nó de computação. Um pool de SQL dedicado com recursos de computação mínimos tem todas as distribuições em um nó de computação.

Tabelas distribuídas em hash

Uma tabela de hash distribuída pode fornecer o melhor desempenho de consulta para junções e agregações em tabelas grandes.

Para fragmentar dados em uma tabela distribuída por hash, o pool de SQL dedicado usa uma função de hash para atribuir de forma determinada cada linha a uma distribuição. Na definição de tabela, uma das colunas é designada como a coluna de distribuição. A função de hash usa valores na coluna de distribuição para atribuir cada linha a uma distribuição.

O diagrama a seguir ilustra como uma (tabela não distribuída) completa é armazenada como uma tabela distribuída em hash.

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

Há considerações de desempenho para a seleção de uma coluna de distribuição, como distinção, distorção de dados e tipos de consultas executadas no sistema.

Tabelas distribuídas round robin

Uma tabela de round-robin é a tabela mais simples para criar e oferece um desempenho rápido quando usada como uma tabela de preparo para cargas.

Uma tabela distribuída round-robin distribui dados uniformemente entre a tabela, mas sem qualquer otimização adicional. Uma distribuição é escolhida primeiramente de forma aleatória e, em seguida, buffers de linhas são atribuídos a distribuições em sequência. É rápido carregar dados em uma tabela de round-robin, mas o desempenho da consulta geralmente pode ser melhor com tabelas de hash distribuídas. Junções de tabelas de round-robin exigem nova recombinação de dados, e isso leva tempo extra.

Tabelas replicadas

Uma tabela replicada fornece o melhor desempenho de consulta para tabelas pequenas.

Uma tabela replicada faz cache de uma cópia completa da tabela em cada nó de computação. Então, replicar uma tabela elimina a necessidade de transferir dados entre nós de computação antes de uma junção ou agregação. Tabelas replicadas são melhor usadas com tabelas pequenas. Armazenamento extra é necessário e há custos adicionais ao gravar dados que tornam grandes tabelas inexequíveis.

O diagrama a seguir mostra uma tabela replicada armazenada em cache na primeira distribuição em cada nó de computação.

Próximas etapas

Agora que você já sabe um pouco sobre o SQL do Synapse, saiba como criar rapidamente um pool de SQL dedicado e carregar dados de exemplo. Ou comece usando pool de SQL sem servidor. Se você ainda não conhece o Azure, o Glossário do Azure poderá ser útil quando encontrar nova terminologia.