Dans les coulisses d’Azure Synapse Pathway
S’applique à : 
Azure Synapse Analytics
L’objectif d’Azure Synapse Pathway est de préserver l’intention fonctionnelle du code d’origine tout en effectuant une optimisation pour Synapse SQL. Synapse Pathway utilise un processus en trois phases pour traduire le code SQL d’un système source vers Azure Synapse SQL.
Chacune des phases préserve et augmente la connaissance de la source, y compris les métadonnées spécifiques à la source, pour garantir la meilleure qualité de la traduction.
Phase 1 : Segmentation et analyse
L’analyse du langage SQL est un problème qui a été résolu depuis longtemps. Il existe de nombreux analyseurs commerciaux et open source qui facilitent le processus sous-jacent consistant à prendre une instruction source, à la décomposer en jetons logiques, puis à exécuter un ensemble de règles d’analyse pour garantir la cohérence du langage.
Synapse Pathway définit des grammaires sources qui permettent à l’outil d’identifier et de traiter l’entrée SQL en une arborescence de syntaxe abstraite (AST) augmentée, qui est utilisée dans un traitement ultérieur.
Phase 2 : Arborescence de syntaxe abstraite (AST) augmentée
Synapse Pathway définit une représentation commune de tous les objets dans une arborescence de syntaxe abstraite (AST) augmentée. L’arborescence AST de Pathway comprend des métadonnées provenant d’autres instructions ou fragments pour faciliter la conversion d’une instruction.
En n’établissant pas simplement qu’un jeton est une fonction mais plutôt la spécification du type du système source, les composants de génération de script peuvent prendre des décisions plus intelligentes quant à la traduction vers Synapse SQL.
Par exemple, la fonction source pour la fonction « absolute » (absolu) est définie comme suit :
ABS( float_expression )
Azure Synapse SQL définit la fonction « absolute » comme suit :
ABS ( numeric_expression )
Dans ce cas simple, Synapse Pathway comprend que la conversion en Synapse SQL de flottant en numérique est une conversion implicite et ne nécessite aucun cast de type supplémentaire. Traduction du code simple, propre et efficace.
Conserver ces méta-informations sur les instructions et les fragments sources permet de résoudre les différences structurelles entre les plateformes, par exemple les conversions en logique de refus pour les prédicats des conditions de recherche dans une clause WHERE.
Phase 3 : Génération de la syntaxe
La dernière phase du processus est de générer une syntaxe pour Synapse SQL. En utilisant la structure AST générée à partir des fichiers sources, Synapse Pathway écrit chaque objet DDL dans un fichier individuel. Les générateurs de syntaxe utilisent une connaissance approfondie de la plateforme cible pour optimiser les instructions.
Par exemple, un modèle courant observé dans les scénarios de chargement de données est de d’abord supprimer tout le contenu d’une table intermédiaire, puis de charger les données à partir d’une autre table intermédiaire en mode INSERT/SELECT.
DELETE staging.table1 ALL;
INSERT INTO staging.table1…
FROM staging.table2;
Synapse SQL a un chemin optimisé pour ce scénario : une instruction CREATE TABLE AS SELECT. L’instruction CTAS est une opération par lot avec journalisation minimale, qui offre un niveau de performance élevé en utilisant toute l’infrastructure de calcul disponible. Sans cette connaissance de Synapse SQL, les outils produisent souvent des instructions TRUNCATE et INSERT/SELECT.
TRUNCATE TABLE staging.table1;
INSERT INTO staging.table1…
FROM staging.table2;
Bien qu’il ne soit pas incorrect, ce code peut être optimisé en instructions TABLE DROP et CTAS pour obtenir de meilleures performances.
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;