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

В чём разница между ETL и ELT и почему победил ELT?

ETL преобразует данные до загрузки в хранилище — это имело смысл, когда хранение и вычисления в хранилище были дорогими и негибкими. ELT сначала грузит сырые данные и трансформирует их уже внутри хранилища его же движком. В аналитике победил ELT, потому что облачные хранилища сделали вычисления эластичными и отделили их от хранения: имея сырые данные, вы можете пересобрать витрины при смене требований, а не переливать заново из систем-источников, к которым доступа может уже и не быть.

Что такое star schema и когда её не стоит применять?

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

Объясните slowly changing dimensions, особенно Type 2.

SCD описывает атрибуты, меняющиеся во времени, — например, клиент переехал в другой город. Type 1 перезаписывает старое значение, теряя историю. Type 2 вставляет новую строку с датами действия и флагом актуальности, поэтому факт, приджойненный по суррогатному ключу, отражает атрибут таким, каким он был на момент события. Именно это позволяет корректно ответить на вопрос «какие были продажи по регионам в прошлом году», а не переприписать старые продажи новому региону клиента.

Что такое оконные функции и где они лучше 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 вынуждают каждый раз сканировать и разбирать всё. Партиционирование по колонке, по которой вы фильтруете, обычно по дате, даёт движку пропускать целые директории, но избыточное партиционирование рождает миллионы крошечных файлов, и накладные расходы на метаданные съедают всю выгоду.