Очередь за self-hosting: Docker, YAML, ночные падения пайплайнов и ручной дебаг.

Рядом managed-сервис: платишь $20–100 в месяц, нажимаешь deploy и всё работает.

В первом случае экономишь деньги.
Во втором часы жизни.

Self-hosting редко бесплатный.
Просто счёт приходит не в долларах, а в потраченном времени.

@tldr_data

Новый поток курса LLM Zoomcamp стартует 8 июня 2026 года. Присоединяйтесь к бесплатному курсу и пройдите путь от основ LLM до готового к продакшену AI-ассистента за 10 недель.

Алексей Григорьев, автор курса, обновит весь контент для этого потока во время своих онлайн-воркшопов.

Вы изучите Retrieval-Augmented Generation, векторный поиск, эмбеддинги, AI-агентов, function calling, оценку (evaluation), мониторинг, гибридный поиск, переранжирование и многое другое.

@tldr_data

From IDEs to AI Agents with Steve Yegge

Работа с поддержкой ИИ может иметь вампирский эффект. Steve Yegge — о том, насколько изматывающей может быть работа с ИИ и почему рабочий день стоит сокращать, чтобы это компенсировать:

С ИИ происходит своего рода вампирский эффект: он тебя воодушевляет, ты работаешь очень интенсивно и создаёшь огромное количество ценности.

Я, например, делаю это для себя, и всё равно чувствую, что работаю на пределе. Ловлю себя на том, что днём приходится спать, и друзья из стартапов говорят, что у них то же самое — они тоже начали спать днём.»

«Мы начинаем уставать, становимся раздражительными.

Компании устроены так, чтобы извлекать из тебя ценность и платить за это. Но исторически они всегда были устроены одинаково: тебе будут давать всё больше работы, пока ты не сломаешься. Если ты справляешься — тебе с радостью дадут ещё, пока твоя “тарелка” не переполнится и ты не выгоришь окончательно.

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

Ответ: вам придётся, иначе сломается уже ваша компания.

Подробнее в подкасте The Pragmatic Engineer.

@tldr_data

С Airbyte такое в порядке вещей 😅

@tldr_data

Firn

Firn — это open-source API для быстрого векторного и полнотекстового поиска по данным, хранящимся в S3. Он использует Lance и кэширование, чтобы делать повторные запросы очень быстрыми. Подходит командам, которым нужен поиск по object storage без затрат и сложности, связанных с запуском OpenSearch.

@tldr_data

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

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

Flowfile — это визуальный ETL-инструмент, построенный вокруг Polars. Позволяет проектировать пайплайны на drag-and-drop canvas или описывать их на Python через API, похожий на Polars.

Визуальные workflow можно экспортировать в самостоятельный Python/Polars-код, что помогает избежать классического lock-in, характерного для low-code платформ.

Также в системе есть каталог на базе Delta, SQL-редактор, scheduler, параметры и изолированные Python kernels.

@tldr_data

Data Landscape — это интерактивная карта открытых стандартов, лежащих в основе современной архитектуры данных: контракты данных, схемы, семантика, файловые и табличные форматы, перемещение данных, обработка, каталоги, lineage, query-движки, качество данных, observability, политики и AI-интерфейсы.

@tldr_data

Xorq — это open-source compute catalog для AI.

Он помогает командам каталогизировать, собирать, переиспользовать и наблюдать трансформации, фичи, модели и пайплайны между разными compute-движками.

Если проводить аналогию: Apache Iceberg стандартизировал данные. Xorq пытается стандартизировать compute.

Так же команда Xorq сделали — Porq.

Это интеграция для coding-агента pi.dev.

Интеграция дает структурированный доступ к заранее подготовленным и проверенным data expressions из каталога xorq.

Вместо загрузки сырых CSV и попыток угадать join’ы, агент использует уже каталогизированные expressions — и за счет этого выдает заметно более качественный результат.

@tldr_data

Я давно слежу за 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

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

The Evolution of Cassandra Data Movement at Netflix

Netflix заменил свой движок переноса данных из Cassandra в Iceberg на многоуровневую платформу, которая читает бэкапы напрямую из S3, преобразует их в Spark DataFrame и позволяет каждому уровню абстракции данных строить собственный оптимизированный коннектор.

Платформа обрабатывает около 3 ПБ данных в день. Для миграции использовались shadow validation, улучшенная observability и fallback-механизм через Maestro Decider на предыдущее решение. Это позволило выполнить прозрачное переключение без каких-либо изменений кода у downstream-потребителей.

@tldr_data