В блоге dbt вышла (относительно давно, но я только сейчас дошёл) интересная заметка о том, как SDF реализует концепцию SQL comprehension.

SQL comprehension – это способность системы анализировать и интерпретировать SQL-код. Но это не единичная функция, а целая цепочка технологий, которые раскрываются по мере развития инструментария.
Самая популярная система, которая анализирует анализировать и интерпретировать SQL-код это база данных. Но вся идея SDF отделить понимание SQL от конкретной базы данных, что позволяет реализовать целую цепочку технологий с расширенными возможностями:

1/ Column-Level Lineage: отслеживание происхождения данных на уровне отдельных колонок.

2/ Предварительная валидация запросов: проверка корректности и логики SQL до отправки запроса в хранилище.

3/ Расширенный IntelliSense: интеллектуальные подсказки, ускоряющие разработку и повышающие качество кода.

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

Почему создание глубокого уровня SQL comprehension оказалось сложной задачей?

Инструменты, анализирующие программный код, существуют давно, однако данные – это особая сфера. Они обладают «физичностью», зависят от схем, метаданных и динамических зависимостей, что делает задачу разработки продвинутого SQL comprehension куда сложнее.

привет!

планируем в ближайшее немного больше писать практического контента по теме семантического слоя.

а это тема напрямую завязана на библиотеку cube.

пока статьи пишутся, сделал телеграм-чат — t.iss.one/cubejsru
подключайтесь!

reasoning-first подход к Text-to-SQL

прочитал китайскую статью об адаптации text-to-sql через reasoning, поэтому небольшой обзор.

Few-shot prompting справляется с простыми схемами, но требует гигантских подсказок (тысячи токенов) и всё равно ломается на нескольких джоинах или вложенных запросах.

Seq2Seq fine-tuning (RAT-SQL) хорошо обрабатывает знакомые паттерны, но не даёт прозрачности, почему именно сгенерирован тот или иной SQL, и плохо работает с новыми или сложными запросами.

поэтому идея проста - вместо чистого sequence-to-sequence STaR-SQL рассматривает задачу как reasoning-процесс, состоящий из четырёх этапов, которые вместе дают state-of-the-art на сложных многошаговых запросах:

chain-of-thought
предлагают вместо прямого вопрос -> SQL предлагают разбивать на шаги

step 1: определить релевантные таблицы и дать им алиасы  
step 2: отфильтровать столбец x в таблице a по условию y  
step 3: выполнить join таблицы a и b по ключу z  
…  
sql: select a.col1, b.col2  
     from a as a  
     join b as b on a.id = b.a_id  
     where …  

эти промежуточные шаги становятся примерами для обучения: видя «черновую работу», модель учится отслеживать несколько логических шагов, не терять условия и генерировать более точный sql. без cot execution accuracy падает более чем на 15 pp.

метрики оценки
EM (Exact Match) — покадровое сравнение предсказанного и золотого SQL по структуре и токенам
EX (Execution Accuracy) — процент вопросов, для которых при выполнении предсказанного SQL на БД результат полностью совпадает с результатом выполнения эталонного SQL. В отличие от EM, EX оценивает семантическую корректность по данным и учитывает разные, но эквивалентные по смыслу формулировки запросов.

seed rationales

базовый корпус берётся из text-to-sql датасета Spider: около 7000 вопросов с разметкой схемы и «золотым» SQL (train split). (Q, S, Y) — вопрос, схема, эталонный SQL.
вручную аннотируют небольшую выборку (~40 примеров Spider) пошаговыми CoT-обоснованиями: разбиваем NL-вопрос на логику («сначала выбрать таблицу X», «затем джоин с Y по Z», «применить фильтр W»).

rationale-driven generation

для каждого из 7000 примеров в few-shot режиме генерируют k=8 (!) пар (rationale + SQL);
Prompt: «По этой NL-формулировке и схеме БД сгенерируй многошаговое rationale, а потом финальный SQL».
выполняют каждый SQL на соответствующей тестовой базе: те, что дают правильный результат, метят как correct, остальные как incorrect;
k-way Sampling: для каждого примера получаем k пар (rationale + SQL).
из 7000×8 = 56 000 кандидатов обычно попадает в первый forward пул порядка 20–30 % correct запросов, остальные это negative.

difficulty-aware self-finetuning

все это хорошо, но есть проблема: модель слишком быстро учится на «простых» примерах, и данные для дообучения получаются перекошенными. Поэтому после первого раунда считаем для каждого примера ошибочность. Для «тяжёлых» случаев в prompt добавляем золотой SQL как backward-hint, чтобы модель генерировала rationale, объясняющее уже известную правильную структуру..
здесь используется стандартный токенный cross-entropy, но с весом, зависящим от сложности

verifier-supervised selection.

Даже после дообучения генератор может допускать тонкие логические ошибки. Обучаем лёгкий классификатор (на тех же примерах Spider) помеченным как correct/incorrect.

На инференсе генерируем 16 кандидатов (rationale + SQL), прогоняем каждый через верификатор и выбираем самый «достоверный».
осле одного раунда возвращаются к исходному checkpoint, повторяют генерацию → фильтрацию → дообучение, пока gain по EX/EM не схлынет (обычно 2–3 итерации).
В отличие от majority-voting (self-consistency), напрямую использует execution outcomes при обучении.

то же самое, но в картинках. так немного попроще.

прочитал слегка старую (от июня), но годную заметку от General Analysis про уязвимости в связке Supabase MCP + RLS.

Ключевая идея: даже если использовать service_role и включить row-level security, остаются сценарии, где ИИ-ассистент может «обойти» защиту. Достаточно хитро сформулированного запроса и модель вставит в ответ данные, к которым у пользователя не должно быть доступа (например, токены интеграций).

Что показали ребята:

1/ RLS и привилегии базы это не панацея, если AI-агент выполняет SQL напрямую.

2/ Основной риск остается prompt injection, когда пользователь подсовывает скрытые инструкции.

3/ Контрмеры: ограниченные токены вместо service_role, прокси-гейтвей для SQL, фильтрация запросов и аудит действий ассистента.

кажется наблюдаем закат движения modern data stack

https://www.theinformation.com/articles/data-startup-fivetran-talks-buy-dbt-labs-multibillion-dollar-deal

Что, на самом деле происходит в слиянии Fivetran и dbt

Думаю, все уже слышали о самом свежем слиянии в мире data-индустрии. Было довольно трудно собрать воедино всю картину — зачем это делается и что на самом деле стоит за этим шагом.
Попробую объяснить, почему это происходит.

Коротко (TL;DR):
Fivetran зажимают с двух сторон, а dbt достиг потолка роста. Они объединяются, чтобы попытаться забрать часть денег у вендоров хранилищ данных и приблизиться с нынешних ~$10 млрд до уровня Databricks/Snowflake (~$100 млрд).

Несколько исходных предположений

1. Fivetran зажимают сверху со стороны хранилищ (Databricks, Snowflake), которые всё чаще включают функциональность EL (extract-load) прямо в свои корпоративные контракты.
Зачем вашей IT-команде просить юристов рассматривать ещё один вендорский договор (и тратить на это сотни тысяч долларов), если можно просто взять один контракт, где уже всё есть?
Тем более что выгода не в ETL, а в вычислениях, именно там зарабатываются основные деньги.
2. Fivetran зажимают снизу — со стороны более дешёвых и массовых решений вроде Airbyte, DLTHub и других.
3. У dbt рост практически остановился — проект достиг своего пика.

Вот цитата из поста dbt What is Open Data Infrastructure

В результате клиенты начали раздражаться из-за проблем с интеграцией инструментов и невозможностью решать крупные, сквозные задачи. Они стали требовать от вендоров “делать больше” — чтобы меньше интеграционной работы оставалось на внутренних командах.

Вендоры увидели в этом возможность: расширить свои продукты и занять новые ниши. Это не хорошо и не плохо само по себе. Сквозные решения действительно дают более чистую интеграцию, лучший пользовательский опыт и снижают стоимость владения. Но они также ограничивают выбор, создают эффект lock-in и могут повышать цены. Всё зависит от деталей.

За время облачной эры индустрию данных фактически захватили пять гигантов, у каждого из которых выручка давно перевалила за миллиард долларов в год: Databricks, Snowflake, Google Cloud, AWS и Microsoft Azure.
Каждый из них начинал с базового набора — аналитический движок, хранилище и каталог метаданных. Но за последние пять лет, по мере того как развивалась концепция Modern Data Stack, клиенты начали просить их “делать больше”. И они ответили. Теперь каждый из этих пяти игроков предлагает решения по всему стеку: ingestion, трансформации, BI, оркестрация и многое другое.

По сути, они стали всё-в-одном платформами данных: принеси данные — и делай с ними всё внутри их экосистемы.

Возвращаясь к Fivetran

Чтобы понять вторую часть уравнения, достаточно просто зайти на страницу с ценами любого конкурента — Fivetran дорог, и это факт.
Третье утверждение (что dbt достиг пика) формально не доказано, это скорее моё наблюдение.

Что они пытаются сделать

Если принять эти три пункта, становится понятно, куда движется Fivetran + dbt.
Новый игрок (назовём его условно DBTran) пытается перевернуть игровое поле в отношении хранилищ данных.

Обычно именно хранилище — это центр вселенной, а все остальные инструменты (каталоги данных, слой трансформаций, семантический слой и т.д.) работают вокруг него и постепенно становятся частью предложения этих вендоров. Поэтому Snowflake и Databricks оцениваются в сотни миллиардов.

DBTran же хочет сделать наоборот — сделать хранилище товаром (commodity) и взять под контроль всё остальное.

Как это возможно

Главная технологическая ставка здесь — Apache Iceberg.
Когда используется Iceberg, вычисления и хранение разделены.
Традиционные вендоры хранилищ — BigQuery, ClickHouse, Snowflake — становятся просто вычислительными движками, которые можно менять местами.

А всё остальное берёт на себя DBTran:

- Хранилище: S3, GCS и т.д.
- Вычисления: Snowflake, BigQuery и др.
- Каталог: DBTran
- ETL: DBTran
- Трансформация: DBTran
- Семантический слой: DBTran

И при желании — добавить ещё больше.
Таким образом DBTran сможет построить новый тип платформы данных, в которой хранилище перестаёт быть главным центром, а контроль за всей цепочкой от загрузки до аналитики оказывается в их руках.

@data_whisperer

​​Семантический слой

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

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

Вдобавок к этому недавно прошла конференция СБЕРа на тему использования AI в BI, где коллеги говорили про тестирование подходов в виде DataAPI или Text2SQL. А нам внедренный семантический слой позволил подключить агента меньше, чем за неделю(!)

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

Сила атрибута meta в Cube

Как организовать тенанты в Cube