SQL-first подход для PostgreSQL 🐘

pGenie — инструмент, строящий workflow вокруг SQL без лишних абстракций. Вы пишете SQL, система валидирует запросы, управляет индексами и генерирует type-safe SDK на основе миграций, исключая дублирование логики.

SQL становится источником правды для data-логики и контрактов между backend и БД. Это снижает ошибки, повышает прозрачность и упрощает поддержку в командах, работающих с SQL.

@tldr_data

Вы установили dbt_utils. Хорошее начало.

Вот список пакетов и инструментов, которые должны быть в каждом серьёзном dbt-проекте:

- dbt_utils — суррогатные ключи, date spine, pivot. Базовый минимум без компромиссов.

- dbt_expectations — более 50 типов тестов. Позволяет проверять то, что dbt не умеет из коробки.

- dbt_audit_helper — сравнение старых и новых результатов моделей перед релизом рефакторинга.

- dbt_codegen — генерация source YAML на основе вашей схемы.

- dbt_project_evaluator — автоматический аудит проекта на соответствие best practices.

- elementary — обнаружение аномалий, алерты по схеме, lineage.

- dbt_profiler — подсчёт null, уникальных значений, min/max — не выходя из dbt.

- dbt_external_tables — создание и управление внешними таблицами прямо в dbt.

- dbt-colibri — бесплатный column-level lineage для dbt-проектов.

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

@tldr_data

AI Enablement Engineer: The Highest-Leverage Role in Tech

Интересная мысль от Maxime Beauchemin - человека, которого часто называют отцом data engineering.

Появляется новая роль внутри технологических компаний - её можно назвать AI Enablement Engineer.

Речь не про поверхностный AI enablement: обучающие сессии про промпты, подбор инструментов или внутренние гайды. Это почти не влияет на реальную скорость работы.

Речь про инженеров, которые строят инфраструктуру вокруг AI. Они делают контекстные слои, продумывают guardrails, собирают toolkits для агентов и встраивают это в реальные процессы. В результате не один человек разобрался с AI, а вся команда начинает быстрее решать задачи от аналитики до разработки.

Это даёт кратный рост скорости. И этот рост пока ничем не ограничен.

Такие инженеры работают не на уровне личной продуктивности. Их задача - разогнать всю команду. Не просто эффективно использовать AI самим, а сделать так, чтобы этим пользовались остальные и получали результат.

По сути, это один из самых сильных мультипликаторов эффективности, который сейчас формируется в индустрии. И приоритет у этого направления уже максимальный.

За последний год всё чаще видно, что путь к реальному импакту внутри компаний ведёт именно сюда. И это уже не просто тренд, а новая функция, которую начинают выделять отдельно.

@tldr_data

Claude Certified Architect

У Anthropic появилась сертификация.

Сертификация Claude Certified Architect - Foundations подтверждает, что специалист способен принимать обоснованные решения о компромиссах при внедрении реальных решений на базе Claude.
Экзамен проверяет базовые знания по Claude Code, Claude Agent SDK, Claude API и Model Context Protocol (MCP) - основным технологиям для создания production-приложений с Claude.

Так же на GitHub есть русскоязычный гайд для подготовки.
Выглядит как не плохой вариант разобраться с Claude Code.
Ну и сертификат не будет лишним.

@tldr_data

Apache Airflow 3.2 вышел.

Ниже представлены ключевые нововведения:

• Партиционирование ассетов (Asset Partitioning)
Запуск DAG’ов при обновлении конкретных партиций данных.

• Поддержка нескольких команд (Multi-team support)
Изолированные секреты и ресурсы для разных команд в рамках одного инстанса Airflow.

• Уведомления о дедлайнах (Deadline Alerts)
Уведомления в случае, если выполнение DAG занимает больше времени, чем ожидалось; альтернатива SLA.

• Поддержка асинхронных функций в PythonOperator
Нативный запуск async-функций (особенно актуально для AI-задач), без необходимости создавать кастомные операторы.

• Сравнение изменений кода (Diff) в Code View
Возможность отслеживать различия между версиями DAG непосредственно в интерфейсе.

• Кнопка копирования логов
Упрощает работу с логами за счёт быстрого копирования.

• Новый механизм плагинов на React
Расширенные возможности кастомизации пользовательского интерфейса Airflow.

• История согласований Human-in-the-loop
Отслеживание действий пользователей при одобрении или отклонении результатов AI.

• Индикатор версий DAG
Явное отображение различий между версиями DAG в Grid View.

P.S. Вебинар по Airflow 3.2 проходит сегодня.

@tldr_data

Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update

Семантический слой не исчез, но его роль меняется.

В последнее время вокруг этой темы много разговоров:
одни списывают Semantic Layer, другие считают Text-to-SQL угрозой качеству данных. На практике оба подхода уже используются параллельно и решают разные задачи.

Text-to-SQL заметно прибавил в качестве.
Он хорошо работает для ad-hoc запросов: быстрые срезы, проверки гипотез, разовые вопросы. Можно получить черновой ответ без участия аналитика.

Но когда речь про метрики, то ситуация немного другая.
Semantic Layer по-прежнему даёт более точные результаты в прямом сравнении и фиксирует единую логику расчётов. Это критично для финансовых показателей, продуктовых KPI и любой отчётности, где одна и та же метрика должна считаться одинаково везде.

Причина простая: Semantic Layer задаёт единое определение метрик и делает его источником истины для всех инструментов.

При этом качество данных остаётся ключевым фактором. Улучшения в модели (структура, связи, naming) повышают точность и у Text-to-SQL, и у Semantic Layer - это подтверждается и практикой, и бенчмарками.

Как это использовать на практике:

Сначала исследование.
Аналитик или продукт задаёт вопрос и быстро получает ответ через Text-to-SQL.
Это этап, где важна скорость и допускаются неточности.

Если метрика начинает использоваться регулярно её фиксируют в Semantic Layer.
Там задаётся единая логика расчёта, и дальше все дашборды и отчёты используют уже её.

Например: сначала кто-то посчитал retention на лету, потом эта формула закрепляется, и вся команда начинает работать с одной версией метрики.

Полный разбор тут

@tldr_data

BI умрёт к концу года

Это мнение Pete Hunt - CEO Dagster и человека из data-инфраструктуры, а не BI-вендора.

Я думаю, что к концу этого года BI умрёт.

Все BI-вендоры оказываются зажаты с двух сторон.

Снизу, вертикальная интеграция со стороны data-компаний, плюс Claude уже довольно хорошо справляется с анализом данных. Сверху, компании из мира vibe coding, такие как Lovable и Replit, пытаются зайти в enterprise. Один из их сценариев - генерация презентаций и аналитики.
По сути, это те же данные, только зафиксированные в конкретный момент времени, без постоянных дашбордов.

BI-вендоры отвечают ожидаемо, добавляют AI-функции и повышают цены, чтобы сохранить маржу.
Но здесь классическая дилемма инноватора. AI быстро становится commodity: похожие возможности появляются у всех, а цена неизбежно давится вниз.

Поэтому ставка делается в другую сторону.

Цель - сделать AI дешёвым и доступным интерфейсом, а основную ценность сместить ниже: в оркестрацию и data-платформу.
Именно там остаются требования к надёжности, поддержке и восстановлению - вещи, за которые компании реально платят.

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

@tldr_data

LAKEHOUSE LANDSCAPE 2026

Почти год назад обсуждение Lakehouse всё ещё было сосредоточено вокруг открытых табличных форматов и предположения, что Parquet с метаданными достаточно для большинства корпоративных задач. Но управление данными быстро развивается, и ландшафт 2026 года показывает более зрелую, модульную и амбициозную экосистему.

Что изменилось?

✅ Файловый слой снова становится зоной инноваций.
Новые форматы, такие как Lance и Vortex, привлекают внимание, потому что ориентированы на сценарии, для которых классические Parquet-ориентированные подходы не предназначались: мультимодальный ИИ, векторный поиск, произвольный доступ, встроенные индексы и выборочные чтения. В то же время File Format API в Apache Iceberg - это серьёзный шаг вперёд: он позволяет подключать новые форматы файлов без нарушения open lakehouse-контракта.

✅ Каталоги становятся стабильнее и более стандартизированными.
Ключевой сдвиг- не в появлении множества новых каталогов, а в росте значимости Iceberg REST Catalog как общего слоя интероперабельности. Именно он сохраняет экосистему открытой, позволяя движкам, инструментам и managed-сервисам взаимодействовать через единый протокол, а не через хрупкие интеграции.

✅ Открытая интероперабельность явно побеждает.
Провайдеры и платформы всё больше сходятся вокруг совместимых с Iceberg паттернов доступа, REST-подключения к каталогам и подходов с выдачей учётных данных (credential vending). Центр тяжести смещается от изолированных метаданных к единой control plane, которая может последовательно обслуживать разные движки.

✅ Появляются лёгкие инструменты, упрощающие работу с Lakehouse.
DuckDB становится одним из самых практичных движков доступа к современным lakehouse, с растущей поддержкой Iceberg, Lance и каталогов. DataFusion также набирает популярность как переиспользуемый execution-слой на базе Apache Arrow, делая доступ к lakehouse более программируемым и удобным для встраивания в современные системы.

✅ Streaming-first подход становится частью архитектуры lakehouse.
Apache Paimon заслуживает большего внимания, поскольку предлагает модель, ориентированную на стриминг, для обработки высокочастотных обновлений и CDC-нагрузок. Это важно, потому что корректность в реальном времени и непрерывное обслуживание таблиц становятся базовыми требованиями, а не опциональными возможностями.

Главный вывод:
lakehouse больше не сводится к связке Parquet + table format. Архитектура становится многослойной. Файловый слой, каталоги, execution и streaming развиваются независимо. За счёт этого систему можно менять частями — без миграций на годы вперёд.

@tldr_data

Список гостей в The Pragmatic Engineer Podcast — это уже не просто подкаст, а почти зал славы индустрии.

Из ближайших выпусков:

• Thuan Pham — первый и самый долго работающий CTO Uber
• Martin Kleppmann — автор одной из ключевых книг по data engineering
• David Heinemeier Hansson — создатель Ruby on Rails, известный своими резкими позициями
• Anders Hejlsberg — человек за TypeScript и C#
• Kelsey Hightower — одна из ключевых фигур вокруг Kubernetes

Из последних выпусков:

• Mitchell Hashimoto — автор Ghostty
• Andrey Breslav — создатель Kotlin
• Mai-Lan Tomsen Bukovec — человек, который отвечает за Amazon S3

Лично мне очень зашел выпуск с Mitchell Hashimoto (He is the co-founder of HashiCorp and creator of Ghostty).
Ghostty сейчас, на мой взгляд, один из лучших терминалов, недавно полностью переехал на него с WezTerm.

Больше всего жду выпуски с Martin Kleppmann и David Heinemeier Hansson(Создатель Ruby on Rails).
Клепман — понятно, про распределённые системы.
DHH, скорее всего, опять пройдётся по микросервисам и расскажет, почему всем нужен монолит.

И отдельно — у Gergely Orosz есть книга The Software Engineer’s Guidebook — советую всем.
Сам прочитал пока примерно треть, но уже забрал несколько практичных идей.

Например: фиксировать свою работу, что делал, какие задачи закрывал, кому помогал.
Такие заметки сильно упрощают жизнь на performance review, не нужно вспоминать полгода задним числом.

@tldr_data

Vector Database Performance Compared: pgvector vs Pinecone vs Qdrant vs Weaviate

Каждая команда, которая делает поиск или RAG, в какой-то момент доходит до выбора векторной базы. На это часто уходит непропорционально много времени.

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

Pinecone закрывает вопрос инфраструктуры: поднял и работаешь. Это удобно на старте и в прототипах, но за это платишь меньшим контролем над тем, как именно считается recall.

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

Milvus имеет смысл, когда речь идёт о сотнях миллионов или миллиардах векторов. Там уже важны шардинг и партиционирование, и у него это реализовано зрелее, чем у остальных.

Weaviate упрощает жизнь, если нужен гибридный поиск, когда в одном запросе сочетаются keyword и vector. Плюс у него аккуратно сделан managed-вариант.

pgvector хорошо ложится в существующий стек с Postgres. До примерно 10 миллионов векторов он закрывает задачи без отдельной инфраструктуры. Дальше уже приходится думать про масштабирование, например через pgvectorscale.

Но в реальных системах узкое место другое.

Задержка 5 мс против 15 мс на векторном запросе не влияет на восприятие продукта. Пользователь этого не увидит. Зато разница между сильной и слабой моделью эмбеддингов сразу видна в результатах поиска. В одном случае ответы попадают в контекст, в другом нет.

Та же история с релевантностью и UX. Переранжирование, нормальная работа с контекстом, понятные ответы, всё это даёт кратно больший эффект, чем выбор между двумя быстрыми базами.

@tldr_data

Краткий обзор на интервью DHH

Удивительно, в это раз про микросервисы не вспомнили и даже переобулись с темой AI.

Вот вообщем короткая выжимка из интервью.

Всего шесть месяцев назад David Heinemeier Hansson (создатель Ruby on Rails и Omarchy) в подкасте Lex Fridman говорил, что не использует AI-инструменты для написания кода — они были недостаточно хороши. Сейчас он работает иначе: agent-first.

Автор подкаста расспросил за ситуацию про то, как изменился его процесс разработки и что он думает о профессии. В этом плане он последователен: тот же фокус на коде как ремесле, на аккуратности и внимании к деталям.

Первое, что бросается в глаза — его отношение к AI почти не поменялось. Поменялись сами инструменты. Полгода назад автодополнение уровня tab completion только мешало: оно сбивает темп и даёт слишком слабые подсказки. Переход к агентным моделям изменил ситуацию. В связке с более сильными моделями, вроде Opus 4.5, результат стал другим: агент генерирует код, который можно принимать без существенных правок. Это уже не подсказки, а полноценные изменения в кодовой базе.

Второй момент — его взгляд на красоту кода.
Для него это не эстетика ради эстетики.
Он формулирует это жёстко: если что-то выглядит правильно, скорее всего, оно и работает правильно. Здесь он ссылается на Steve Jobs — идея о том, что даже внутренняя часть системы должна быть аккуратно сделана.

Люди, которые внимательно разводят платы, как правило, так же внимательно проектируют интерфейсы. Это один и тот же навык, просто в разных слоях.

И, наконец, его текущий workflow. Он работает в tmux с несколькими сплитами. В одном — быстрая модель (обычно Gemini 2.5), которая даёт быстрые итерации. В другом — более медленная, но сильная (Opus), куда уходят сложные задачи. По центру — Neovim, где он просматривает изменения через Lazygit.

Это не выглядит как AI пишет код вместо разработчика. Скорее как система из инструментов с разной латентностью и качеством, между которыми он маршрутизирует задачи.

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

Про настройку и кастомизацию терминала будет следующий пост.

@tldr_data

Introducing Metrics SQL: A SQL-based semantic layer for humans and agents

Metrics SQL от Rill создаёт семантический слой, нативный для SQL: бизнес-метрики определяются один раз и затем используются консистентно во всех дашбордах, инструментах и AI-агентах, устраняя расхождения в метриках.

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

@tldr_data

AI CONTEXT ENGINEERING WITH APACHE AIRFLOW

Если вы работаете в analytics engineering, игнорировать AI уже не получится. Но и переоценивать его не стоит.

Сейчас много разговоров про AI-агентов как будущее data engineering. На практике это новый слой над существующей инфраструктурой, а не её замена. Пайплайны, модели данных, качество и lineage остаются. Просто появляется ещё один потребитель - AI.

Ключевое изменение, работа с контекстом.
Модели не знают вашу предметную область.
Их результат напрямую зависит от того, какие данные вы им даёте и как эти данные организованы. Фактически появляется новая задача: готовить данные не только для BI или ML, но и для агентов.

Это выглядит как эволюция привычных процессов. Те же DAG’и в Apache Airflow, но с дополнительными шагами: генерация, проверка, обратная связь. Добавляются практики вроде Agent-as-Judge или Human-in-the-Loop, чтобы контролировать поведение моделей. Это пока не стандарт, а скорее рабочие подходы, которые тестируются в продакшене.

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

Через две недели Astronomer проведёт бесплатный вебинар по этой теме.

Будут разбирать, как на базе Airflow собрать AI-агента для поддержки: от сбора сырых данных до формирования AI-ready контекста и трассировки решений в виде context graph.

@tldr_data

Launching S3 Files, making S3 buckets accessible as file systems

Amazon S3 Files - это новая возможность, которая позволяет монтировать любой S3-бакет и работать с ним как с полноценной файловой системой напрямую из инстансов EC2, контейнеров или функций Lambda. При этом обеспечивается задержка около 1 мс для активных данных и автоматическая двунаправленная синхронизация между файловой системой и S3-бакетом.

Сервис уже доступен во всех коммерческих регионах AWS и устраняет классический компромисс между преимуществами объектного хранилища S3 и интерактивностью файловых систем. Это делает его особенно полезным для совместных нагрузок - например, AI-агентов и пайплайнов обучения ML, которым требуется общий доступ к данным S3 с низкой задержкой.

@tldr_data

Один из самых внятных бесплатных курсов по AI coding agents

opencode.school - 14 уроков, 7 практических проектов, без регистрации.

Я сам ежедневно использую Claude Code. Но зависеть от одного провайдера готовы не все.

OpenCode - open-source альтернатива, которая работает с 75+ моделями: Claude, GPT, Gemini или локальные модели на вашей машине.

Чем курс отличается:

Вы учитесь прямо внутри инструмента.
Копируете промпты в OpenCode, и он ведёт вас по шагам, параллельно синхронизируя прогресс с сайтом.

Покрывает весь базовый слой: установка, права доступа, кастомные команды, плагины, multi-agent сценарии.

В конце курса, прикладные проекты:
сборка сайтов, автоматизация браузера.

Если вы хотели разобраться с AI-агентами, но откладывали из-за непонятного старта, то это один из самых понятных способов начать.

@tldr_data

Вышел Dagster 1.13

И здесь есть несколько вещей, на которые стоит обратить внимание.

Лично для меня главное обновление, наконец появились partitioned asset checks.
Теперь проверки можно запускать для конкретной партиции upstream-ассета, а не прогонять всё целиком.

Второе большое обновление AI-инструменты.

Команда заопенсорсила dagster-io/skills - репозиторий со знаниями по Dagster, адаптированный под Claude Code, OpenAI Codex, OpenCode и другие агентные инструменты.

Это дополняется расширенным API в dg CLI, который даёт структурированный доступ к job’ам, run’ам, расписаниям, сенсорам и другим сущностям.

Что ещё интересного:

Virtual assets (пока в preview) позволяют описывать database views и другие производные ассеты, которые автоматически обновляются при изменении родительских данных, без явной materialization.
Это убирает давнюю проблему с декларативной автоматизацией и устаревшим статусом view.

State-backed компоненты теперь включены по умолчанию.
Интеграции с dbt, Fivetran, Tableau, Looker и другими инструментами используют сохранённые метаданные вместо повторных запросов к внешним системам.

Также в версиях 1.12.x / 1.13 добавили более 20 новых компонентов: dbt Cloud, Apache Spark (preview), Microsoft Azure, Google Cloud Platform, Databricks, а также расширили поддержку Fivetran и BI-инструментов.

Полный разбор в релизном блоге.

@tldr_data

Docglow — это open-source инструмент, который превращает проекты dbt в более удобную и интерактивную документацию: с визуализацией lineage, поиском и AI-чатом.
Он делает изучение моделей данных проще по сравнению со стандартной документацией dbt.

Это легковесная self-hosted альтернатива более тяжёлым инструментам дата-каталога, с акцентом на удобство как для технических, так и для бизнес-пользователей.

@tldr_data

Database Branching in Postgres: Git-Style Workflows with Databricks Lakebase

Databricks запустили функцию ветвления баз данных (database branching) для Lakebase Postgres, используя механизм copy-on-write для создания изолированных окружений базы данных за считанные секунды без дублирования данных. Это заменяет традиционный подход с использованием pg_dump, который может занимать часы для больших баз данных.

@tldr_data

Технологический стек данных Lyft

Разбор масштабной data-инфраструктуры, которую использует Lyft для поддержки более 25 млн активных пользователей и обработки миллионов событий в реальном времени каждую секунду.

Метрики:

• 28,7 млн активных пользователей в Q3 2025, совершающих ~2,7 млн поездок в день.
• Apache Kafka обрабатывает миллионы событий в секунду для стриминговой аналитики.
• Тысячи пайплайнов на Apache Airflow и Flyte оркестрируют ETL- и ML-процессы.
• Хранилище данных превышает 100+ ПБ в Amazon S3 с использованием Apache Hive Metastore.
• ETL на Trino выполняет ~250 тыс. запросов в день, читая ~10 ПБ/день и записывая ~100 ТБ/день.

@tldr_data

Thoughts on Apache Iceberg Summit 2026

Неделю назад в Сан-Франциско закончился Apache Iceberg Summit 2026.
Два дня саммита позволили выработать общее понимание по обсуждениям, которые доминировали в dev-рассылке всю весну.

Тема опциональности metadata.json в V4 собрала самую большую аудиторию среди всех дизайн-сессий:
эксперты подробно разобрали вопросы переносимости и последствий для статических таблиц, если корневой JSON-файл становится опциональным в случае, когда каталог управляет состоянием метаданных.
Сформировавшееся направление — признать управление метаданными со стороны каталога полноценным режимом first-class, при этом гарантии переносимости сохраняются через явную opt-in семантику, а не текущие предположения по умолчанию.

Дизайн one-file commits — направление, которое Russell Spitzer и Amogh Jahagirdar продвигали через серию предложений — движется к формальному описанию спецификации после согласования, достигнутого на саммите.
Подход заменяет списки манифестов на корневые манифесты и использует delete-векторы манифестов для поддержки коммитов в один файл, что обещает существенное снижение латентности коммитов и объёма хранимых метаданных.
Это одно из наиболее значимых изменений V4 для сценариев с высокой частотой записи, и очные обсуждения позволили закрыть оставшиеся разногласия по поводу inline против внешних delete-векторов манифестов.

Предложение Peter Vary по эффективным обновлениям колонок для AI/ML-нагрузок вызвало заметный интерес на саммите.
Дизайн ориентирован на широкие таблицы, где при каждой записи изменяется лишь подмножество колонок — embedding-векторы, скоринги моделей, значения фичей.
Это позволяет Iceberg записывать только изменённые колонки в отдельные файлы и объединять их на этапе чтения.
Для команд, управляющих feature store’ами петабайтного масштаба, экономия I/O может быть существенной.
Петер отметил, что формальное предложение с POC-бенчмарками появится в dev-рассылке в течение нескольких дней после саммита.

Политика вклада с использованием AI, в обсуждении которой участвовали Holden Karau, Kevin Liu, Steve Loughran и Sung Yun, приблизилась к практическому разрешению.
Саммит дал ту ясность, которой часто не хватает асинхронным обсуждениям, и ожидается, что рабочая версия политики — включая требования к раскрытию информации и стандарты происхождения кода для AI-сгенерированных вкладов — будет опубликована в dev-рассылке уже на этой неделе.

@tldr_data

Polars in Aggregate: Streaming Expands, Lakehouse I/O, and Cloud Profiling

Последний цикл релизов Polars приближает стриминговый движок к использованию по умолчанию за счёт расширения поддержки: теперь доступны streaming merge join, as-of join, а также потоковые чтения и записи (scan/sink) для CSV, NDJSON, IPC и облачных источников.

Также добавлена нативная поддержка roundtrip-операций с Delta Lake и Iceberg, включая прямую ленивую запись (lazy writes) обратно в Delta и функцию sink_iceberg() для построения готовых к коммиту стриминговых пайплайнов.

В Polars Cloud теперь доступен профайлинг запросов с метриками на каждом этапе выполнения: CPU, RAM, сеть и shuffle.

@tldr_data