How to build a distributed queue in a single JSON file on object storage

И еще одна новость про turbopuffer, которую активно осуждали на Haker News.

Как построить распределённую очередь на одном JSON-файле в object storage

turbopuffer переписали внутреннюю очередь задач для индексации, которая уведомляет ноды после записи в WAL. Это не часть write path, а просто механизм для асинхронной обработки.
Раньше очередь была зашардирована по нодам, и если одна нода тормозила, её задачи блокировались, даже при свободных ресурсах у других.
Теперь - один файл очереди в object storage и stateless-брокер. В результате получили FIFO, at-least-once доставку и примерно в 10 раз меньше tail latency. Задачи стали заметно быстрее проходить очередь.

Почему object storage?
Простота, предсказуемость и масштабируемость.
Если учитывать его ограничения, можно строить надёжные распределённые системы без лишней сложности.

В итоге, очередь на одном JSON-файле и нескольких stateless-процессах, которая спокойно справляется с нагрузкой и автоматически фейловерится между нодами.

Так же разбор на youtube

@tldr_data

Data Engineering Empire

Игру для data-инженеров сделал не кто нибудь, а Кирилл Бобров.

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

По механике это что-то вроде Cookie Clicker, только вместо печенек ты собираешь сырые данные, строишь пайплайны, нанимаешь инженеров и пытаешься не обанкротиться до того, как доберёшься до AGI.

Причём внутри всё завязано на вполне реальные вещи: ETL, стриминг, feature store, распределённые вычисления. Инфраструктура может случайно падать, инженеры стоят денег буквально каждую секунду, а как только у тебя появляются AI-ресёрчеры, часть команды могут переманить.

Сам автор пишет, что неожиданно залип не в разработку механик, а в баланс экономики и в какой-то момент понял, что занимается обычным capacity planning.
Просто для браузерной игры.

Игра бесплатная, работает прямо в браузере, без регистрации и трекинга.

@tldr_data

Apache Iceberg Rust

Apache Iceberg выпустил версию iceberg-rust 0.9.0, в которой представлена архитектура хранилища на основе трейтов, отделяющая библиотеку от конкретных storage-бэкендов и упрощающая интеграцию и расширение.

В этой версии также реализованы значительные улучшения производительности при чтении через Arrow, расширена поддержка DataFusion, а обработка decimal-типов обновлена до точности в 38 знаков с использованием crate fastnum.

@tldr_data

Volga: A Rust Rewrite of a Real-Time AI/ML Data Engine

Volga теперь представляет собой полностью Rust-ориентированный движок для real-time AI/ML, заменив прежнее ядро на базе Python+Ray, чтобы добиться более простой архитектуры, высокой производительности и более строгого контроля над выполнением и состоянием.

Он объединяет стриминговые, батчевые и запросные вычисления в единую самостоятельную систему, стремясь устранить типичную «склейку» между Flink, Spark, Redis и кастомными сервисами, при этом сохраняя корректное состояние (point-in-time) непосредственно внутри движка.

Ключевыми строительными блоками выступают Apache DataFusion для SQL-пайплайнов, Apache Arrow для семантики исполнения и SlateDB для хранения состояния поверх S3.

@tldr_data

Using Gravitino with Apache Flink for Streaming

В этом туториале вы узнаете, как использовать Apache Gravitino вместе с Apache Flink для построения простого стримингового пайплайна. Вы создадите каталог Hive и каталог Paimon в Gravitino, определите универсальную таблицу в каталоге Hive с источником на базе Apache Kafka, а затем с помощью Flink SQL (через коннектор Gravitino для Flink) будете читать данные из Kafka и записывать их в таблицу Paimon.

@tldr_data

MCP is Dead; Long Live MCP!

Еще шесть месяцев назад протокол MCP был у всех на устах, и казалось, что все стремятся выпустить продукты и инструменты, связанные с MCP.
Но что изменилось за это время?

Люди стали замечать, что при работе с MCP агент тратит больше токенов, чем если бы он использовал обычные CLI tools.
Но это не основная проблема.
MCP стали расти как на дрожжах, и не всегда становится понятно, надежным ли инструментом ты пользуешься.

Один разработчик рассказывает, что он с удивлением обнаружил 66 zombie Docker containers.

Агент взаимодействует с локальными MCP-серверами через stdio.
Он запускает docker run -i, отправляет JSON через stdin и читает ответы из stdout.
Когда вы закрываете сессию Claude Code, процесс docker run завершается.
Но сам контейнер — это отдельный процесс, управляемый демоном Docker, который не знает, что сессия MCP завершена.
Контейнер продолжает работать, удерживая открытым соединение с базой данных и ожидая данные из stdin, которые уже никогда не придут.
Флаг --rm в этом случае не помогает: он удаляет контейнер после его остановки.
Но эти контейнеры никогда не останавливаются.

Решение: использовать uvx вместо Docker.
И многие MCP доступны как пакеты, которые можно запускать напрямую.
uvx запускает сервер как обычный дочерний процесс.
Когда агент завершает работу, этот процесс автоматически очищается.
npx и pnpx работают аналогичным образом.

Другая ситуация оказалась намного хуже.

Атаку выявили при анализе инцидента: у разработчика litellm оказался транзитивной зависимостью MCP-плагина в Cursor.
Но инцидент с litellm произошёл не на ровном месте.
Чуть ранее был подвержен атаке Trivy.

Trivy — это инструмент, который ты запускаешь в своём CI/CD пайплайне, и он проверяет твой код на уязвимости. Ищет проблемы в NPM-пакетах, Python-зависимостях, Docker-образах, проверяет мисконфигурации в Kubernetes, находит захардкоженные секреты.
В общем, это именно тот инструмент, который должен быть про безопасность — но иронично, что вот его-то и взломали.

24 марта.
LiteLLM — Python-библиотека-прокси для всех LLM API с 95 миллионами загрузок в месяц, которая использовала Trivy в своём CI, потеряла токен мейнтейнера, и с его помощью были опубликованы версии 1.82.7 и 1.82.8 с вредоносным кодом.

Какие выводы можно сделать из этих историй с MCP?

Пинить и убирать :latest из Docker-образов
Пинить и убирать :latest из любых сторонних пакетов
Хотя бы частично проверять код MCP и issues на GitHub

@tldr_data

ELT-Bench: An End-to-End Benchmark for Evaluating AI Agents
on ELT Pipelines

Достаточно интересный whitepaper, оценивающий способность агентов собирать end-to-end пайплайны.

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

На этом фоне логично ожидать, что ИИ сможет упростить разработку. Модели уже показывают сильные результаты в задачах вроде text-to-SQL и в целом уверенно работают с данными. Но если посмотреть шире, оказывается, что почти все существующие бенчмарки оценивают лишь отдельные навыки: написать SQL-запрос, воспользоваться инструментом, преобразовать данные. Полноценный end-to-end сценарий от источников до готовой модели, практически не покрыт.

ELT-Bench как раз пытается закрыть этот пробел.
Это сквозной бенчмарк, в котором собраны 100 пайплайнов, 835 исходных таблиц и 203 модели данных из разных доменов. Внутри максимально приближённые к реальности задачи: интеграция разнородных источников, работа с популярными инструментами, необходимость писать код и SQL, а также управлять всем процессом целиком.

Результаты получились интересными.
Даже лучший агент OpenHands CodeActAgent на базе Claude-3.5-Sonnet , корректно генерирует лишь 11,3% моделей данных.
В среднем на один пайплайн уходит 72 шага и около $1.41. Это уже не уровень отдельных функций или запросов, здесь проявляется вся сложность оркестрации, управления состоянием и зависимости между этапами.

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

@tldr_data

Fivetran donates its SQLMesh data transformation framework to the Linux Foundation

Fivetran передаёт SQLMesh (свой фреймворк трансформаций на базе SQL, полученный после приобретения Tobiko Data в сентябре прошлого года) в Linux Foundation, чтобы продвигать вендор-нейтральное управление слоем трансформаций. SQLMesh добавляет в SQL-пайплайны тестирование, версионирование и процессы планирования/применения, похожие на Terraform. Стратегическая цель - влиять на формирование стандарта открытой дата-инфраструктуры (наряду с dbt) и ускорять внедрение за счёт владения со стороны сообщества.

@tldr_data

Bruin: Project Competition

Bruin - это инструмент для построения data-пайплайнов, который объединяет загрузку данных, их трансформацию с использованием SQL, Python и R, а также контроль качества данных в едином фреймворке. Он работает со всеми основными платформами данных и может запускаться на локальной машине, на экземпляре EC2 или в GitHub Actions.

Сейчас Bruin проводят интересный конкурс.

Нужно сделать data engineering проект с использованием Bruin.
Потом будет голосование, за лучший проект.

Призы достаточно крутые:

- Mac Mini for an outstanding project
- 1 year Claude Pro for the top 3 projects
- 1 month Claude Pro for participants

Deadline: Monday, June 1st, 12:00 UTC

@tldr_data

Claude How-To

Вы установили Claude Code, попробовали пару промптов и застряли.
Документация объясняет функции по отдельности, но не показывает, как собрать их в реальный workflow: связать slash-команды с хуками, памятью и субагентами.
Понятного пути обучения нет, что изучать сначала, MCP или hooks, навыки или субагентов?

В итоге всё просматривается поверхностно, а до продакшен-уровня дело не доходит.
Базовые примеры тоже не помогают: hello world не превращается в полноценный pipeline для code review с автоматическими проверками и делегированием задач.

В результате используется лишь малая часть возможностей, остальное просто теряется.

Этот курс закрывает пробел: 10 модулей, покрывающих весь функционал от slash-команд до команд агентных систем, (CLAUDE.md, hooks, MCP, субагенты, плагины), диаграммы Mermaid с разбором внутренней логики, и чёткий путь обучения, который за 11–13 часов доводит до уровня уверенного пользователя.

Плюс встроенная самопроверка через /self-assessment и /lesson-quiz прямо внутри Claude Code, чтобы быстро находить слабые места и закрывать их.

@tldr_data

Open Data Platform

Open Data Platform (ODP) - это набор инструментов с открытым исходным кодом, который позволяет дата-инженерам интегрировать проприетарные, лицензируемые и публичные источники данных в AI-копилоты и исследовательские дашборды через архитектуру:
подключи один раз, используй везде.

Платформа устанавливается через pip и работает в различных Python-окружениях, Excel, MCP-серверах для AI-агентов и REST API, а также интегрируется с корпоративным интерфейсом Workspace от OpenBB для визуализации и анализа данных.

@tldr_data

The Claude Code Source Leak: fake tools, frustration regexes, undercover mode, and more

У Anthropic утек исходный код Claude Code, именно CLI, потому что в npm-пакет уехал .map файл.

Код быстро удалили, но его уже успели разобрать по частям.

Пара вещей, которые бросаются в глаза.

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

Undercover mode.
Модели прямо запрещают упоминать Claude Code, внутренние названия и вообще что-либо, что указывает на Anthropic. Выключить нельзя.
То есть AI-коммиты с их стороны в open source ничем не отличаются от обычных.

Детекция фрустрации:
regex со списком (wtf, this sucks и т.д.).
На фоне всего остального выглядит смешно, но получается, что это дешевле и быстрее любого LLM-вызова.

/\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|horrible|awful|
piss(ed|ing)? off|piece of (shit|crap|junk)|what the (fuck|hell)|
fucking? (broken|useless|terrible|awful|horrible)|fuck you|
screw (this|you)|so frustrating|this sucks|damn it)\b/

Есть попытка привязать API к клиенту. В запросе placeholder, который на уровне Bun заменяется на хэш. Сервер проверяет, что это настоящий клиент. По сути DRM. Судя по коду — не особо жёсткий.

Из реального продакшена: были сессии с тысячами подряд ошибок, что сжигало ~250k API-вызовов в день. Фикс - лимит на количество неудач.

KAIROS - самый интересный кусок.
Зафлагованный режим автономного агента: фоновые процессы, cron каждые ~5 минут, GitHub вебхуки, ночная обработка памяти.
Похоже на always-on агента.

И важный момент: Anthropic недавно купили Bun, и Claude Code построен поверх него.
При этом в Bun есть баг, из-за которого source map может отдаваться в проде, хотя не должен. Если утечка произошла из-за этого - это буквально их же стек, который раскрыл их же код.

Upd: Буквально через пару часов, после того, как в сеть попал код Claude Code,
произошла параллельная supply-chain атака на пакет axios в npm.

Если вы устанавливали или обновляли Claude Code через npm 31 марта 2026 между 00:21 и 03:29 UTC, есть риск, что подтянулась вредоносная версия axios (1.14.1 или 0.30.4) с встроенным RAT. Стоит проверить lock-файлы (package-lock.json, yarn.lock, bun.lockb) на эти версии или зависимость plain-crypto-js. Если нашли, машину лучше считать скомпрометированной: перевыпустить все секреты и переустановить систему.

@tldr_data

Эволюция pgAdmin: от GUI к AI-ассистенту

pgAdmin впервые появился в 1998 году под названием pgManager - это более 28 лет разработки, вложенных в один GUI-инструмент для выполнения запросов и администрирования. (Он существует почти столько же, сколько и сам PostgreSQL)

Сейчас 2026 год, и pgAdmin получил очередное обновление.

В pgAdmin появилась новая функциональность на базе ИИ, и создатель проекта (Dave Page) разобрал все нововведения в серии из трёх блог-постов, чтобы вы получили полную картину. Можно из коробки работать с провайдерами LLM, такими как Anthropic, OpenAI, Ollama или Docker Model Runner, чтобы получать:

- AI-отчёты с анализом производительности, дизайна схемы и безопасности

- AI-инсайты по планам EXPLAIN / EXPLAIN ANALYZE

- AI-ассистента для преобразования запросов на естественном языке в SQL

Как он подытоживает в конце серии:

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

@tldr_data

MOTHERDUCK NOW SPEAKS POSTGRES

MotherDuck объявила о запуске нового Postgres-совместимого endpoint’а, который позволяет пользователям подключаться к своему хранилищу данных MotherDuck и выполнять запросы с помощью любого стандартного PostgreSQL-клиента, драйвера или BI-инструмента. Это дает командам возможность продолжать использовать PostgreSQL для транзакционных нагрузок, одновременно вынося быстрые аналитические запросы на серверлесс-вычисления MotherDuck.

@tldr_data

​📝 сделал демку с streaming lakehouse на опинсорсных технологиях (без confluent cloud и tableflow) и написал блог. Как раз к Iceberg Summit на след неделе.
Почитайте, покомментируйте

https://gamov.io/posts/streaming-lakehouse/

How to Structure an AI Project for Data Engineering

Небольше видео про то, как структурировать AI-проект в data engineering:

В центре файл CLAUDE.md, который используется как единая точка управления: через него задаются контекст, правила и ожидаемое поведение модели.
Это позволяет уйти от набора несвязанных промптов и выстроить более системную работу.

Также показывается, как такая структура соотносится с привычным prompt engineering, приводится пример организации AI-проекта и даются практические рекомендации по ускорению начальной настройки.

@tldr_data

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