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 змушують щоразу сканувати й розбирати все. Партиціонування за колонкою, за якою ви фільтруєте, зазвичай за датою, дає рушію пропускати цілі директорії, але надмірне партиціонування народжує мільйони крихітних файлів, і накладні витрати на метадані зʼїдають усю вигоду.