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

Azure Synapse Pathway: сопутствующие ресурсы

  • Статья

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

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

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

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

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

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

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

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

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

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

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

ABS( float_expression )

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

ABS ( numeric_expression )

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

Хранение этих метаданных об исходных инструкциях и фрагментах помогает понять структурные различия между платформами, например преобразования в логике отказа для предикатов условий поиска в предложении 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 средства часто выполняют усечение и создают инструкции 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;

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