Rosetta DBT Studio — open-source десктопный workspace для команд, работающих с dbt.
Новый AI Agent — это не просто обёртка над чат-ботом. Это tool-loop engine, который умеет:
📂 Просматривать директории проекта и читать schema-файлы, чтобы понимать реальный контекст
✍️ Писать SQL и YAML для dbt-моделей напрямую в ваш проект
▶️ Запускать dbt-команды (compile, run, test) и читать логи
📑 Автоматически открывать каждый созданный файл в новой вкладке редактора, чтобы вы могли сразу всё проверить
Безопасность прежде всего: Agent никогда не запускает terminal-команду без того, чтобы сначала показать вам, что именно он собирается выполнить, и дождаться явного Allow или Deny. Никаких сюрпризов.
Расширяемость:
Skills Library — импортируйте skills в формате Markdown с GitHub, чтобы обучить агент вашим внутренним практикам и соглашениям команды
MCP Servers — встроенная поддержка Rosetta CLI, dbt Core, DuckDB и DuckLake
Поддержка моделей: OpenAI, Anthropic, Gemini и Ollama (локальные модели) — через Vercel AI SDK.
🎬 Полный обзор: YouTube walkthrough
📥 Скачать (macOS, Windows, Linux): Rosetta DBT Studio Download
⭐ GitHub: Rosetta DBT Studio GitHub
@tldr_data
Новый AI Agent — это не просто обёртка над чат-ботом. Это tool-loop engine, который умеет:
📂 Просматривать директории проекта и читать schema-файлы, чтобы понимать реальный контекст
✍️ Писать SQL и YAML для dbt-моделей напрямую в ваш проект
▶️ Запускать dbt-команды (compile, run, test) и читать логи
📑 Автоматически открывать каждый созданный файл в новой вкладке редактора, чтобы вы могли сразу всё проверить
Безопасность прежде всего: Agent никогда не запускает terminal-команду без того, чтобы сначала показать вам, что именно он собирается выполнить, и дождаться явного Allow или Deny. Никаких сюрпризов.
Расширяемость:
Skills Library — импортируйте skills в формате Markdown с GitHub, чтобы обучить агент вашим внутренним практикам и соглашениям команды
MCP Servers — встроенная поддержка Rosetta CLI, dbt Core, DuckDB и DuckLake
Поддержка моделей: OpenAI, Anthropic, Gemini и Ollama (локальные модели) — через Vercel AI SDK.
🎬 Полный обзор: YouTube walkthrough
📥 Скачать (macOS, Windows, Linux): Rosetta DBT Studio Download
⭐ GitHub: Rosetta DBT Studio GitHub
@tldr_data
YouTube
Rosetta DBT Studio — Meet the AI Agent: Your Autonomous dbt Engineer
Stop copy-pasting AI suggestions. The AI Agent in Rosetta DBT Studio doesn't just chat — it reads your project, writes your models, and runs your dbt commands. All inside one secure, extensible desktop workspace.
🔍 Topics covered in this video:
• What makes…
🔍 Topics covered in this video:
• What makes…
👍1
Prefect 3.7.0
В последнем релизе Prefect 3.7.0: команда углубляет интеграцию с uv от Astral.
Поскольку uv продолжает задавать направление для следующего поколения управления Python-пакетами, Prefect развивается вместе с ним: теперь лучше поддерживаются uv workspaces и установка зависимостей через файлы pyproject.toml.
Ключевая часть этого улучшения — Prefect теперь заранее проверяет, что перед запуском flow есть всё необходимое.
Благодаря этому проекты на uv работают стабильнее — от локальной разработки до production.
Для команд, которые стандартизируют стек вокруг uv, это делает Prefect более естественной частью процесса разработки: собирайте проект современным Python-способом, а затем оркестрируйте его без дополнительных костылей для управления зависимостями.
Это ещё один шаг к тому, чтобы Prefect органично вписывался в инструменты, которые Python-команды уже выбирают для своей работы.
@tldr_data
В последнем релизе Prefect 3.7.0: команда углубляет интеграцию с uv от Astral.
Поскольку uv продолжает задавать направление для следующего поколения управления Python-пакетами, Prefect развивается вместе с ним: теперь лучше поддерживаются uv workspaces и установка зависимостей через файлы pyproject.toml.
Ключевая часть этого улучшения — Prefect теперь заранее проверяет, что перед запуском flow есть всё необходимое.
Благодаря этому проекты на uv работают стабильнее — от локальной разработки до production.
Для команд, которые стандартизируют стек вокруг uv, это делает Prefect более естественной частью процесса разработки: собирайте проект современным Python-способом, а затем оркестрируйте его без дополнительных костылей для управления зависимостями.
Это ещё один шаг к тому, чтобы Prefect органично вписывался в инструменты, которые Python-команды уже выбирают для своей работы.
@tldr_data
Prefect
3.7 - Prefect
👍1
Flowfile — это визуальный ETL-инструмент, построенный вокруг Polars. Позволяет проектировать пайплайны на drag-and-drop canvas или описывать их на Python через API, похожий на Polars.
Визуальные workflow можно экспортировать в самостоятельный Python/Polars-код, что помогает избежать классического lock-in, характерного для low-code платформ.
Также в системе есть каталог на базе Delta, SQL-редактор, scheduler, параметры и изолированные Python kernels.
@tldr_data
Визуальные workflow можно экспортировать в самостоятельный Python/Polars-код, что помогает избежать классического lock-in, характерного для low-code платформ.
Также в системе есть каталог на базе Delta, SQL-редактор, scheduler, параметры и изолированные Python kernels.
@tldr_data
GitHub
GitHub - Edwardvaneechoud/Flowfile: Flowfile is a visual ETL tool and Python library combining drag-and-drop workflows with Polars…
Flowfile is a visual ETL tool and Python library combining drag-and-drop workflows with Polars dataframes. Build data pipelines visually, define flows programmatically with a Polars-like API, and e...
👍1
Data Landscape — это интерактивная карта открытых стандартов, лежащих в основе современной архитектуры данных: контракты данных, схемы, семантика, файловые и табличные форматы, перемещение данных, обработка, каталоги, lineage, query-движки, качество данных, observability, политики и AI-интерфейсы.
@tldr_data
@tldr_data
Data Landscape
Data Landscape — Open Standards for Modern Data Architecture
An opinionated, interactive map of the open standards that power a modern data architecture. Curated by Entropy Data.
👍2
Xorq — это open-source compute catalog для AI.
Он помогает командам каталогизировать, собирать, переиспользовать и наблюдать трансформации, фичи, модели и пайплайны между разными compute-движками.
Если проводить аналогию: Apache Iceberg стандартизировал данные. Xorq пытается стандартизировать compute.
Так же команда Xorq сделали — Porq.
Это интеграция для coding-агента pi.dev.
Интеграция дает структурированный доступ к заранее подготовленным и проверенным data expressions из каталога xorq.
Вместо загрузки сырых CSV и попыток угадать join’ы, агент использует уже каталогизированные expressions — и за счет этого выдает заметно более качественный результат.
@tldr_data
Он помогает командам каталогизировать, собирать, переиспользовать и наблюдать трансформации, фичи, модели и пайплайны между разными compute-движками.
Если проводить аналогию: Apache Iceberg стандартизировал данные. Xorq пытается стандартизировать compute.
Так же команда Xorq сделали — Porq.
Это интеграция для coding-агента pi.dev.
Интеграция дает структурированный доступ к заранее подготовленным и проверенным data expressions из каталога xorq.
Вместо загрузки сырых CSV и попыток угадать join’ы, агент использует уже каталогизированные expressions — и за счет этого выдает заметно более качественный результат.
@tldr_data
GitHub
GitHub - xorq-labs/porq: xorq semantic catalog integration for pi.dev — dramatically improve data engineering and ML tasks with…
xorq semantic catalog integration for pi.dev — dramatically improve data engineering and ML tasks with pre-computed, cataloged expressions - xorq-labs/porq
👍1
Я давно слежу за Alexander Noonan.
Еще с его времен в Dagster.
Мне всегда нравилось, как он объяснял новые фичи. Без ощущения, что тебе читают маркетинговый лендинг. Просто нормальный инженерный разбор того, как и зачем это работает. Многие вещи в Dagster я в свое время понял именно через его видео и посты.
Сейчас Alexander перешел в dbt Labs.
И, кажется, это очень хороший мэтч.
Недавно он написал про отчет 2026 State of Analytics Engineering. Там есть цифра, которая хорошо описывает то, что сейчас происходит почти во всех data-командах.
72% команд используют AI в первую очередь для генерации кода.
И только 24% — для тестирования, observability и управления пайплайнами.
Получается довольно знакомая история. Генерировать стало сильно быстрее. Проверять — почти нет.
SQL, dbt models, DAG-и и пайплайны теперь появляются быстрее, чем команды успевают разбираться, что именно уехало в production. А потом все удивляются hallucinated data, странным метрикам и потерянному доверию со стороны бизнеса.
И проблема тут даже не в AI.
Data-команды годами откладывали validation, ownership, lineage, тесты и monitoring «на потом». Просто раньше скорость изменений была ниже, и это не так бросалось в глаза. Теперь AI резко увеличил throughput, а процессы проверки остались примерно на том же уровне.
Мне кажется, ближайшие несколько лет будут не про кто быстрее пишет код через LLM. Скорее про то, кто сможет нормально масштабировать reliability вокруг этого кода.
Тесты, observability, документация, feedback loops — это постепенно становится не дополнительной инженерной культурой, а базовой частью платформы.
@tldr_data
Еще с его времен в Dagster.
Мне всегда нравилось, как он объяснял новые фичи. Без ощущения, что тебе читают маркетинговый лендинг. Просто нормальный инженерный разбор того, как и зачем это работает. Многие вещи в Dagster я в свое время понял именно через его видео и посты.
Сейчас Alexander перешел в dbt Labs.
И, кажется, это очень хороший мэтч.
Недавно он написал про отчет 2026 State of Analytics Engineering. Там есть цифра, которая хорошо описывает то, что сейчас происходит почти во всех data-командах.
72% команд используют AI в первую очередь для генерации кода.
И только 24% — для тестирования, observability и управления пайплайнами.
Получается довольно знакомая история. Генерировать стало сильно быстрее. Проверять — почти нет.
SQL, dbt models, DAG-и и пайплайны теперь появляются быстрее, чем команды успевают разбираться, что именно уехало в production. А потом все удивляются hallucinated data, странным метрикам и потерянному доверию со стороны бизнеса.
И проблема тут даже не в AI.
Data-команды годами откладывали validation, ownership, lineage, тесты и monitoring «на потом». Просто раньше скорость изменений была ниже, и это не так бросалось в глаза. Теперь AI резко увеличил throughput, а процессы проверки остались примерно на том же уровне.
Мне кажется, ближайшие несколько лет будут не про кто быстрее пишет код через LLM. Скорее про то, кто сможет нормально масштабировать reliability вокруг этого кода.
Тесты, observability, документация, feedback loops — это постепенно становится не дополнительной инженерной культурой, а базовой частью платформы.
@tldr_data
dbt Labs
2026 State of Analytics Engineering Report | dbt Labs
New research: AI is scaling analytics output faster than governance can follow. Download the 2026 State of Analytics Engineering Report.
🔥2
MOR Isn’t a Storage Optimization. It’s an Architectural Shift
MOR — это не просто оптимизация хранения данных.
Это архитектурный сдвиг.
Многие описывают Merge-On-Read слишком упрощенно: COW — для чтения, MOR — для записи.
Формально это верно, но такое объяснение упускает главное.
MOR по сути переносит часть работы во времени, разделяя обработку изменений на этапе ingestion и оптимизацию на этапе хранения. Если смотреть на это с такой точки зрения, современная lakehouse-архитектура перестает быть набором отдельных фич и начинает выглядеть как последовательное следствие одного архитектурного решения.
Первым к этому подходу пришел Hudi еще в 2017 году. Iceberg фактически пришел к похожим выводам только в 2021, а Delta — в 2023. Вероятно, Hudi просто опередил свое время: тогда индустрия еще не до конца понимала, зачем вообще нужна подобная фундаментальная архитектура.
В посте разбирается сама архитектурная идея, реальные издержки MOR, временной разрыв между Hudi и другими форматами, а также production-кейсы. Например, ByteDance управляет 400 PB данных в одной MOR-таблице Hudi, а Walmart называет MOR единственным открытым файловым форматом, способным справиться с их workload с большим количеством обновлений.
Подробнее в посте
@tldr_data
MOR — это не просто оптимизация хранения данных.
Это архитектурный сдвиг.
Многие описывают Merge-On-Read слишком упрощенно: COW — для чтения, MOR — для записи.
Формально это верно, но такое объяснение упускает главное.
MOR по сути переносит часть работы во времени, разделяя обработку изменений на этапе ingestion и оптимизацию на этапе хранения. Если смотреть на это с такой точки зрения, современная lakehouse-архитектура перестает быть набором отдельных фич и начинает выглядеть как последовательное следствие одного архитектурного решения.
Первым к этому подходу пришел Hudi еще в 2017 году. Iceberg фактически пришел к похожим выводам только в 2021, а Delta — в 2023. Вероятно, Hudi просто опередил свое время: тогда индустрия еще не до конца понимала, зачем вообще нужна подобная фундаментальная архитектура.
В посте разбирается сама архитектурная идея, реальные издержки MOR, временной разрыв между Hudi и другими форматами, а также production-кейсы. Например, ByteDance управляет 400 PB данных в одной MOR-таблице Hudi, а Walmart называет MOR единственным открытым файловым форматом, способным справиться с их workload с большим количеством обновлений.
Подробнее в посте
@tldr_data
❤1
The Evolution of Cassandra Data Movement at Netflix
Netflix заменил свой движок переноса данных из Cassandra в Iceberg на многоуровневую платформу, которая читает бэкапы напрямую из S3, преобразует их в Spark DataFrame и позволяет каждому уровню абстракции данных строить собственный оптимизированный коннектор.
Платформа обрабатывает около 3 ПБ данных в день. Для миграции использовались shadow validation, улучшенная observability и fallback-механизм через Maestro Decider на предыдущее решение. Это позволило выполнить прозрачное переключение без каких-либо изменений кода у downstream-потребителей.
@tldr_data
Netflix заменил свой движок переноса данных из Cassandra в Iceberg на многоуровневую платформу, которая читает бэкапы напрямую из S3, преобразует их в Spark DataFrame и позволяет каждому уровню абстракции данных строить собственный оптимизированный коннектор.
Платформа обрабатывает около 3 ПБ данных в день. Для миграции использовались shadow validation, улучшенная observability и fallback-механизм через Maestro Decider на предыдущее решение. Это позволило выполнить прозрачное переключение без каких-либо изменений кода у downstream-потребителей.
@tldr_data
Medium
The Evolution of Cassandra Data Movement at Netflix
By Guil Pires, Jennifer Prince, Jose Camacho, Ken Kurzweil, Phanindra Chunduru
❤1
Объединение dbt Labs и Fivetran официально завершено.
Если раньше эти компании закрывали разные части современного data stack, то теперь они строят единую платформу вокруг идеи Open Data Infrastructure.
Но на этом новости не заканчиваются.
dbt Labs представила dbt Core v2.0 и открыла исходный код runtime-движка Fusion.
По сути, это фундамент для следующего поколения dbt. Проект становится не просто инструментом трансформации данных, а полноценной платформой со своим стандартом и экосистемой.
Подробности о dbt Core v2.0:
Из других анонсов особенно выделяются две вещи.
Первая — dbt State.
Теперь dbt становится stateful и начинает хранить состояние между запусками, что открывает новые возможности для оптимизации и управления пайплайнами.
Вторая — dbt Wizard.
Это AI-агент для работы с данными, который позиционируется как инструмент для решения сложных задач аналитической инженерии. По заявлениям команды, он показывает сильные результаты на ADE-Bench.
Обзор новых продуктов и видение объединённой компании:
Если посмотреть на всё вместе, становится заметен интересный тренд.
Analytics Engineering постепенно перестаёт быть просто набором SQL-моделей и оркестрации. Инструменты начинают объединять хранение данных, трансформации, контекст, состояние и AI-агентов в единую среду разработки.
Отдельно рекомендую почитать дорожную карту dbt Core v2.
Там много интересного про будущее стандарта dbt, Fusion Engine и развитие платформы:
Интересно будет посмотреть, насколько удачно dbt Labs и Fivetran смогут реализовать эту стратегию на практике. Но уже сейчас видно, что экосистема dbt движется в сторону гораздо более амбициозной платформы, чем многие представляли ещё пару лет назад.
@tldr_data
Если раньше эти компании закрывали разные части современного data stack, то теперь они строят единую платформу вокруг идеи Open Data Infrastructure.
Но на этом новости не заканчиваются.
dbt Labs представила dbt Core v2.0 и открыла исходный код runtime-движка Fusion.
По сути, это фундамент для следующего поколения dbt. Проект становится не просто инструментом трансформации данных, а полноценной платформой со своим стандартом и экосистемой.
Подробности о dbt Core v2.0:
Из других анонсов особенно выделяются две вещи.
Первая — dbt State.
Теперь dbt становится stateful и начинает хранить состояние между запусками, что открывает новые возможности для оптимизации и управления пайплайнами.
Вторая — dbt Wizard.
Это AI-агент для работы с данными, который позиционируется как инструмент для решения сложных задач аналитической инженерии. По заявлениям команды, он показывает сильные результаты на ADE-Bench.
Обзор новых продуктов и видение объединённой компании:
Если посмотреть на всё вместе, становится заметен интересный тренд.
Analytics Engineering постепенно перестаёт быть просто набором SQL-моделей и оркестрации. Инструменты начинают объединять хранение данных, трансформации, контекст, состояние и AI-агентов в единую среду разработки.
Отдельно рекомендую почитать дорожную карту dbt Core v2.
Там много интересного про будущее стандарта dbt, Fusion Engine и развитие платформы:
Интересно будет посмотреть, насколько удачно dbt Labs и Fivetran смогут реализовать эту стратегию на практике. Но уже сейчас видно, что экосистема dbt движется в сторону гораздо более амбициозной платформы, чем многие представляли ещё пару лет назад.
@tldr_data
Getdbt
dbt Core v2 is here: still open source, now rebuilt for what's next | dbt Developer Blog
The two-engine era is drawing to a close: from now on, dbt Core and Fusion will be built on a shared foundation.
🔥1
Launching Polars Distributed on Kubernetes
С сегодняшнего дня, Polars также доступен как распределённый движок (Distributed Engine) для Kubernetes.
Цель Polars всегда заключалась в том, чтобы сделать обработку данных на одном узле максимально производительной и удобной. Теперь Polars хочет распространить этот подход и на распределённые вычисления.
https://pola.rs/posts/polars-distributed-available-on-kubernetes/
@tldr_data
С сегодняшнего дня, Polars также доступен как распределённый движок (Distributed Engine) для Kubernetes.
Цель Polars всегда заключалась в том, чтобы сделать обработку данных на одном узле максимально производительной и удобной. Теперь Polars хочет распространить этот подход и на распределённые вычисления.
https://pola.rs/posts/polars-distributed-available-on-kubernetes/
@tldr_data
pola.rs
Launching Polars Distributed on Kubernetes
DataFrames for the new era
👍2🔥2
Anthropic наконец-то опубликовали свой секретный рецепт для агентной аналитики, и это…
Моделирование данных по Кимбаллу (Kimball Data Modeling)
Шутка здесь в том, что многие ожидают увидеть какой-то революционный AI-фреймворк, сложную агентную архитектуру или новый research paper, а оказывается, что в основе агентной аналитики лежат старые добрые принципы построения аналитических хранилищ данных по Кимбаллу: факты, измерения, схема звезда, понятные бизнес-сущности и качественно подготовленные данные.
Для дата-инженеров и аналитиков это примерно звучит как:
Секрет успешных AI-агентов? Сделайте нормальный DWH
@tldr_data
Моделирование данных по Кимбаллу (Kimball Data Modeling)
Шутка здесь в том, что многие ожидают увидеть какой-то революционный AI-фреймворк, сложную агентную архитектуру или новый research paper, а оказывается, что в основе агентной аналитики лежат старые добрые принципы построения аналитических хранилищ данных по Кимбаллу: факты, измерения, схема звезда, понятные бизнес-сущности и качественно подготовленные данные.
Для дата-инженеров и аналитиков это примерно звучит как:
Секрет успешных AI-агентов? Сделайте нормальный DWH
@tldr_data
🔥3
We Tried ty for Performance. It Found Real Bugs
Dagster заменил Pyright на новый инструмент проверки типов от Astral — ty,
во всём монорепозитории Dagster.
В результате время проверки типов в CI сократилось примерно с 12 минут до 2 минут на каждый запуск, это было ожидаемо.
Чего команда не ожидали, так это того, что ty обнаружит реальные ошибки времени выполнения (runtime bugs), которые Pyright ранее пропустил.
Это также стало отличным примером того, как много можно сделать с помощью агентных систем.
В Dagster поддерживается более 100 пакетов, и все их нужно было перевести на ty.
Первые несколько миграций выполнялись вручную, пока разбирались в тонких различиях между инструментами и определяли, какие подавления предупреждений (suppressions) безопасны. Но после того как рабочий процесс был отлажен, команда смогла запускать несколько агентов параллельно, чтобы раскатить изменения на все оставшиеся библиотеки.
Если вам интересно узнать больше о проверке типов или о том, как ИИ может повышать продуктивность разработчиков в крупных репозиториях, обязательно ознакомьтесь с этим материалом.
@tldr_data
Dagster заменил Pyright на новый инструмент проверки типов от Astral — ty,
во всём монорепозитории Dagster.
В результате время проверки типов в CI сократилось примерно с 12 минут до 2 минут на каждый запуск, это было ожидаемо.
Чего команда не ожидали, так это того, что ty обнаружит реальные ошибки времени выполнения (runtime bugs), которые Pyright ранее пропустил.
Это также стало отличным примером того, как много можно сделать с помощью агентных систем.
В Dagster поддерживается более 100 пакетов, и все их нужно было перевести на ty.
Первые несколько миграций выполнялись вручную, пока разбирались в тонких различиях между инструментами и определяли, какие подавления предупреждений (suppressions) безопасны. Но после того как рабочий процесс был отлажен, команда смогла запускать несколько агентов параллельно, чтобы раскатить изменения на все оставшиеся библиотеки.
Если вам интересно узнать больше о проверке типов или о том, как ИИ может повышать продуктивность разработчиков в крупных репозиториях, обязательно ознакомьтесь с этим материалом.
@tldr_data
dagster.io
We Tried ty for Performance. It Found Real Bugs
Dagster replaced Pyright with Astral’s new Python type checker, ty, and saw CI type checking drop from minutes to seconds. Along the way, ty surfaced real runtime bugs Pyright missed and improved developer feedback loops across a large Python monorepo.
👍2
Crack Any Codebase with AI
Начал сейчас читать эту книгу и вот первая цитата из книги прямо жиза.
Автор книги — Zezhou Huang, также известен как Zachary (Zach) Huang. Сейчас он работает исследователем в подразделении Microsoft Research AI Frontiers и занимается LLM-агентами и системами. До этого был связан с Microsoft Research, учился в Columbia University и создал проект Codebase Knowledge Builder.
Интересно, что его основная мысль не про генерацию кода, а про понимание кода. В книге он противопоставляет vibe coding и code comprehension.
Книгу только начал читать, поэтому полноценный отзыв дать не могу, но по количеству кода, который сейчас генерируется, надеюсь эта книга поможет быстрее разобраться с кодовой базой.
@tldr_data
Начал сейчас читать эту книгу и вот первая цитата из книги прямо жиза.
Вы знаете эту боль. Это легаси-система, созданная восемь лет назад людьми, которые уже давно ушли, а документация описывает версию, которой больше не существует. Это инцидент в продакшене в 2 часа ночи, где ошибка находится в сервисе, который вы не писали, но чинить его приходится именно вам. Это ваш первый месяц на новой работе: перед вами 100 000 строк кода и задача, которую нужно выпустить через две недели. Это взгляд на собственный код, написанный шесть месяцев назад, когда вы уже не помните, почему сделали всё именно так. Во всех этих случаях код работает. Но никто до конца не понимает, почему он работает. Это то, что мы называем долгом понимания (comprehension debt).
Автор книги — Zezhou Huang, также известен как Zachary (Zach) Huang. Сейчас он работает исследователем в подразделении Microsoft Research AI Frontiers и занимается LLM-агентами и системами. До этого был связан с Microsoft Research, учился в Columbia University и создал проект Codebase Knowledge Builder.
Интересно, что его основная мысль не про генерацию кода, а про понимание кода. В книге он противопоставляет vibe coding и code comprehension.
Книгу только начал читать, поэтому полноценный отзыв дать не могу, но по количеству кода, который сейчас генерируется, надеюсь эта книга поможет быстрее разобраться с кодовой базой.
@tldr_data
👍2