Вопросы на собеседовании дата-инженера

Пример сильного ответа

WHERE фильтрует строки до группировки, поэтому агрегаты в нём использовать нельзя. HAVING работает уже после GROUP BY и отсекает группы по результатам функций. Логический порядок такой: FROM и JOIN, затем WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY и LIMIT — при этом SELECT выполняется позже WHERE, поэтому псевдоним из SELECT в WHERE недоступен. На практике мне приходилось переносить условие из HAVING в WHERE: отчёт по 40 миллионам строк ускорился примерно в десять раз, потому что агрегировалось заметно меньше данных.

• Показан именно порядок выполнения, а не только определения
• Есть практический кейс с переносом условия
• Цифры: 40 млн строк и ускорение в десять раз

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Классическое решение — оконная функция: нумерую заказы внутри каждого клиента через ROW_NUMBER() OVER (PARTITION BY client_id ORDER BY created_at DESC) и оставляю строки с номером не больше трёх. Если важны все заказы с одинаковым временем, вместо ROW_NUMBER беру DENSE_RANK. Альтернатива — LATERAL JOIN с LIMIT 3, иногда на хорошем индексе он работает быстрее. Такой запрос у меня выдавал выборку по 2 миллионам клиентов за пару минут, а после составного индекса по клиенту и дате — за секунды.

• Назван конкретный инструмент — оконные функции
• Показано понимание нюанса с одинаковым временем
• Есть альтернатива и измеримый результат

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Виден алгоритм: план, статистика, индексы
• Упомянуто партиционирование и переписывание логики
• Есть измеримый результат на большой таблице

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Знаю INNER, LEFT, RIGHT, FULL OUTER и CROSS JOIN. INNER оставляет только совпавшие строки в обеих таблицах, LEFT сохраняет все строки левой таблицы, а по правой подставляет NULL там, где совпадений нет. На практике разница критична: при INNER JOIN клиенты без заказов просто исчезают из отчёта, а бизнесу нужны все. Мне приходилось считать конверсию по базе: LEFT JOIN дал полную картину, и оказалось, что около 30 процентов клиентов за период не сделали ни одного заказа — с INNER эта доля потерялась бы.

• Сначала теория, потом живой кейс
• Показан риск потери данных при INNER
• Есть цифра из собственного опыта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Читаю файл построчно или чанками, например через чтение с параметром chunksize, чтобы в памяти был только кусок. Если формат построчный, обычная итерация по файлу даёт минимальный расход памяти. Дальше агрегирую инкрементально или пишу промежуточный результат на диск, а не собираю всё в один датафрейм. Для сложной логики подключаю Dask или PyArrow — они умеют работать вне памяти. Так мне приходилось обрабатывать лог на 50 гигабайт: чанки по 500 тысяч строк и потоковая агрегация вместо полной загрузки, память держалась в пределах пары гигабайт.

• Названы конкретные инструменты и размер чанка
• Показано понимание расхода памяти
• Есть кейс с 50 ГБ и лимитом по памяти

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Показано понимание памяти, а не только синтаксиса
• Есть личный кейс с объёмом и потреблением памяти
• Виден практический вывод для ETL-конвейеров

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

OLTP — это транзакционные системы: много коротких операций, точечные чтения и записи по ключу, важны скорость отклика и целостность каждой транзакции. OLAP — аналитика: запросов мало, но каждый читает огромные объёмы и агрегирует их по многим разрезам. Если гонять такие запросы по боевой базе, они надолго занимают ресурсы, конкурируют с пользовательскими транзакциями и мешают продакшену. В моей практике аналитический отчёт на боевой базе давал такую нагрузку, что время отклика приложения выросло с двухсот миллисекунд до нескольких секунд; после переноса отчётов в отдельное хранилище инциденты с производительностью сошли на нет. Поэтому аналитику выносят в отдельный слой с другой моделью хранения.

• Чёткое сравнение по характеру нагрузки
• Конкретные цифры деградации отклика
• Ясен практический вывод — разделять контуры

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

ClickHouse — колоночная СУБД: данные лежат не по строкам, а по столбцам, поэтому запрос читает только нужные колонки и хорошо жмётся. В основе таблиц семейства MergeTree — сортировка по ключу. Данные пишутся кусками, партами: каждый парт отсортирован по ключу и разбит на гранулы, а фон периодически сливает мелкие парты в крупные. По ключу сортировки строится разреженный первичный индекс, который позволяет пропускать целые гранулы, не читая их. Плюс сжатие по колонкам и векторное выполнение. В моей практике после переезда витрины на MergeTree с правильно подобранным ключом время ключевого отчёта сократилось примерно с десяти минут до секунд.

• Названы ключевые механизмы, а не общие слова
• Объяснена роль ключа сортировки и индекса
• Есть измеримый результат ускорения

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Greenplum — это MPP-хранилище на базе Postgres: массивно-параллельная архитектура, шардирование по ключу распределения, полноценные соединения, транзакции, привычный SQL. ClickHouse — колоночная аналитическая СУБД, которая сильнее в широких сканированиях и агрегациях по большим фактам. Выбор зависит от задачи: если нужны сложные многотабличные соединения, обновления и транзакционная согласованность в хранилище — скорее Greenplum; если основа — быстрые агрегаты по миллиардам строк и вставка большими батчами, выигрывает ClickHouse. У меня был кейс миграции витрины объёмом около двух миллиардов строк: на Greenplum отчёт шёл минуты, на ClickHouse — доли секунды.

• Сравнение по архитектуре, а не по лозунгам
• Ясные критерии выбора под задачу
• Кейс с объёмом и разницей по времени

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Дано точное определение факта и измерения
• Показаны различия по объёму и изменчивости
• Есть личный пример с масштабом витрины

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Медленно меняющиеся измерения — это справочники, атрибуты которых меняются нечасто, но историю изменений важно сохранять. SCD Type 2 реализую так: у строки есть суррогатный ключ, бизнес-ключ, даты начала и окончания действия, флаг текущей версии. При загрузке сравниваю хэш атрибутов с активной записью. Если атрибуты изменились, закрываю старую версию, проставляю дату окончания и вставляю новую с открытой датой. Если запись новая, просто добавляю. В одном проекте справочник на 2 млн клиентов обновлялся ежедневно, доля изменений — около 1–2%, и такой подход давал корректную историю без полной перезагрузки.

• Даёт чёткое определение SCD
• Описывает реализацию Type 2 с ключами и датами
• Подкрепляет примером с объёмом справочника

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Показывает понимание обоих подходов
• Приводит критерии выбора
• Подкрепляет примером из практики с цифрами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Идемпотентность — это свойство пайплайна давать одинаковый результат при повторном запуске за тот же период, без дублей и потерь. Обеспечиваю её так: все записи идут через merge или upsert по бизнес-ключу, вместо append. Для партиционированных таблиц использую перезапись партиции, а не добавление. Добавляю проверки на дубликаты и контрольные суммы. В одном проекте пайплайн обрабатывал 50 млн событий в сутки, и после сбоя повторный запуск не создавал дублей, а данные сходились с источником. Также фиксирую версию кода и параметры запуска, чтобы результат был воспроизводим.

• Даёт простое определение идемпотентности
• Перечисляет конкретные технические приёмы
• Показывает результат на примере с объёмом данных

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

DAG в Airflow — это направленный ациклический граф: задачи и зависимости между ними, расписание и параметры запуска. Он не содержит циклов, поэтому выполнение всегда конечно. Для backfill пропущенных дат использую штатный механизм с указанием диапазона дат. Важно, чтобы задачи были идемпотентны, иначе повторная загрузка даст дубли. Обычно запускаю backfill последовательно или с ограничением параллелизма, чтобы не перегрузить источники. В одном проекте после сбоя нужно было восстановить 30 дней данных, backfill занял около 4 часов и прошёл без ручных правок. После этого проверяю полноту и сверяю контрольные суммы.

• Объясняет устройство DAG в Airflow
• Описывает практический сценарий backfill
• Упоминает идемпотентность и проверку полноты

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

При джойне Spark сначала определяет стратегию: broadcast, если одна таблица маленькая, иначе shuffle sort-merge. В shuffle данные перераспределяются по ключу джойна между партициями. Data skew возникает, когда ключи распределены неравномерно: один или несколько ключей дают огромные партиции, а остальные — маленькие. Из-за этого часть задач работает дольше остальных, и весь этап ждёт самых медленных. В одном проекте на 200 млн строк один ключ занимал около 30% данных, и джойн шёл 6 часов вместо часа. Помогают salting, broadcast, adaptive query execution и предварительная агрегация.

• Объясняет стратегии и механику shuffle
• Раскрывает причину data skew
• Приводит решение и цифры из опыта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В Kafka доставка строится вокруг партиций, офсетов и подтверждений. Продюсер пишет в лидер-партицию, реплики синхронизируются, консьюмер в группе читает и коммитит офсет. At-least-once означает, что при сбое возможны повторы: сообщение не потеряется, но может прийти дважды. Exactly-once достигается идемпотентным продюсером и транзакциями, при чтении только подтверждённых сообщений. В моей практике поток до 5 миллионов событий в сутки: для витрин с финансами выбираю exactly-once, для логов достаточно at-least-once с дедупликацией по ключу. Это снижает нагрузку и сохраняет корректность.

• Показывает понимание партиций, офсетов и ролей продюсера и консьюмера
• Различает семантики и объясняет, когда какую выбирать
• Есть конкретный пример с потоком и обоснованием выбора

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Я контролирую качество на всех этапах: при загрузке, трансформации и выдаче. Внедряю проверки на полноту, уникальность, диапазоны, ссылочную целостность и свежесть. Настраиваю алерты в мониторинге и дашборды по метрикам. Важны data-контракты с источниками и версионирование. Также проверяю логические связи между таблицами и аномалии во времени. В одном проекте внедрение 80 автоматических проверок сократило число инцидентов в отчётности на 40% и ускорило разбор сбоев в разы. Регулярно провожу ретроспективы по инцидентам и обновляю правила.

• Перечислены конкретные виды проверок и мониторинг
• Упомянуты контракты и версионирование как зрелые практики
• Есть измеримый результат: снижение инцидентов на 40%

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.