Давно сюда не писал. Но пора исправляться, поэтому сегодня про dbt.
dbt недавно похвастался, что преодолел $100M ARR, в основном за счёт роста клауд-продукта среди Enterprise-клиентов.
Средний чек — $20K на клиента. Конечно, среднее в SaaS — это такое себе мерило. SpatialChat генерит dbt $1.2K в год, а Siemens, думаю, под $100K+.
Но что интересно — dbt, похоже, окончательно сменил стратегию. Фокус на Enterprise немного ранил дух open-source, на котором dbt вырос. Я это и на себе заметил. Долгое время я жил в длинном хвосте dbt-клиентов на $1.2K, и с каждым годом продукт радовал всё меньше. Семантический слой так и не поддерживает Postgres (понимаю, что так себе выбор для dwh, но все же). В Cloud-версии нельзя выбрать версию для запуска. Изменения в прайсинге даже не самые прозрачные – я как-то пропустил даже, что меня начали чарджить за модели.
Но бизнес есть бизнес. Новый план может и расстроил коммьюнити в Slack, зато закрыли сильные Enterprise-сделки.
Помимо ARR-апдейта, dbt ещё купил SDF — интересный стартап, который я давно хотел разобрать. SDF поднимал $9M от Two Sigma Ventures, Sequoia, a16z и даже знакомого многим RTP Global.
SDF воспринимает SQL не как текст, а как объектную систему. dbt всю жизнь относился к SQL как к строкам. Всё, что делал dbt — это добавлял Jinja-шаблонизацию, референсы и макросы, чтобы облегчить работу с SQL-пайплайнами. SDF пошёл дальше. Он анализирует SQL на уровне типов и зависимостей, а не просто передаёт его в базу. Он понимает метаданные, может инспектировать lineage и анализировать SQL ещё до выполнения. По сути, это SQL-компилятор, трансформационный движок, linter и language server в одном. Он написан на Rust и просто быстрее dbt Core, который работает на Python.
Если dbt удачно встроит SDF в экосистему, это может изменить саму парадигму работы с SQL. SQL-пайплайны начнут разрабатываться как полноценный код, а не как “набор текстовых файлов”. SQL-компиляция станет быстрее, ошибки будут отлавливаться до деплоя. Data lineage станет встроенной фичей, а не чем-то, что приходится восстанавливать вручную. Это движение в сторону data control plane.
dbt уже давно строит не просто инструмент для трансформации данных, а что-то большее — платформу, которая станет стандартом работы с SQL.
Еще одна особенность SDF в независимости от платформы. Пишешь SQL в одном языке, dbt/SDF транслирует его под нужный движок (Snowflake, BigQuery, DuckDB и т.д.). Программы и пайплайны становятся независимыми от движка. Можно выбирать оптимальный execution engine под конкретную задачу.
Кажется это хорошая покупка для dbt; dbt скорее сделал им хороший оффер, а аудитория адоптила медленно.
dbt недавно похвастался, что преодолел $100M ARR, в основном за счёт роста клауд-продукта среди Enterprise-клиентов.
5,000 dbt Cloud customers, 30% year-over-year рост
Средний чек — $20K на клиента. Конечно, среднее в SaaS — это такое себе мерило. SpatialChat генерит dbt $1.2K в год, а Siemens, думаю, под $100K+.
Но что интересно — dbt, похоже, окончательно сменил стратегию. Фокус на Enterprise немного ранил дух open-source, на котором dbt вырос. Я это и на себе заметил. Долгое время я жил в длинном хвосте dbt-клиентов на $1.2K, и с каждым годом продукт радовал всё меньше. Семантический слой так и не поддерживает Postgres (понимаю, что так себе выбор для dwh, но все же). В Cloud-версии нельзя выбрать версию для запуска. Изменения в прайсинге даже не самые прозрачные – я как-то пропустил даже, что меня начали чарджить за модели.
Но бизнес есть бизнес. Новый план может и расстроил коммьюнити в Slack, зато закрыли сильные Enterprise-сделки.
Помимо ARR-апдейта, dbt ещё купил SDF — интересный стартап, который я давно хотел разобрать. SDF поднимал $9M от Two Sigma Ventures, Sequoia, a16z и даже знакомого многим RTP Global.
SDF воспринимает SQL не как текст, а как объектную систему. dbt всю жизнь относился к SQL как к строкам. Всё, что делал dbt — это добавлял Jinja-шаблонизацию, референсы и макросы, чтобы облегчить работу с SQL-пайплайнами. SDF пошёл дальше. Он анализирует SQL на уровне типов и зависимостей, а не просто передаёт его в базу. Он понимает метаданные, может инспектировать lineage и анализировать SQL ещё до выполнения. По сути, это SQL-компилятор, трансформационный движок, linter и language server в одном. Он написан на Rust и просто быстрее dbt Core, который работает на Python.
Если dbt удачно встроит SDF в экосистему, это может изменить саму парадигму работы с SQL. SQL-пайплайны начнут разрабатываться как полноценный код, а не как “набор текстовых файлов”. SQL-компиляция станет быстрее, ошибки будут отлавливаться до деплоя. Data lineage станет встроенной фичей, а не чем-то, что приходится восстанавливать вручную. Это движение в сторону data control plane.
dbt уже давно строит не просто инструмент для трансформации данных, а что-то большее — платформу, которая станет стандартом работы с SQL.
Еще одна особенность SDF в независимости от платформы. Пишешь SQL в одном языке, dbt/SDF транслирует его под нужный движок (Snowflake, BigQuery, DuckDB и т.д.). Программы и пайплайны становятся независимыми от движка. Можно выбирать оптимальный execution engine под конкретную задачу.
Кажется это хорошая покупка для dbt; dbt скорее сделал им хороший оффер, а аудитория адоптила медленно.
dbt Labs
dbt Labs Surges Past $100 Million in Annual Recurring Revenue, Driven by Significant Adoption from Fortune 500 Companies | dbt…
More than 5,000 organizations rely on dbt Cloud to power enterprise data practices
записали недавно подкаст про то, что сегодня представляет из себя семантический слой. спасибо Артемию за то, что всех собрал!
Forwarded from Data Apps Design (Artemiy Kozyr)
— Эволюция работы с метриками. Почему вообще возникает проблема которую решает семантический слой
— Аналитические потребности компаний
— Семантическая модель и BI
— Разница между семантическим слоем и дата-каталогом
— Семантичская модель и GenAI / LLM / Human language
— Где место таким инструментам как Streamlit / Observable / Evidently и смогут ли они заменить BI?
— Deployment best practics (fault-tolerance, k8s)
— Migration from LookML?
— Можно ли создать полноценное решение на основе Open Source / Core опций продукта?
— Вопросы - ответы - мнения - дискуссия
— Live demo, демонстрация интересных фичей и возможностей
— Кейсы и опыт различных компаний
— Даня Чепенко – synmetrix.org; автор Tg semanticlayer (https://news.1rj.ru/str/semanticlayer)
— Иван Фокеев – founding team Statsbot / Cube.dev; ex-Narrative BI; автор synmetrix.org
— Михаил Шеянов - Head of Data Architecture Practice/Senior PO @ SIBUR
— Артемий Козырь - Data Platform Leader @ Wheely
00:00:00 Что такое семантический слой? Для чего, когда и почему?
00:04:39 Семантический слой как подход к проектированию аналитических систем
00:06:52 Унификация метрик / Single source of truth
00:11:32 Synmetrix Semantic Layer Demo
00:20:30 SQL API
00:23:55 Semantic Layer sync to BI systems
00:27:19 Advanced modeling / measures / window functions
00:29:40 Headless BI / Consuming data / Observable / Embedded analytics
00:33:49 Case SIBUR + Synmetrix
00:52:19 Разница Cube core, Cube cloud, Synmetrix. Как сделать выбор?
00:58:40 Влияние GenAI / LLM, генерация SQL, мнения и прогнозы
01:08:37 Миграция с других реализаций семантического слоя / LookML (Looker)
01:11:05 Отличия Synmetrix & Cube
01:12:40 Synmetrix Roadmap - ближайшие планы развития продукта
01:13:35 Несколько слов о Data Catalog / Data Governance
01:18:05 Wrap up / Заключение
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Есть такой стартап Tobiko, который делает конкурента dbt — SQLMesh.
На поверхности всё то же самое: Jinja-шаблоны, версионирование, коллаборация, поддержка Python.
Но отличие в том, что SQLMesh строится на time-based моделировании, упрощая исторические партиции и инкрементальные пересчёты. В dbt нужно отдельно прописывать max-даты, проверять режим запуска (full refresh или incremental), а в SQLMesh всё работает в одном режиме — incremental.
Там же есть встроенная оркестрация (аналог dbt + Dagster/Airflow), возможность создавать разные окружения (по сути разные схемы) и автоматическая проверка изменений вплоть до уровня колонок (column-level lineage). С помощью простого переключения указателя можно быстро «перевести» staging-данные в production.
Зачем всё это нужно?
Перерасчет данных стоит так дорого
Как только инженер вносит изменение в трансформационный слой, dwh начинает пересчитывать всё подряд, даже если поменялась только одна метрика.
Затраты на это накопительные. Чем больше данных, тем выше счета за compute.
Но кажется логично пересчитывать только то, что изменилось.
Databricks вместе с Tobiko проверили, как selective recalculation влияет на стоимость.
Результат — экономия в 9 раз.
Тестировали четыре ключевых задачи, которые выполняет каждый data-инженер:
- Создание окружения для разработки
- Внесение изменений в модели
- Продвижение изменений в прод
- Откат изменений
Что показал бенчмарк?
1. Создание окружения: в dbt Core это полный пересчёт схемы, который занимает 3.5 часа. В SQLMesh — виртуальный слой, который разворачивается за 20 секунд.
2. Обработка изменений: dbt Core пересчитывает всё, даже если затронута одна колонка. SQLMesh анализирует зависимости и пересчитывает только нужные модели — в 1.5 раза быстрее и дешевле.
3. Продвижение в прод: в dbt Core это значит заново пересчитать все данные. В SQLMesh изменения применяются в виртуальном слое без лишних затрат — 134x быстрее, 123x дешевле.
4. Откат: в dbt Core это ручной процесс, требующий поиска затронутых данных. В SQLMesh всё версиируется автоматически — 136x быстрее, 117x дешевле.
На цифрах:
1. SQLMesh и Tobiko Cloud сокращают время перерасчёта с 12 часов до 32 минут.
2. Затраты падают с $34.66 до $1.48 за цикл.
При этом SQLMesh позволяет получить эту экономию без изменения кода dbt-проектов. Переключение проходит безболезненно, без необходимости переписывать схему.
CFO сейчас давят на повышение ROI от data & AI, что удивительно после эпохи modern data stack (2010–2022) и роста бюджетов. Это усиливает нагрузку на облачные dwh, и компании ищут способы радикально снизить расходы. Особенно в контексте AI-нагрузок, где перерасчёты становятся постоянными. Когда каждый доллар на облаке считается, нет смысла пересчитывать весь стек, если можно работать точечно.
На поверхности всё то же самое: Jinja-шаблоны, версионирование, коллаборация, поддержка Python.
Но отличие в том, что SQLMesh строится на time-based моделировании, упрощая исторические партиции и инкрементальные пересчёты. В dbt нужно отдельно прописывать max-даты, проверять режим запуска (full refresh или incremental), а в SQLMesh всё работает в одном режиме — incremental.
Там же есть встроенная оркестрация (аналог dbt + Dagster/Airflow), возможность создавать разные окружения (по сути разные схемы) и автоматическая проверка изменений вплоть до уровня колонок (column-level lineage). С помощью простого переключения указателя можно быстро «перевести» staging-данные в production.
Зачем всё это нужно?
Перерасчет данных стоит так дорого
Как только инженер вносит изменение в трансформационный слой, dwh начинает пересчитывать всё подряд, даже если поменялась только одна метрика.
Затраты на это накопительные. Чем больше данных, тем выше счета за compute.
Но кажется логично пересчитывать только то, что изменилось.
Databricks вместе с Tobiko проверили, как selective recalculation влияет на стоимость.
Результат — экономия в 9 раз.
Тестировали четыре ключевых задачи, которые выполняет каждый data-инженер:
- Создание окружения для разработки
- Внесение изменений в модели
- Продвижение изменений в прод
- Откат изменений
Что показал бенчмарк?
1. Создание окружения: в dbt Core это полный пересчёт схемы, который занимает 3.5 часа. В SQLMesh — виртуальный слой, который разворачивается за 20 секунд.
2. Обработка изменений: dbt Core пересчитывает всё, даже если затронута одна колонка. SQLMesh анализирует зависимости и пересчитывает только нужные модели — в 1.5 раза быстрее и дешевле.
3. Продвижение в прод: в dbt Core это значит заново пересчитать все данные. В SQLMesh изменения применяются в виртуальном слое без лишних затрат — 134x быстрее, 123x дешевле.
4. Откат: в dbt Core это ручной процесс, требующий поиска затронутых данных. В SQLMesh всё версиируется автоматически — 136x быстрее, 117x дешевле.
На цифрах:
1. SQLMesh и Tobiko Cloud сокращают время перерасчёта с 12 часов до 32 минут.
2. Затраты падают с $34.66 до $1.48 за цикл.
При этом SQLMesh позволяет получить эту экономию без изменения кода dbt-проектов. Переключение проходит безболезненно, без необходимости переписывать схему.
CFO сейчас давят на повышение ROI от data & AI, что удивительно после эпохи modern data stack (2010–2022) и роста бюджетов. Это усиливает нагрузку на облачные dwh, и компании ищут способы радикально снизить расходы. Особенно в контексте AI-нагрузок, где перерасчёты становятся постоянными. Когда каждый доллар на облаке считается, нет смысла пересчитывать весь стек, если можно работать точечно.
семантический слой
Давно сюда не писал. Но пора исправляться, поэтому сегодня про dbt. dbt недавно похвастался, что преодолел $100M ARR, в основном за счёт роста клауд-продукта среди Enterprise-клиентов. 5,000 dbt Cloud customers, 30% year-over-year рост Средний чек — $20K…
В блоге 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 куда сложнее.
SQL comprehension – это способность системы анализировать и интерпретировать SQL-код. Но это не единичная функция, а целая цепочка технологий, которые раскрываются по мере развития инструментария.
Самая популярная система, которая анализирует анализировать и интерпретировать SQL-код это база данных. Но вся идея SDF отделить понимание SQL от конкретной базы данных, что позволяет реализовать целую цепочку технологий с расширенными возможностями:
1/ Column-Level Lineage: отслеживание происхождения данных на уровне отдельных колонок.
2/ Предварительная валидация запросов: проверка корректности и логики SQL до отправки запроса в хранилище.
3/ Расширенный IntelliSense: интеллектуальные подсказки, ускоряющие разработку и повышающие качество кода.
SDF реализовал свой движка анализа SQL кода (парсинг, AST и семантический анализ выполняются вне базы данных) а также сделал несколько интересных инженерно-продуктовых решений, таких как предварительная валидация и улучшенный IntelliSense.
Почему создание глубокого уровня SQL comprehension оказалось сложной задачей?
Инструменты, анализирующие программный код, существуют давно, однако данные – это особая сфера. Они обладают «физичностью», зависят от схем, метаданных и динамических зависимостей, что делает задачу разработки продвинутого SQL comprehension куда сложнее.
привет!
планируем в ближайшее немного больше писать практического контента по теме семантического слоя.
а это тема напрямую завязана на библиотеку cube.
пока статьи пишутся, сделал телеграм-чат — t.me/cubejsru
подключайтесь!
планируем в ближайшее немного больше писать практического контента по теме семантического слоя.
а это тема напрямую завязана на библиотеку cube.
пока статьи пишутся, сделал телеграм-чат — t.me/cubejsru
подключайтесь!
👍3
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 предлагают разбивать на шаги
эти промежуточные шаги становятся примерами для обучения: видя «черновую работу», модель учится отслеживать несколько логических шагов, не терять условия и генерировать более точный 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 при обучении.
прочитал китайскую статью об адаптации 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 при обучении.
🔥2
прочитал слегка старую (от июня), но годную заметку от General Analysis про уязвимости в связке Supabase MCP + RLS.
Ключевая идея: даже если использовать service_role и включить row-level security, остаются сценарии, где ИИ-ассистент может «обойти» защиту. Достаточно хитро сформулированного запроса и модель вставит в ответ данные, к которым у пользователя не должно быть доступа (например, токены интеграций).
Что показали ребята:
1/ RLS и привилегии базы это не панацея, если AI-агент выполняет SQL напрямую.
2/ Основной риск остается prompt injection, когда пользователь подсовывает скрытые инструкции.
3/ Контрмеры: ограниченные токены вместо service_role, прокси-гейтвей для SQL, фильтрация запросов и аудит действий ассистента.
Ключевая идея: даже если использовать service_role и включить row-level security, остаются сценарии, где ИИ-ассистент может «обойти» защиту. Достаточно хитро сформулированного запроса и модель вставит в ответ данные, к которым у пользователя не должно быть доступа (например, токены интеграций).
Что показали ребята:
1/ RLS и привилегии базы это не панацея, если AI-агент выполняет SQL напрямую.
2/ Основной риск остается prompt injection, когда пользователь подсовывает скрытые инструкции.
3/ Контрмеры: ограниченные токены вместо service_role, прокси-гейтвей для SQL, фильтрация запросов и аудит действий ассистента.
General Analysis
Comprehensive Oversight and Security for GenAI
Stress testing enterprise AI systems to find failure modes.
кажется наблюдаем закат движения modern data stack
https://www.theinformation.com/articles/data-startup-fivetran-talks-buy-dbt-labs-multibillion-dollar-deal
https://www.theinformation.com/articles/data-startup-fivetran-talks-buy-dbt-labs-multibillion-dollar-deal
The Information
Data Startup Fivetran In Talks to Buy Dbt Labs in Multibillion Dollar Deal
Fivetran, a startup used by companies to manage and prepare data for analytics and artificial intelligence, is in talks to buy data management companydbt Labs, according to people with direct knowledge of the deal. The deal would combine two data companies…
Forwarded from 5 minutes of data
Что, на самом деле происходит в слиянии 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
Возвращаясь к 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
Думаю, все уже слышали о самом свежем слиянии в мире 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
1👍4❤1
Forwarded from subquery.ru - dbt, clickhouse, cube
Семантический слой
Когда-то, работая аналитиками, мы делали сотни дашбордов.
Заказчики использовали их реже, чем обещали, дашборды теряли актуальность, а данные между ними неизбежно расходились.
Семантический слой позволил унифицировать данные, а его реализация с помощью Cube дала возможность вообще позабыть про дашборды, кроме отдельных случаев.
Вдобавок к этому недавно прошла конференция СБЕРа на тему использования AI в BI, где коллеги говорили про тестирование подходов в виде DataAPI или Text2SQL. А нам внедренный семантический слой позволил подключить агента меньше, чем за неделю(!)
Я написал пару статей о нашем опыте взаимодействия с Cube и надеюсь, что это поможет стать ему хоть чуточку популярнее
Сила атрибута meta в Cube
Как организовать тенанты в Cube
Когда-то, работая аналитиками, мы делали сотни дашбордов.
Заказчики использовали их реже, чем обещали, дашборды теряли актуальность, а данные между ними неизбежно расходились.
Семантический слой позволил унифицировать данные, а его реализация с помощью Cube дала возможность вообще позабыть про дашборды, кроме отдельных случаев.
Вдобавок к этому недавно прошла конференция СБЕРа на тему использования AI в BI, где коллеги говорили про тестирование подходов в виде DataAPI или Text2SQL. А нам внедренный семантический слой позволил подключить агента меньше, чем за неделю(!)
Я написал пару статей о нашем опыте взаимодействия с Cube и надеюсь, что это поможет стать ему хоть чуточку популярнее
Сила атрибута meta в Cube
Как организовать тенанты в Cube
🔥1