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

Зачем DE спрашивают про data modeling

Data modeling — то, как ты раскладываешь данные в DWH чтобы они были (а) понятны бизнесу, (б) эффективны для запросов, (в) поддерживаемы. На собесе Data Engineer это обязательный блок: либо отдельным раундом 45-60 минут, либо в системном дизайне.

Уровень: junior — знает star schema, normalisation; middle — SCD-типы, понимание Data Vault; senior — Data Mesh, многослойная архитектура medallion, lakehouse, data products.

Source / Staging / DWH / Marts

Стандартная слойная архитектура:

Source layer — данные «как есть» из источников. Минимальная обработка, может быть нормализованным OLTP-форматом.

Staging layer — промежуточный, очищенный, типизированный, готовый для трансформации.

DWH / Core layer — моделированные данные. Star / Snowflake / Data Vault.

Data marts — узкоспециализированные витрины для конкретных команд (marketing, finance).

Medallion (Databricks): bronze (raw) → silver (cleaned) → gold (business-ready).

Star schema

Star schema — центральная fact-таблица + несколько dimension-таблиц.

[fact_orders]
- order_id (PK)
- customer_id (FK)
- product_id (FK)
- date_id (FK)
- amount
- quantity

[dim_customer]
- customer_id (PK)
- name, country, segment

[dim_product]
- product_id (PK)
- name, category, brand

[dim_date]
- date_id (PK)
- date, year, quarter, month

Преимущества:

• Простые SELECT (мало JOIN-ов)
• Хорошо для BI tools
• Понятно бизнесу

Подходит: аналитические запросы, BI, MOLAP-кубы.

Snowflake schema

Snowflake — нормализованные dimensions. У dim_product есть подсправочник dim_category, у dim_category — dim_department и т.д.

Преимущества: меньше дублирования данных, экономия места.

Недостатки: больше JOIN-ов в запросах, сложнее для пользователей.

На собесе: «По умолчанию star, snowflake — только если есть веская причина (compliance, нормализация critical reference data)».

Подробнее — Star vs Snowflake schema.

Slowly Changing Dimensions (SCD)

Когда атрибут в dimension меняется со временем (customer переехал в другую страну), как хранить?

SCD Type 1 — overwrite. Просто UPDATE. Историю теряем.

SCD Type 2 — версионирование. Новая строка с новым valid_from, старая с valid_to. Сохраняем историю.

customer_id | name | country | valid_from | valid_to   | is_current
1          | John | US      | 2020-01-01 | 2023-01-01 | FALSE
1          | John | UK      | 2023-01-01 | NULL       | TRUE

SCD Type 3 — две колонки: current_country, previous_country. Только одна предыдущая версия.

SCD Type 4 — отдельная history table.

На собесе чаще всего: SCD Type 2. Подробнее — SCD типы для DE.

Data Vault

Альтернативная методология. Three layers:

Hubs — уникальные business keys. Например, hub_customer хранит customer_id.

Satellites — атрибуты, могут изменяться. Например, sat_customer_details хранит name, country, etc. Связаны с hub.

Links — отношения между hubs. Например, link_order_customer связывает orders и customers.

Преимущества:

• Гибкость к изменениям source
• Полная история (audit trail)
• Параллельная загрузка (loose coupling)

Недостатки:

• Сложнее запросы (много JOIN-ов)
• Нужен слой над Data Vault для аналитиков (часто star)

Подробнее — Data Vault 2.0 на собесе DE.

Data Mesh

Modern paradigm — не централизованный DWH, а decentralized data ownership.

Принципы:

1. Domain ownership. Каждая команда (orders, products, customers) владеет своими data products.
2. Data as product. Данные — это продукт со своим SLA, документацией, schema contract.
3. Self-service infrastructure. Платформа для discovery, governance, deployment.
4. Federated governance. Глобальные правила (security, quality), децентрализованное выполнение.

Применимо: большие компании с десятками команд, страдающие от bottleneck-а центрального DE-команды.

Lakehouse

Modern архитектура — комбинирует data lake (cheap storage, любые форматы) с DWH-функциональностью (ACID, indexes, time travel).

Технологии: Iceberg, Delta Lake, Apache Hudi.

Преимущества:

• Одно место хранения (S3 / GCS / ABFS)
• ACID транзакции на object storage
• Time travel (запрос на старое состояние)
• Schema evolution
• Streaming + batch единое API

Подробнее — Lakehouse, Iceberg, Delta.

Типичные вопросы

«Спроектируй DWH для маркетплейса»

Структура: source layer → staging → DWH (star schema) → marts.

Star schema: fact_orders, fact_returns, fact_views. Dimensions: dim_customer (SCD2), dim_product, dim_seller, dim_date. Подробнее проектируется на доске.

«Когда выбирать Data Vault?»

Когда: (1) источники часто меняются (нужна гибкость), (2) compliance требует audit trail, (3) много параллельных источников, (4) есть ресурсы поддерживать сложность.

«Что такое SCD Type 2 и недостатки?»

Версионирование dimension через valid_from / valid_to. Сохраняет историю. Недостаток: таблица растёт, нужен правильный partitioning и индексы.

«Star vs Data Vault?»

Star — для аналитики, простота, скорость запросов. Data Vault — для управления данными, audit, гибкость. На практике часто комбинация: DV → star.

«Lakehouse vs DWH?»

Lakehouse — modern, единое хранилище для structured + unstructured, дешевле для cold data. DWH (Snowflake, BigQuery) — managed, проще в operations, дороже на масштабе.

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

• Сразу делать снежинку. Без причины — лишний JOIN. Start with star.
• SCD Type 1 везде. Теряешь историю. Для важных dimensions — SCD2.
• Игнорировать data lineage. В сложной схеме без lineage не разберёшься, откуда данные.
• Не учитывать SLA. Real-time mart требует другого подхода, чем daily batch.
• «Один большой fact для всего». Денормализация ≠ всё в одну таблицу. Один fact per business event.

FAQ

Какую методологию выбрать?

Зависит от размера и зрелости компании. Малая команда — star schema. Растущая компания — silver/gold + star. Большая organisation с десятками команд — Data Mesh с lakehouse.

Какие книги?

«The Data Warehouse Toolkit» (Kimball) — фундамент. «Building the Data Lakehouse» (Inmon) — modern. «Data Mesh» (Dehghani) — для понимания decentralized.

Нужен ли опыт с конкретным engine?

Полезно. Snowflake, BigQuery, Redshift, ClickHouse — разные оптимизации. На собесе хороший знак — опыт с одним.

Сколько готовиться?

С нуля — 1-2 месяца с практикой. Уже работал — 2-4 недели.

Спрашивают ли BI tools?

Иногда — Tableau, Power BI, Looker. На уровне «понимаю, как они потребляют DWH». Глубоко — только в дата-аналитических командах.

Смотрите также

• Собеседование на Data Engineer
• Star vs Snowflake schema
• SCD типы для DE
• Data Vault 2.0 на собесе DE
• Lakehouse, Iceberg, Delta
• Data Warehouse vs Database