Open Table Formats are not built for streaming

Open Table Formats плохо сочетаются с real-time стримингом, изначально они проектировались под batch-нагрузки.

При этом 85% Kafka sink-трафика уходит в lake, так что неудивительно, что все пытаются решить эту проблему интеграции.

Идеальный размер файлов в таких форматах (например, Apache Parquet) — около 0.5 GB.
Но если писать данные часто (как в real-time), файлы получаются маленькими → медленное чтение + рост затрат на S3.

Какие решения есть?
• batching - писать сразу более крупные файлы
• compaction - потом склеивать мелкие файлы в крупные

Что есть на рынке?

• (free) Kafka Connect → Apache Iceberg, по умолчанию батчит раз в 5 минут
• (paid, $) Kafka Connect → Delta Lake, пишет во временный S3, потом перекладывает
• (paid + lock-in, $$$) Confluent Tableflow, свои компоненты для batching/compaction, работает через S3
• (paid + lock-in, $$$) Databricks Zerobus, простой API для записи в Delta
• (paid + lock-in, $) Bufstream, zero-copy, по сути замена Kafka
• (paid + lock-in, $) Streambased, работает поверх Kafka, дает Iceberg API
• (free, сырой) Aiven Iceberg Topics, использует tiered storage, но кладет данные как Iceberg-таблицы
• (free) Apache Spark Structured Streaming, micro-batch из Kafka в Iceberg; те же проблемы с мелкими файлами, нужны отдельные compaction job’ы
• (радикально другой подход) Apache Paimon

Apache Paimon - альтернативный table format, изначально заточенный под стриминг.

Ключевое отличие, слой хранения на базе LSM-деревьев (Log-Structured Merge).
Новые данные сначала буферизуются и пишутся в level-0 файлы.

Система изначально предполагает много маленьких файлов:
- level-0 → компакция → level-1
- дальше → level-2 и т.д.

За счет этого запись оптимизирована под high-throughput.

Также у Paimon есть эффективный streaming reader:
он читает только дельту между снапшотами.
Это быстрее, чем incremental scan в Iceberg, потому что Paimon хранит manifest delta, а Iceberg вынужден читать много файлов из S3, чтобы понять, что изменилось.

хотя Paimon, это спецификация формата, он вырос из Apache Flink (раньше назывался Flink Table Store), поэтому лучше всего работает именно с ним.

Без Flink это будет ощущаться примерно как Kubernetes без Docker:
- чекпоинты
- управление топологией
- сериализация записи
все завязано на Flink.

У нас на работе используется связка Kafka Connect+Iceberg Sink.
Пришлось писать свое решение с использованием Spark, для maintenance iceberg tables.
А когда у тебя 2к+ таблиц, получается тот еще квест.

@tldr_data

Introducing the Apache Airflow Registry

Централизованный каталог для экосистемы Airflow:
98 провайдеров и более 1600 модулей, включая 848 operators, 298 hooks и 372 модуля только для Amazon.

Что внутри:

- быстрый поиск (Cmd+K)
- отдельные страницы провайдеров с one-click install командами
- встроенный connection builder (генерирует URI, JSON и Env Vars)
- JSON API для интеграции с инструментами и IDE

В итоге - проще находить модули, настраивать подключения и автоматизировать работу с Airflow.

@tldr_data

turbopuffer - это быстрый поисковый движок, который объединяет векторный и полнотекстовый поиск, используя object storage, благодаря чему все ваши данные становятся легко доступными для поиска.

Используя только object storage для хранения состояния и NVMe SSD с кэшем в памяти для вычислений, turbopuffer горизонтально масштабируется и способен обрабатывать миллиарды документов.

Система кэширует только активно запрашиваемые данные, а остальное хранит в дешёвом object storage, что обеспечивает конкурентную стоимость. Холодные запросы по 1 миллиону векторов имеют p90 = 444 мс, тогда как тёплые - всего p50 = 8 мс. Такая архитектура позволяет достигать скорости in-memory поисковых систем при наличии кэша, но при этом обходится значительно дешевле.

Хранение данных в кэше и object storage стоит меньше, чем в традиционных системах с реплицированными дисками, даже для часто запрашиваемых данных.

turbopuffer сфокусирован на первом этапе поиска (first-stage retrieval), эффективном сужении выборки с миллионов документов до десятков или сотен. Хотя у него может быть меньше возможностей по сравнению с традиционными поисковыми системами, этот упрощённый подход позволяет создавать более качественные и поддерживаемые поисковые приложения, которые можно настраивать на предпочитаемом языке программирования.

turbopuffer уже используют такие компании, как Notion и Cursor.

@tldr_data

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