Поддерживаемые диалекты SQL

AIDA строит единый граф из двух источников: то, что разбирается из кода статически, и то, что собирается во время выполнения. Принцип страницы — честный статус: не заявлять поддержку там, где её нет.

Два способа построить граф

СпособЧто этоКогда применяется
Статический разборПарсер читает SQL и восстанавливает зависимости вплоть до колонокПроцедурный код, legacy, миграции
Сбор в рантаймеПлатформа принимает события OpenLineage от инструментов конвейераТехнологии, которые уже эмитят происхождение данных

Особенность AIDA — объединение обоих в одном графе: статический код и рантайм-поток видны вместе.

Грамматика ≠ поддержка диалекта

Важно понимать различие, чтобы не обмануться числами:

  • В парсере 18 диалектных грамматик (ANTLR4). Грамматика разбирает синтаксис — строит дерево.
  • Граф зависимостей строит семантический listener, и он есть для шести диалектов: PL/SQL, PostgreSQL, MySQL, MariaDB, ClickHouse, Trino.

То есть «18 грамматик» — это про то, что мы умеем читать; «6 диалектов с графом» — про то, где реально извлекаются зависимости. Ниже — по второму, честному, счёту.

Статический разбор

ДиалектСтатусЧто покрыто
Oracle PL/SQL✅ production99.93% разбора на 78 файлах синтезированного Oracle ERP-корпуса (255 580 строк).* Процедуры, функции, пакеты, параметры, переменные, курсоры; DML, CTE и рекурсивные CTE, JOIN, оконные функции, DDL
PostgreSQL✅ productionSELECT/INSERT/UPDATE/DELETE/MERGE, CTE/RECURSIVE, JOIN, оконные функции, CREATE TABLE (+ constraints PK/FK→REFERENCES/UNIQUE/CHECK)/VIEW/FUNCTION/PROCEDURE/TRIGGER/INDEX/SEQUENCE, ALTER TABLE, CALL, DO
MySQL✅ productionSELECT/INSERT/UPDATE/DELETE/REPLACE, DML с подзапросами, CTE, JOIN, CREATE TABLE/VIEW/FUNCTION/PROCEDURE/TRIGGER/INDEX, ALTER TABLE, CALL, курсоры, обработка исключений
MariaDB✅ productionПокрытие MySQL + специфика MariaDB: RETURNING, оконные функции, sequences
ClickHouse✅ productionSELECT/INSERT (column-level DATA_FLOW для INSERT…SELECT), CREATE TABLE/VIEW (колонки из SELECT)/MATERIALIZED VIEW (… TO target → lineage)/DICTIONARY, ALTER TABLE, CTE, JOIN, ARRAY JOIN, оконные функции
Trino✅ productionSELECT/INSERT/UPDATE/DELETE/MERGE, CTE/RECURSIVE, JOIN, LAMBDA, CREATE TABLE/VIEW/SCHEMA, оконные функции
Greenplum⚪ не отдельным диалектомANSI-совместимый SQL разбирается PostgreSQL-парсером; GP-специфика — в roadmap

* Корпус Oracle ERP — синтезированный: валидные PL/SQL-файлы, сгенерированные программно (не выгрузка одного клиента). Отдельно проверен набор из 60 трудных конструкций — оконные функции, цепочки CTE, CONNECT BY, MERGE, динамический SQL, FORALL/BULK, обработчики исключений, антипаттерны: 46 разбираются полностью, 14 частично, 0 не разбираются.

Известные ограничения

Что работает во всех диалектах: SELECT/INSERT/UPDATE/DELETE, DDL (CREATE/ALTER TABLE, VIEW), JOIN, CTE, оконные функции.

Диалект-специфичные ограничения:

  • PostgreSQL. Тела процедур PL/pgSQL (блоки $$…$$) обрабатываются как непрозрачный текст — ссылки на таблицы внутри функций в граф не попадают. Roadmap H1 2027.
  • MySQL. Верифицирован на корпусе Beaver — 237 760 атомов, 98.9% однозначно определено (полные числа). Хранимые процедуры разбираются.
  • MariaDB. Хранимые процедуры разбираются; верификационные метрики на реальных корпусах — в следующем релизе.
  • ClickHouse. Семантика движков хранения (MergeTree, ReplicatedMergeTree и др.) в граф не вносится.
  • Trino. Реализован в полном объёме; верификационные метрики — в следующем релизе.

Greenplum. Отдельного диалекта нет. ANSI-совместимый код парсится через PostgreSQL. GP-специфика (DISTRIBUTED BY, AO-таблицы, EXTERNAL TABLE) — roadmap. Мы не заявляем «поддержку Greenplum» — только ANSI-совместимое подмножество.

Известные пробелы PL/SQL (roadmap)

Парсер рассчитан на реальный код, и про дыры мы говорим прямо:

  • JSON_TABLE (разрешение путей колонок), оптимизаторные хинты (/*+ … */ — игнорируются, на граф не влияют), DBLINK (@remote), MATCH_RECOGNIZE (≈2% аналитических запросов) — roadmap.
  • Динамический SQL (EXECUTE IMMEDIATE) — это не дыра статики, а зона рантайм-сбора: SQL, собранный в строку на лету, нельзя восстановить из исходника; он разбирается из логов выполнения. См. ниже.

Сбор в рантайме (OpenLineage)

Технологии, которые уже эмитят OpenLineage, не нужно парсить заново — платформа принимает события (спецификация OL 2-0-2) и встраивает их в общий граф: вход/выход датасетов → рёбра READS_FROM/WRITES_TO, фасет колоночной связности → DATA_FLOW.

ТехнологияСтатус
dbt✅ протестировано
Apache Airflow🟢 приём
Apache Spark🟢 приём
Apache Flink🟢 приём (стриминг)

Честная граница. Приём событий OpenLineage от инструментов конвейера — работает. А вот автоматическое вычитывание динамического SQL из системных логов БД (V$SQL, pg_stat_statements, system.query_log) с последующим парсингом — пока в разработке (заготовка есть, интеграция не завершена). Не подаём как готовое.

Динамический SQL и рантайм-потоки покрываются именно этим слоем — то, что не видно в статике, видно в выполнении.

Чего нет в периметре

Облачные хранилища, недоступные в РФ (Snowflake, BigQuery, Databricks Cloud), не поддерживаются. AIDA работает только on-premise, в закрытом контуре.

Не нашли свой диалект?

Список расширяется. Если нужен диалект, которого здесь нет, — напишите команде через запрос доступа.