Как я стал дата-инженером?

Хочу поделиться своей историей перехода в мир дата-инженерии. Возможно, кого-то это вдохновит и поможет сделать первые шаги 🤝

💡Изначально меня привлекал Data Science с точки зрения ML - обучение моделей, участие в хакатонах по компьютерному зрению, ранжированию и NLP 🤖. Я активно изучал ML, экспериментировал и набирался опыта.

Но всё изменилось, когда я устроился в геномный центр 🧬Именно там я впервые столкнулся с инженерной стороной данных. Вокруг были свои форматы, специфичные инструменты и оркестраторы, разработанные специально для работы с геномными данными. Объёмы данных были по-настоящему впечатляющими: более 10 000 человеческих геномов (каждый весом около 100 ГБ), хранившихся на ленточных хранилищах

Там я начал писать свои первые пайплайны, настраивал сбор и обработку данных. Постепенно понял, что такая разработка мне реально нравится. Даже больше, чем обучение моделей. Было интересно копаться в инструментах, разбираться, как всё устроено, и делать так, чтобы система работала чётко и надёжно. Именно тогда я и решил двигаться в сторону дата-инженерии ⚙️

Чтобы вкатиться по-настоящему, мне пришлось подтянуть базовые навыки:

✔️SQL — базовый навык, который спрашивают на каждом собеседовании. Отличный интерактивный курс на Stepik помог разобраться с этим языком запросов.

✔️Python — умение писать простенькие алгоритмы, знать основы структур данных и объектно-ориентированного программирования. Здесь очень помогли открытые курсы от МФТИ по алгоритмам и структурам данных и ООП(с 5ого по 9ый модули) , хорошо бы освоить хотя бы на теории.

✔️Решение задач уровня medium на Leetcode — отличный способ подготовиться к собеседованиям и улучшить алгоритмическое мышление.

✔️Чтение статей про HDFS, Airflow, СУБД, Spark — чтобы понять, с какими инструментами приходится работать в реальной инженерной практике. О них всех и о том какие этапы я проходил расскажу в следующих постах.

Если было интересно, ставьте 🔥

❗️Вопрос с собеса в BigTech:

«Мы удвоили количество executor ов, но Spark джоба не ускорилась. Почему?»

Это классическая ловушка для тех, кто пытается лечить любую проблему масштабированием 🥸

У тебя есть медленный pipeline. Ты увеличиваешь  количество executor ов в 2 раза, перезапускаешь job, а время выполнения остаётся прежним или даже растёт.

Что происходит?

1️⃣Data skew 🥴

Если один ключ содержит 90% данных, все связанные с ним записи могут попасть в одну shuffle-partition. Один task будет работать 20 минут, пока остальные завершатся за секунды.

В таком случае дополнительные executor’ы не помогут: job ждёт самую медленную task 🐌

В Spark UI сравни  Max  и  Median  по длительности tasks и объёму  Shuffle Read .

Большой разрыв — сигнал проверить перекос данных❗️

2️⃣Узкое место в shuffle🔀

 JOIN ,  GROUP BY  и  repartition  могут вызвать shuffle — перераспределение данных между executor’ами.

Если bottleneck (узкое место) находится в shuffle, добавление машин не убирает саму пересылку, сортировку и запись промежуточных данных на диск.

Сначала нужно проверить план и объём shuffle, а затем рассмотреть broadcast join, предварительную агрегацию, фильтрацию до join и настройку числа shuffle-partitions.

3️⃣Недостаточно задач для параллелизма🟰

Количество executor’ов само по себе не создаёт работу. Если в stage всего несколько крупных tasks, дополнительные executor’ы будут простаивать.

Поэтому нужно смотреть не только на число executor’ов, но и на количество tasks, размер partition и соотношение доступных ядер к параллельной работе.

4️⃣Слишком много мелких файлов💛

Миллион файлов по 10 КБ — это не много вычислений, а много служебных операций: listing, планирование и запуск tasks.

Масштабирование кластера проблему не устранит. Нужно менять стратегию записи и объединять мелкие файлы.

5️⃣Memory pressure, GC и spill🕳

Если tasks обрабатывают слишком большие partition, executor может тратить время на сборку мусора или сбрасывать промежуточные данные на диск ( spill ).

 Spill  не всегда означает ошибку — это допустимый механизм Spark. Но если он массовый, а  GC Time  высокий, нужно проверить размер partition, shuffle и конфигурацию памяти.

Как отвечать на собеседовании 🧐

Я бы сказал:

☑️«Сначала открою Spark UI и найду самый долгий stage».
☑️«Сравню  Max  и  Median  длительности tasks».
☑️ «Проверю  Shuffle Read/Write , spill и  GC Time ».
☑️ «Посмотрю, хватает ли tasks для загруженных ядер».
☑️«Только после диагностики буду менять конфигурацию или добавлять ресурсы».

Главная мысль: больше executor’ов ускоряют job только тогда, когда есть достаточно независимой работы. Если причина в skew, shuffle, мелких файлах или memory pressure, масштабирование лишь увеличит стоимость, но не устранит bottleneck.

📚Для изучения:

⏺ Руководство для начинающих по Spark UI

⏺Оптимизируем Shuffle в Spark

Ставь 🔥, если было полезно!

С нуля в Data Engineering: Путь до оффера в BigTech 🚀

Записал интервью со своим учеником. Это честный разговор о том, как реально сменить профессию и устроиться дата инженером в 2026 году.

Важно: Личность и голос Антона изменены для сохранения его анонимности на текущем месте работы. Все результаты — подлинные, верифицированные отзывы есть в канале.

О чем видео:
⏺Сколько времени занял переход с нуля до оффера
⏺Как мы прорабатывали легенду для резюме
⏺Страхи на первых собесах
⏺Совет тем, кто думает вкатываться

📺Смотреть:

YOUTUBE

RUTUBE

ИИ в проде: что агенты уже могут делать в Data Engineering

Про ИИ-агентов сейчас много шума. Иногда агентом называют обычный чат с LLM 😺, хотя разница довольно простая.

Чат отвечает. Агент может сам сходить за информацией и что-то сделать 🤖

Например, ночью упал DAG. Агент открывает логи, смотрит прошлые запуски, проверяет схему и пытается понять, где всё сломалось. После этого может предложить retry, backfill или завести инцидент.

То есть это уже не просто скинь ошибку в ChatGPT. Агент получает доступ к Airflow, мониторингу, каталогу данных и другим инструментам.

🧐Звучит удобно, но сразу появляется вопрос: а стоит ли давать ему самому что-то менять в проде?

Прочитать логи и найти подозрительное место — нормально. Удалить данные, изменить схему или запустить большой backfill без подтверждения человека — уже страшновато😱

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

Сейчас самые понятные сценарии выглядят так:

⏺описание таблиц и колонок;
⏺поиск связей между данными;
⏺генерация SQL;
⏺разбор логов и упавших пайплайнов;
⏺поиск аномалий и причин алертов.

Например, MWS запустила
Data Scout. Агент анализирует метаданные, ищет связи между таблицами и помогает наполнять каталог данных.

Пока агенты не заменяют дата-инженеров. Скорее, становятся еще одним слоем над платформой🧠

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

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

💡Кстати, в программе появилось видео про ИИ в проде: как агенты сейчас устроены и работают на реальной платформе в крупном бигтехе. + Сейчас планируем видео курс (для менти) про внедрение ИИ агентов в проект 😎

Как рассказывать о своём опыте на собеседовании 🎙

Просто перечислить Kafka, Spark и ClickHouse недостаточно. Интервьюеру важно понять, какую задачу ты решал, что сделал лично и почему выбрал такой подход.

Хороший рассказ выглядит так:

1️⃣Какая была проблема
2️⃣За что отвечал лично ты
3️⃣Почему выбрали этот стек
4️⃣С какими сложностями столкнулись
5️⃣Какой получили результат

Но мало просто подготовить красивый текст. Нужно понимать каждую его часть.

Если говоришь, что работал с Kafka, будь готов объяснить:

⏺как выбирали количество партиций
⏺что происходило при падении consumer
⏺как контролировали дубли и lag
⏺почему вообще понадобилась Kafka

Иначе первый же глубокий вопрос покажет, что что-то не так…🥶

Для подготовки можно использовать чат гпт😺. Отправь ему описание вакансии/ проекта и попроси:

Проведи со мной собеседование на Middle Data Engineer. Задавай вопросы по одному, уточняй детали, ищи противоречия и отмечай места, где непонятен мой личный вклад

Ещё один полезный приём: подготовить три версии рассказа: на 30 секунд, на 2 минуты и подробную, если интервьюер решит копнуть глубже.

Я бы начинал с короткой версии. А дальше лучше остановиться. Не нужно сразу рассказывать весь проект. Пусть интервьюер сам выберет, куда копать.

Ещё полезно оставлять в рассказе крючки🪝:

«При повторном запуске у нас появлялись дубли, поэтому пришлось отдельно продумывать идемпотентность»

Скорее всего, следующим вопросом будет:

«А как именно вы решили проблему?»

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

И обязательно проговаривай всё вслух. В голове ответ всегда звучит лучше, чем на реальном собеседовании🤵‍♀️

Не нужно учить текст дословно😎Лучше заранее продумать связки и формулировки, а затем несколько раз рассказать всё своими словами.

Уверенно звучит не тот, кто идеально выучил текст, а тот, кто понимает каждое своё решение🙂

Ставь 🔥, если было полезно!

Что такое векторные базы данных?

Представим, что пользователь пишет📝:

«Не проходит оплата»

А нужная инструкция называется:

«Ошибка при проведении платежа»

Слова разные, поэтому обычный поиск может ничего не найти. Но смысл у запросов похожий - именно это учитывает векторный поиск.

Как он работает🤔

Специальная модель превращает каждый текст в набор чисел - вектор. Чем ближе смысл двух текстов, тем больше похожи их векторы.

Эти векторы сохраняются в специальной базе. Примеры таких баз: Qdrant, Milvus, Weaviate, pgvector — дополнение для PostgreSQL.

В базе обычно хранятся:
❗️вектор текста
❗️сам текст или ссылка на него
❗️дополнительная информация: дата, источник, категория и права доступа

Когда пользователь задаёт вопрос, он тоже превращается в вектор. База находит несколько похожих фрагментов и передаёт их нейросети. Уже на их основе она формирует ответ❔

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

Векторный поиск используют для:

⏺поиска по внутренним документам;
⏺чат-ботов поддержки;
⏺рекомендаций товаров;
⏺поиска похожих изображений;
⏺работы с юридическими и банковскими документами.

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

Поэтому Data Engineer здесь отвечает за сбор и очистку документов, удаление дублей, загрузку данных и их своевременное обновление.

📚Для изучения:

Векторные базы данных: простым языком про сложное

Векторные базы для RAG: сравнение Qdrant, pgvector, Milvus и Weaviate

Ставь 🔥, если было полезно!

До конца года 4 месяца. Что можно успеть? 📖

Лето закончили с сильными результатами: 13 менти получили офферы, а суммарно ребятам поступило 20 предложений о работе 🔥

Многие ребята получили сразу несколько предложений, а рекорды лета: 5 финальных офферов у одного менти и 7 предофферов у другого 🏆В итоге ребята могли выбирать между компаниями, условиями и зарплатой. Дата инженеры сейчас нарасхват!

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

За последние месяцы программа менторства сильно улучшилась! ⚙️

В закрытой базе появилось много новых видео по Spark, Kafka, Iceberg, Greenplum и другим инструментам. В них не только теория, но и разборы на примерах из реальных продов!

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

Подготовка строится поэтапно:
⏺разбираем твой опыт и составляем индивидуальный план
⏺подтягиваем SQL, Python и основные DE-инструменты;
⏺лично проверяю каждый блок и всегда остаюсь на связи
⏺создаём проект
⏺готовим резюме и легенду в несколько итераций
⏺проводим мок-собеседование и выходим на рынок

Дополнительно ты получаешь доступ к закрытому DE-комьюнити, где ребята делятся свежими вопросами, рефералками и опытом. Групповые созвоны каждую пятницу🍻

После оффера я остаюсь на связи ещё три месяца и помогаю пройти испытательный срок 🤝

Отзывы и количество офферов говорят сами за себя!

Если хочешь использовать эту осень для перехода в Data Engineering или роста до следующего уровня, пиши: @ampodvalniy 🔥

Мини гайд по ИИ-агентам

Агент снова забыл условия задачи, полез менять лишнее или написал готово, хотя код не работает? 😓Начать стоит с того, как организована работа.

Вот несколько вещей, которые полезно использовать👇

1️⃣Давай конкретные вводные

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

Переписку по пяти разным проектам лучше не смешивать. Для новой, несвязанной задачи открывай отдельный чат 🤝

2️⃣Сохрани правила проекта

Где лежат исходники, как запускать проверки, какие файлы нельзя менять. Это можно записать в инструкции проекта 📩, которые поддерживает твой инструмент.

3️⃣Повторяющиеся задачи оформляй в Skills

Skill — инструкция для конкретной задачи с примерами и, при необходимости, скриптами.

4️⃣Подключай нужные сервисы через MCP

Допустим, описание задачи лежит в Jira. Чтобы агент сам его прочитал, можно подключить MCP-сервер — программу, которая обращается к Jira и возвращает данные агенту.

MCP задаёт общие правила такого подключения. Аналогично можно подключить другие поддерживаемые сервисы.

Скилл при этом объясняет, что делать с полученными данными. Они вполне могут работать вместе.

5️⃣Поручай субагентам отдельные части работы

Субагенты — помощники, которым основной агент передаёт задачи👋

Один изучает логи, другой проверяет изменения кода. Каждый возвращает выводы, а основной агент сопоставляет результаты ❤️

📚Подробнее о настройке агента под проект

Ставь 🔥, если было полезно!

Тебе тоже кажется, что забываешь быстрее, чем учишь?

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

Думаю всем знакомо…☹️

Полез почитать на эту тему. Много полезного нашёл в книге «Запомнить всё» Питера Брауна и соавторов. Некоторые приёмы знакомы ещё со школы и универа🤔 . Сам так делал, особо не задумываясь, почему помогает)

Простое перечитывание часто даёт обманчивое ощущение, что ты всё знаешь. 🤥Открываешь статью третий раз, узнаёшь формулировки. Но закрываешь её и своими словами объяснить уже сложно.🥺

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

Вот как это можно понемногу добавлять в обычный день 👇

🤩Едешь в метро или идёшь куда-то — вспомни, что изучал вчера. Как решалась задача? Почему выбрали такой подход? Не получается сразу — немного подумай, прежде чем искать ответ. Потом проверь, что забыл или перепутал.

🗣 Пересказывай вслух, когда удобно. Хоть самому себе или чату гпт. Например, объясни, чем отличаются два вида JOIN. Где застрял, туда и стоит заглянуть в материалах.

😺Попроси гпт тебя поопрашивать. Скинь материал, который изучал, и напиши:

Задавай мне вопросы по этому материалу по одному. Дождись моего ответа, затем проверь его по тексту и объясни ошибки. Проси приводить свои примеры. Не подсказывай заранее

Можно отвечать голосом, заодно потренируешься формулировать мысли. Если объяснение чата вызывает сомнения, сверяйся с исходным материалом.

⏰Возвращайся к старому через время. Встретил знакомый термин в статье, попробуй объяснить его до того, как читать дальше. Это уже маленькое повторение.

И ещё интересно: если вспоминать тяжело, это не обязательно значит, что ты плохо поучился. Перечитывать готовое объяснение легче. А когда пытаешься ответить сам, ошибаешься и разбираешь ошибку, знания могут закрепляться лучше.

Поэтому с такой проблемой я бы предложил начать с коротких и регулярных возвращений к пройденному: пару вопросов в дороге, объяснение вслух, небольшой опрос в чате👋

Через месяц что-то всё равно забудется — это нормально! Но такие небольшие попытки вспомнить помогают сохранить больше и быстрее восстановить остальное 👊

А какими лайфхаками вы пользуетесь? 🖊️

CDC и Debezium: как передавать изменения, а не выгружать всю таблицу заново?

Допустим, заказы интернет-магазина 🟧 хранятся в MySQL, а отчёты строятся в ClickHouse🏠. Данные между ними нужно регулярно обновлять.

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

Здесь пригодится Debezium — инструмент, который отслеживает изменения в базе и передаёт их дальше. Такой подход называется CDC — Change Data Capture

Как он понимает, что изменилось? 🤔

В MySQL есть binlog — журнал🗂, в котором фиксируются изменения. При соответствующей настройке Debezium читает его и формирует события:

📍появился заказ — добавлена запись;
📍статус поменялся с создан на оплачен — запись обновлена;
📍заказ удалили из таблицы — запись удалена.

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

🔄А как данные попадут в ClickHouse?

Один из вариантов: Debezium отправляет события в Kafka, а отдельный обработчик или готовый коннектор читает их и записывает результат в ClickHouse.

Здесь у каждого своя задача: Debezium замечает изменения, Kafka хранит и передаёт события, а загрузчик применяет их в хранилище. Пример архитектуры.

Кстати, почему бы просто не выбирать строки по updated_at?⏰

Так тоже можно. Но поле должно корректно обновляться при каждом изменении. А если строку физически удалили, запрос по updated_at её уже не найдёт. В журнале остаётся событие удаления, Debezium может его передать.

Но подключить Debezium недостаточно, чтобы данные сами стали правильными ☑️

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

Для небольшого справочника с обновлением раз в сутки обычная выгрузка может быть проще. А если большая таблица постоянно меняется и эти изменения нужны в аналитике с небольшой задержкой, стоит разобраться с Debezium 👊

А вас спрашивали на собесах про CDC?🧑‍💼

Как вкатиться в Data Engineering с нуля? 🗺

Самая частая ошибка новичков- пытаться сразу выучить весь стек

Python, SQL, Spark, Kafka, Airflow, Docker, Kubernetes… Через несколько месяцев человек знает десятки названий, но не может самостоятельно собрать даже простой пайплайн 🥸

Поэтому идти лучше поэтапно⬇️

1️⃣Сначала база

На старте нужны:

📍Python: функции, структуры данных, файлы, исключения и основы ООП
📍SQL: SELECT, JOIN, группировки и агрегатные функции
📍базы данных: таблицы, ключи, индексы и транзакции

2️⃣Затем пайплайны

Здесь уже появляются оконные функции, Docker, Airflow, хранилища данных, моделирование, Hadoop и Spark

Но просто посмотреть видео про каждый инструмент недостаточно, а пощупать их, помучаться с настройкой (гпт в помощь). На этом этапе нужен нормальный пет-проект:

источник → обработка → хранение → запуск по расписанию → готовая витрина

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

Ты должен уметь ответить:

⏺что произойдёт при падении загрузки
⏺появятся ли дубли после повторного запуска
⏺как проверить качество данных
⏺почему ты выбрал именно такую архитектуру

3️⃣Дальше добавляем скиллы мидла👊

Middle — это не человек, который добавил в резюме ещё десять инструментов.

Это инженер, который может самостоятельно вести задачу, искать узкие места, оптимизировать запросы и понимать последствия своих решений🤔

В разных компаниях могут понадобиться Kafka, ClickHouse, MongoDB, Redis, Trino, dbt, Iceberg или Kubernetes ⌛️ Но учить всё подряд нет смысла.

Открой вакансии, которые тебе интересны, выпиши повторяющиеся требования и углубляйся именно в них👆

Главный принцип простой:

Python и SQL → пайплайны и хранилища → Big Data → оптимизация и архитектура

И не жди момента, когда выучишь всё. Он не наступит 😅

Собирай проекты, решай задачи и учись объяснять, почему сделал именно так. Именно это потом проверяют на собеседованиях)

Подробный roadmap от стажёра до middle, стек и полезные материалы собрал в статье:

➡️Как стать Data Engineer в 2026: честный roadmap от стажёра до мидла

❓Что бы вы добавили еще в роудмап?