Forward-Deployed Engineer (FDE) — одна из самых быстрорастущих инженерных ролей в AI.

По данным a16z и TechCrunch, за последний год количество вакансий FDE выросло более чем на 1100%.
OpenAI, Anthropic, Palantir, Cursor, Redpanda и десятки других компаний активно нанимают таких специалистов.

При этом вокруг роли много путаницы.
Чаще всего обсуждают зарплаты, требования и способы попасть на позицию. Но гораздо интереснее понять, за что компании готовы платить миллионы долларов.

Идея FDE не нова. Ещё в 2007 году Palantir построила вокруг неё свою модель работы с корпоративными клиентами. Сегодня её используют многие AI-компании.

Что же делает FDE?

Если коротко, это инженер, который отвечает за внедрение AI-решения у конкретного клиента и доводит его до production.

В его задачи обычно входят:

изучение бизнес-процессов заказчика;
разработка production-кода, а не PoC;
интеграция с внутренними системами (API, базы данных, IAM, CRM, ERP);
деплой, наблюдаемость, эксплуатация и поддержка решения;
передача повторяющихся запросов обратно в продуктовую команду, чтобы улучшить платформу для всех клиентов.

По сути, FDE находится на пересечении сразу нескольких ролей: Software Engineer, Data Engineer, Platform Engineer и Solutions Architect.

Главное отличие от Solutions Engineer заключается в ответственности. Solutions Engineer чаще помогает спроектировать решение и провести демонстрацию. FDE отвечает за то, чтобы система действительно заработала в инфраструктуре клиента и приносила бизнес-результат.

Недавно Алексей Григорьев, автор Data Engineering Zoomcamp, опубликовал один из самых подробных разборов этой профессии. Вместо карьерных советов он проанализировал 113 вакансий AI Forward-Deployed Engineer и показал, какие навыки действительно требуются компаниям и чем эти инженеры занимаются каждый день.

Рекомендую к прочтению:

https://alexeyondata.substack.com/p/what-ai-forward-deployed-engineers

Если вы работаете с Data Engineering, AI Platform, LLM-инфраструктурой или строите внутренние платформы для разработчиков, есть большая вероятность, что многие из этих задач уже знакомы.
Возможно, вы уже выполняете часть обязанностей FDE, просто эта роль появилась на рынке относительно недавно.

@tldr_data

Pipelines you own. Author locally, deploy to your servers.

Duckle — это open-source ETL-платформа для команд, которые хотят запускать свои пайплайны на собственной инфраструктуре.

Разрабатывать пайплайны можно локально на ноутбуке — с помощью визуального canvas, Python или SQL, — а затем отправить тот же файл на сервер. Команда duckle-runner serve позволяет запускать его без GUI по расписанию: в Docker или на собственном сервере. При этом доступны веб-консоль, управление ролями и журнал аудита.

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

Duckle компилирует пайплайны в SQL и выполняет их на DuckDB, используя все доступные процессорные ядра. Поэтому чем мощнее сервер, тем быстрее работает пайплайн. Например, 96 миллионов строк из PostgreSQL в Parquet были обработаны за 39,9 секунды.

Никакого облака конкретного вендора. Никакой оплаты за количество обработанных строк. Никакого vendor lock-in.

@tldr_data

Spark observability skills

Skills предназначенные для диагностики и оптимизации нагрузок Apache Spark.

Каждый навык представляет собой отдельный файл SKILL.md, содержащий упорядоченный список наиболее значимых потенциальных причин проблем, которые следует проверить в первую очередь.

Кроме того, в директории scripts/ находится read-only REST-клиент для Spark History Server, который собирает данные о выполнении Spark-приложения в единый ограниченный по объёму snapshot для последующего анализа.

@tldr_data

Apache Airflow 3.3.1: совместимость с pandas 3 и исправления безопасности

Главное изменение касается передачи DataFrame через XCom. В pandas 3 класс теперь записывается как pandas.DataFrame, а не pandas.core.frame.DataFrame.
Airflow 3.3.1 поддерживает оба варианта, поэтому старые XCom остаются доступными.

Обновлять нужно все компоненты Airflow до появления pandas 3 на workers. Старые версии Airflow не смогут десериализовать созданные ими DataFrame XCom. Также стоит проверить DAG, которые зависят от конкретных dtype: строки теперь могут возвращаться как str вместо object, а пропущенные значения — как nan вместо None.

Исправлена миграция с Airflow 2.x при использовании custom Dag bundles. Раньше legacy DAG автоматически получали bundle_name='dags-folder', из-за чего запуск завершался ошибкой. Теперь Airflow определяет bundle по пути к файлу. Принудительно обновить данные можно через airflow dags reserialize.

В релиз также вошли исправления безопасности: маскирование team-scoped sensitive config, защита от получения секрета другой команды, очистка secrets в audit logs и Rendered Templates.

Из операционных исправлений: устранены зависания deferrable tasks, CrashLoopBackOff Triggerer при json_logs, блокировки базы из-за медленных asset listeners и несколько проблем с retries, scheduler и Dag bundles.

Источник: [Apache Airflow 3.3.1 Release Notes]

@tldr_data

А вы знали, что первая версия Apache Airflow называлась Flux?

И её UI выглядел вот так.

Уже тогда была заложена главная идея Airflow: описывать data pipelines на Python как DAG’и, запускать их по расписанию и мониторить через UI.

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

@tldr_data

Apache Airflow 3.3.0: Stateful Tasks and Multi-Language Support

В Airflow 3.3 появился AIP-108 — Language Task SDK. Теперь отдельные tasks можно реализовывать на Java или Go, при этом сам DAG и scheduling остаются в Python.

В DAG задача объявляется как stub:

@task.stub(queue="golang")

Дальше Airflow через Coordinator передает выполнение нужному runtime: JavaCoordinator для JVM или ExecutableCoordinator для Go.

При этом задача остается частью Airflow: доступны XCom, Variables, Connections, retries и стандартный logging.

Это особенно интересно для команд, где orchestration построен на Airflow, а часть production-кода уже написана на Java или Go. Теперь такую логику не обязательно переписывать на Python или выносить за пределы task model Airflow.

Пока Language Task SDK — experimental feature, поэтому API и protocol еще могут меняться.

Документация

@tldr_data

chdb-go

В chdb-go стало проще встраивать ClickHouse прямо в Go-приложение.
Теперь достаточно добавить
blank import:

import _ "github.com/chdb-io/chdb-go/lib/embedded"

Он подтягивает подходящий prebuilt chDB engine для Linux/macOS и amd64/arm64.

При первом запуске движок распаковывается в локальный cache, после чего переиспользуется.
Отдельно устанавливать libchdb больше не нужно.

chDB — это in-process OLAP engine на базе ClickHouse: без отдельного сервера, но с ClickHouse SQL и возможностью напрямую работать с Parquet, CSV, JSON, S3, Iceberg и другими источниками.

Для Go это особенно интересно в контексте CLI, self-contained сервисов и небольших контейнеров, где отдельная native dependency только усложняет deployment.

@tldr_data

Analyst Gym

Analyst Gym — ежедневная тренировка аналитического мышления

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

На этом и построен Analyst Gym.

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

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

Хороший формат для ежедневной тренировки аналитического мышления в мире, где execution всё чаще можно делегировать AI.

@tldr_data

AI Dev Tools Zoomcamp 2026 launches tomorrow.

The course teaches you how to:

- Choose the right AI tools
- Give them the right context
- Extend them with the right capabilities
- Ship safely with review, audit, security, and DevOps controls

The cohort starts tomorrow. Register now to join from the beginning and stay on track with homework, peer review, and the final project.

Register here: https://courses.datatalks.club/register/ai-dev-tools/
Join the launch: https://luma.com/tsiusx8s

Gridex — database IDE для AI-агентов

Gridex — open-source database IDE для macOS, Windows и Linux. Поддерживает PostgreSQL, MySQL, SQLite, Redis, MongoDB, SQL Server и ClickHouse.

Есть встроенный MCP server и единый MCP layer для всех подключений.

Он включает:
→ permissions
→ SQL sanitization
→ row count estimation
→ audit logs

То есть AI-агент работает с базами через контролируемый слой, а не получает прямой доступ.

@tldr_data

Free Airflow AI Crash Course with Marc Lamberti

В прошлом году виртуальная конференция Astronomer собрала более 8 000 инженеров по данным.

В этом году Orchestrate Everything начнётся с бесплатного интенсивного курса Марка Ламберти о том, как оркестрировать AI с помощью Airflow. За участие вы также получите бесплатный код на сертификационный экзамен стоимостью $150.

Затем вы увидите, как на самом деле выглядит оркестрация AI в production: своими кейсами поделятся инженеры из Lyft, Ramp и Wix.

Участие бесплатное. Подходит для data engineers любого уровня.

@tldr_data

dbt Doctor — это open-source инструмент статического анализа, который сканирует dbt-проекты и выявляет отсутствие документации и тестов, расхождения в схемах, устаревшие модели, чрезмерную сложность DAG и пробелы в управлении данными.

Он может запускаться локально, через coding-агентов или в CI, чтобы оценивать состояние проекта и блокировать изменения, которые приводят к проблемам с качеством.

@tldr_data

Make analytics context usable by agents

ktx — open-source context layer for data agents, который решает проблему, которой не хватает обычного доступа агента к warehouse.

Агенту недостаточно знать, какие есть таблицы.
Ему нужно понимать, какой metric является canonical, какие JOIN безопасны, что именно бизнес подразумевает под active customer и откуда вообще взялось определение.

ktx собирает этот контекст из warehouse metadata, dbt/BI, query history и документации, а затем сохраняет его в обычных YAML и Markdown-файлах, которые можно ревьюить и коммитить в Git.

Дальше агент через CLI или MCP может искать нужный контекст, использовать approved metrics и joins, компилировать semantic queries и выполнять read-only SQL.

По сути, ktx пытается стать context layer между data stack и AI-агентом — чтобы агент не каждый раз заново угадывал, как устроены данные и бизнес-логика.

@tldr_data

HydraDB - fast graph database on object storage

HydraDB превращает графовую базу данных в S3-бакет.

Хранилище и вычисления полностью разделены: сам граф, его журнал предварительной записи (WAL) и индексы для обхода графа постоянно хранятся только в объектном хранилище.

Узлы, выполняющие запросы, содержат лишь временный локальный кэш и восстанавливают его заново после перезапуска.

Активный узел-записыватель для каждой ячейки выбирается с помощью lease на основе операции compare-and-swap в бакете.

Подключение осуществляется через стандартный протокол Neo4j Bolt.

@tldr_data