Шпаргалка по собесам, которую не стыдно перечитать за день до

Прошёл через десятки интервью и как кандидат, и как тот, кто помогает с этим другим. Вот что реально работает:

👀 Тебя оценивают до первого вопроса
Свет, фон, ракурс камеры считывается за первые секунды. Свет перед лицом и камера чуть выше глаз. Минута настройки, которая меняет первое впечатление.

👀 Исследуй компанию глубже, чем остальные
Не просто почитай сайт. Найди технический блог, статьи на Habr от их инженеров. Упомяни это на собесе. Сразу видно человека, который хочет именно сюда, а не просто рассылает резюме всем подряд

📵 Резюме под каждую вакансию
Большинство отправляет одно резюме всем. Если в вакансии написано Spark и Airflow - эти слова должны быть в твоём резюме на видном месте. ATS-системы отсеивают кандидатов ещё до живого человека.

🔖Не рассказывай, а показывай стек
Работал с большими данными слышат все.

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

✅Готовь истории, а не ответы
На расскажи про сложный кейс шпаргалка не поможет. Заранее вспомни 2-3 реальные ситуации: что была за задача, что пошло не так, как решил. Это универсальная заготовка под половину вопросов на любом собесе.

😅 Говори про ошибки
Вопрос про провалы будет точно. Расскажи, что упало, как починил и что изменил после. Именно так выглядит человек, которому можно доверять.

💵 Зарплата - называй цифру
Диапазон - приглашение торговаться вниз. Одна конкретная сумма, спокойный тон, без оправданий. Если давят - мои ожидания такие, готов обсуждать остальные условия)

❓Задавай вопросы сам/а
В конце собеса спроси что-то про команду или процессы:
— Как выглядит типичный пайплайн в вашей команде?

— Как устроен онбординг?

— Какие задачи будут первые три месяца?

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

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

В конце спроси: Когда примерно ждать обратную связь? Если в срок не ответили - напиши первым. Это не навязчивость, это нормальный контроль процесса.

🗂Записывай вопросы после каждого собеса
Завёл отдельный файл - записываешь всё, что спросили. Через 5-6 собесов у тебя будет личный банк реальных вопросов именно по твоему уровню и стеку. Это лучше любого списка из интернета.

Это база, но именно на ней чаще всего и спотыкаются😎

💾Сохрани себе - пригодится перед следующим собесом)

Что делать, если твой Spark-кластер из 200 воркеров работает как один 🐌

Запускаешь джобу на 200 воркеров, а вся нагрузка едет на одном узле, пока остальные 199 простаивают🥺

Это data skew - неравномерное распределение данных по партициям. Spark делит данные по ключу (обычно при join или groupBy), и если один ключ встречается в разы чаще остальных - весь воркер, который его обрабатывает, становится бутылочным горлышком. Время выполнения джобы определяет не средний воркер, а самый перегруженный.

Заметить просто: открой Spark UI - один или несколько тасков выполняются заметно дольше остальных, иногда доходит до OOM (out of memory) на конкретном экзекьюторе.

Что с этим делать 🤔

Adaptive Query Execution - начни отсюда ▶️

В Spark 3.x можно включить adaptive query execution со skew join handling прямо в конфиге. Spark сам на лету разобьёт перегруженные партиции. Закрывает большинство случаев без единой строчки кода.

Broadcast join, если одна таблица маленькая📊

Можно разослать маленький датасет на все экзекьюторы и обойтись без шаффла полностью. Часто проще и быстрее, чем что-либо солить.

Salting, если ничего не помогло🧂

Добавляешь к перегруженному ключу случайное число - соль. Один огромный партишн превращается в несколько поменьше. Для join большую таблицу солишь, а маленькую размножаешь под каждое значение соли. Это последний инструмент, не первый — усложняет код, и если есть способ попроще, лучше им и обойтись.

🔖полезно почитать дополнительно

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

DE vs DS vs DA: чем отличаются и что выбрать

Давайте разберем чем одна профессия лучше другой 🤗

Кто чем занимается:

🏗 Data Engineer строит инфраструктуру для данных: пайплайны, хранилища, интеграции, качество и доставку данных. Результат виден чётко: пайплайн либо работает, либо нет.

💡Data Scientist ищет закономерности, проверяет гипотезы, строит модели и пытается понять, что скрыто в данных. Здесь много экспериментов, статистики и работы с неопределенностью.

🤔 Data Analyst помогает бизнесу принимать решения на основе данных: собирает отчеты, делает дашборды, анализирует метрики и объясняет, что стоит за изменениями в цифрах.

Где разница ощущается сильнее🤔

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

У DE результат более понятный и проверяемый: данные либо приехали вовремя, либо нет; пайплайн либо отработал, либо упал. У аналитика похожая логика - либо цифры актуальны и помогают принять решение, либо нет.

Про вход с нуля🤵‍♀️
В аналитике часто вход кажется самым простым: меньше математики, меньше тяжёлого кода, больше понятных бизнес-задач. Но из-за этого и конкуренция выше - туда приходит много людей после курсов и из смежных сфер.

Порог входа в DE ниже не потому, что профессия проще. На старте обычно достаточно SQL, Python и баз данных, а остальные инструменты осваиваются по мере работы.

В DS порог выше из-за статистики и математики: без этого сложно не только построить модель, но и понять, почему она работает именно так😔

Что выбрать:
Если нравится строить системы и видеть конкретный технический результат — Data Engineer

Если интересно работать с гипотезами, экспериментами и моделями — Data Science

Если хочется быть ближе к продукту и бизнес-решениям — Data Analyst

Все три направления востребованы. Но это разные типы работы, и лучше понять это заранее, чем потом долго переучиваться👆

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

🔖Записал для вас видео, где подробнее говорю на эту тему. Чем больше 🔥, тем быстрее выложу)

Новое видео на ютуб ⛔️

Бегом смотреть😆:
YOUTUBE
RUTUBE

P.s. лайки, комментарии и подписка очень мотивируют снимать дальше

🗂 Навигатор по техническим постам

Собрала все статьи канала в одном месте — сохраняйте, чтобы не потерять 👇

🧭 Старт в профессии
Как я стал дата-инженером

Как я получил оффер на Джуна в ML


⚙️ Основы Data Engineering
Что такое ETL и ELT?

OLTP и OLAP

Что такое оркестратор данных

Взрыв дублей при JOIN

Разный grain таблиц и как его фиксить

〰️ Базы данных и хранилища
Oracle

HDFS

Объектное хранилище (object storage/ S3)

Redis

Parquet и ORC


🏔 Data Lake / Lakehouse
Lake house
Data Vault и Anchor Modelling

Apache Iceberg: зачем он нужен и почему вокруг него шум. Надежность и ACID в Data Lake.
Сравнение Delta Lake и Apache Iceberg.

🏠 ClickHouse
Click House

Click House (гранулы, ORDER BY и индексы)

Почему UPDATE в ClickHouse — это плохая идея

Dictionaries в ClickHouse: как ускорить аналитику


⚙️ Обработка больших данных
Map Reduce

Как кластеры делят ядра и гигабайты: управление ресурсами при обработке больших данных

Почему Spark вытеснил MapReduce

Spark за 2 минуты

Data Skew в Spark: что делать, eкогда один воркер перегружен. Разбор Spark UI, AQE и Salting.

🔄 Оркестрация и пайплайны
Airflow

3 практических кейса на дебаг Airflow.


💬 Стриминг и брокеры сообщений
Что такое брокеры сообщений

Kafka

Kafka vs Rabbit MQ

Apache Flink

Как устроен стриминг данных, и зачем он нужен

Debezium

Как работают CDC пайплайн


🧩 Query-движки
Trino

🏗 Архитектура и качество данных
Как собрать систему, которая не падает

Data Quality и контракты данных

Новая статья на 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