В целом вопросы по CV

Question 1

Какие типовые Spark-задачи ты писал?

Answer 1

Фильтрация, агрегации, join’ы, дедупликация, переработка логики.

Question 2

Как оптимизировал Spark-задачи?

Answer 2

Broadcast join
Partitioning
Cache / persist
Parquet вместо CSV
Уменьшение shuffle
SQL оптимизации

Question 3

Был ли опыт падения Spark-задач в проде? Что делал?

Answer 3

1️⃣ Обнаружение проблемы

Обычно я узнавал о падении либо из алёрта Airflow, либо утром при проверке статуса ночных DAG-ов.
Сначала я фиксировал, какой именно DAG и какая Spark-задача упала, и на каком шаге.

2️⃣ Анализ логов

Дальше я открывал логи в Airflow и переходил к логам Spark.
Смотрел stack trace, тип ошибки — OutOfMemory, shuffle failure, проблемы с данными или внешним источником.

Обычно ошибки были:

OOM или превышение executor memory

долгие shuffle и таймауты

некорректные данные

недоступность внешнего API или HDFS

3️⃣ Определение типа проблемы

Я всегда старался понять, это проблема кода, данных или инфраструктуры.

если ошибка в коде или логике трансформаций — брал на себя

если нехватка ресурсов или проблемы с кластером — подключал infra-команду

если проблема в источнике данных — уведомлял команду владельца источника

4️⃣ Временное решение (если критично)

Если пайплайн был бизнес-критичным, я сначала искал быстрый workaround:
ограничить объём данных, изменить фильтр, временно увеличить ресурсы или перезапустить задачу.

5️⃣ Исправление причины

После этого вносил изменения в код:

оптимизировал Spark-задачу

уменьшал количество shuffle

добавлял broadcast join

корректировал партиционирование

усиливал обработку ошибок и ретраи

6️⃣ Тестирование и деплой

Изменения проверялись локально или на тестовом окружении, затем проходили CI/CD.
После деплоя я переобрабатывал данные, если это было необходимо.

7️⃣ Валидация результата

Я проверял, что DAG успешно отработал, данные корректно загрузились, а аналитические витрины не содержат аномалий.
При необходимости сверял результаты с аналитиками.

8️⃣ Пост-инцидентные действия

После инцидента мы:

добавляли дополнительные алёрты

улучшали логирование

дописывали тесты

фиксировали выводы в документации

Цель была — чтобы такая ошибка больше не повторялась.

Question 4

Какие DAG’и ты делал?

Answer 4

Daily batch ETL, витрины, удаление и архивирование данных

Question 5

Как обрабатывал ошибки в Airflow?

Answer 5

retries, retry_delay
on_failure_callback
алерты
idempotent задачи

Question 6

Как проверяешь корректность загрузки данных в Data Lake?

Answer 6

• Сравниваю row count и контрольные суммы источника и Data Lake.
• Проверяю типы данных и nullable-поля.
• Семплирую данные для ручной проверки.
• Автоматизирую через unit/integration тесты (PySpark/SQL).
• Логирую ошибки и мониторю пайплайн.

Question 7

Как анализируешь существующую ETL-логику перед её оптимизацией?

Answer 7

• Понимаю бизнес-логику через документацию и аналитиков.
• Смотрю код: shuffles, join’ы, дублирование.
• Замеряю производительность: время, память, использование executor’ов.
• Сравниваю результаты с исходными метриками.
• Оптимизирую через partitioning, caching, broadcast join, Parquet/ORC.

Question 8

Как оформить pull request и что обязательно должно быть в описании?

Answer 8

• Название: кратко о сути изменений.
• Описание: что и зачем делается.
• Что изменено: код, таблицы, пайплайны.
• Тесты: какие проверил.
• Ссылки на Jira/документацию.
• Указываю возможное влияние на существующие процессы.

Question 9

Как документируешь свои решения в Confluence, чтобы их могли поддерживать другие команды?

Answer 9

• Цель и описание решения.
• Архитектура: схемы потоков данных и зависимостей.
• Технические детали: форматы данных, SQL/PySpark, DAG Airflow.
• Примеры данных и запросов.
• Ошибки и рекомендации.
• Контакты и ссылки на Jira задачи.

Question 10

Как тестировались даги, spark-задачи?

Answer 10

> DAG’и и Spark-задачи тестировались через локальный запуск и проверку корректности результатов.
Для Spark использовались unit-тесты на ключевую бизнес-логику трансформаций, что позволяло фиксировать ошибки на раннем этапе.
Также проверялись схемы данных, количество строк и агрегаты на тестовых выборках перед выкаткой в прод.

Question 11

Как кафка интегрируется со spark?

Answer 11

df = (
    spark.readStream
        .format("kafka")
        .option("kafka.bootstrap.servers", "kafka:9092")
        .option("subscribe", "user_events")
        .option("startingOffsets", "latest")
        .load()
)

Question 12

Что за линтеры в CI/CD?

Answer 12

Это стадия в CI/CD, которая проверяет код на стиль, а также проверка тестов pytest

Question 13

Почему в первом проекте использовался ClickHouse, а во втором — Greenplum?

Answer 13

В первом проекте ClickHouse использовался для быстрого OLAP и дашбордов, во втором — Greenplum как полноценное аналитическое хранилище с более сложной SQL-логикой и интеграциями.

Question 14

Для чего был streaming-pipeline во втором проекте?

Answer 14

Streaming-pipeline во втором проекте использовался для обработки пользовательских событий в реальном времени.
Это было нужно, чтобы получать оперативные метрики и быстрее реагировать на происходящие события в системе.
Конкретный набор метрик и бизнес-решений формировался заказчиком, а мы реализовывали требуемую логику обработки и доставки данных.

Question 15

А почему devops не входил в команду ?

Answer 15

Во втором проекте команда была разделена по ролям: разработчики (Data Engineer) занимались логикой обработки данных и пайплайнами, а деплой и инфраструктурную поддержку выполняла отдельная инфраструктурная команда

Question 16

А было ли CI/CD во втором проекте?

Answer 16

Полноценного CI/CD в классическом виде во втором проекте не было.
Использовались отдельные элементы: Git, code review, базовые проверки и ручной деплой.
Основной упор был на стабильность пайплайнов и поддержку существующей инфраструктуры.

Question 17

А можно ли установить условие: выполнение одного дага, если выполнен другой?

Answer 17

Да, можно. В Airflow используют ExternalTaskSensor, чтобы DAG ждал завершения другого DAG, или TriggerDagRunOperator, чтобы один DAG запускал другой после успешного выполнения.

Question 18

С помощью чего или каким образом архивировались данные?

Answer 18

“Через Airflow DAG запускал Spark-задачи: данные старше TTL читались из HDFS и перекладывались в архивный слой в Parquet, после чего удалялись из основного Data Lake.”

Question 19

Как проверялись контрольные суммы? Была отдельная колонка?

Answer 19

“Да, использовалась отдельная колонка с контрольной суммой (checksum / hash).
Контрольная сумма вычислялась на стороне источника или на этапе ingestion (например, md5 или sha256 от набора бизнес-полей).
При загрузке в Spark мы пересчитывали хеш и сравнивали его со значением в колонке.
Если контрольная сумма не совпадала, такая запись помечалась как некорректная и откладывалась в отдельный quarantine / error-dataset для последующего анализа.
Основной пайплайн при этом не падал.”

Question 20

Что значит данные семплировались для проверки корректности загрузки?

Answer 20

“После загрузки мы брали случайную выборку строк и проверяли, что значения полей соответствуют ожидаемым: даты, числовые диапазоны, null-ы.”