Собеседование дата-инженера сильно опирается на SQL и на то, переживут ли ваши пайплайны запуск дважды, с опозданием или не по порядку. Будут и вопросы по моделированию, где нет единственно верного ответа. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом. Middle: более глубокое понимание, оптимизацию и реальные рабочие ситуации.
1
Что такое star schema и когда её не стоит применять?
Ответ
Звезда — это центральная таблица фактов с числовыми мерами, окружённая денормализованными измерениями, описывающими контекст. Она оптимизирована под аналитические запросы: мало джойнов, предсказуемая агрегация, понятна BI-инструментам. Отказываются от неё в чистом событийном стриминге, в по-настоящему исследовательской работе с сырыми событиями, а также когда колоночное хранилище настолько эффективно, что широкая денормализованная таблица работает быстрее и дешевле в поддержке.
2
Объясните slowly changing dimensions, особенно Type 2.
Ответ
SCD описывает атрибуты, меняющиеся во времени, — например, клиент переехал в другой город. Type 1 перезаписывает старое значение, теряя историю. Type 2 вставляет новую строку с датами действия и флагом актуальности, поэтому факт, приджойненный по суррогатному ключу, отражает атрибут таким, каким он был на момент события. Именно это позволяет корректно ответить на вопрос «какие были продажи по регионам в прошлом году», а не переприписать старые продажи новому региону клиента.
3
Что такое оконные функции и где они лучше GROUP BY?
Ответ
Оконная функция считает по набору строк, связанному с текущей, не схлопывая их, поэтому детализация строки сохраняется рядом с агрегатом. Это делает их правильным инструментом для нарастающих итогов, ранжирования внутри партиции, сравнения строки со средним по группе и сопоставления соседних событий через lag/lead. GROUP BY заставил бы агрегировать, а затем джойнить обратно к детализации — больше кода, больше перемешивания и выше шанс ошибиться.
4
Что значит идемпотентность пайплайна и почему это важно?
Ответ
Идемпотентность означает, что повторный запуск той же задачи за тот же период даёт тот же результат, а не дублирует данные. Это важно, потому что ретраи неизбежны: задача упала на середине, кто-то перезапустил вчерашний день, бэкфилл наложился на плановый запуск. Обычные реализации — удалить и переписать целевую партицию либо сделать merge по бизнес-ключу вместо слепого insert. Пайплайны, работающие только при ровно однократном запуске, ломаются при первом же ретрае.
5
Как спроектировать DAG в Airflow, который безопасно бэкфиллить?
Ответ
Каждая задача должна параметризоваться логической датой выполнения, а не «сейчас», чтобы запуск за старую дату читал и писал данные именно той даты. Задачи обязаны быть идемпотентными, чтобы перезапуск перезаписывал свою партицию. Ставят разумные ретраи с backoff и используют max_active_runs и пулы, чтобы бэкфилл за два года не съел всё хранилище и не заморил продовые запуски. Зависимости между DAG-ами надёжнее выражать проверкой готовности данных, а не угаданным расписанием.
6
Что такое shuffle в Spark и почему он дорогой?
Ответ
Узкая трансформация вроде map или filter работает в пределах партиции и не требует перемещения данных. Широкая — groupBy, join, repartition — требует, чтобы строки с одинаковым ключом оказались на одном исполнителе, а значит промежуточные данные пишутся на диск и едут по сети: это и есть shuffle. Он доминирует во времени выполнения, поэтому тюнинг сводится к сокращению shuffle: броадкаст маленькой стороны джойна, фильтрация до джойна и выбор партиционирования под то, как вы читаете.
7
Что такое перекос данных (skew) и как с ним бороться?
Ответ
Перекос — это когда на один ключ приходится непропорционально много строк, поэтому одна задача обрабатывает почти все данные, пока остальной кластер простаивает: джоба час стоит на 99%. В Spark UI это видно как одна задача с входом кратно больше соседних. Лечится солением горячего ключа, чтобы разнести его по партициям, броадкастом меньшей таблицы, чтобы вовсе избежать shuffle-джойна, и отдельной обработкой известных горячих ключей отдельно от длинного хвоста.
8
Почему Parquet, а не CSV или JSON, и что даёт партиционирование?
Ответ
Parquet колоночный и сжатый, поэтому запрос, читающий три колонки из сорока, прочитает только их, а схема и статистики по колонкам позволяют движку целиком пропускать группы строк. CSV и JSON вынуждают каждый раз сканировать и разбирать всё. Партиционирование по колонке, по которой вы фильтруете, обычно по дате, даёт движку пропускать целые директории, но избыточное партиционирование рождает миллионы крошечных файлов, и накладные расходы на метаданные съедают всю выгоду.
9
Что на самом деле означает exactly-once в стриминге?
Ответ
Настоящая доставка ровно один раз сквозным образом недостижима; системы дают effectively-once обработку: дубликаты могут прийти, но наблюдаемый результат такой, будто сообщение учли однажды. Достигается идемпотентной записью, дедупликацией по ключу сообщения или транзакционными приёмниками, которые атомарно коммитят офсеты вместе с результатом. Заявить exactly-once, не назвав механизм, за счёт которого это верно, — частый красный флаг на собеседовании.
10
Как обрабатывать опоздавшие данные?
Ответ
Сначала определяются с семантикой: запись относится ко времени, когда событие произошло, или когда вы его получили? Для аналитики обычно корректно event time, но тогда пайплайн должен уметь переоткрыть и переписать уже опубликованную партицию. Watermark задаёт, сколько ждать до закрытия окна, а всё, что пришло позже, идёт в корректирующий путь или отдельную таблицу опозданий. Проектная ошибка — молча выбрасывать опоздавшее, потому что цифры начинают расходиться с источником и никто не знает почему.
🦎
Прочитать ответы недостаточно
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Middle Data Engineer →Бесплатно · 3 интервью в месяц