сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · ETL и оркестрация

Вопросы по ETL и Airflow на собеседовании

Пайплайны спрашивают через отказы: что произойдёт, если задача упала на середине и её перезапустили. Ответ показывает, писал ли человек продакшн-загрузки или учебные примеры.

111 вопросов в банке·10 подтем·ниже разбор 9

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

Примеры вопросов с разбором

  1. #airflow_dags1 / 9
    Что такое DAG в оркестраторе вроде Airflow?
    A)Направленный ациклический граф задач с зависимостями между ними
    B)Единая большая монолитная SQL-процедура, которую база выполняет целиком за раз
    C)Очередь сообщений между микросервисами без всякого порядка
    D)Формат хранения таблиц на диске в колоночном представлении
    показать ответ и разбор
    +A)Направленный ациклический граф задач с зависимостями между ними

    // разбор: DAG (directed acyclic graph) описывает задачи и порядок их выполнения через зависимости. Ацикличность обязательна: цикл невозможно упорядочить и спланировать. Оркестратор строит по DAG расписание, следит за статусами и ретраит упавшие задачи — это про координацию шагов, а не про сам код обработки.

  2. #data_quality2 / 9
    Что такое data quality checks в пайплайне?
    A)Проверки, замеряющие общую скорость и производительность пайплайна
    B)Автоматические юнит-тесты кода трансформаций, но не самих данных
    C)Ручной визуальный просмотр аналитиком выгрузки примерно раз в квартал перед сдачей квартального отчёта руководству компании
    D)Автопроверки данных: схема, доли пропусков, диапазоны, уникальность ключей
    показать ответ и разбор
    +D)Автопроверки данных: схема, доли пропусков, диапазоны, уникальность ключей

    // разбор: DQ-проверки автоматически валидируют сами данные в потоке: соответствие схемы, доля null'ов, диапазоны значений, уникальность ключей, ожидаемый объём. Они отличаются от юнит-тестов кода (те проверяют логику, а не текущие данные) и от ручных просмотров — работают на каждом запуске и останавливают распространение мусора.

  3. #dbt_transformations3 / 9
    Что такое dbt и в какой парадигме он работает?
    A)Dbt — это оркестратор пайплайнов, заменяющий Airflow и сам вытягивающий данные из источников
    B)Dbt — это движок распределённых вычислений вроде Spark, обрабатывающий данные вне хранилища
    C)Dbt — библиотека для обучения ML-моделей на данных, лежащих в аналитическом хранилище
    D)SQL-трансформации внутри хранилища; модель = SELECT, это T в ELT
    показать ответ и разбор
    +D)SQL-трансформации внутри хранилища; модель = SELECT, это T в ELT

    // разбор: dbt (data build tool) отвечает за трансформацию уже загруженных в хранилище данных — букву T в ELT. Модель dbt — это, по сути, SELECT-запрос в .sql-файле; dbt оборачивает его в CREATE TABLE/VIEW и выполняет прямо в DWH (ClickHouse/Postgres/Snowflake/Greenplum). dbt добавляет вокруг SQL инженерные практики: зависимости через ref(), тесты данных, документацию, версионирование в git, окружения. Он не грузит и не извлекает данные — только трансформирует их силами самого хранилища.

  4. #idempotency_backfill4 / 9
    Что значит, что задача пайплайна идемпотентна?
    A)Повторный запуск задачи даёт тот же результат без дублей и побочек
    B)Задача, которая исполняется строго один раз
    C)Задача, которую не получится перезапустить после сбоя
    D)Задача, которая при повторном запуске выполняется заметно быстрее благодаря кэшированию промежуточного результата на диске
    показать ответ и разбор
    +A)Повторный запуск задачи даёт тот же результат без дублей и побочек

    // разбор: Идемпотентность = повторное выполнение не меняет итог: перезапуск после сбоя не создаёт дублей и побочных эффектов. Это ключевое свойство надёжного пайплайна, потому что оркестратор штатно ретраит упавшие задачи. Достигается перезаписью партиции целиком или upsert'ом по ключу вместо слепого добавления.

  5. #pipeline_patterns5 / 9
    Какие есть базовые стратегии загрузки таблицы и когда каждую берут?
    A)Стратегия загрузки одна — full refresh, а append и merge применять не рекомендуется
    B)Merge и append — это полные синонимы, оба просто дописывают новые строки в конец таблицы одинаково
    C)Full / append / merge — по размеру и тому, меняются ли строки
    D)Full refresh обязателен для больших факт-таблиц, потому что он обеспечивает свежесть данных
    показать ответ и разбор
    +C)Full / append / merge — по размеру и тому, меняются ли строки

    // разбор: Три базовые стратегии. Full refresh: перезаписать таблицу целиком — просто и идемпотентно, годится для небольших/справочных данных. Append-only: дописывать только новые строки — для неизменяемых событий/логов (быстро, но не отражает изменения существующих). Merge/upsert: по ключу вставить новые и обновить изменённые (ON CONFLICT/MERGE) — для больших таблиц, где строки и добавляются, и меняются. Выбор диктуют объём (full дорог на больших) и изменяемость (append не годится, если строки правятся). Часто комбинируют с партиционированием (overwrite партиции).

  6. #async_concurrency6 / 9
    Что такое GIL (Global Interpreter Lock) в CPython?
    A)Глобальный лок, позволяющий выполнять байткод Python лишь одному потоку одновременно
    B)Механизм, который автоматически распараллеливает Python-код по всем ядрам процессора сразу
    C)Лок уровня отдельного объекта, защищающий конкретную переменную от гонок данных
    D)Настройка, отключающая многопоточность в Python на уровне операционной системы
    показать ответ и разбор
    +A)Глобальный лок, позволяющий выполнять байткод Python лишь одному потоку одновременно

    // разбор: GIL — мьютекс интерпретатора CPython: в любой момент Python-байткод исполняет только один поток. Поэтому чисто вычислительный (CPU-bound) код не ускоряется несколькими потоками — они не идут параллельно по ядрам. На I/O-bound задачах GIL отпускается во время ожидания (сеть, диск), и потоки полезны. Для параллельного CPU берут процессы (multiprocessing).

  7. #generators_memory7 / 9
    Почему читать большой файл генератором лучше, чем целиком в список?
    A)Читать весь файл в один список обычно заметно быстрее и надёжнее построчного
    B)Генератор и чтение в список расходуют примерно одинаковый объём памяти
    C)Генератор держит одну строку за раз — файл больше RAM обработается
    D)Построчное чтение через генератор в Python работает медленнее и не рекомендуется
    показать ответ и разбор
    +C)Генератор держит одну строку за раз — файл больше RAM обработается

    // разбор: Чтение всего файла в список (или .read()) держит его целиком в памяти — на файле больше RAM процесс упадёт по памяти. Генератор (например, итерация for line in file) отдаёт по одной строке, и обработка идёт в константной памяти независимо от размера файла. Это база потоковой обработки данных в Python.

  8. #io_serialization8 / 9
    Почему построчный INSERT в цикле медленнее батчевой вставки (executemany)?
    A)Построчный INSERT быстрее, потому что БД оптимизирует каждую отдельную маленькую вставку эффективнее пакетной
    B)Разницы в скорости нет: число round-trip'ов к базе на итог вообще никак не влияет
    C)Каждый INSERT — отдельный round-trip к БД; батч шлёт много строк за один обмен, амортизируя накладные
    D)Батч медленнее, так как БД вынуждена держать всю пачку строк в памяти до фиксации транзакции
    показать ответ и разбор
    +C)Каждый INSERT — отдельный round-trip к БД; батч шлёт много строк за один обмен, амортизируя накладные

    // разбор: Вставка по строке платит фиксированные накладные (сетевой round-trip, парсинг запроса, транзакционные издержки) на каждую строку — на миллионах это доминирует над самой записью. executemany/COPY/batch отправляет пачку строк за один обмен, амортизируя накладные и разгружая планировщик. Разница на больших объёмах — порядки. COPY в Postgres ещё быстрее executemany.

  9. #reliability_retries9 / 9
    Что такое retry с backoff?
    A)Повтор упавшего вызова с нарастающей паузой между попытками
    B)Мгновенный повтор запроса без пауз между попытками, пока он не пройдёт
    C)Полный откат всей транзакции базы данных при первой же ошибке
    D)Кэширование ответа внешнего сервиса, чтобы не звать его повторно
    показать ответ и разбор
    +A)Повтор упавшего вызова с нарастающей паузой между попытками

    // разбор: Внешние сервисы и сеть временно флапают, поэтому упавший вызов повторяют — но с нарастающей паузой (backoff), чтобы дать системе восстановиться и не добить её шквалом. Обычно ограничивают число попыток и общий бюджет времени. Повтор без пауз только усугубляет перегрузку и превращает сбой в лавину.

это 9 из 111

Ещё 102 вопросов по теме — в тренажёре, с движком повторения

Прочитать разбор и ответить самому — разные навыки. В Сеньорчике вопросы идут сессиями, а движок возвращает подтемы, где вы ошибаетесь, пока они не начнут отскакивать. Бесплатно, лимит по энергии.

Открыть тренажёрДругие темы

Частые вопросы

куда дальше