Bastidores do Azure Synapse Pathway
Aplica-se a: 
Azure Synapse Analytics
A meta do Azure Synapse Pathway é preservar a intenção funcional do código original durante a otimização do SQL do Synapse. O Synapse Pathway usa um processo de três fases para converter o código SQL de um sistema de origem para o SQL do Azure Synapse.
Cada uma das fases preservará e aumentará o conhecimento da fonte, incluindo metadados específicos da fonte, a fim de garantir a mais alta qualidade na conversão.
Fase 1 – Léxico e análise
A análise da Linguagem SQL é um problema que foi resolvido várias vezes. Há vários analisadores comerciais e de software livre que ajudam no processo subjacente de obtenção de uma instrução de origem. Eles dividem a instrução em tokens lógicos e a executam em conjunto ou em regras do analisador a fim de garantir a consistência da linguagem.
O Synapse Pathway define gramáticas de origem. Elas permitem que a ferramenta identifique e processe a entrada SQL em uma AST (Árvore de Sintaxe Abstrata) aumentada que será usada em um processamento adicional.
Fase 2 – AST (Árvore de Sintaxe Abstrata) aumentada
O Synapse Pathway define uma representação comum de todos os objetos em uma AST (Árvore de Sintaxe Abstrata) aumentada. O AST do Pathway inclui metadados de outras instruções ou fragmentos para ajudar na conversão adequada de uma instrução.
Os componentes de geração de script podem tomar decisões mais inteligentes sobre a conversão para o SQL do Synapse ao acompanhar não somente se um token é uma função, mas também o requisito do tipo de sistema de origem.
Por exemplo, a função de origem da função absoluta será definida como:
ABS( float_expression )
O SQL do Azure Synapse definirá a função absoluta como:
ABS ( numeric_expression )
Nesse caso simples, o Synapse Pathway entende que a conversão de float para numérico no SQL do Synapse é uma conversão implícita que não requer conversões adicionais de tipo. Uma conversão de código simples, limpa e eficaz.
Manter essas metainformações sobre as instruções e os fragmentos de origem ajudará a obter diferenças estruturais entre plataformas, como as conversões em lógica de recusa para predicados de critérios de pesquisa em uma cláusula WHERE, por exemplo.
Fase 3 – Geração de sintaxe
A última fase do processo é gerar uma sintaxe para o SQL do Synapse. Ao usar uma estrutura AST gerada dos arquivos de origem, o Synapse Pathway gravará cada objeto DDL em um arquivo individual. Os geradores de sintaxe usam um conhecimento profundo da plataforma de destino para otimizar instruções.
Por exemplo, um padrão comum visto em cenários de carregamento de dados é excluir primeiro todo o conteúdo de uma tabela de preparo e carregar os dados de outra tabela de preparo do mesmo modo que uma instrução INSERT/SELECT.
DELETE staging.table1 ALL;
INSERT INTO staging.table1…
FROM staging.table2;
O SQL do Synapse tem um caminho otimizado para esse cenário: CREATE TABLE AS SELECT. A instrução CTAS é uma operação baseada em lote e minimamente registrada, gerando alto desempenho ao usar toda a infraestrutura de computação disponível. Sem esse insight sobre o SQL do Synapse, as ferramentas geralmente produzem uma instrução INSERT/SELECT truncada.
TRUNCATE TABLE staging.table1;
INSERT INTO staging.table1…
FROM staging.table2;
Embora isso não seja ruim, esse código poderá ser otimizado para uma instrução DROP TABLE e CTAS a fim de obter um desempenho mais alto.
DROP TABLE staging.table1;
CREATE TABLE staging.table1
WITH
(
-- Derived from the original table definition
DISTRIBUTION = HASH(column1),
-- Derived from the original table definition
CLUSTERED COLUMNSTORE INDEX
)
AS SELECT * FROM staging.table2;