Яких питань про Databricks очікувати на співбесіді?

Співбесіди в Databricks починають із Delta Lake, оскільки на ньому побудована платформа. Будьте готові пояснити, що таблиця Delta додає до звичайних файлів Parquet: журнал транзакцій, який фіксує кожне підтвердження змін і забезпечує атомарний запис, узгоджене читання та можливість звернутися до попередньої версії таблиці. Подальший ланцюжок питань передбачуваний: як працює подорож у часі (читання попереднього знімка журналу), що видаляє VACUUM і чому це обмежує глибину повернення в минуле, а також як MERGE реалізує оновлення або вставлення записів і шаблони фіксації змін у даних.

• Контроль і розвиток схеми. Записи, що не відповідають схемі, відхиляються, якщо не дозволено її розвиток; поясніть, коли ви б його дозволили.
• OPTIMIZE і структура файлів. Малі файли погіршують швидкодію читання; ущільнення перезаписує їх, а кластеризація або Z-впорядкування розміщує поруч значення, за якими фільтрують запити.
• Потокове й пакетне опрацювання однієї таблиці. Та сама таблиця Delta може бути приймачем потокових даних і джерелом пакетних; поясніть, що означає рівно одноразове опрацювання для завдання Structured Streaming, яке записує дані в Delta.
• Delta Live Tables і конвеєри. Декларативні конвеєри з очікуваннями щодо якості даних; будьте готові пояснити, що відбувається, коли рядок не відповідає очікуванню.

Пояснюйте механізм. Твердження, що Delta підтримує ACID, — це гасло; пояснення, що журнал транзакцій приховує від читачів частково невдалий запис, — це відповідь.

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

• Бронзовий. Приймання необроблених даних, лише додавання, схема в початковому вигляді. Додаткове питання: навіщо взагалі зберігати сирі дані, якщо срібні чистіші? Для повторного опрацювання й аудиту.
• Срібний. Очищені, дедупліковані й узгоджені записи. Додаткове питання: як усувати дублікати в потоці подій, які можуть надходити із запізненням або двічі, і яку роль тут відіграють водяні знаки?
• Золотий. Агрегати й таблиці бізнес-рівня для аналітиків та інформаційних панелей. Додаткове питання: хто відповідає за визначення і як запобігти розбіжностям у показниках доходу між двома золотими таблицями?
• Оркестрація. Завдання, залежності між ними, повторні спроби та сповіщення. Додаткове питання: як зробити завдання ідемпотентним, щоб повторний запуск не призвів до подвійного підрахунку?
• Приймання даних. Auto Loader для поступового виявлення файлів і пояснення, чому наївне отримання списку каталогу погано масштабується.

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

На співбесідах для старших фахівців вам описують симптом. Типовий приклад: інженеру даних, який проходить співбесіду на платформну роль у роздрібній компанії, кажуть, що нічне завдання з об’єднання замовлень із довідником клієнтів після різкого зростання обсягу даних почало тривати годинами замість хвилин. Сильна відповідь починається з плану запиту та Spark UI, а не з більшого кластера: слід перевірити, чи не перетворилося об’єднання з трансляцією на об’єднання з перетасуванням, чи немає перекосу за кількома ключами, чи досі кількість розділів перетасування відповідає обсягу даних і чи немає у вихідних таблицях проблем із малими файлами, які виправив би OPTIMIZE. Інтерв’юер оцінює порядок дослідження.

Інші повторювані сценарії: потокове завдання з постійним зростанням відставання та взаємодія інтервалів запуску, розміру стану й водяних знаків; ноутбук, який працює для одного користувача й не працює для іншого, що зазвичай указує на проблему з дозволами та веде до Unity Catalog, робочих просторів і сервісних облікових записів; таблиця, на несвіжість якої скаржаться аналітики, що стосується актуальності й оркестрації; а також запит на безпечне надання даних іншій команді, де доречні Delta Sharing і дозволи на рівні каталогу.

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

У розмовних раундах — так, але з чесними обмеженнями. Нативна настільна програма SubcueAI для macOS і Windows захоплює системний звук та ваш мікрофон і показує короткі підказки для відповіді в локальному накладному вікні. Тому, коли інтерв’юер запитує, що робить водяний знак під час дедуплікації потоку, механізм буде на вашому екрані, поки ви пояснюєте його власними словами. Розширення для браузера підтримує дзвінки у вкладках Chrome та Edge, захоплюючи лише звук вкладки зустрічі. Жоден бот не приєднується до дзвінка, а на сторінку зустрічі нічого не вбудовується; порядок налаштування наведено на сторінці посібника.

Обмеження: контрольоване оцінювання, запис екрана, керований компанією ноутбук або вправа наживо в ноутбуці, де ви пишете PySpark під наглядом, не передбачають такої допомоги, а саме туди на співбесідах Databricks часто виносять найскладнішу частину. Помічник найкорисніший для питань про архітектуру й компроміси. Спочатку завантажте резюме, щоб пропозиції враховували конвеєри, які ви справді створювали; цей профіль зберігається в конструкторі резюме.