Вопросы по DWH и моделированию данных на собеседовании

Моделирование это ядро собеседования дата-инженера: по ответам видно, проектировал человек хранилище или только писал в него загрузки. Классический вопрос про SCD второго типа отсеивает половину кандидатов.

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Звезда и снежинка18
• SCD и историчность11
• Нормализация и слои DWH11
• Физика DWH и MPP10
• Data Vault8

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Data Vault8 вопросов
• Звезда и снежинка в DWH18 вопросов
• Физика DWH и MPP10 вопросов
• Слои и нормализация DWH11 вопросов
• SCD и историчность измерений11 вопросов

Примеры вопросов с разбором

1. #data_vault_modeling1 / 9
   Из каких трёх типов сущностей состоит модель Data Vault?

   A)Хабы (бизнес-ключи), линки (связи между хабами) и сателлиты (атрибуты и их история)

   B)Из фактов, измерений и мостов — ровно как в классической размерной модели Кимбалла

   C)Из таблиц bronze, silver и gold, соответствующих трём слоям очистки данных

   D)Из нормализованных таблиц в 1NF, 2NF и 3NF, по одной сущности на каждую нормальную форму

   показать ответ и разбор

   +A)Хабы (бизнес-ключи), линки (связи между хабами) и сателлиты (атрибуты и их история)

   // разбор: Data Vault раскладывает данные на три сущности. Hub — уникальные бизнес-ключи (клиент, счёт) плюс суррогат/хеш и метаданные загрузки. Link — связи между хабами (клиент↔счёт), тоже только ключи. Satellite — описательные атрибуты и их история во времени, привязанные к хабу или линку. Ключи, связи и контекст разведены, поэтому модель гибкая к изменениям источников, распараллеливаемая при загрузке и полностью аудируемая. Обычно это raw-слой, поверх которого строят витрины-звёзды.

2. #dimensional_modeling2 / 9
   Что такое схема «звезда» (star schema)?

   A)Центральная факт-таблица, окружённая денормализованными измерениями

   B)Нормализованная до 3NF модель для транзакционной нагрузки OLTP

   C)Граф без таблиц фактов, где всё хранится в одной широкой таблице

   D)Схема хранения всех данных в формате «ключ-значение» в оперативной памяти

   показать ответ и разбор

   +A)Центральная факт-таблица, окружённая денормализованными измерениями

   // разбор: Звезда — факт-таблица с числовыми метриками в центре и денормализованные измерения-справочники вокруг. Такая форма минимизирует число джойнов для аналитики и понятна бизнесу. Это осознанный уход от нормализации (3NF), которая оптимальна для записи в OLTP, но медленна для чтения.

3. #dwh_physical3 / 9
   Зачем большие факт-таблицы в DWH партиционируют по дате?

   A)Чтобы обеспечить уникальность строк факта — партиционирование по дате работает как первичный ключ

   B)Чтобы отказаться от индексов: партиции якобы делают индексацию таблицы ненужной

   C)Чтобы запросы читали лишь нужные партиции (partition pruning), а старые данные можно было дёшево дропать и грузить параллельно

   D)Чтобы автоматически распределить факт-таблицу по разным географическим дата-центрам компании

   показать ответ и разбор

   +C)Чтобы запросы читали лишь нужные партиции (partition pruning), а старые данные можно было дёшево дропать и грузить параллельно

   // разбор: Партиционирование факта по дате (день/месяц) даёт три выгоды. Запрос с фильтром по периоду читает только соответствующие партиции — partition pruning резко сокращает сканирование. Управление данными дешевеет: удалить/переналить месяц — это drop/overwrite партиции, а не тяжёлый DELETE. И загрузка распараллеливается по партициям. Грабля — слишком мелкое дробление (тысячи крохотных партиций) даёт накладные расходы на метаданные и мелкие файлы.

4. #normalization_layers4 / 9
   Зачем в DWH разделять слои raw/staging → core → data marts?

   A)Слои нужны для соответствия требованиям внешнего аудита и регуляторов

   B)Чтобы каждый аналитик мог держать собственную личную копию всех данных для своих личных экспериментов с витринами без оглядки на других

   C)Слои замедляют пайплайн, их держат по историческим причинам

   D)Разделение ответственности: сырой приём → чистое ядро → витрины под бизнес

   показать ответ и разбор

   +D)Разделение ответственности: сырой приём → чистое ядро → витрины под бизнес

   // разбор: Слои разделяют ответственность: raw/staging принимает сырые данные как есть, core чистит и согласует их в единую модель, data marts формируют представления под конкретные задачи. Это даёт воспроизводимость, переиспользование и точку отладки на каждом уровне — а не тормоза.

5. #scd_history5 / 9
   Какую задачу решают Slowly Changing Dimensions (SCD)?

   A)Как хранить изменения атрибутов измерения во времени (юзер сменил город)

   B)Как ускорять медленные аналитические запросы к факт-таблице кэшированием

   C)Как сжимать редко используемые измерения для экономии дискового места

   D)Как надёжно реплицировать таблицы измерений сразу между несколькими дата-центрами

   показать ответ и разбор

   +A)Как хранить изменения атрибутов измерения во времени (юзер сменил город)

   // разбор: SCD — семейство стратегий хранения историчности: что делать, когда описательный атрибут измерения меняется (клиент переехал, товар сменил категорию). Выбор типа (перезаписать, добавить версию, хранить прошлое значение отдельным полем) определяет, можно ли потом считать факты в исторически верном контексте.

6. #data_vault_modeling6 / 9
   Чем hub отличается от satellite в Data Vault?

   A)Hub хранит атрибуты и их историю, а satellite — только уникальные бизнес-ключи сущностей

   B)Hub хранит только бизнес-ключи (что существует), satellite — описательные атрибуты и их историю (какое оно во времени)

   C)Hub и satellite — это синонимы, обозначающие одну и ту же таблицу бизнес-ключей в Data Vault

   D)Hub хранит связи между сущностями, а satellite — сами сущности, участвующие в этих связях

   показать ответ и разбор

   +B)Hub хранит только бизнес-ключи (что существует), satellite — описательные атрибуты и их историю (какое оно во времени)

   // разбор: Hub — список уникальных бизнес-ключей сущности (плюс хеш-ключ и метаданные загрузки), он отвечает на «что вообще существует» и почти не меняется. Satellite привязан к хабу (или линку) и хранит описательные атрибуты вместе с временем загрузки — при изменении атрибута добавляется новая строка сателлита, так копится история (аналог SCD2). Разделение «ключи отдельно, контекст отдельно» позволяет добавлять новые источники атрибутов новыми сателлитами, не трогая хаб.

7. #dimensional_modeling7 / 9
   Чем факт-таблица отличается от таблицы измерений?

   A)Факт-таблица хранит текстовые описания, а измерение — числовые метрики для удобства чтения человеком в аналитических отчётах

   B)Факт — измеримые события (числа + ключи); измерение — описательный контекст

   C)Между факт-таблицей и таблицей измерения нет никакой разницы

   D)Факт меньше измерения по числу строк в модели

   показать ответ и разбор

   +B)Факт — измеримые события (числа + ключи); измерение — описательный контекст

   // разбор: Факт-таблица хранит измеримые события: числовые метрики (сумма, количество) и внешние ключи на измерения. Измерения дают описательный контекст «кто/что/где/когда» (клиент, товар, дата). Фактов обычно на порядки больше, чем строк измерений, — отсюда и разный дизайн.

8. #dwh_physical8 / 9
   Что задаёт distribution key в MPP-хранилище (Greenplum и аналоги) и как его выбирают?

   A)Distribution key задаёт порядок сортировки строк внутри сегмента для ускорения диапазонных запросов

   B)Distribution key определяет, сколько реплик-копий таблицы будет создано ради отказоустойчивости

   C)Distribution key нужно выбирать по столбцу с самой низкой кардинальностью для равномерности

   D)Ключ распределения по сегментам; равномерный + co-location для джойнов

   показать ответ и разбор

   +D)Ключ распределения по сегментам; равномерный + co-location для джойнов

   // разбор: В MPP-СУБД (Greenplum, аналоги) таблица разложена по сегментам-узлам, и distribution key определяет, на какой сегмент попадёт строка (обычно hash от ключа). Хороший ключ высококардинальный и равномерный — иначе один сегмент перегружен (data skew). Ещё важнее co-location: если две джойнимые таблицы распределены по одному ключу, соединение идёт локально на сегментах; если по разным — данные тасуются по сети (motion/redistribute), что медленно. Плохой выбор — низкая кардинальность или несовпадение с ключами частых джойнов.

9. #normalization_layers9 / 9
   Почему витрины (data marts) часто денормализуют, а не держат в 3NF?

   A)Оптимизация чтения: меньше джойнов — быстрее BI, а место дёшево

   B)Нормальная форма 3NF в аналитических витринах плохо работает в колоночных СУБД

   C)Денормализация нужна витринам ради экономии дискового пространства

   D)Витрины денормализуют, потому что нормализация ломает целостность данных

   показать ответ и разбор

   +A)Оптимизация чтения: меньше джойнов — быстрее BI, а место дёшево

   // разбор: Аналитика — read-heavy: запросы часто джойнят и агрегируют. Денормализация схлопывает джойны в широкие таблицы, ускоряя чтение ценой дублирования, которое на дешёвом хранилище терпимо. Нормализация (3NF) минимизирует аномалии записи и хороша для OLTP, но для BI-чтения она медленна.

Частые вопросы

• Звезда или снежинка: что отвечать?

  Что выбор это компромисс между простотой запросов и дублированием данных. Звезда быстрее и понятнее аналитикам, снежинка экономнее и строже, а на практике часто получается гибрид.

• Что такое SCD второго типа?

  Способ хранить историю изменений измерения: вместо перезаписи добавляется новая версия строки с датами действия. Это позволяет считать метрики на состояние прошлого периода.