Hinter den Kulissen von Azure Synapse Pathway

Gilt für:Azure Synapse Analytics

Das Ziel von Azure Synapse Pathway ist der Erhalt der funktionalen Absicht des ursprünglichen Codes bei gleichzeitiger Optimierung für Synapse SQL. Die Übersetzung von SQL-Code aus einem Quellsystem für Azure Synapse SQL in Synapse Pathway besteht aus drei Phasen.

In jeder dieser Phasen wird das Wissen aus der Quelle einschließlich quellspezifischer Metadaten beibehalten und erweitert, um bei der Übersetzung die bestmögliche Qualität sicherzustellen.

Phase 1: Lexing und Analyse

Die Analyse von SQL-Code ist ein Problem, für das es bereits viele Lösungen gibt. Es gibt zahlreiche kommerzielle und quelloffene Parser, die Unterstützung für den zugrunde liegenden Prozess der Aufteilung einer Quellanweisung in logische Token und Ausführung für eine Gruppe von Parserregeln zur Sicherstellung von Sprachkonsistenz bieten.

Synapse Pathway definiert Quellgrammatiken, die es dem Tool ermöglichen, die SQL-Eingabe zu identifizieren und in einer erweiterten abstrakten Syntaxstruktur (Abstract Syntax Tree, AST) weiterzuverarbeiten.

Phase 2: Erweiterte abstrakte Syntaxstruktur (AST)

Synapse Pathway definiert eine allgemeine Darstellung aller Objekte in einer erweiterten abstrakten Syntaxstruktur (AST). Die Pathway-AST enthält Metadaten aus anderen Anweisungen oder Fragmenten, um die ordnungsgemäße Konvertierung einer Anweisung zu unterstützen.

Wenn nicht nur nachverfolgt wird, dass es sich bei einem Token um eine Funktion handelt, sondern auch die Typanforderungen des Quellsystems, können die Skriptgenerierungskomponenten intelligentere Entscheidungen hinsichtlich der Übersetzung für Synapse SQL treffen.

Beispielsweise wird die Quellfunktion für die absolute Funktion wie folgt definiert:

ABS( float_expression ) 

Azure Synapse SQL definiert die absolute Funktion wie folgt:

ABS ( numeric_expression )  

In diesem einfachen Fall versteht Synapse Pathway, dass es sich bei der Konvertierung von „float“ in „numeric“ in Synapse SQL um eine implizite Konvertierung handelt und keine weitere Typumwandlung erforderlich ist. Die Codeübersetzung ist einfach, sauber und effektiv.

Das Beibehalten dieser Metainformationen zu den Quellanweisungen und Fragmenten ist hilfreich bei strukturellen Unterschieden zwischen Plattformen, z. B. bei Konvertierungen in Deaktivierungslogik für Suchbedingungsprädikate in WHERE-Klauseln.

Phase 3: Syntaxgenerierung

Die letzte Phase des Prozesses ist das Generieren von Syntax für Synapse SQL. Synapse Pathway schreibt basierend auf der aus den Quelldateien generierten AST-Struktur jedes DDL-Objekt in eine eigene Datei. Die Syntax-Generatoren verwenden für die Optimierung von Anweisungen detailliertes Wissen über die Zielplattform.

Ein gängiges Muster bei Szenarios, in denen Daten geladen werden, besteht beispielsweise darin, erst den gesamten Inhalt einer Stagingtabelle zu löschen und dann mit INSERT/SELECT die Daten aus einer anderen Stagingtabelle zu laden.

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

Synapse SQL verfügt über einen für dieses Szenario optimierten Pfad: CREATE TABLE AS SELECT. Bei der CTAS-Anweisung handelt es sich um einen batchbasierten, in minimalem Umfang protokollierten Vorgang mit hoher Leistung durch Nutzung der gesamten verfügbaren Computeinfrastruktur. Ohne diese Erkenntnisse zu Synapse SQL erzeugen Tools häufig TRUNCATE- und INSERT/SELECT-Anweisungen.

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

Dies ist zwar nicht schlecht, aber der Code kann mit DROP TABLE und CTAS optimiert werden, um eine höhere Leistung zu erzielen.

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;

Nächste Schritte

• Azure Synapse Pathway herunterladen
• Häufig gestellte Fragen