Семантический слой и talk to your data
Когда LLM плотно вошли в нашу жизнь, в дата-мире возникло много энтузиазма относительно того, что наконец-то аналитики будут не нужны можно будет писать запросы на естественном языке. И правда появилось много инноваций в этой области от стартапов и вендоров, которые стараются заставить базы данных общаться не через SQL, а на английском. Примитивный вариант – трансляция натурального языка в SQL-код.
Однако тут есть свои детали – взять тот же простой вопрос на человеческом языке: "сколько активных пользователей из Азии было в моем приложении?"
Без дополнительного контекста LLM не сможет написать что-либо полезное и будет галлюцинировать. Даже внутри одной компании, может быть разная трактовка "активности", считать ли анонимные сессии за пользователей; и к какому региону отнести Турцию.
Озадачившись проблемой с интерпретацией метрик, в дата-мире зазвучали такие слова, как headless BI, metric storage или семантический слой (которые, в общем-то все про одно и то же). Эволюцию в этом мире задала компания Looker, которая представила миру первую семантическую модель LookML в основе своего BI. LookML позволял абстрагировать сложные SQL-запросы в удобный и многократно используемый формат.
На более предметном уровне, семантический слой – это протокол для описания OLAP кубов и отношений между ними. Эта концепция обеспечивает гибкость и согласованность данных, взаимодействуя с несколькими инструментами BI и DS.
Концепция случайно оказалась востребована в зарождающемся мире GenAI, где LLM испытывают сложность с согласованностью. Любой чат-бот или агент, должен как-то синхронизироваться с хранилищем данных.
LLM были обучены на языке как таковом - существительных, прилагательных и т.д. А семантические слои предоставляют LLM объекты, эквивалентные этим элементам языка: сущности для существительных, измерения/атрибуты для прилагательных и меры для количественного описания. У LLM есть выбор объектов в семантическом слое и их атрибутов, чтобы отвечать на вопросы.Так что возможно уже скоро модели данных будут создаваться не для людей, а для LLM.
И вся эта преамбула подталкивает к последним новостям из стартап-дата мира. Cube, компания, основанная россиянами, недавно анонсировала новый раунд на $25 миллионов. Основатели компании считают, что это поможет масштабировать OSS-решения на корпоративный сегмент и конкурировать с другими вендорами, такими, как DBT и AtScale. Но про это поговорим уже в следующих постах.
Этим постом отметим зарождение канала. В этом канале мы решили писать про новые инновации в области дата-продуктов, про то, как соединить мир данных и LLM, и про эволюцию самого семантического слоя.
Когда LLM плотно вошли в нашу жизнь, в дата-мире возникло много энтузиазма относительно того, что
Однако тут есть свои детали – взять тот же простой вопрос на человеческом языке: "сколько активных пользователей из Азии было в моем приложении?"
Без дополнительного контекста LLM не сможет написать что-либо полезное и будет галлюцинировать. Даже внутри одной компании, может быть разная трактовка "активности", считать ли анонимные сессии за пользователей; и к какому региону отнести Турцию.
Озадачившись проблемой с интерпретацией метрик, в дата-мире зазвучали такие слова, как headless BI, metric storage или семантический слой (которые, в общем-то все про одно и то же). Эволюцию в этом мире задала компания Looker, которая представила миру первую семантическую модель LookML в основе своего BI. LookML позволял абстрагировать сложные SQL-запросы в удобный и многократно используемый формат.
На более предметном уровне, семантический слой – это протокол для описания OLAP кубов и отношений между ними. Эта концепция обеспечивает гибкость и согласованность данных, взаимодействуя с несколькими инструментами BI и DS.
Концепция случайно оказалась востребована в зарождающемся мире GenAI, где LLM испытывают сложность с согласованностью. Любой чат-бот или агент, должен как-то синхронизироваться с хранилищем данных.
LLM были обучены на языке как таковом - существительных, прилагательных и т.д. А семантические слои предоставляют LLM объекты, эквивалентные этим элементам языка: сущности для существительных, измерения/атрибуты для прилагательных и меры для количественного описания. У LLM есть выбор объектов в семантическом слое и их атрибутов, чтобы отвечать на вопросы.Так что возможно уже скоро модели данных будут создаваться не для людей, а для LLM.
И вся эта преамбула подталкивает к последним новостям из стартап-дата мира. Cube, компания, основанная россиянами, недавно анонсировала новый раунд на $25 миллионов. Основатели компании считают, что это поможет масштабировать OSS-решения на корпоративный сегмент и конкурировать с другими вендорами, такими, как DBT и AtScale. Но про это поговорим уже в следующих постах.
Этим постом отметим зарождение канала. В этом канале мы решили писать про новые инновации в области дата-продуктов, про то, как соединить мир данных и LLM, и про эволюцию самого семантического слоя.
Cube Blog
Cube raises $25 million - Cube Blog
Cube secures $25 million in funding from existing VCs and partner, Databricks. This confirms that the semantic layer is a needed for the AI-enabled future.
🔥9
На этой поговорим про еще один тренд в дата-мире, который даже отвлек 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-нагрузок, где перерасчёты становятся постоянными. Когда каждый доллар на облаке считается, нет смысла пересчитывать весь стек, если можно работать точечно.