Анонс для Airflow: новые возможности интеграции AI

Появился новый провайдер Common AI Provider, который добавляет поддержку LLM и агентных сценариев непосредственно в Apache Airflow.
Он построен на Pydantic AI и поддерживает более 20 провайдеров моделей, включая OpenAI, Anthropic, Google, Azure, Bedrock и Ollama.

Новые декораторы
@task.llm — отправка prompt в LLM с возвратом текстового или структурированного результата
@task.agent — запуск автономного агента с инструментами, памятью и многошаговым reasoning
@task.llm_branch — делегирование выбора downstream-задач модели
@task.llm_sql — преобразование естественного языка в валидный SQL-запрос
@task.llm_file_analysis — анализ файлов из object storage (текст, изображения, PDF) с помощью LLM
@task.llm_schema_compare — выявление schema drift между базами данных с использованием LLM-рассуждений
Toolsets

В дополнение к декораторам добавлены toolsets — наборы инструментов, которые агент использует для взаимодействия с внешними системами во время выполнения.

SQLToolset предоставляет read-only доступ к SQL-базам. HookToolset позволяет превращать Airflow Hooks в инструменты агента. MCPToolset подключает агента к MCP-серверу через Airflow connection. DataFusionToolset дает возможность выполнять SQL-запросы по файлам Parquet, CSV и Iceberg без отдельной базы данных. LoggingToolset добавляет логирование всех вызовов инструментов с замером времени выполнения.

@tldr_data

Designing Data-intensive Applications with Martin Kleppmann

Как изменились фундаментальные подходы к построению распределённых систем за последнее десятилетие?
Martin Kleppmann, автор культовой книги Designing Data-Intensive Applications (2017), выпустил в этом месяце второе, существенно обновлённое издание.
В обсуждении он делится тем, как эволюционировали требования и практики построения систем.

Ниже — три ключевых тезиса из разговора:

1. Multi-region и multi-cloud — это не best practice, а компромисс

По мнению Клеппмана, не существует универсального правильного ответа, стоит ли использовать multi-region или multi-cloud архитектуру. Это всегда компромисс между рисками и затратами. Решение должно приниматься на уровне бизнеса, а задача инженеров — уметь чётко формулировать эти trade-offs, а не следовать догмам.

2. Репликация важнее шардинга для большинства команд

Хотя в книге подробно разбирается шардирование, сегодня его необходимость снизилась благодаря развитию облаков. Современные машины стали мощнее, и многие нагрузки помещаются в пределах одного узла.

В результате:
шардирование становится более нишевой, специализированной задачей,
а репликация для обеспечения отказоустойчивости остаётся критически важной практически на любом масштабе.

3. Понимание внутренних механизмов систем — конкурентное преимущество

Книга изначально не задумывалась как руководство для разработчиков баз данных или инфраструктуры.
Однако глубокое понимание внутренних механизмов систем даёт разработчикам приложений важное преимущество:
помогает принимать более обоснованные архитектурные решения,
упрощает диагностику проблем с производительностью,
формирует инженерную интуицию, которая становится критичной по мере роста системы.

В целом, за последние годы акцент сместился с жёстких архитектурных паттернов к осознанному выбору компромиссов, где инженерия тесно связана с бизнес-контекстом.

@tldr_data

dbt-score — линтер для качества метаданных в dbt

dbt-score — это инструмент для оценки качества метаданных в проектах dbt.
Он анализирует модели и проекты по набору правил (документация, тесты, ownership, нейминг, сложность SQL), позволяя командам внедрять стандарты через CI/CD и выявлять проблемные модели на ранних этапах. Поддерживаются кастомные правила для учета внутренних требований и governance-политик.

Ключевые возможности

• Комплексный линтинг
Проверяет dbt-объекты по настраиваемым правилам: документация, тесты, структура, нейминг

• Система скоринга
Присваивает числовые оценки (0–10) как отдельным моделям, так и проекту в целом

• Гибкая конфигурация
Настройка правил, уровней строгости и порогов оценки через pyproject.toml

• Интеграция с CI/CD
Возможность падать сборке при несоответствии стандартам качества

• Отслеживание прогресса
Визуальные бейджи и метрики для мониторинга улучшения качества данных со временем

• Расширяемость
Возможность создавать собственные правила под требования конкретной организации

@tldr_data

Kafka + KSQL doing ~200 KB/s in/out costs these guys $120,000 a year 💀

@tldr_data

Rocky — это инструмент на базе Rust, который добавляет управляющий слой поверх хранилищ данных, помогая командам управлять пайплайнами с помощью таких возможностей, как контракты данных, отслеживание происхождения данных (lineage) и безопасное тестирование через ветки.

Он нацелен на раннее выявление ошибок, предотвращение проблем с данными и делает дата-процессы более надежными и понятными.

@tldr_data

В Python-пакет elementary-data, имеющий 1.1 млн загрузок в месяц, внедрён вредоносный код

https://www.opennet.ru/opennews/art.shtml?num=65313

@tldr_data

Очередь за 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