Senior Data Engineer — Вопросы на собеседовании data engineer

Что такое оконные функции и где они лучше GROUP BY?

Оконная функция считает по набору строк, связанному с текущей, не схлопывая их, поэтому детализация строки сохраняется рядом с агрегатом. Это делает их правильным инструментом для нарастающих итогов, ранжирования внутри партиции, сравнения строки со средним по группе и сопоставления соседних событий через lag/lead. GROUP BY заставил бы агрегировать, а затем джойнить обратно к детализации — больше кода, больше перемешивания и выше шанс ошибиться.

Что значит идемпотентность пайплайна и почему это важно?

Идемпотентность означает, что повторный запуск той же задачи за тот же период даёт тот же результат, а не дублирует данные. Это важно, потому что ретраи неизбежны: задача упала на середине, кто-то перезапустил вчерашний день, бэкфилл наложился на плановый запуск. Обычные реализации — удалить и переписать целевую партицию либо сделать merge по бизнес-ключу вместо слепого insert. Пайплайны, работающие только при ровно однократном запуске, ломаются при первом же ретрае.

Как спроектировать DAG в Airflow, который безопасно бэкфиллить?

Каждая задача должна параметризоваться логической датой выполнения, а не «сейчас», чтобы запуск за старую дату читал и писал данные именно той даты. Задачи обязаны быть идемпотентными, чтобы перезапуск перезаписывал свою партицию. Ставят разумные ретраи с backoff и используют max_active_runs и пулы, чтобы бэкфилл за два года не съел всё хранилище и не заморил продовые запуски. Зависимости между DAG-ами надёжнее выражать проверкой готовности данных, а не угаданным расписанием.

Что такое shuffle в Spark и почему он дорогой?

Узкая трансформация вроде map или filter работает в пределах партиции и не требует перемещения данных. Широкая — groupBy, join, repartition — требует, чтобы строки с одинаковым ключом оказались на одном исполнителе, а значит промежуточные данные пишутся на диск и едут по сети: это и есть shuffle. Он доминирует во времени выполнения, поэтому тюнинг сводится к сокращению shuffle: броадкаст маленькой стороны джойна, фильтрация до джойна и выбор партиционирования под то, как вы читаете.

Что такое перекос данных (skew) и как с ним бороться?

Перекос — это когда на один ключ приходится непропорционально много строк, поэтому одна задача обрабатывает почти все данные, пока остальной кластер простаивает: джоба час стоит на 99%. В Spark UI это видно как одна задача с входом кратно больше соседних. Лечится солением горячего ключа, чтобы разнести его по партициям, броадкастом меньшей таблицы, чтобы вовсе избежать shuffle-джойна, и отдельной обработкой известных горячих ключей отдельно от длинного хвоста.

Почему Parquet, а не CSV или JSON, и что даёт партиционирование?

Parquet колоночный и сжатый, поэтому запрос, читающий три колонки из сорока, прочитает только их, а схема и статистики по колонкам позволяют движку целиком пропускать группы строк. CSV и JSON вынуждают каждый раз сканировать и разбирать всё. Партиционирование по колонке, по которой вы фильтруете, обычно по дате, даёт движку пропускать целые директории, но избыточное партиционирование рождает миллионы крошечных файлов, и накладные расходы на метаданные съедают всю выгоду.

Что на самом деле означает exactly-once в стриминге?

Настоящая доставка ровно один раз сквозным образом недостижима; системы дают effectively-once обработку: дубликаты могут прийти, но наблюдаемый результат такой, будто сообщение учли однажды. Достигается идемпотентной записью, дедупликацией по ключу сообщения или транзакционными приёмниками, которые атомарно коммитят офсеты вместе с результатом. Заявить exactly-once, не назвав механизм, за счёт которого это верно, — частый красный флаг на собеседовании.

Как обрабатывать опоздавшие данные?

Сначала определяются с семантикой: запись относится ко времени, когда событие произошло, или когда вы его получили? Для аналитики обычно корректно event time, но тогда пайплайн должен уметь переоткрыть и переписать уже опубликованную партицию. Watermark задаёт, сколько ждать до закрытия окна, а всё, что пришло позже, идёт в корректирующий путь или отдельную таблицу опозданий. Проектная ошибка — молча выбрасывать опоздавшее, потому что цифры начинают расходиться с источником и никто не знает почему.

Как тестировать качество данных и что именно проверять?

Тесты выполняются шагами пайплайна и падают громко, а не живут дашбордом, который никто не смотрит. Стандартный набор: свежесть, объём строк относительно ожидания, уникальность ключей, not-null на обязательных колонках, ссылочная целостность между фактом и измерением, допустимые диапазоны и перечисления. Формализуют это через dbt tests или Great Expectations. Важное проектное решение — какие падения блокируют следующие задачи, а какие только алертят, потому что блокировка на любой аномалии приучает людей игнорировать алерты.