Databricks на собеседовании Data Engineer

Что такое Databricks

Databricks — облачная платформа для работы с данными и ML, которую основали создатели Apache Spark. Идея простая: собрать в одном месте хранение, обработку, SQL-аналитику, ML и governance, чтобы дата-инженеру не приходилось склеивать десяток разрозненных инструментов. Под капотом — Spark для распределённых вычислений, Delta Lake для транзакционного хранения и Unity Catalog для управления доступом и происхождением данных.

Работает поверх облачного объектного хранилища на AWS, Azure и GCP: данные лежат в S3/ADLS/GCS, а Databricks даёт вычислительные кластеры и слой управления. В РФ прямого доступа нет из-за санкций, поэтому чаще всего Databricks встречается у кандидатов с опытом в международных или облачных проектах — и вопросы на собесе идут именно про концепции платформы, а не про кнопки в интерфейсе.

На интервью Databricks спрашивают, когда в стеке компании есть Spark и облако. Ждут, что вы понимаете три вещи: чем Lakehouse отличается от классического хранилища, зачем нужен Delta Lake поверх обычного Parquet и как Unity Catalog решает вопросы доступа и происхождения данных.

Lakehouse

Lakehouse — это архитектура, которая объединяет дешёвое хранение data lake с транзакционностью и производительностью data warehouse. Раньше приходилось выбирать: либо озеро (гибко и дёшево, но без ACID, без гарантий качества, с «болотом» из файлов), либо хранилище (быстро и надёжно, но дорого и с закрытым форматом). Lakehouse снимает этот выбор — данные лежат в открытом формате на объектном хранилище, но получают ACID-транзакции, версионирование и SQL-производительность.

Стандартный способ организовать данные внутри Lakehouse — медальонная архитектура из трёх слоёв:

Bronze (сырьё)   → данные как есть из источников, без обработки
Silver (очищенный) → дедуп, приведение типов, валидация, джойны
Gold (витрины)   → агрегаты и модели под конкретные задачи аналитики

Все три слоя хранятся как Delta-таблицы на объектном хранилище. По ним можно бегать SQL-запросами через Databricks SQL, а тяжёлую трансформацию и обучение моделей гонять на Spark. Главный тезис для собеса: ACID-гарантии живут на уровне слоя хранения, поэтому аналитика работает с транзакционно консистентными данными, а не с полусырыми файлами.

Unity Catalog

Unity Catalog — централизованный каталог и слой governance для всех рабочих пространств Databricks. Он решает боль, которая возникает, когда данные расползаются по разным воркспейсам и у каждого свои разрозненные ACL и метасторы: кто имеет доступ, откуда взялась таблица, какие есть модели — всё разбросано.

Пространство имён трёхуровневое:

catalog.schema.table

Что даёт Unity Catalog на практике:

• Централизованный доступ. Права выдаются один раз на уровне каталога и действуют во всех воркспейсах, а не настраиваются отдельно в каждом.
• Встроенный lineage. Платформа сама отслеживает, из каких таблиц и колонок собрана целевая таблица. На собесе это любят: «как понять, что сломает изменение схемы источника?» — по графу происхождения.
• Обнаружение данных. Поиск и описание таблиц, чтобы аналитики находили нужный датасет, а не плодили дубликаты.
• Реестр ML-моделей. Модели живут в том же каталоге, что и данные, с теми же правами доступа.

Короткий ответ на интервью: Unity Catalog заменяет фрагментированные ACL и метасторы единым слоем управления доступом, происхождением и обнаружением данных.

Delta Lake

Delta Lake — open-source формат хранения, который добавляет к обычному Parquet ACID-транзакции, тайм-тревел и эволюцию схемы. Работает это за счёт транзакционного лога (_delta_log): каждое изменение записывается как атомарная транзакция в лог, поэтому параллельные читатели и писатели не видят «полузаписанных» данных, а откат — это просто чтение нужной версии лога.

-- создать Delta-таблицу поверх файлов на объектном хранилище
CREATE TABLE events USING delta LOCATION 's3://...'

Что нужно уметь объяснить про Delta на собесе:

• OPTIMIZE — компакция мелких файлов в крупные. Стриминг и частые записи плодят «маленькие файлы», которые убивают производительность чтения; OPTIMIZE их сливает.
• VACUUM — физически удаляет старые версии файлов, на которые больше нет ссылок. Освобождает место, но уменьшает глубину тайм-тревела, поэтому у него есть порог хранения (по умолчанию 7 дней).
• Z-ORDER — многомерная кластеризация данных для data skipping: файлы раскладываются так, чтобы по частым фильтрам движок читал меньше файлов.
• Тайм-тревел — чтение таблицы на конкретную версию или момент времени. Нужно для отката ошибочной записи, аудита и воспроизводимости ML-экспериментов.
• MERGE — атомарный upsert по ключу, база для CDC и загрузки инкрементов без дублей.

Ключевое отличие от голого Parquet: Parquet — это просто набор файлов без гарантий согласованности при параллельной записи, а Delta даёт ACID и историю версий поверх тех же файлов.

Databricks SQL и Photon

Databricks SQL (DBSQL) — это SQL-движок и хранилища (SQL warehouses) для интерактивной аналитики прямо по данным Lakehouse: дашборды, ad-hoc запросы, BI-подключения. Смысл в том, что аналитику не нужно копировать данные в отдельное хранилище — он работает с теми же Delta-таблицами, что и инженеры.

Под капотом — движок Photon: векторизованный исполнитель запросов, переписанный на C++, который ускоряет SQL- и DataFrame-нагрузки без изменения кода. За счёт векторизации и работы с колоночными данными DBSQL на Lakehouse-данных конкурирует по скорости со Snowflake и BigQuery, оставаясь при этом на открытом формате Delta.

Частые ошибки

• Путать data lake, warehouse и lakehouse. Озеро — дёшево и гибко, но без ACID; хранилище — быстро и надёжно, но дорого и закрыто; Lakehouse объединяет плюсы обоих. Если не развести эти три понятия — сразу видно поверхностное знание.
• Считать Delta «просто Parquet». Delta даёт ACID, тайм-тревел и эволюцию схемы через транзакционный лог. Без упоминания _delta_log ответ выглядит заученным.
• Не различать OPTIMIZE, VACUUM и Z-ORDER. OPTIMIZE сливает мелкие файлы, VACUUM удаляет старые версии, Z-ORDER раскладывает данные под фильтры. Их часто путают.
• Забывать про проблему мелких файлов. Стриминговые записи плодят тысячи маленьких файлов; без компакции чтение деградирует. Классический вопрос на собесе.
• Не понимать, зачем нужен Unity Catalog. Отвечать «это каталог» мало — важно назвать доступ, lineage и обнаружение данных как единый слой поверх воркспейсов.

Связанные темы

• Lakehouse Iceberg Delta для DE
• Spark RDD vs DataFrame для DE
• Snowflake vs BigQuery для DE
• Медальон-архитектура для DE
• Подготовка к собесу Data Engineer

FAQ

Чем Databricks отличается от обычного Spark-кластера?

Databricks — это управляемая платформа поверх Spark: помимо вычислений вы получаете Delta Lake для транзакционного хранения, Unity Catalog для governance, Databricks SQL для аналитики, ноутбуки, оркестрацию задач и ML-инструменты в едином окружении. Голый Spark даёт только движок обработки — всё остальное приходится собирать самому.

Зачем нужен Delta Lake, если есть Parquet?

Parquet — это просто колоночные файлы без гарантий при параллельной записи и без истории. Delta добавляет поверх них ACID-транзакции через лог _delta_log, тайм-тревел (чтение старых версий), эволюцию схемы и MERGE для upsert-ов. Это превращает набор файлов в полноценную транзакционную таблицу.

В чём разница между OPTIMIZE, VACUUM и Z-ORDER?

OPTIMIZE сливает много мелких файлов в несколько крупных, чтобы ускорить чтение. VACUUM удаляет старые, больше не нужные версии файлов и освобождает место (но урезает глубину тайм-тревела). Z-ORDER перекладывает данные внутри файлов по нескольким колонкам, чтобы движок пропускал лишние файлы при фильтрации.

Что такое медальонная архитектура?

Это разбиение данных на три слоя Delta-таблиц: Bronze — сырьё из источников как есть, Silver — очищенные и провалидированные данные, Gold — агрегаты и витрины под конкретные задачи. Каждый слой добавляет качество и удобство, а трансформация идёт последовательно снизу вверх.

Это официальная информация?

Нет. Статья основана на документации Databricks, Delta Lake и Apache Spark и на опыте кандидатов. Конкретный стек и глубина вопросов зависят от компании, команды и уровня позиции.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.