Новая статья на VC!

Вспомните или узнаете про UPDATE в ClickHouse🏠

ССЫЛКА

P.S. буду благодарен за лайк и комментарий 😛

Рынок в Data Engineering, лето 2026??⚙️

Рынок изменился, и это факт. Но важно понимать: он не умер. За последние две недели 5 моих учеников уже получили офферы 👊, поэтому вакансии есть, но конкуренция стала заметно выше.

Если раньше для оффера на Junior/Middle позицию достаточно было знать теорию и пару инструментов, то в 2026 году требования взлетели. Сейчас на собеседованиях мало просто понимать технологии. От тебя ждут глубоких деталей и умения рассказать, как ты решал настоящие проблемы в продакшене.

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

Как мы будем идти к результату🥇🥇

Мы не просто учим теорию, мы строим твой профессиональный профиль шаг за шагом. 📍Сначала мы анализируем твой бэкграунд и составляем индивидуальный роудмап, отсекая лишнее и фокусируясь на том, что реально спрашивают. Если нужно, подтягиваем базу (SQL, Python, алгоритмы), а затем переходим к глубокой практике. Мы разбираем задачи в формате реальных интервью, работая с кейсами по Spark, Airflow и Kafka. Чтобы закрепить навыки, мы создаем пет проект.

Но мало уметь — нужно уметь продать. 📵 Поэтому основной упор мы делаем на этап упаковки и проработки легенды.

⭐️️️️️Ты получишь доступ к моей базе закрытых видео, где на примерах из реальных проектов показано применение инструментов в проде. Уже сейчас там есть подробные разборы по Iceberg, Spark, Greenplum и Kafka, и база активно пополняется. Это живой опыт бигтеха: как устроены данные, почему выбраны именно эти технологии и какие нюансы всплывают при их внедрении. Имея такие примеры перед глазами, подготовить свою легенду становится в разы проще.

Плюс к этому — доступ к базе из 25+ реальных собеседований, чтобы ты точно знал/а, какие каверзные вопросы тебя ждут.

Когда ты будешь готов/а, мы выходим на рынок. Я сопровождаю тебя на этапе откликов, мы анализируем каждый фидбек и докручиваем слабые места. После получения оффера (а мои ученики выходят на 250к–375к+) наша работа не заканчивается. 🫱‍🫲 Я остаюсь с тобой на испытательный срок (первые 3 месяца), помогая адаптироваться и решать первые рабочие задачи.

Комьюнити DE 👥

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

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

Условия участия🤝

✨Отзывы говорят сами за себя: прочитать реальные отзывы

Хочешь так же?
Пиши — проведём короткий бесплатный созвон, разберём твой бэкграунд и цели: @ampodvalniy 🔥

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

13 параметров Spark, которые стоит знать перед собеседованием

Надеюсь все правильно ответили в предыдущем опросе, но в любом случае советую освежить память или узнать что-то новое🔥Перечислил самые популярные параметры Spark, которые реально встречается в конфигах и на проде

💦 Ресурсы

spark.executor.instances

  — сколько executors поднимется для приложения.

spark.executor.cores 

— сколько ядер выделяем на один executor.

spark.executor.memory

  — heap-память executor’а.

spark.executor.memoryOverhead

  — память вне heap: Python worker’ы, native memory, shuffle buffers и другие внехиповые расходы.

  spark.driver.memory /  spark.driver.cores  

— ресурсы драйвера.

😶‍🌫️Параллелизм

spark.default.parallelism 

— дефолтное число партиций для RDD-операций.

spark.sql.shuffle.partitions 

— число партиций после shuffle в Spark SQL.

spark.sql.files.maxPartitionBytes

  — максимальный размер данных на одну input partition при чтении файлов.

spark.sql.files.openCostInBytes  

— помогает Spark лучше группировать мелкие файлы при чтении.

🤩Оптимизация

spark.sql.adaptive.enabled

  — включает AQE: Spark может динамически менять число shuffle-партиций и улучшать план выполнения.

spark.sql.autoBroadcastJoinThreshold

  — порог, при котором Spark может выбрать Broadcast Join.

spark.dynamicAllocation.enabled

  — динамически увеличивает и уменьшает число executors.

spark.sql.adaptive.skewJoin.enabled

  — помогает бороться с data skew на join’ах.

Если коротко: на собесе важно не просто помнить названия, а понимать, за что отвечает каждый параметр — ресурсы, параллелизм, shuffle, память и join-стратегии

🐈Полезные статьи:

⏺Подбираем параметры сессии в Apache Spark

⏺Как правильно просить ресурсы и как понять, сколько нужно брать

⏺6 сегментов памяти Apache Spark и параметры их конфигурирования

Что спрашивают в Бигтехе: вопросы по Iceberg и Trino из закрытого канала

В вакансиях всё чаще мелькает связка Iceberg + Trino + S3. Тренд понятный: многие компании сейчас мигрируют с классических СУБД на объектные хранилища и ищут инженеров под эти задачи🚨

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

Некоторые вопросы требуют понимания того, как это работает в бою, поэтому если опыта нет — придется включать фантазию и строить гипотезы 😅 Попробуйте ответить на них, чтобы подсветить свои пробелы.

Для тех, кто совсем не в теме, сначала прочитайте базу:
🗻 Iceberg
🚀 Trino
📁 S3

Список вопросов с собеседований:
1. Зачем нужен Iceberg? В чем его реальные преимущества перед обычными Hive-таблицами?
2. Какие у формата есть минусы и «подводные камни»?
3. Обслуживание таблиц: Как следить за размерами файлов и как правильно делать компакцию (очистку мелких файлов)?
4. Логическая структура: Как выстраивали архитектуру хранилища? На какие слои делили данные?
5. Разделение ролей: Для каких задач использовали Trino, а для каких — Spark? По каким критериям разграничивали нагрузку?

Получилось ответить на всё или где-то поплыли❓Пишите в комментах, какие вопросы вызвали больше всего затыка — разберем🔥

Кстати в нашем закрытом сообществе ребята постоянно делятся свежими собеседованиями)

Не забывай, что можешь записаться на первый бесплатный созвон для обсуждения деталей менторства и вашей текущей точки @ampodvalniy ⭐️

Зачем нужен dbt, если есть Spark и ClickHouse?

Многие до сих пор путают dbt (Data Build Tool) с вычислительными движками. Давайте сразу: dbt сам ничего не считает🚨

Он не заменяет Spark, Trino или ClickHouse. dbt — это инструмент для организации трансформаций внутри вашего хранилища🖥Он превращает разрозненные SQL-скрипты в полноценный инженерный проект с тестами, документацией и зависимостями.

В чем суть?

Без dbt вы сами следите за тем, в каком порядке запускать скрипты. С dbt вы просто описываете модели, а инструмент сам строит DAG.

Например:

stg_users → stg_orders → mart_sales

Зачем нужен dbt 🤔

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

Что он дает на практике:

✔️ Управление зависимостями: Автоматическое построение графа (DAG).
✔️ Тестирование: Можно из коробки проверять данные на NOT NULL, UNIQUE или проверять внешние ключи.
✔️ Документация: dbt сам генерирует описание моделей и связей между ними.
✔️ Версионирование: Весь ваш SQL живет в Git как код.

Кто тогда считает?

dbt - это мозг, а не мышцы. Он просто отправляет SQL-код в ваш вычислительный движок: Spark, Trino, ClickHouse или Postgres🖥 Именно они делают тяжелую работу (JOIN, GROUP BY), а dbt управляет этим процессом.

Итог: dbt приносит в мир аналитики лучшие практики разработки. Это мастхэв, если вы хотите строить поддерживаемые и надежные витрины, а не просто плодить горы SQL кода🔥

Почитать по теме:
🔗 DBT: трансформация данных без боли
🔗 DBT в продакшене

Flink vs Spark Streaming: что выбрать для Data Lakehouse

Если совсем просто, Flink и Spark Streaming - это инструменты, которые обрабатывают данные на лету➡️

То есть не ждут конца дня, чтобы всё пересчитать, а работают с событиями почти сразу, как только они появляются🌟

🐿Что делает Flink:

Flink нужен там, где данные идут непрерывным потоком: из Kafka, из логов, из CDC, из событий приложения.
Он умеет сразу принимать эти события, обрабатывать их и писать результат дальше, например, в Iceberg, Hudi или Delta Lake.

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

Что делает Spark Streaming⭐

Spark Streaming тоже умеет работать с потоком данных, но его подход немного другой. Он исторически вырос из batch-мира, то есть из обработки больших пачек данных.

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

Это нормально, если тебе не нужна супер-низкая задержка и если у команды уже вся архитектура построена на Spark.

В чём разница:

➖Flink - когда нужен настоящий live-streaming и минимальная задержка

➖Spark Streaming - когда потоковая обработка нужна, но ты уже живёшь в Spark-экосистеме и хочешь не менять стек

Где, что используют в Data Lakehouse 🟦

В Lakehouse-архитектуре обычно так:

⏺Flink — забирает события, обрабатывает их и пишет в таблицы lakehouse.
⏺Trino — потом читает эти таблицы через SQL.
⏺Spark — часто используют для тяжёлых batch-вычислений и больших пересчётов.

🤓Почитать дополнительно:

⏺Введение в Apache Flink: архитектура и основные концепции

⏺Стриминговые фреймворки: Apache Flink

Было полезно? Ставь 🔥

Собес в бигтех: когда теория уже не спасает

На собесах в классные компании на интервью редко спрашивают только «что такое ETL?». Чаще дают кейс с прода и смотрят, как ты думаешь🧐: где риск дублей, что сломается при ретрае, как найти узкое место и чем лечить проблему.

💡Собрал 5 интересных и реальных вопросов, на которых проверяют реальный опыт:

1️⃣Airflow: задача упала на середине загрузки — что делать?

Не просто  Clear . Сначала проверь идемпотентность: staging,  UPSERT , перезапись партиции, атомарный commit. Повторный запуск не должен портить данные.

🔗 Статья про идемпотентность в Airflow

2️⃣Spark тормозит, хотя ресурсов в кластере много — с чего начнёшь?

С Spark UI. Ищи  shuffle ,  data skew , лишние мелкие файлы и дорогие UDF. Часто проблема не в памяти, а в плане выполнения.

🔗 Диагностика Spark приложений

3️⃣Kafka: пришёл дубль события — как не сломать витрину?

Офсеты не спасают. Нужны exactly-once на pipeline-уровне и идемпотентная запись в приёмник:  UPSERT ,  MERGE , уникальный ключ.

🔗Идемпотентность и повторные запуски

4️⃣Iceberg: наплодили много мелких файлов — чем это плохо?

Растёт нагрузка на метаданные, а Trino/Spark тратят время на планирование. Нужен  compaction  и нормальный размер файлов.

5️⃣Когда реально нужен real-time?

Бизнес всегда хочет быстрее, но платить за это тоже нужно. Стриминг (Flink/Spark Streaming) нужен только там, где задержка в секунды критична: антифрод, алерты, персонализация. Если можно подождать 5–10 минут обычный batch будет в разы проще и дешевле.

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

🚀Хочешь оценить свою готовность к рынку?
Пиши мне в личку @ampodvalniy, укажи текущий стек и на какой грейд/ЗП метишь. Посмотрим, где у тебя пробелы и как их закрыть.

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

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

💡Изначально меня привлекал 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. Агент анализирует метаданные, ищет связи между таблицами и помогает наполнять каталог данных.

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

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

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

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