Share via


Dietro le quinte di Azure Synapse Pathway

Si applica a:Azure Synapse Analytics

L'obiettivo di Azure Synapse Pathway è mantenere la finalità funzionale del codice originale durante l'ottimizzazione per Synapse SQL. Synapse Pathway usa un processo in tre fasi per convertire il codice SQL da un sistema di origine ad Azure Synapse SQL.

Ognuna delle fasi mantiene e aumenta la conoscenza dell'origine includendo metadati specifici dell'origine per garantire la massima qualità nella conversione.

Diagram explaining the Azure Synapse Pathway source, translation, and output

Fase 1 - Lessicalizzazione e analisi

L'analisi del linguaggio SQL è un problema che è stato risolto molte volte. Sono disponibili molti parser commerciali e open source in grado di agevolare il processo sottostante che consiste nel prendere un'istruzione di origine, suddividerla in token logici e quindi eseguirla a fronte di un set di regole del parser per assicurare la coerenza del linguaggio.

Synapse Pathway definisce le grammatica di origine che consente allo strumento di identificare ed elaborare l'input SQL in un albero sintattico astratto ampliato usato in ulteriori attività di elaborazione.

Fase 2 - Albero sintattico astratto ampliato

Synapse Pathway definisce una rappresentazione comune di tutti gli oggetti in un albero sintattico astratto ampliato. L'albero sintattico astratto di Pathway include metadati da altre istruzioni o altri frammenti per favorire la conversione corretta di un'istruzione.

Verificando non solo che un token sia una funzione, ma piuttosto il requisito del tipo di sistema di origine, i componenti di generazione di script possono prendere decisioni più intelligenti sulla conversione in Synapse SQL.

Ad esempio, la funzione di origine per la funzione assoluta è definita come:

ABS( float_expression ) 

Azure Synapse SQL definisce la funzione assoluta come:

ABS ( numeric_expression )  

In questo semplice caso, Synapse Pathway riconosce che la conversione in Synapse SQL da float a numeric è una conversione implicita e non richiede ulteriori cast di tipi. Conversione di codice semplice, pulita ed efficace.

Mantenere queste meta-informazioni sulle istruzioni e sui frammenti di origine agevola la distinzione strutturale tra le piattaforme, ad esempio le conversioni nella logica di opt-out per i predicati delle condizioni di ricerca in una clausola WHERE.

Fase 3 - Generazione della sintassi

L'ultima fase del processo consiste nel generare la sintassi per Synapse SQL. Usando la struttura dell'albero sintattico astratto generata dai file di origine, Synapse Pathway scrive ogni oggetto DDL in un singolo file. I generatori di sintassi usano informazioni approfondite sulla piattaforma di destinazione per ottimizzare le istruzioni.

Ad esempio, un modello comune negli scenari di caricamento dei dati consiste nell'eliminare prima tutto il contenuto di una tabella di staging e quindi caricare i dati da un'altra tabella di staging con un'operazione di tipo INSERT/SELECT.

DELETE staging.table1 ALL;
INSERT INTO staging.table1…
FROM staging.table2;

Synapse SQL ha un percorso ottimizzato per questo scenario, ovvero CREATE TABLE AS SELECT. L'istruzione CTAS è un'operazione basata su batch e registrazione minima, che consente prestazioni elevate grazie all'uso di tutta l'infrastruttura di calcolo disponibile. Senza queste informazioni dettagliate su Synapse SQL, gli strumenti spesso producono un troncamento e un'istruzione INSERT/SELECT.

TRUNCATE TABLE staging.table1;
INSERT INTO staging.table1…
FROM staging.table2;

Pur non essendo di scarso livello, questo codice può essere ottimizzato in una DROP TABLE e CTAS per ottenere prestazioni superiori.

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;

Passaggi successivi