Материал Эйч · Опубликовано 21 июля 2026
Middle, команда DWH Доставки: Data Mesh, витрины данных, SQL и моделирование хранилища
Фишка: Команда работает по концепции Data Mesh: кросс-функциональные доменные команды, где системный аналитик — связующее звено между бизнесом, data-инженерами, аналитиками данных и BI-экспертами. Задача — сделать данные понятными и полезными для бизнес-решений в быстро растущем сервисе Доставки.
| Этап | Длительность | Что проверяют |
|---|---|---|
| HR-скрининг | 30–45 мин | Опыт с DWH/ETL/витринами, уровень SQL, мотивация, формат работы, готовность к темпу Яндекса |
| SQL и data design | 45–60 мин | JOIN, GROUP BY, CTE, оконные функции; задачи на проверку целостности данных между источником и витриной |
| Моделирование DWH | 60–90 мин | Data Vault (Hub/Link/Satellite), звёздная схема, SCD, слои хранилища (ODS/DDS/DMT), Source-to-Target маппинг |
| Кейс по требованиям | 60–90 мин | Разбор бизнес-запроса на витрину/дашборд: источники, трансформации, метрики, edge cases, согласование с заказчиком |
| Поведенческое | 45 мин | Работа в кросс-функциональной команде, конфликты требований, управление ожиданиями заказчиков |
| Финал с руководителем | 30–45 мин | Подход к системному анализу в Data Mesh, вопросы о команде DWH Доставки, зона ответственности |
Обязательный минимум
Плюсом будет
Как устроены таблицы и джойны в SQL?
Таблицы — строки и столбцы с типами данных. JOIN объединяет по ключу: INNER — только совпадения, LEFT — все из левой + совпадения справа, FULL — все из обеих. Для проверки интеграций чаще LEFT JOIN + WHERE IS NULL.
Опыт написания SQL-запросов
Готовь 2–3 примера: проверка данных между источником и витриной, поиск дублей, агрегация с GROUP BY/HAVING, CTE для читаемости. Акцент на практику, не на теорию.
Как правильно использовать синтаксис BETWEEN в SQL?
BETWEEN включает обе границы. Подводный камень: `BETWEEN '2024-01-01' AND '2024-01-31'` не захватит timestamp после полуночи 31-го. Для дат лучше `>= start AND < end+1`.
Можно ли использовать одинаковые алиасы в разных JOIN?
Алиас действует в рамках одного SELECT. Повторное имя в другом JOIN допустимо, но создаёт путаницу. Лучше давать осмысленные имена: src, tgt, dim.
Какие ограничения (constraints) бывают в PostgreSQL?
NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK. Для DWH важны FK на уровне витрин и CHECK для валидации бизнес-правил при загрузке.
Совет: На DWH-собесе SQL-задачи часто про проверку данных: «найди записи в источнике, которых нет в витрине», «найди дубли по бизнес-ключу», «посчитай накопительный итог по пользователю».
Ловушка: SUM() OVER без ORDER BY даёт сумму по всей партиции, а не накопительную. Для running total нужен ORDER BY в окне.
Фишка: В Яндексе SQL проверяют на уровне уверенного пользователя: не нужен LeetCode, но JOIN + оконные функции + CTE обязательны.
Что такое Data Vault и зачем Hub, Link, Satellite?
Hub — бизнес-ключ + метаданные. Link — связь между хабами. Satellite — атрибуты с историей (insert-only). Цель: масштабируемость, audit trail, параллельная загрузка.
Чем Raw Vault отличается от Business Vault?
Raw Vault — точная копия источника с хешированием. Business Vault — бизнес-правила и вычисляемые поля. Витрины (Information Mart) — денормализованные данные для BI.
Что такое нормализация БД и зачем она нужна?
Разделение данных на таблицы для устранения избыточности (1NF–3NF). В DWH: 3NF/Inmon для EDW, денормализация (звёзды) для витрин. Нормализация — в DDS, денормализация — в DMT.
Чем витрина данных отличается от модели данных?
Модель (DDS) — нормализованная, для хранения и интеграции. Витрина (DMT) — денормализованная, заточена под конкретный бизнес-кейс/дашборд. Одна модель → несколько витрин.
Какие типы SCD вы знаете?
SCD1 — перезапись (без истории). SCD2 — новая строка с датами valid_from/valid_to (полная история). SCD3 — предыдущее значение в отдельном столбце. Для DWH чаще SCD2.
Совет: В вакансии явно указаны Data Vault, Anchor Modeling и «звёзды» — будь готов сравнить подходы и назвать, когда какой применять.
Ловушка: Data Vault не для прямых запросов аналитика — нужны витрины поверх. Не предлагай DV как конечный слой для BI.
Фишка: Hash keys в DV: MD5/SHA от business key. Hash diff — для определения «изменилось / нет» в satellite. Только INSERT, никогда UPDATE.
Какие знаешь атрибуты качества требований?
Полные, однозначные, проверяемые, согласованные, прослеживаемые, реализуемые, необходимые (SMART + IEEE 830). Для DWH добавь: источник данных, гранулярность, периодичность обновления.
Что такое User Story?
Формат: «Как [роль], я хочу [действие], чтобы [ценность]». Для data-команды дополняй acceptance criteria: источники, метрики, фильтры, SLA обновления.
В чём разница между функциональными и нефункциональными требованиями?
Функциональные — что система делает (метрики, поля, фильтры). Нефункциональные — как: latency обновления, объём данных, SLA, безопасность, производительность запросов.
Для чего используют BPMN?
Моделирование бизнес-процессов: события, задачи, шлюзы, потоки. Для SA DWH — описание процесса от запроса бизнеса до готовой витрины.
Для чего нужна диаграмма последовательности?
Показывает взаимодействие компонентов во времени. Для DWH: поток данных Source → Staging → ETL → Vault → Mart → BI.
Совет: На кейсе покажи структуру: бизнес-вопрос → метрики → источники → трансформации → витрина → acceptance criteria.
Ловушка: Не начинай с технического решения. Сначала уточни бизнес-вопрос, гранулярность, период, фильтры, потребителей.
Как вы проверяете, что витрина соответствует бизнес-требованиям?
Reconciliation (сверка сумм/количеств с источником), проверка NULL/дублей, граничные даты, spot-check выборок, acceptance criteria из требований.
Что такое профилирование данных?
Анализ структуры источника: типы, NULL-rate, дубли, распределения, нарушения FK. Делается до проектирования маппинга.
Как обрабатываете NULL в ETL-маппинге?
Явная политика: COALESCE для дефолтов, фильтрация, отдельный флаг is_null, исключение из агрегации. Документируй в S2T.
Чем ETL отличается от ELT?
ETL — трансформация до загрузки (классика on-prem). ELT — загрузка raw, трансформация в DWH (облачные MPP: Greenplum, ClickHouse).
Что такое колоночные базы данных и почему они лучше для аналитики?
Данные хранятся по столбцам, а не строкам. Быстрые агрегации, сжатие, column pruning. ClickHouse, Greenplum — типичные для DWH.
Совет: Опиши свой чеклист тестирования витрины: row count, sum reconciliation, uniqueness PK, freshness, sample records.
Фишка: В вакансии «тестирование и профилирование данных в ETL» — плюс. Подготовь конкретный пример из опыта (без персональных деталей, общий кейс).
Что такое Data Mesh?
Децентрализованная архитектура: данные — продукт домена. Кросс-функциональные команды владеют своими данными end-to-end. Принципы: domain ownership, data as product, self-serve platform, federated governance.
Какие знаешь виды архитектур?
Монолит, микросервисы, SOA, event-driven, lambda/kappa (streaming). Для DWH: Inmon (3NF EDW), Kimball (звёзды), Data Vault, Data Mesh.
Что такое микросервисная архитектура?
Независимые сервисы с собственными БД, общение через API/очереди. Для SA DWH важно понимать, что источники данных часто распределены.
Что такое принцип REST?
Stateless, ресурсы через URI, HTTP-методы (GET/POST/PUT/DELETE), представления (JSON). Нужно для понимания API-источников данных.
Какие знаешь HTTP статус-коды?
200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many, 500 Internal Error. Для SA — понимание при интеграции источников.
Фишка: Команда DWH Доставки работает именно в Data Mesh: ты будешь в доменной кросс-функциональной команде с бизнесом, DE, DA и BI.
Совет: Покажи, что понимаешь роль SA в Data Mesh: формализация требований домена, проектирование моделей, связь с платформой DWH.
Поиск расхождений между источником и витриной
Есть таблица-источник `orders_src(order_id, customer_id, amount, created_at)` и витрина `dm_orders(order_id, customer_id, amount, order_date)`. Найдите заказы, которые есть в источнике, но отсутствуют в витрине.
SELECT s.order_id, s.customer_id, s.amount, s.created_at FROM orders_src s LEFT JOIN dm_orders d ON s.order_id = d.order_id WHERE d.order_id IS NULL;
Сложность: O(n + m) при индексе на order_id
Накопительная сумма по пользователю
В таблице `payments(user_id, amount, paid_at)` для каждой транзакции нужен накопительный итог сумм пользователя на этот момент.
SELECT user_id, amount, paid_at,
SUM(amount) OVER (
PARTITION BY user_id
ORDER BY paid_at
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS running_total
FROM payments;Сложность: O(n log n) — сортировка в окне
Проектирование витрины для бизнес-запроса
Бизнес просит дашборд «Время доставки по зонам за последние 30 дней» с разбивкой по типу курьера (авто/пеший/велосипед). Опишите: источники, ключевые поля витрины, гранулярность, трансформации, SCD-подход.
Источники: orders (order_id, zone_id, courier_type, created_at), deliveries (order_id, delivered_at, status), zones (zone_id, zone_name). Витрина dm_delivery_time: - grain: 1 строка = 1 доставленный заказ - поля: order_id, zone_id, zone_name, courier_type, order_date, delivery_time_min (= delivered_at - created_at), is_on_time - фильтр: status = 'delivered', created_at >= current_date - 30 - SCD: не нужен (транзакционная витрина, пересчёт ежедневно) - проверки: delivery_time > 0, zone_id NOT NULL, reconciliation count с источником
Сложность: N/A — проектная задача
Объединение событий из двух источников
Есть `events_web(user_id, event_name, created_at)` и `events_app(user_id, event_name, created_at)`. Нужен общий поток событий для агрегации.
SELECT user_id, event_name, created_at, 'web' AS source FROM events_web UNION ALL SELECT user_id, event_name, created_at, 'app' AS source FROM events_app;
Сложность: O(n + m)
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| SQL | можешь написать LEFT JOIN для поиска расхождений, running total через SUM OVER, CTE для читаемости |
| Data Vault | можешь объяснить Hub/Link/Satellite, hash keys, insert-only, raw vs business vault |
| Моделирование | можешь спроектировать витрину: grain, ключи, SCD, источники, трансформации |
| Требования | можешь формализовать бизнес-запрос в acceptance criteria с метриками и SLA |
| Тестирование | можешь описать чеклист проверки витрины: reconciliation, NULL, дубли, freshness |
| Data Mesh | можешь объяснить роль SA в доменной команде и принципы Data Mesh |
| Behavioral | есть 3 STAR-истории про DWH-проекты, конфликты и работу с заказчиками |
В день собеседования