25 найпоширеніших питань на співбесіді з Data Engineering у 2026 році

Питання на співбесідах з data engineering у 2026 році виходять далеко за межі базового SQL. Команди, що проводять найм, перевіряють знання проєктування систем, архітектури обробки даних у реальному часі, оптимізації витрат та готовності до роботи з AI. Цей матеріал охоплює 25 питань, які найчастіше зустрічаються на співбесідах з data engineering у компаніях від стартапів до FAANG, з відповідями, написаними для практикуючих інженерів.

SQL та оптимізація запитів

SQL залишається фундаментом кожної співбесіди з data engineering. Навіть досвідчені кандидати стикаються з питаннями по SQL, зазвичай зосередженими на продуктивності, а не на синтаксисі.

1. Яка різниця між віконною функцією та GROUP BY?

GROUP BY згортає рядки в агреговані результати, зменшуючи кількість рядків. Віконні функції обчислюють значення на наборі рядків, пов'язаних з поточним рядком, не згортаючи їх. Результат зберігає кожен оригінальний рядок.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Версія з віконною функцією є незамінною, коли запит потребує одночасно деталізації на рівні рядків та агрегованого контексту -- поширена вимога у перевірках якості даних та звітних pipeline'ах.

2. Як оптимізувати повільний запит на таблиці фактів із 500 млн рядків?

Найкраще працює структурований підхід:

1. Перевірити план виконання (EXPLAIN ANALYZE), щоб виявити повне сканування таблиці, hash join на неіндексованих стовпцях або переповнення на диск.
2. Партиціонувати таблицю за датою або іншим стовпцем з високою кардинальністю, що відповідає фільтрам запитів.
3. Додати цільові індекси на часто фільтровані стовпці, але уникати надмірного індексування (кожен індекс додає навантаження при записі).
4. Матеріалізувати проміжні результати, якщо один і той самий підзапит виконується повторно в кількох дашбордах.
5. Просувати предикати вниз, щоб фільтрувати на ранніх етапах, зменшуючи обсяг даних, що переміщуються між стадіями.

Ключовий сигнал для інтерв'юерів: розуміння того, що оптимізація -- це ітеративний та контекстно-залежний процес, а не чекліст.

3. Поясніть CTE, підзапити та тимчасові таблиці. Коли використовувати кожен з них?

CTE (Common Table Expressions) покращують читабельність та дозволяють рекурсивні запити. Більшість движків запитів вбудовують їх, тому продуктивність відповідає підзапитам. Тимчасові таблиці фізично матеріалізують дані, що допомагає, коли один і той самий проміжний результат використовується кількома подальшими запитами в рамках сесії. Підзапити добре працюють для простих одноразових трансформацій.

Правило: CTE для ясності, тимчасова таблиця для повторного використання, підзапит для тривіальних інлайн-фільтрів.

Для глибшого занурення в просунуті патерни SQL див. SQL для аналітиків даних: Window Functions, CTE та просунуті запити.

ETL vs ELT та архітектура data pipeline

Питання про проєктування pipeline'ів перевіряють архітектурне мислення. Інтерв'юери хочуть побачити аналіз компромісів, а не прихильність до конкретних інструментів.

4. ETL vs ELT: коли обирати один підхід замість іншого?

| Критерій | ETL | ELT | |----------|-----|-----| | Місце трансформації | До завантаження (зовнішній compute) | Після завантаження (compute сховища) | | Найкраще для | Застарілих систем, жорстких схем | Хмарних сховищ (BigQuery, Snowflake) | | Гнучкість схеми | Низька (трансформація фіксує схему рано) | Висока (сирі дані доступні для ретрансформації) | | Модель витрат | Compute поза сховищем | Витрати на compute сховища зростають з трансформаціями | | Свіжість даних | Вища затримка (етап трансформації) | Нижча затримка (спочатку завантаження, трансформація на вимогу) |

ELT домінує у сучасних cloud-native стеках, оскільки зберігання коштує дешево, compute масштабується еластично, а збереження сирих даних забезпечує еволюцію схеми. ETL залишається актуальним, коли регуляторні вимоги передбачають трансформацію даних до потрапляння у сховище (наприклад, очищення PII).

5. Спроєктуйте ідемпотентний data pipeline. Чому ідемпотентність важлива?

Ідемпотентність гарантує, що багаторазовий запуск pipeline з однаковими вхідними даними дає однаковий результат без дублювання даних. Це важливо, оскільки pipeline'и зазнають збоїв та перезапускаються.

Стратегії реалізації:

• Upsert-патерни (MERGE або INSERT ... ON CONFLICT) з ключем на натуральних або складених ключах
• Перезапис партицій: заміна цілих date-партицій замість додавання
• Дедублікація при записі: призначення детермінованих ID (хеш бізнес-ключа + мітка часу події)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Цей підхід гарантує, що повторний запуск за 11 квітня замінить партицію за 11 квітня, а не додасть дубльовані рядки.

6. Що таке data lineage і чому це критично для продакшн pipeline'ів?

Data lineage відстежує походження, переміщення та трансформацію даних у pipeline. Він відповідає на питання: звідки взялося це число, які трансформації були застосовані та які downstream-системи від нього залежать.

Практична цінність: коли дашборд показує неочікувані значення, lineage дозволяє провести аналіз першопричини за хвилини замість годин. Такі інструменти, як OpenLineage, dbt docs та cloud-native lineage (column-level lineage у BigQuery), автоматизують цей процес.

Потокова обробка та обробка даних у реальному часі

Питання про потокову обробку змістилися від "що таке Kafka" до архітектурних рішень про те, коли та як використовувати streaming.

7. Batch vs streaming: як прийняти рішення, що використовувати?

Рішення залежить від вимог до затримки, а не від технологічних уподобань:

• Batch: прийнятний, коли споживачі даних толерують затримку від хвилин до годин. Простіше побудувати, протестувати та відлагодити. Нижча операційна вартість для більшості навантажень.
• Streaming: необхідний, коли бізнес-логіка залежить від свіжості даних менше хвилини: виявлення шахрайства, ціноутворення в реальному часі, live-дашборди.
• Micro-batch: прагматичний компроміс (Spark Structured Streaming, наприклад), що забезпечує майже реальний час з простотою batch-підходу.

Найсильніша відповідь визнає, що більшість pipeline'ів мають починати з batch та переходити на streaming лише тоді, коли конкретний SLA щодо затримки цього вимагає.

8. Поясніть архітектуру Kafka: topics, partitions, consumer groups

Kafka організовує дані в topics (логічні канали). Кожен topic поділяється на partitions (впорядковані, незмінні логи), розподілені між брокерами. Producers записують повідомлення в партиції (round-robin або за ключем). Consumer groups паралелізують читання: кожна партиція призначається рівно одному consumer у межах групи, що забезпечує горизонтальне масштабування.

Ключовий компроміс: більше партицій збільшує паралелізм, але додає навантаження на брокер (файлові дескриптори, реплікація). Типова початкова точка -- 6-12 партицій на topic, з масштабуванням на основі вимог до пропускної здатності.

9. Як обробляти дані, що надходять із запізненням, у потоковому pipeline?

Запізнення даних неминуче у розподілених системах. Три підходи:

1. Watermarks: визначення порогу (наприклад, 10 хвилин), після якого запізнілі дані відкидаються. Apache Flink та Spark Structured Streaming підтримують це нативно.
2. Вікна повторної обробки: періодичний перезапуск агрегацій для нещодавніх часових вікон для захоплення запізнілих даних.
3. Delta/upsert sinks: запис у мутабельне сховище (Delta Lake, Apache Iceberg), що підтримує оновлення, дозволяючи запізнілим записам виправити попередні результати.

Правильний підхід залежить від того, чи потребують downstream-споживачі exactly-once семантику, чи можуть толерувати eventual consistency.

Моделювання даних та проєктування схем

Питання про моделювання даних виявляють, чи думає кандидат про те, як дані будуть споживатися, а не лише про те, як вони зберігаються.

10. Star schema vs snowflake schema: компроміси?

Star schema денормалізує таблиці вимірів у плоскі, широкі таблиці, з'єднані з центральною таблицею фактів. Snowflake schema нормалізує виміри у підвиміри.

| Аспект | Star | Snowflake | |--------|------|-----------| | Продуктивність запитів | Вища (менше join'ів) | Нижча (більше join'ів) | | Зберігання | Більше (надлишкові дані) | Менше (нормалізовані) | | Складність | Просте для розуміння | Складніші зв'язки | | Обслуговування | Складніше оновлення вимірів | Простіше оновлення підвимірів | | Найкраще для | BI/звітність (read-heavy) | Ситуації, що вимагають суворої нормалізації |

На практиці star schema домінують в аналітичних сховищах (BigQuery, Snowflake, Redshift), оскільки продуктивність запитів та простота переважають економію на зберіганні. Детальніше -- у модулі моделювання даних.

11. Що таке slowly changing dimension (SCD)? Поясніть Type 1, 2 та 3.

SCD відстежують зміни атрибутів вимірів з часом:

• Type 1: Перезапис старого значення. Без історії. Просто, але з втратою даних.
• Type 2: Додавання нового рядка з відстеженням версій (valid_from, valid_to, is_current). Повна історія зберігається. Найпоширеніший варіант у продакшн-сховищах.
• Type 3: Додавання стовпця для попереднього значення (current_city, previous_city). Обмежена історія (відстежується лише одна зміна).

Type 2 -- вибір за замовчуванням для більшості бізнес-вимірів (адреса клієнта, категорія продукту, відділ працівника), оскільки аудит та історична звітність цього вимагають.

12. Як змоделювати дані подій для аналітики реального часу та довгострокового зберігання?

Дворівневий підхід:

1. Hot layer: потокова передача подій у сховище реального часу (Apache Druid, ClickHouse або Materialized Views у сховищі), оптимізоване для агрегацій з низькою затримкою на нещодавніх даних.
2. Cold layer: збереження сирих подій у lakehouse (Delta Lake, Iceberg), партиціонованому за датою, з необмеженим терміном зберігання для ad-hoc аналізу та feature engineering для ML.

Hot layer використовує попередньо агреговані або денормалізовані схеми для швидкості. Cold layer зберігає повну гранулярність. Задача reconciliation періодично перевіряє, що обидва шари збігаються.

Apache Spark та розподілена обробка

Питання про Spark зосереджені на розумінні паралелізму та продуктивності, а не лише на API.

13. Що спричиняє data skew у Spark та як це виправити?

Data skew виникає, коли одна партиція містить непропорційно більше даних, ніж інші, що призводить до того, що одне завдання стає вузьким місцем для всієї стадії.

Поширені причини: join на ключі з кількома домінуючими значеннями (null-ключі, один популярний product ID) або партиціонування за стовпцем з низькою кардинальністю.

Вирішення:

• Salting: додавання випадкового суфікса до skewed ключа, join за salted ключем, потім агрегація для видалення salt.
• Broadcast join: якщо одна сторона достатньо мала (зазвичай <200 МБ), broadcast її для повного уникнення shuffle.
• AQE (Adaptive Query Execution): Spark 3.x+ може автоматично виявляти та розділяти skewed партиції під час виконання.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Це рівномірно розподіляє навантаження між executor'ами, усуваючи вузьке місце.

14. Поясніть різницю між трансформаціями та діями (actions) у Spark.

Трансформації (map, filter, select, join) є лінивими: вони будують логічний план, але нічого не виконують. Дії (count, collect, write) запускають фактичне обчислення, надсилаючи план на кластер.

Ця лінива обробка дозволяє оптимізатору Catalyst у Spark перегрупувати операції, просунути предикати вниз та усунути непотрібні shuffle перед будь-яким переміщенням даних. Розуміння цього розрізнення є ключовим для відлагодження: трансформація, що здається повільною, насправді не виконується -- вузьке місце знаходиться в дії, яка її запускає.

15. Яка різниця між repartition() та coalesce()?

repartition(n) виконує повний shuffle для створення рівно n партицій, рівномірно розподіляючи дані. Використовується для збільшення паралелізму або перебалансування skewed партицій.

coalesce(n) зменшує кількість партицій без shuffle шляхом злиття суміжних партицій. Використовується для зменшення кількості партицій перед записом (щоб уникнути великої кількості маленьких файлів).

Правило: coalesce для зменшення, repartition для збільшення або перебалансування.

Оркестрація та управління pipeline'ами

Питання про оркестрацію перевіряють операційну зрілість: як pipeline'и працюють, зазнають збоїв та відновлюються у продакшені.

16. Порівняйте Airflow, Dagster та Prefect. Коли обирати кожен?

| Характеристика | Airflow | Dagster | Prefect | |----------------|---------|---------|--------| | Зрілість | Найзріліший, найбільша спільнота | Зростає, сильний у ML/data командах | Cloud-first, сильний DX | | Основна абстракція | DAG'и задач | Assets (data-centric) | Flows та tasks | | Тестування | Складніше (рівень DAG) | Вбудоване тестування assets | Добре тестування на рівні задач | | Локальна розробка | Потребує Docker/контейнерів | Нативне локальне виконання | Нативне локальне виконання | | Найкраще для | Складних, тривалих ETL | Data mesh / asset-орієнтованих команд | Команд, що хочуть мінімальної інфраструктури |

Airflow залишається галузевим стандартом для зрілих платформ даних. Dagster підходить командам, які мислять категоріями data assets, а не послідовностями задач. Prefect приваблює команди, які хочуть оркестрацію подібну до Airflow з меншим операційним навантаженням. Для підготовки до питань по Airflow див. модуль основ Airflow.

17. Як обробляти збої pipeline'ів та налаштувати алертинг у продакшені?

Стратегія обробки збоїв продакшн-рівня включає:

1. Retry з backoff: транзієнтні збої (мережеві тайм-аути, ліміти API) вирішуються експоненціальним retry.
2. Dead-letter queues: проблемні повідомлення направляються в окрему чергу для ручної перевірки, не блокуючи pipeline.
3. Circuit breakers: після N послідовних збоїв pipeline зупиняється та надсилає алерт, замість того щоб заповнювати downstream-системи поганими даними.
4. Observability: структуровані логи, метрики (тривалість задач, кількість рядків, частота помилок) та перевірки якості даних (Great Expectations, dbt tests) на кожній стадії pipeline.
5. Рівні алертів: P1 (pipeline не працює, дані відсутні) -- оповіщення чергового. P2 (дрейф якості даних) -- повідомлення в Slack для наступного робочого дня.

18. Що робить pipeline "production-ready" на відміну від прототипу?

Готовність до продакшену означає: ідемпотентні запуски, автоматичні retry, моніторинг та алертинг, валідація даних на етапах ingestion та transformation, документація data contracts, визначення pipeline'ів під контролем версій та протестований шлях відкату. Прототип не має жодного з цих елементів. Розрив між ними -- це те, де накопичується більшість технічного боргу pipeline'ів.

Хмарні платформи даних та архітектура lakehouse

Питання про хмарні платформи оцінюють, чи розуміє кандидат компроміси між вартістю, масштабом та архітектурою, виходячи за межі vendor-specific синтаксису.

19. Що таке lakehouse і чому ця архітектура стала домінуючою?

Lakehouse поєднує гнучкість data lake (schema-on-read, зберігання сирих даних, множинні формати файлів) з надійністю data warehouse (ACID-транзакції, enforcement схеми, оптимізація запитів). Такі технології, як Delta Lake, Apache Iceberg та Apache Hudi, забезпечують це, додаючи рівень метаданих/транзакцій поверх object storage (S3, GCS, ADLS).

Lakehouse перемагає, оскільки усуває дороговартісний ETL-рівень між lake та warehouse, підтримує як BI-запити, так і ML-навантаження на одних і тих самих даних, та використовує дешеве object storage.

20. Як оптимізувати витрати на хмарне сховище (BigQuery, Snowflake, Redshift)?

Стратегії оптимізації витрат:

• Партиціонування та кластеризація таблиць для зменшення обсягу зісканованих байтів на запит
• Налаштування відповідних розмірів warehouse (Snowflake) або slot reservations (BigQuery) на основі патернів навантаження
• Автоматичне призупинення неактивних ресурсів: Snowflake warehouses мають автоматично призупинятися після 1-5 хвилин неактивності
• Моніторинг витрат на запит: view INFORMATION_SCHEMA.JOBS у BigQuery виявляє дорогі запити
• Використання materialized views для агрегацій, що обчислюються повторно
• Архівація холодних даних на дешевші рівні зберігання з lifecycle-політиками

Сигнал для інтерв'юерів: кандидати, які розглядають вартість як першочергове інженерне обмеження, а не як другорядне питання.

Якість даних та governance

Питання про якість даних відрізняють інженерів, що просто запускають pipeline'и, від тих, хто підтримує надійні платформи даних.

21. Як реалізувати перевірки якості даних у pipeline?

Перевірки якості даних належать на трьох стадіях:

1. Ingestion: валідація відповідності схемі, перевірка на null primary keys, верифікація порогів кількості рядків відносно джерела.
2. Transformation: перевірка бізнес-правил (наприклад, revenue > 0, дати у валідному діапазоні), перевірка referential integrity між таблицями.
3. Serving: моніторинг дрейфу метрик (раптове падіння DAU на 50% скоріше вказує на проблему pipeline, а не на зміну бізнес-показників).

Інструменти: dbt tests (schema та custom), Great Expectations, Soda Core, Monte Carlo (data observability). Найкращий підхід інтегрує перевірки безпосередньо в DAG pipeline, щоб збої блокували downstream-обробку.

22. Що таке data contract і як він запобігає поломкам pipeline'ів?

Data contract -- це формальна угода між продюсером даних та його споживачами, що визначає: схему (назви стовпців, типи, nullability), SLA свіжості (дані доступні до 6:00 UTC), очікування щодо обсягу (від 1 млн до 10 млн рядків на день) та семантичні правила (поле status містить лише ACTIVE, INACTIVE, SUSPENDED).

Коли продюсери змінюють схему без оновлення контракту, автоматична валідація виявляє невідповідність до того, як вона пошириться downstream. Це зміщує збої pipeline'ів від тихого пошкодження даних до явних, дієвих помилок.

Проєктування систем та архітектура

Раунди проєктування систем є стандартними для mid-to-senior ролей data engineering. Вони перевіряють end-to-end мислення.

23. Спроєктуйте pipeline аналітики реального часу для e-commerce платформи.

Якісний дизайн охоплює:

Ingestion: події кліків та транзакцій потрапляють у Kafka topics, партиціоновані за user_id для гарантій порядку в межах сесії користувача.

Processing: завдання Flink або Spark Structured Streaming споживає з Kafka, збагачує події даними каталогу продуктів (broadcast join з таблиці вимірів), обчислює агрегації на рівні сесії та 5-хвилинні агрегації.

Serving: агреговані метрики потрапляють у real-time OLAP-сховище (ClickHouse або Apache Druid) для запитів дашбордів із sub-second затримкою. Сирі події зберігаються у Delta Lake/Iceberg для історичного аналізу.

Якість даних: schema registry (Confluent або AWS Glue) валідує схеми подій при ingestion. Потокові перевірки якості даних виявляють аномалії (раптове падіння обсягу подій) та направляють у dead-letter topic.

Обробка збоїв: consumer offsets Kafka забезпечують exactly-once обробку з checkpointing. Потокове завдання автоматично перезапускається з останнього checkpoint при збої.

24. Як мігрувати legacy ETL pipeline на сучасний стек?

Міграція відбувається за патерном strangler fig:

1. Аудит: каталогізація всіх існуючих pipeline'ів, їх джерел, трансформацій та споживачів. Ідентифікація залежностей та SLA.
2. Паралельний запуск: побудова нового pipeline паралельно зі старим. Обидва споживають ті самі джерела та пишуть у різні цілі.
3. Валідація: порівняння результатів між старим та новим pipeline'ами. Автоматичні reconciliation-запити виявляють розбіжності.
4. Переключення: після того як результати збігаються в межах толерантності протягом 2+ тижнів, споживачі переключаються на нову ціль. Старий pipeline залишається в режимі лише для читання для можливості відкату.
5. Виведення з експлуатації: після періоду стабільності legacy pipeline вимикається.

Ключовий інсайт: ніколи не робити міграцію одним махом. Обидві системи мають працювати паралельно, доки не буде встановлена достатня впевненість.

25. Критичний дашборд показує некоректні числа. Опишіть процес відлагодження.

Систематичний підхід:

1. Визначити масштаб проблеми: які метрики некоректні? Від якого моменту? Всі виміри чи конкретні фільтри?
2. Перевірити рівень serving: запитати сховище напряму, щоб підтвердити, чи проблема у інструменті дашборду (кешування, логіка фільтрів) чи в самих даних.
3. Простежити lineage upstream: прослідкувати дані від таблиці дашборду через кожен етап трансформації. Перевірити кількість рядків та ключові метрики на кожній стадії.
4. Визначити точку розриву: стадія, де очікувані значення розходяться з фактичними, є місцем першопричини.
5. Перевірити типові причини: зміни схеми у вихідних системах, невдалі запуски pipeline'ів, що пройшли без алерту, запізнілі дані, що пропустили вікно обробки, або деплоймент, що змінив логіку трансформації.
6. Виправити та запобігти: усунути проблему, додати перевірку якості даних, яка б її виявила, та оновити runbook.

Це питання перевіряє зрілість реагування на інциденти. Інтерв'юери хочуть бачити структуроване мислення, а не випадкові здогадки.

Підготовка до співбесіди з data engineering

Програма підготовки до співбесіди з data engineering на SharpSkill охоплює ці теми з інтерактивною практикою по патернах ETL/ELT, моделюванню даних, Airflow, BigQuery та іншим темам.

Висновок

• Віконні функції SQL, CTE та оптимізація запитів залишаються фундаментальними незалежно від рівня досвіду
• Рішення ETL vs ELT мають базуватися на вимогах до затримки, потребах data governance та витратах на інфраструктуру, а не на слідуванні трендам
• Ідемпотентність, data contracts та перевірки якості даних відрізняють продакшн-рівень pipeline'ів від прототипів
• Питання про потокову архітектуру зосереджені на компромісах (batch vs streaming vs micro-batch), а не на знаннях конкретних інструментів
• Вибір моделювання даних (star vs snowflake, типи SCD) має відповідати патернам споживання, а не теоретичним найкращим практикам
• Відповіді на проєктування систем мають охоплювати обробку збоїв, оптимізацію витрат та observability поряд зі сценарієм успішного виконання
• Найсильніші кандидати демонструють структуроване розв'язання проблем та чесне обґрунтування компромісів