tl;dr data

Amazon S3 annotations: attach rich, queryable context directly to your objects

Amazon S3 представил Annotations — новую функцию метаданных, которая позволяет пользователям прикреплять к каждому объекту до 1 ГБ бизнес-контекста, распределённого по 1 000 именованным аннотациям. Эти аннотации можно изменять без перезаписи самого объекта, а также они автоматически индексируются в таблицы Apache Iceberg, доступные для запросов.

Функция уже доступна во всех регионах AWS и предназначена для поддержки AI-агентов и автономных рабочих процессов. Она позволяет хранить расширенные метаданные — например, транскрипты, возрастные рейтинги контента, технические характеристики и другую контекстную информацию — непосредственно рядом с объектами в S3.

Все аннотации можно искать и анализировать через Amazon Athena, что избавляет от необходимости поддерживать отдельные базы данных для хранения метаданных.

@tldr_data

pg_kpart — это расширение для PostgreSQL, которое блокирует выполнение запросов к партиционированным таблицам, если они пытаются просканировать все партиции без использования условия по ключу партиционирования. Оно защищает от случайных полных сканирований, возникающих из-за отсутствующих условий WHERE или JOIN по ключу партиционирования.

Если вы работаете DBA, то наверняка сталкивались с ситуацией, когда запрос обращается к партиционированной таблице, но не использует ключ партиционирования. На таблицах с сотнями миллионов или миллиардами строк это превращается в настоящую катастрофу: PostgreSQL вынужден сканировать все партиции, подсистема ввода-вывода сервера перегружается, а производительность падает для всех пользователей, подключённых к базе.

Принцип работы расширения очень простой: если запрос к защищённой партиционированной таблице не позволяет исключить ни одну партицию (partition pruning), его выполнение запрещается. Вместо масштабной нагрузки на сервер разработчик получает понятную ошибку и вынужден переписать запрос так, чтобы он фильтровал данные по ключу партиционирования — именно под такой сценарий и создавались партиционированные таблицы.

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

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

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

@tldr_data

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

Он выходит далеко за рамки обычной проверки графиков, используя таксономию Avoiding Data Pitfalls Бена Джонса для выявления таких проблем, как предвзятость, незаметные сбои в конвейерах обработки данных, некорректная агрегация, статистические ошибки, вводящие в заблуждение визуализации и неясная подача информации. После этого инструмент оценивает серьёзность каждой проблемы и предлагает способы её устранения.

@tldr_data

Bruin Semantic Layer

Семантический слой — одна из тех вещей, которые все хотят иметь, но никто толком не знает, с чего начать.
Существует огромное количество способов его реализовать: некоторые встроены в SQL-уровень, например dbt MetricFlow, некоторые являются независимыми решениями, например Cube, а некоторые живут на стороне базы данных, например Snowflake Metric Views.
У каждого подхода есть свои компромиссы.

У семантического слоя Bruin есть несколько особенностей, которые делают его привлекательным:

- Вы можете определять семантический слой в той же кодовой базе, что и ваши data assets. Он хранится в системе контроля версий и находится в том же контексте, что и остальная часть вашей дата-платформы.

- Существующая CLI-команда query в Bruin позволяет выполнять семантические запросы напрямую локально. Это дает возможность использовать такие запросы вместе с AI-агентами.

- Он работает «из коробки» с dac — нашим продуктом для создания дашбордов как кода (dashboard-as-code), который также является open-source.

- Поддерживает вложенные ссылки (nested references), сегменты (segments) и графы соединений (join graphs).

- Может быть проверен с помощью команды bruin validate, чтобы убедиться в корректности определений метрик.

Это означает, что если вы используете агентов для построения пайплайнов, они смогут по ходу работы обновлять и ваш семантический слой. Если Bruin используется как контекстный слой для AI-аналитика данных, вы сразу получаете семантический слой, пригодный для использования этим аналитиком.
Семантический слой пока находится на ранней стадии развития, но уже работает на всех платформах, которые мы поддерживаем. Он совместим с любыми существующими агентами — будь то Claude Code, Codex или Pi.

@tldr_data

LLM Zoomcamp starts

Успевайте зарегестрироваться на курс

https://t.me/tldr_data/84

Crack Any Codebase with AI

Начал сейчас читать эту книгу и вот первая цитата из книги прямо жиза.

Вы знаете эту боль. Это легаси-система, созданная восемь лет назад людьми, которые уже давно ушли, а документация описывает версию, которой больше не существует. Это инцидент в продакшене в 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

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

Anthropic наконец-то опубликовали свой секретный рецепт для агентной аналитики, и это…

Моделирование данных по Кимбаллу (Kimball Data Modeling)

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

Для дата-инженеров и аналитиков это примерно звучит как:

Секрет успешных AI-агентов? Сделайте нормальный DWH

@tldr_data

Launching Polars Distributed on Kubernetes

С сегодняшнего дня, Polars также доступен как распределённый движок (Distributed Engine) для Kubernetes.

Цель Polars всегда заключалась в том, чтобы сделать обработку данных на одном узле максимально производительной и удобной. Теперь Polars хочет распространить этот подход и на распределённые вычисления.

https://pola.rs/posts/polars-distributed-available-on-kubernetes/

@tldr_data

Объединение 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

The Evolution of Cassandra Data Movement at Netflix

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

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

@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

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

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

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

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

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

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

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

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

@tldr_data

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

@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

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

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

Firn

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

@tldr_data

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

@tldr_data