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

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