На этой поговорим про еще один тренд в дата-мире, который даже отвлек VC от мониторинга AI проектов. Стартап Tinybird, который позволяет разработчикам строить real-time дата-продукты привлек $25 миллионов в Series B раунде.
Стартап строит целую платформу для решения разных задач с высокими требования к low latency обновлениям. На практике это значит, что они подключаются к какому-то стриминговому источнику типа Kafka, Kinesis / Redpanda / Pub/Sub; объединяют это все с хранилищем данных (dwh) через единый интерфейс для батчевых и стриминговых данных; кладут все это в ClickHouse и предоставляют разработчикам эндпоинты для доступа к данным. Внутри есть небольшое подобие семантического слоя для описания ключевых метрик.
Если одеть шапку сноба, то можно сказать, что это просто хорошо управляемый ClickHouse кластер, с Python оберткой вокруг него.
Если одеть маску визионера, то мы переходим в интересный мир дата-бэкенда, который напрямую соседствует с семантичкским слоем.
На диаграммах modern data stack как правило все сводится к тому, как данные надо как-то доставить в DWH, а потом из него запушить эти данные, например в BI. Однако DWH не очень подходит для real-time решений.
Например, Tinybird обычно используют для задач, где нужна персонализация на лету (например, cold start в рекомендациях) или где надо быстро реагировать на изменяющуюся природу данных, например, в беттинге или управлении инвентарем.
Из моей практики, один из самых частых случаев применения – это создание внутренний клиентской аналитики (aka embedded аналитика), которая обновляется не раз в 12 часов, а real-time.
Представьте, например, любой деволперский тул, который в админке показывает сколько вы израсходовали ресурсов или API запросов в режиме реального времени.
Тут возникает такое понятие, как «дата-бэкенд» (не сказать, что люблю его, но вендоры часто используют). За основу берутся таблицы и бизнес-логика из dwh, но отличны схемы интеграции, low-latency querying, tenant-isolated access control и отдельный пайплан для обработки стриминга.
Подход Tinybird это платформенный метод решения задачи, но есть и другие вендоры, кто решает глобальную задачу, но на разных участках value chain. Например, можно посмотреть на тот же Cube, Patch, Propel, Hasura.
Наверное, может возникнуть вопрос, что все это как-то не гармонично выглядит — и DWH держать и еще Clickhouse где-то рядом. Например, Databricks с вами полностью согласен, который намекает на то, что дата-платформу и бэкенд можно связать единый унифицированным хранилищем. Но про это поговорим в другом посте.
Стартап строит целую платформу для решения разных задач с высокими требования к low latency обновлениям. На практике это значит, что они подключаются к какому-то стриминговому источнику типа Kafka, Kinesis / Redpanda / Pub/Sub; объединяют это все с хранилищем данных (dwh) через единый интерфейс для батчевых и стриминговых данных; кладут все это в ClickHouse и предоставляют разработчикам эндпоинты для доступа к данным. Внутри есть небольшое подобие семантического слоя для описания ключевых метрик.
Если одеть шапку сноба, то можно сказать, что это просто хорошо управляемый ClickHouse кластер, с Python оберткой вокруг него.
Если одеть маску визионера, то мы переходим в интересный мир дата-бэкенда, который напрямую соседствует с семантичкским слоем.
На диаграммах modern data stack как правило все сводится к тому, как данные надо как-то доставить в DWH, а потом из него запушить эти данные, например в BI. Однако DWH не очень подходит для real-time решений.
Например, Tinybird обычно используют для задач, где нужна персонализация на лету (например, cold start в рекомендациях) или где надо быстро реагировать на изменяющуюся природу данных, например, в беттинге или управлении инвентарем.
Из моей практики, один из самых частых случаев применения – это создание внутренний клиентской аналитики (aka embedded аналитика), которая обновляется не раз в 12 часов, а real-time.
Представьте, например, любой деволперский тул, который в админке показывает сколько вы израсходовали ресурсов или API запросов в режиме реального времени.
Тут возникает такое понятие, как «дата-бэкенд» (не сказать, что люблю его, но вендоры часто используют). За основу берутся таблицы и бизнес-логика из dwh, но отличны схемы интеграции, low-latency querying, tenant-isolated access control и отдельный пайплан для обработки стриминга.
Подход Tinybird это платформенный метод решения задачи, но есть и другие вендоры, кто решает глобальную задачу, но на разных участках value chain. Например, можно посмотреть на тот же Cube, Patch, Propel, Hasura.
Наверное, может возникнуть вопрос, что все это как-то не гармонично выглядит — и DWH держать и еще Clickhouse где-то рядом. Например, Databricks с вами полностью согласен, который намекает на то, что дата-платформу и бэкенд можно связать единый унифицированным хранилищем. Но про это поговорим в другом посте.
TechCrunch
Tinybird raises another $30 million to transform data into real-time APIs
Tinybird is not so tiny anymore. The enterprise data startup TechCrunch first covered three years ago has been growing at a rapid pace and recently raised
LLM и продуктовая аналитика
Когда ChatGPT только появился, целая плеяда стартапов сразу же попыталась использовать его для помощи аналитикам. На первый взгляд, в этом есть смысл: у компаний есть огромные хранилища данных, в этих данных (предположительно) есть какие-то полезные инсайты. Если бы что-то могло соединить точки в наших массивах данных, это был бы ChatGPT или что-то подобное.
Как мы знаем, не все так просто. Семантический слой, про который тут часто говорим, как категория продуктов, возможно станет мостом к этому переходу. Но это только один из подходов к современному conversational BI, который хорошо решает задачу репортинга.
Однако задача аналитика на самом деле - искать правильные вопросы. Начальные вопросы могут быть ясными, но вы не знаете, куда они приведут вас в зависимости от того, что вы найдете. Поэтому детальный причинно-следственный анализ через conversational B может быть сложнее.
И тут приходит логичная, и даже не очень новаторская для 2024, идея – а почему бы не применить трансформеры к сырому логу ивентов. При правильно расставленной телеметрии, любое взаимодействие пользователя с цифровым продуктом можно представить через аккуратную последовательность ивентов. А трансформеры отлично справляются с последоватльностями.
Интересный подход в этом направлении делает американский продукт Motif Analytics (один из основателей - физтех btw). Они громко заявляют о создании foundational модели, обученной на продуктовых ивентах (правда это маркетинговое название / подход, чем реально общедоступная сетка).
Чтобы моделировать последовательности событий с минимальными изменениями в исходных данных, они используют подход, имитирующий обучение LLM на текстовых данных. Команда разработала свой токенизатор для событий, который позволяет гибко фиксировать их время и различные свойства. Они также создали кастомную функцию потерь с несколькими временными масштабами: изменили цель обучения, чтобы сделать модели менее близорукими, поощряя их изучать, как события будут развиваться в течение следующих нескольких минут, часов и дней, а не просто предсказывать следующее ивент из набора.
Технологически решение интересное. Но сложно представить, что такой продукт конкурирует с условным Amplitude. Скорее всего аудитория – компании, которые шлют десятки миллионы ивентов в сутки, держат все in-house и нанимают целую команду аналитиков и дата-саентистов.
Но что тут мне нравится, что продукт не пытается создать ИИ-агента для продуктовой аналитики и не пытается самостоятельно заниматься анализом, заставляя компьютеры действовать как аналитики. Вместо этого он относится к LLM как к тому, чем он является на самом деле: к легковесному молниеносному калькулятору с потрясающей памятью.
Такая модель и сам подход не только быстро отвечает на вопросы вроде "сколько пользователей сделали ивент A перед ивентом B и не счернулись", но и предоставляет возможность моделировать динамику продукта. Например, можно спросить вопрос –”если я поменяю первый экран в онбординге мобильного приложения, как это скажется на конверсии в первую покупку?” и получить какой-то бейзлайн, который можно будет сравнить с онлайн экспериментом.
Конечно звучит немного абстрактно, но это в теории новый подход, находящийся между A/B тестированием (дорогим, но дающим уверенности в причинности) и общей отчетностью (которая больше рассматривает корреляции, но не причинности).
P.S. Очень похожий популярный проект есть в российском сообществе — Retenteering, Python библиотека для анализа пользовательских траекторий и CJM. Довольно мощный инструмент для продуктовой аналитики, который позволяет анализировать траектории, находить похожие и выявлять узкие места в продукте. Вместо LLM используются вычислительно простые методы из прикладного анализа данных, такие как TF-IDF и TSNE для снижения размерности графов траекторий, что облегчает визуализацию и анализ на плоской карте, изучая их кластеры и различия.
Когда ChatGPT только появился, целая плеяда стартапов сразу же попыталась использовать его для помощи аналитикам. На первый взгляд, в этом есть смысл: у компаний есть огромные хранилища данных, в этих данных (предположительно) есть какие-то полезные инсайты. Если бы что-то могло соединить точки в наших массивах данных, это был бы ChatGPT или что-то подобное.
Как мы знаем, не все так просто. Семантический слой, про который тут часто говорим, как категория продуктов, возможно станет мостом к этому переходу. Но это только один из подходов к современному conversational BI, который хорошо решает задачу репортинга.
Однако задача аналитика на самом деле - искать правильные вопросы. Начальные вопросы могут быть ясными, но вы не знаете, куда они приведут вас в зависимости от того, что вы найдете. Поэтому детальный причинно-следственный анализ через conversational B может быть сложнее.
И тут приходит логичная, и даже не очень новаторская для 2024, идея – а почему бы не применить трансформеры к сырому логу ивентов. При правильно расставленной телеметрии, любое взаимодействие пользователя с цифровым продуктом можно представить через аккуратную последовательность ивентов. А трансформеры отлично справляются с последоватльностями.
Интересный подход в этом направлении делает американский продукт Motif Analytics (один из основателей - физтех btw). Они громко заявляют о создании foundational модели, обученной на продуктовых ивентах (правда это маркетинговое название / подход, чем реально общедоступная сетка).
Чтобы моделировать последовательности событий с минимальными изменениями в исходных данных, они используют подход, имитирующий обучение LLM на текстовых данных. Команда разработала свой токенизатор для событий, который позволяет гибко фиксировать их время и различные свойства. Они также создали кастомную функцию потерь с несколькими временными масштабами: изменили цель обучения, чтобы сделать модели менее близорукими, поощряя их изучать, как события будут развиваться в течение следующих нескольких минут, часов и дней, а не просто предсказывать следующее ивент из набора.
Технологически решение интересное. Но сложно представить, что такой продукт конкурирует с условным Amplitude. Скорее всего аудитория – компании, которые шлют десятки миллионы ивентов в сутки, держат все in-house и нанимают целую команду аналитиков и дата-саентистов.
Но что тут мне нравится, что продукт не пытается создать ИИ-агента для продуктовой аналитики и не пытается самостоятельно заниматься анализом, заставляя компьютеры действовать как аналитики. Вместо этого он относится к LLM как к тому, чем он является на самом деле: к легковесному молниеносному калькулятору с потрясающей памятью.
Такая модель и сам подход не только быстро отвечает на вопросы вроде "сколько пользователей сделали ивент A перед ивентом B и не счернулись", но и предоставляет возможность моделировать динамику продукта. Например, можно спросить вопрос –”если я поменяю первый экран в онбординге мобильного приложения, как это скажется на конверсии в первую покупку?” и получить какой-то бейзлайн, который можно будет сравнить с онлайн экспериментом.
Конечно звучит немного абстрактно, но это в теории новый подход, находящийся между A/B тестированием (дорогим, но дающим уверенности в причинности) и общей отчетностью (которая больше рассматривает корреляции, но не причинности).
P.S. Очень похожий популярный проект есть в российском сообществе — Retenteering, Python библиотека для анализа пользовательских траекторий и CJM. Довольно мощный инструмент для продуктовой аналитики, который позволяет анализировать траектории, находить похожие и выявлять узкие места в продукте. Вместо LLM используются вычислительно простые методы из прикладного анализа данных, такие как TF-IDF и TSNE для снижения размерности графов траекторий, что облегчает визуализацию и анализ на плоской карте, изучая их кластеры и различия.
Forwarded from Инжиниринг Данных (Dmitry)
Пример типичной организации в Северной Америке и расходов на data-инструменты. Компания на 1000+ человек.
Команда данных состоит почти из 20 человек, и структура примерно следующая:
- Director Data Engineering (подчиняется VP Engineering)
- Manager Data Engineering (Pipelines) — команда занимается интеграцией данных (загрузка данных в Staging).
- Manager Data Engineering (Data Warehouse) — команда занимается созданием хранилища данных поверх Staging, то есть моделированием данных, использует dbt и применяет бизнес-логику, чтобы создавать корпоративную модель данных и рассчитывать бизнес-показатели. Команда — смесь Data Engineering и Analytics Engineering.
- Manager Data Enablement — команда представляет собой смесь Analytics Engineering и BI-разработчиков, делает дашборды в Tableau/Looker и, по необходимости, дорабатывает модели в dbt (кустарным способом, далеким от лучших практик DE).
Инструменты, которые используются:
- Snowflake — $100k в месяц только за compute.
- Airflow — оркестрация, open source, хостится на AWS ECS.
- dbt core — SQL-трансформации, open source, запускается на AWS ECS.
- Alation — $170k в год, дата-каталог, документация по показателям. Идея была внедрить Data Governance, единый портал для бизнес-пользователей, но фактически затея провалилась.
- Looker — $120k в год, конкурирует с Tableau (Enterprise-лицензия, такая же безлимитная по пользователям, но за дорого), и поэтому Looker долго не продержится.
- Monte Carlo — $140k в год, отличный инструмент для отслеживания Data Observability, качества данных, часто выручает, когда даже dbt tests ничего не видят. Но честно говоря, дорого — это где-то 8-10% от стоимости Snowflake.
- Hightouch — $30k в год, интеграция с Salesforce, Marketo и другими инструментами. Можно условно бесплатно сделать то же самое через Python+Docker, но по опыту с такими решениями из подручных средств страдают инженеры, и у вас вечные проблемы с различными изменениями в API, rate limit и т.п.
- Fivetran — $45k в год, интеграция с API Salesforce, Gsheets, Marketo, Zendesk и т.п. Так как это малая часть данных, то и цена небольшая.
Это расценки чисто на data-команду, а ещё есть ML-команда, расходы на AWS для инфраструктуры, и самая дорогая часть всего — data platform команда, которая использует Apache Kafka и пишет в S3 данные из MongoDB, Postgres, Cloudflare, серверных логов, Syslog и т.п. Точных цифр нет, но только расходы на платформенную команду могут составлять несколько миллионов долларов.
Какие выводы из этого маленького примера:
- Аналитика — это дорого.
- Облака — это дорого.
- Compute всегда дорого.
- Storage дорого.
- Использовать вендора — очень дорого, и ещё vendor lock в придачу.
- Инженеры — очевидно дорогие.
- Использовать бесплатный open-source — тоже дорого, и часто цена команды компенсирует цену лицензии.
- А самое дорогое — это уволить старую команду и нанять новую, чтобы новая всё починила и наконец-то показала ROI аналитики (хотя если старая не смогла, то и новая не факт, что поможет; хотя если мигрировать Snowflake на Databricks или наоборот, то на пару лет все будут заняты!).
Как ни крути — всё дорого.
Поэтому, если вы внедряете решение, старайтесь сразу отслеживать все расходы и мониторить их еженедельно. Это легче, чем спустя год-два распутывать клубок из высоких расходов.
Если команда использует open-source, старайтесь, чтобы все хорошо понимали, как это работает и как это обслуживается, иначе это будет black box и технический долг. Чаще проводите ревизию и удаляйте ненужные куски кода, старые pipelines, отчёты, dbt-модели и т.п. Сделайте leaderboard и пусть у вас будут top performers — те, кто удаляет старый и ненужный код.
И самое главное, обязательно фокус на business value, хотя это и так очевидно. Нужно балансировать между тем, что нужно бизнесу прямо сейчас и тем, что будет хорошо для аналитического решения и команды.
И чисто для инженеров было бы хорошо иметь 100% прозрачность в performance review, честный разговор о перспективах в компании. А то любят наобещать всего и побольше потом, а по факту 2% индексации🦯
Команда данных состоит почти из 20 человек, и структура примерно следующая:
- Director Data Engineering (подчиняется VP Engineering)
- Manager Data Engineering (Pipelines) — команда занимается интеграцией данных (загрузка данных в Staging).
- Manager Data Engineering (Data Warehouse) — команда занимается созданием хранилища данных поверх Staging, то есть моделированием данных, использует dbt и применяет бизнес-логику, чтобы создавать корпоративную модель данных и рассчитывать бизнес-показатели. Команда — смесь Data Engineering и Analytics Engineering.
- Manager Data Enablement — команда представляет собой смесь Analytics Engineering и BI-разработчиков, делает дашборды в Tableau/Looker и, по необходимости, дорабатывает модели в dbt (кустарным способом, далеким от лучших практик DE).
Инструменты, которые используются:
- Snowflake — $100k в месяц только за compute.
- Airflow — оркестрация, open source, хостится на AWS ECS.
- dbt core — SQL-трансформации, open source, запускается на AWS ECS.
- Alation — $170k в год, дата-каталог, документация по показателям. Идея была внедрить Data Governance, единый портал для бизнес-пользователей, но фактически затея провалилась.
- Looker — $120k в год, конкурирует с Tableau (Enterprise-лицензия, такая же безлимитная по пользователям, но за дорого), и поэтому Looker долго не продержится.
- Monte Carlo — $140k в год, отличный инструмент для отслеживания Data Observability, качества данных, часто выручает, когда даже dbt tests ничего не видят. Но честно говоря, дорого — это где-то 8-10% от стоимости Snowflake.
- Hightouch — $30k в год, интеграция с Salesforce, Marketo и другими инструментами. Можно условно бесплатно сделать то же самое через Python+Docker, но по опыту с такими решениями из подручных средств страдают инженеры, и у вас вечные проблемы с различными изменениями в API, rate limit и т.п.
- Fivetran — $45k в год, интеграция с API Salesforce, Gsheets, Marketo, Zendesk и т.п. Так как это малая часть данных, то и цена небольшая.
Это расценки чисто на data-команду, а ещё есть ML-команда, расходы на AWS для инфраструктуры, и самая дорогая часть всего — data platform команда, которая использует Apache Kafka и пишет в S3 данные из MongoDB, Postgres, Cloudflare, серверных логов, Syslog и т.п. Точных цифр нет, но только расходы на платформенную команду могут составлять несколько миллионов долларов.
Какие выводы из этого маленького примера:
- Аналитика — это дорого.
- Облака — это дорого.
- Compute всегда дорого.
- Storage дорого.
- Использовать вендора — очень дорого, и ещё vendor lock в придачу.
- Инженеры — очевидно дорогие.
- Использовать бесплатный open-source — тоже дорого, и часто цена команды компенсирует цену лицензии.
- А самое дорогое — это уволить старую команду и нанять новую, чтобы новая всё починила и наконец-то показала ROI аналитики (хотя если старая не смогла, то и новая не факт, что поможет; хотя если мигрировать Snowflake на Databricks или наоборот, то на пару лет все будут заняты!).
Как ни крути — всё дорого.
Поэтому, если вы внедряете решение, старайтесь сразу отслеживать все расходы и мониторить их еженедельно. Это легче, чем спустя год-два распутывать клубок из высоких расходов.
Если команда использует open-source, старайтесь, чтобы все хорошо понимали, как это работает и как это обслуживается, иначе это будет black box и технический долг. Чаще проводите ревизию и удаляйте ненужные куски кода, старые pipelines, отчёты, dbt-модели и т.п. Сделайте leaderboard и пусть у вас будут top performers — те, кто удаляет старый и ненужный код.
И самое главное, обязательно фокус на business value, хотя это и так очевидно. Нужно балансировать между тем, что нужно бизнесу прямо сейчас и тем, что будет хорошо для аналитического решения и команды.
И чисто для инженеров было бы хорошо иметь 100% прозрачность в performance review, честный разговор о перспективах в компании. А то любят наобещать всего и побольше потом, а по факту 2% индексации
Please open Telegram to view this post
VIEW IN TELEGRAM
Low-code DWH и BI для SMB.
Изменяющийся ландшафт дата-сервисов создал интересное направление для продуктов, которое можно описать как находящееся на стыке BI и ETL. Это задача, с которой я лично пытался справиться около двух лет назад и в итоге пришлось разработать собственное решение.
Например, есть условный Baremetrics, который строит аналитику поверх твоего Stripe. Но если хочется видеть активность в продукте, нужно задуматься, как передавать логи действий пользователя. Или если хочется объединить данные с Hubspot, то появляется вопрос как правильно объединять сущности.
Получается, что есть непокрытый сегмент пользователей, которым нужно что-то, на стыке BI x ETL, но для тех у кого нет своей дата-инфраструктуры. Отсюда возникает идея создать no-code дата-хранилище, где можно задавать логику объединения данных из разных источников с готовыми скриптами для подсчета ключевых метрик.
За последние годы на моем радаре появилось несколько продуктов в этой области. У всех одна и та же логика и предложение: «Мы заменим вам дата-инженера» и примерно следующий посыл.
Я думаю, что это хороший продукт для SMB, неважно для какого географического рынка. Тратить ресурсы на найм дата-инженера или создание целой команды данных до того, как выручка компании достигнет $1 млн в год, нецелесообразно. Проще делегировать эту задачу.
Пара дата продуктов для расширения кругозора:
Faros, Definite, Kyligence, Velvet, Myko , Canvas
Немного близкое поле, но кейс вокруг spreadsheets: Equals, Rows
Изменяющийся ландшафт дата-сервисов создал интересное направление для продуктов, которое можно описать как находящееся на стыке BI и ETL. Это задача, с которой я лично пытался справиться около двух лет назад и в итоге пришлось разработать собственное решение.
Например, есть условный Baremetrics, который строит аналитику поверх твоего Stripe. Но если хочется видеть активность в продукте, нужно задуматься, как передавать логи действий пользователя. Или если хочется объединить данные с Hubspot, то появляется вопрос как правильно объединять сущности.
Получается, что есть непокрытый сегмент пользователей, которым нужно что-то, на стыке BI x ETL, но для тех у кого нет своей дата-инфраструктуры. Отсюда возникает идея создать no-code дата-хранилище, где можно задавать логику объединения данных из разных источников с готовыми скриптами для подсчета ключевых метрик.
За последние годы на моем радаре появилось несколько продуктов в этой области. У всех одна и та же логика и предложение: «Мы заменим вам дата-инженера» и примерно следующий посыл.
We give you ETL (connectors to 500 data sources), a data warehouse, and BI (reports & dashboards) in one app. Since we're handling ETL, we already know what each source looks like and have pre-built data models for them. This means you can instantly build a report that connects both Hubspot and Stripe data or Klaviyo and Shopify data.
Я думаю, что это хороший продукт для SMB, неважно для какого географического рынка. Тратить ресурсы на найм дата-инженера или создание целой команды данных до того, как выручка компании достигнет $1 млн в год, нецелесообразно. Проще делегировать эту задачу.
Пара дата продуктов для расширения кругозора:
Faros, Definite, Kyligence, Velvet, Myko , Canvas
Немного близкое поле, но кейс вокруг spreadsheets: Equals, Rows
Baremetrics
Baremetrics: Subnoscription Analytics for your Business
Baremetrics is Subnoscription Analytics and Insights: One click and you get hundreds of valuable metrics and business insights!
Давно сюда не писал. Но пора исправляться, поэтому сегодня про 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