Поделиться через


Закулисная работа Azure Synapse Pathway

Область применения:Azure Synapse Analytics

Цель Azure Synapse Pathway — сохранить функциональное назначение исходного кода при оптимизации для Synapse SQL. Synapse Pathway использует трехэтапный процесс для преобразования кода SQL из исходной системы в Azure Synapse SQL.

Каждый из этапов сохраняет и дополняет данные об источнике, включая метаданные, относящиеся к источнику, чтобы обеспечить наивысшее качество преобразования.

Схема, на которой показаны источник, преобразование и выходные данные Azure Synapse Pathway

Этап 1. Лексический и синтаксический анализ

Синтаксический анализ SQL — это проблема, которая решена уже много раз. Существует множество парсеров, как коммерческих, так и с открытым исходным кодом, которые помогают базовому процессу, связанному с взятием исходного утверждения, разбиением его на логические элементы, а затем исполнением в соответствии с набором правил анализа, чтобы обеспечить согласованность языка.

Synapse Pathway определяет исходные грамматики, которые позволяют инструменту идентифицировать и преобразовывать SQL-входные данные в расширенное абстрактное синтаксическое дерево (AST), используемое в дальнейшем процессе.

Этап 2. Дополненное дерево абстрактного синтаксиса (AST)

Synapse Pathway определяет общее представление всех объектов в дополненном дереве абстрактного синтаксиса (AST). Pathway AST содержит метаданные из других выражений или фрагментов, чтобы правильно способствовать преобразованию выражения.

Отслеживая, что токен является не только функцией, но и требованием к типу исходной системы, компоненты генерации сценариев могут принимать более обоснованные решения о преобразовании в Synapse SQL.

Например, исходная функция для абсолютной функции определяется следующим образом:

ABS( float_expression ) 

Azure Synapse SQL определяет абсолютную функцию следующим образом:

ABS ( numeric_expression )  

В этом простом случае Synapse Pathway понимает, что преобразование в Synapse SQL из типа float в тип numeric является неявным преобразованием и не требует дальнейшего приведения типов. Простое, чистое и эффективное преобразование кода.

Хранение этих метаданных об исходных инструкциях и фрагментах помогает понять структурные различия между платформами, например преобразования в логике отказа для предикатов условий поиска в предложении WHERE.

Этап 3. Создание синтаксиса

Последний этап процесса — создание синтаксиса для Synapse SQL. Используя структуру AST, созданную из исходных файлов, Synapse Pathway передает каждый объект DDL в отдельный файл. Генераторы синтаксиса используют подробные сведения о целевой платформе для оптимизации инструкций.

Например, общий шаблон, который используется в сценариях загрузки данных, сначала удаляет все содержимое в промежуточной таблице, а затем загружает данные из другой промежуточной таблицы в режиме INSERT/SELECT.

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

В Synapse SQL имеется оптимизированный способ для этого сценария — CREATE TABLE AS SELECT. Оператор CTAS — это операция на основе пакетной обработки с минимальным логгированием, что позволяет повысить производительность за счёт использования всей доступной вычислительной инфраструктуры. Без этих аналитических сведений о Synapse SQL средства часто создают инструкции TRUNCATE и INSERT/SELECT.

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

Хотя это и неплохо, этот код можно оптимизировать с использованием DROP TABLE и CTAS для повышения производительности.

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;

Следующие шаги