Закулисная работа Azure Synapse Pathway
Область применения:Azure Synapse Analytics
Цель Azure Synapse Pathway — сохранить функциональное назначение исходного кода при оптимизации для Synapse SQL. Synapse Pathway использует трехэтапный процесс для преобразования кода SQL из исходной системы в Azure Synapse SQL.
Каждый из этапов сохраняет и дополняет данные об источнике, включая метаданные, относящиеся к источнику, чтобы обеспечить наивысшее качество преобразования.
Этап 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;