DB-AGENTS

Отец основатель дата инжиниринга Max Beauchemin - предложил соглашение DB-AGENTS в стиле AGENTS.md, которое встраивает понятную для агентов семантику и инструкции непосредственно в базы данных.

Этот документ описывает легковесное соглашение, а не платформу и не фреймворк.

DB-AGENTS позволяет AI-агентам эффективнее взаимодействовать с базами данных, предоставляя контекстные инструкции прямо внутри самой базы.
Для этого не требуется специализированных инструментов: внедрение можно начать с одной таблицы метаданных и небольшого набора инструкций, добавленных в system prompt.

@tldr_data

MCP is dead. Long live the CLI

Достаточно хайповый пост от разработчика.

Он говорит, что LLM отлично работают с командной строкой.
Они обучены на огромном количестве man-страниц, GitHub-репозиториев и shell-скриптов, поэтому команды вроде gh, kubectl или terraform для них естественная среда.
При этом CLI удобен не только для агента, но и для человека: если модель сделала что-то неожиданное, можно просто выполнить ту же команду вручную и увидеть тот же результат.

Командная строка также идеально подходит для композиции инструментов.
Pipes, jq, grep, редиректы — вся Unix-философия уже позволяет обрабатывать данные и соединять инструменты между собой без дополнительной инфраструктуры.

А вот тут уже интереснее, почему пост все же хайпует на том, что MCP мертв.
MCP может быть полезен, если у сервиса нет CLI.

Например - это могут быть:
• Документ-ориентированные SaaS (Notion)
• Issue tracking / project tools
• Knowledge bases (Confluence)
• CRM-системы

Если хотите разабраться в том, как работают MCP, то можно посмотреть курс Андрея Созыкина по Протоколу MCP(курс в процессе разработки).
Андрей прежде всего известен очень хорошими курсами по Компьютерным Сетям.
А в конце, закрепить это все бесплатным курсом от Anthropic - Introduction to Model Context Protocol.

@tldr_data

dbt + Flink для batch и streaming одновременно

Вышел коннектор dbt для Flink.
Теперь можно писать трансформации один раз и запускать их и в batch, и в streaming режиме.

Раньше для batch и streaming нужны были разные инструменты и разные модели.
Что работает для batch, не работает для streaming без переписывания.

Теперь просто пишешь трансформацию один раз, и она работает и для batch, и для streaming.

Плюс все ваши модели остаются версионированными и протестированными.

Так же интересно посмотреть на CLAUDE.md, который используют в адаптере.
Думаю, что то можно взять и в свой проект.

@tldr_data

SQL Crack

Новое расширение для VS Code под названием SQL Crack преобразует SQL-запросы в интерактивные визуальные диаграммы потоков, позволяя разработчикам отслеживать data lineage, находить возможности для оптимизации и анализировать зависимости между файлами в более чем 14 диалектах баз данных, включая PostgreSQL, MySQL и Snowflake.

Этот open-source инструмент использует цветовое кодирование для разных типов узлов (таблицы, join’ы и фильтры) и операций (READ, WRITE, INSERT).
Он поддерживает навигацию с клавиатуры и screen readers, автоматически индексирует SQL-файлы в рабочем пространстве и пропускает build-директории.

@tldr_data

Video Conferencing with Postgres

SpacetimeDB сделали первый в мире видеозвонок через базу данных и в своём стиле предложили всем желающим попробовать повторить это.

Идея действительно интересная и очень необычная.
Они сделали фронтенд, который захватывает аудио и видео из браузерных media API, кодирует их в компактные кадры (PCM16LE для аудио и JPEG для видео), отправляет эти кадры в базу данных, которая выступает в роли брокера сообщений в реальном времени, а затем стримит их обратно в браузер другого участника для воспроизведения.

Реализация выложена в open-source, поэтому автор поста решил разобраться, как это все работает.

@tldr_data

AI Engineering Field Guide

Алекс Григорьев собрал интересный репозиторий с материалами, которые могут помочь подготовиться к позиции AI Engineer.

Алекс проанализировал 1700+ реальных описаний вакансий, опыт прохождения собеседований и истории практиков, чтобы понять, какие навыки и темы чаще всего встречаются в требованиях.

Репозиторий пока находится в процессе наполнения, но уже сейчас там есть полезный ориентир: небольшой roadmap того, на что стоит обратить внимание, если вы, например, хотите перейти из Data Engineer в AI Engineer.

Внутри планируются:
- анализ ролей
- данные по рынку вакансий
- вопросы с собеседований
- learning paths

Выглядит как потенциально хороший справочник для тех, кто пытается понять, какие навыки сейчас реально ожидают от AI-инженеров и в каком направлении двигаться.

@tldr_data

SlowQL

SlowQL - это статический анализатор SQL.
Указываете ему ваши SQL-файлы, и он находит паттерны, которые часто приводят к продакшн-инцидентам, до того как код попадёт в прод.

Инструмент работает полностью офлайн и не имеет зависимостей.

В нём реализовано 171 правило в 6 категориях, которые помогают находить:
• анти-паттерны производительности
• уязвимости безопасности
• нарушения комплаенса
• потенциальные ловушки по стоимости

У SlowQL приятный терминальный интерфейс, который делает использование инструмента довольно удобным для разработчиков.

@tldr_data

OpenAI Data Engineer
$230K – $385K + Offers Equity

Недавно был пост про позицию Analytics Engineer в OpenAI, теперь в компании открыта вакансия Data Engineer.

По стэку все достаточно консервативно - Hadoop, Flink, Airflow, Spark.
Никаких смузи инструментов в виде DuckDB/DLT, только хардкор.

Компания релоцирует новых сотрудников.
В целом хорошая мотивация, чтобы было к чему стремиться. Представьте, что вы работаете в компании, которая меняет облик всего человечества.

@tldr_data

Dolt - это open-source база данных, совместимая с MySQL, со встроенным контролем версий в стиле Git.

Она позволяет создавать ветки, смотреть diff, делать merge, commit и clone для таблиц и схем так же, как это делается с кодом в Git, при этом оставаясь совместимой со стандартными SQL-инструментами.

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

@tldr_data

Breaking the Microbatch Barrier: The Architecture of Apache Spark Real-Time Mode

В Spark наконец-то начали нормально решать старую проблему: либо у тебя высокопроизводительный ETL, либо стриминг с низкой задержкой. Real-Time Mode - это попытка убрать этот компромисс.

Раньше Structured Streaming строился вокруг microbatch-модели: данные собираются в маленькие батчи, обрабатываются, потом следующий батч. Это удобно, но даёт задержку. Даже если батчи маленькие это всё равно batch.

В Real-Time Mode модель меняется. Вместо дискретных микробатчей появляется более гибридный подход: данные идут непрерывно, а обработка не останавливается между итерациями.

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

За счёт этого снижается overhead на планирование, уменьшается latency и исчезают постоянные stop-the-world паузы. Стадии могут выполняться параллельно, а операторы больше не блокируют пайплайн.

В итоге получается что-то между классическим streaming и batch, но с задержками уже ближе к миллисекундам. По сути, Spark уходит от batch disguised as streaming к более честной стриминговой модели.

@tldr_data

Are AI agents actually slowing us down?

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

Также появляются признаки общего ухудшения качества продуктов.

• Anthropic: деградация флагманского сайта. Раздражающая UX-проблема затронула платящих пользователей Claude - и никто в компании этого не заметил. При этом Anthropic двигается очень быстро и генерирует 80%+ продакшен-кода с помощью Claude, но качество и пользовательский опыт, похоже, отходят на второй план.

• Amazon: зависимость от AI-агентов приводит к SEV-инцидентам. В retail-направлении Amazon выросло число сбоев, вызванных собственными AI-агентами. В результате теперь требуется одобрение более сеньорных инженеров для изменений, сделанных с помощью AI.

• Big Tech: используешь AI или ты неэффективен. Компании вроде Uber отслеживают использование AI (например, токены) в performance review, усиливая давление на инженеров - независимо от влияния на качество.

• OpenCode: больше времени на исправления. Создатель OpenCode, Dax Reed, отмечает, что AI-агенты понижают планку качества, демотивируют рефакторинг и не ускоряют команды.

• Стартапы: LLM замедляют долгосрочную скорость. CTO Sentry и другие отмечают, что AI снижает порог входа, но приводит к раздутому и плохо поддерживаемому коду, что замедляет развитие в долгосрочной перспективе.

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

Как это исправить?

Инженеры с сильным архитектурным мышлением становятся критически важными. Среди предлагаемых решений - формальные методы валидации и, возможно, возвращение к некоторым “олдскульным” практикам QA.

полный пост тут

@tldr_data

Data Engineering After AI

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

Традиционные ETL-архитектуры были сфокусированы именно на движении данных и часто зашивали бизнес-логику прямо в пайплайны, из-за чего интерпретационный контекст постепенно размывался по мере прохождения данных через цепочку преобразований.
В качестве альтернативы можно рассматривать подход ECL (Extract, Contextualize, Link), который закрывает этот разрыв за счёт трёх этапов: извлечение надёжных данных из источников, обогащение их контекстом и бизнес-определениями, а затем связывание сущностей между системами, чтобы сохранить целостность и согласованность.

@tldr_data

OpenViking: The Context Database for AI Agents

OpenViking - новый open-source контекстный стор для AI-агентов, который использует файловую парадигму. Он организует память агента, ресурсы и навыки как локальную файловую систему через протокол viking://.

Внутри - трёхуровневая обработка контекста: skeleton, medium и full, что позволяет балансировать между скоростью и полнотой. Для повышения точности используется рекурсивный обход директорий при извлечении контекста.

Отдельно стоит self-iteration loop: агент может автоматически обновлять свою память на основе результатов задач и пользовательского фидбека.

@tldr_data

Anthropic Data Engineer (Safeguards)
£170K – £220K + (возможен equity)

Еще одна открытая позиция в AI гигант.
Data Engineer в Anthropic в команде Safeguards, которая отвечает за безопасность моделей и контроль их поведения.

Роль не совсем про классический data engineering. Это инфраструктура, на которой держится detection абьюза, мониторинг моделей и все safety-механизмы.

По стэку всё довольно стандартно:
SQL, Python, dbt, Airflow, Spark, BigQuery / Snowflake / Redshift, BI-инструменты типа Looker или Tableau.
Все из проверенного data stack.

Из интересного, много работы с real-world сигналами: model outputs, user reports, automated classifiers.
Всё это нужно собрать в единый слой и сделать пригодным для анализа и принятия решений.

Компания спонсирует визы и работает в гибридном формате.

В целом уже прослеживается трансформация роли data engineer, не просто пайплайны и витрины, а система, от которой напрямую зависит, как ведёт себя модель в проде.

@tldr_data

🚨 Breaking: OpenAI to acquire Astral

OpenAI объявили о покупке Astral - команды, которая делает uv, Ruff и ty.

Это уже не какие-то нишевые тулзы.
Ruff - де-факто стандарт линтинга в Python, uv быстро становится заменой pip + venv, ty - попытка переосмыслить type checking.

Все это open-source и уже используется миллионами разработчиков.

Сделка логично укладывается в стратегию OpenAI вокруг Codex, они усиливают слой developer tooling, чтобы закрыть весь lifecycle разработки, а не только генерацию кода.

При этом open-source обещают оставить и развивать.

По сути, они покупают не просто инструменты, а точку входа в developer workflow.

@tldr_data

Your Data Agents Need Context

a16z на этой неделе выпустили материал с довольно жёстким тезисом: первая волна enterprise AI-агентов по сути провалилась из-за отсутствия контекста.

Пример у них почти карикатурный: агенту задают вопрос какой был рост выручки за прошлый квартал? и он ломается.

Ломается, потому что ему никто не объяснил, как в компании считается revenue, какой используется fiscal calendar, что semantic layer давно не обновлялся и какая из трёх таблиц на самом деле source of truth.

В качестве решения предлагается отдельный context layer между данными и агентом - слой, который хранит бизнес-определения, фиксирует tribal knowledge, описывает source mappings и задаёт governance правила, а затем отдаёт всё это через API или MCP, чтобы агент работал не вслепую, а с реальным контекстом.
В целом это звучит логично и давно напрашивалось как отдельная категория.

Но интереснее другое, откуда этот контекст берётся.
В статье почти весь фокус на структурированных системах: data warehouse, BI-слой, dbt, LookML.
Это важная часть, но огромный кусок контекста туда вообще никогда не попадает. Ключевые решения принимаются в других местах: обсуждения что считать revenue происходят в почте, исключения согласуются в пересланных цепочках, часть договорённостей уходит в Slack или остаётся в созвонах.
И это нигде нормально не фиксируется.

В итоге есть две параллельные проблемы.

Первая - построить context layer поверх структурированных данных, и это как раз хорошо разобрано у a16z.

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

@tldr_data

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