Data Modelling, Governance, Metadata, Lineage & Lifecycle — DE Interview Prep

Моделирование данных, Управление, Метаданные, Линедж и Жизненный цикл — Подготовка к DE-интервью

Fast-revision cheatsheet for Data Engineering interviews. Tailored for Senior/Lead DE.

Шпаргалка для быстрого повторения перед Data Engineering интервью. Заточена под Senior/Lead DE.

macro · survey · forecast · vendor-supplied time-series макро · опросы · прогнозы · временные ряды от вендоров modelling · metadata · lineage · lifecycle · CDMP моделирование · метаданные · линедж · жизненный цикл · CDMP

Your edge Strong on modelling + dbt. Light on formal governance vocabulary — this sheet front-loads governance, lineage, DMBOK/CDMP so you can speak the language confidently. Your Career.io shared customer/account spine across 8 brands is a textbook MDM + conformed-dimension + governance story — use it.

Твоё преимущество Силён в моделировании + dbt. Слабее в формальной терминологии управления данными — эта шпаргалка выносит вперёд governance, lineage, DMBOK/CDMP, чтобы ты уверенно говорил на языке. Твой общий spine customer/account в Career.io на 8 брендов — учебный пример MDM + conformed-dimension + governance — используй его.

1 · Dimensional Modelling — Star, Snowflake, Facts & Grain1 · Размерное моделирование — звезда, снежинка, факты и зерно

Core vocabulary

Основная терминология

Fact: numeric measurements at a defined grain (e.g. the value of a series for a period/vintage). Types: transaction, periodic snapshot, accumulating snapshot.
Dimension: descriptive context you filter/group by (series metadata, geography, source, frequency).
Grain: the exact meaning of one fact row. Declare it first, in one English sentence. Wrong grain = double-counting & fan-out joins (the #1 modelling bug).
Surrogate key: meaningless system-generated key (stable). Natural key: business code (can change/collide). Join on surrogate, keep natural as attribute.
Conformed dimension: a shared dimension used by multiple facts → lets you compare across subject areas. The "spine."
Degenerate (ID on fact), junk (bag of flags), role-playing (one date used as period / vintage / publish date) dimensions.

Факт (Fact): числовые измерения на определённом зерне (например, value временного ряда за период/версию). Типы: транзакция, периодический снимок, накапливающий снимок.
Измерение (Dimension): описательный контекст для фильтрации/группировки (метаданные ряда, география, источник, частота).
Зерно (Grain): точный смысл одной строки факта. Объявляй его первым делом, одним предложением. Неверное зерно = двойной подсчёт и множественные join'ы (ошибка моделирования №1).
Суррогатный ключ (Surrogate key): бессмысленный системный ключ (стабилен). Натуральный ключ (Natural key): бизнес-код (может меняться/коллидировать). JOIN по суррогату, натуральный оставь как атрибут.
Согласованное измерение (Conformed dimension): общее измерение для нескольких фактов → позволяет сравнивать по предметным областям. «Позвоночник» (spine).
Вырожденные (ID на факте), мусорные (мешок флагов), ролевые (одна дата используется как период / версия / дата публикации) измерения.

Star vs Snowflake

Звезда vs Снежинка

Aspect	Star	Snowflake
Dimensions	Denormalized (1 hop)	Normalized into sub-dims (multi-hop)
Joins / read speed	Fewer joins, faster, simpler BI	More joins, slower, more complex
Redundancy	Higher	Lower
Dim maintenance	Harder if dim is huge/volatile	Easier; shared sub-dims reused
Default?	Yes — esp. on columnar warehouses (Snowflake/BigQuery make denorm cheap)	Only for very large/volatile dims

Аспект	Звезда	Снежинка
Измерения	Денормализованы (1 хоп)	Нормализованы в под-измерения (много хопов)
JOIN'ы / скорость чтения	Меньше JOIN'ов, быстрее, проще для BI	Больше JOIN'ов, медленнее, сложнее
Избыточность	Выше	Ниже
Обслуживание измерений	Сложнее, если измерение огромное/изменчивое	Легче; общие под-измерения переиспользуются
По умолчанию?	Да — особенно на колоночных хранилищах (Snowflake/BigQuery делают денорм. дешёвой)	Только для очень больших/изменчивых измерений

Interviewer will probe "Define the grain of an economics fact." → "One row per series, per reference period, per vintage." Lead with grain before drawing tables.

О чём спросит интервьюер «Определи зерно факта экономических данных.» → «Одна строка на ряд, на отчётный период, на версию.» Начинай с зерна, прежде чем рисовать таблицы.

Sketch: economics star + bi-temporal fact

Набросок: звезда экономических данных + битемпоральный факт

dim_geography dim_source/vendor \ / dim_series ---- fct_observation ---- dim_date (role-playing) (freq, unit, | - reference_period (valid time) SA flag, | - vintage_date (knowledge time) geo, source) | value, release_id, revision_number GRAIN: 1 row per (series_id, reference_period, vintage_date) append-only — every revision is a NEW row, never UPDATE

dim_geography dim_source/vendor \ / dim_series ---- fct_observation ---- dim_date (ролевое) (freq, unit, | - reference_period (valid time) SA flag, | - vintage_date (knowledge time) geo, source) | value, release_id, revision_number ЗЕРНО: 1 строка на (series_id, reference_period, vintage_date) append-only — каждая ревизия — НОВАЯ строка, никогда UPDATE

2 · Slowly Changing Dimensions & Vintages2 · Медленно меняющиеся измерения и версии ★

SCD types at a glance

Типы SCD в один взгляд

Type	Behaviour	Use when
Type 1	Overwrite, no history	Fix bad data nobody audits (typo in country name)
Type 2	New row per change; full history	Must answer "what did this look like at time T"
Type 3	Keep a "previous value" column	One step of history is enough
Type 4	Separate history table	Keep current table thin
Type 6	1 + 2 + 3 hybrid	Want current + historical + prior-value

Тип	Поведение	Когда использовать
Type 1	Перезапись, нет истории	Исправление плохих данных, которые никто не аудирует (опечатка в названии страны)
Type 2	Новая строка на изменение; полная история	Надо отвечать на "как это выглядело в момент T"
Type 3	Хранить колонку "предыдущее значение"	Достаточно одного шага истории
Type 4	Отдельная таблица истории	Держать текущую таблицу тонкой
Type 6	Гибрид 1 + 2 + 3	Нужны текущие + исторические + предыдущие значения

SCD2 columns: surrogate_key, business_key, valid_from, valid_to, is_current, often version. Use half-open intervals [valid_from, valid_to) to avoid overlap bugs.

Колонки SCD2: surrogate_key, business_key, valid_from, valid_to, is_current, часто version. Используй полуоткрытые интервалы [valid_from, valid_to), чтобы избежать багов пересечения.

The vintage / revision problem (the heart of Economics Data)

Проблема версий/ревизий (сердце экономических данных)

A single (series, period) observation has many values over time: Q1 GDP printed in April, revised in May, rewritten at the annual benchmark. Clients need both "latest" and "as-it-was-on-date-X" (point-in-time / vintage).

Одно наблюдение (series, period) имеет много значений во времени: ВВП за Q1 опубликован в апреле, пересмотрен в мае, переписан при годовом бенчмарке. Клиенты нуждаются в обоих: «последнее» и «каким-оно-было-на-дату-X» (point-in-time / vintage).

Model it bi-temporally — two time axes:

Моделируй это битемпорально — две временные оси:

Valid time = reference_period: the economic period the number describes (2026-Q1).
Knowledge / transaction time = vintage_date: when the value became known to us (the release/as-of date).

Valid time = reference_period: экономический период, который описывает число (2026-Q1).
Knowledge / transaction time = vintage_date: когда значение стало нам известно (дата релиза / as-of).

Physical model = append-only ledger = effectively SCD Type 2 on the measurement. Never UPDATE; each revision is a new row.

Физическая модель = append-only журнал = фактически SCD Type 2 на измерении. Никогда UPDATE; каждая ревизия — новая строка.

▶ Show the two serving views (SQL)Показать два сервисных view (SQL)

-- LATEST view: newest known value per period
SELECT series_id, reference_period, value
FROM fct_observation
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY series_id, reference_period
  ORDER BY vintage_date DESC) = 1;

-- POINT-IN-TIME view: value as known on :as_of (no look-ahead bias)
SELECT series_id, reference_period, value
FROM fct_observation
WHERE vintage_date <= :as_of_date
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY series_id, reference_period
  ORDER BY vintage_date DESC) = 1;

Gotchas — raise these unprompted Seasonal adjustment changes the whole history; base-year rebasing; benchmark revisions rewrite years; frequency mismatches; real vs nominal; "preliminary / second / final" release tags; look-ahead bias if backtests use latest instead of PIT.

Подводные камни — говори об этом без подсказок Сезонная корректировка меняет всю историю; перебазирование; бенчмарковые ревизии переписывают годы; несовпадения частоты; реальное vs номинальное; теги релизов «предварительный / вторичный / финальный»; look-ahead bias, если бэктесты используют latest вместо PIT.

Your story "At Meta I built append-only, late-arriving-tolerant facts over ~3.6B events/day. Revisioned macro series are the same shape with a knowledge-time axis added — I'd treat vintage as a first-class SCD2 column rather than overwriting." For reference data I'd use dbt snapshots (SCD2 out of the box).

Твоя история «В Meta я строил append-only, late-arriving-tolerant факты на ~3.6B событий/день. Ревизионируемые макроэкономические ряды — та же форма с добавленной осью времени знания — я бы трактовал vintage как полноценную SCD2-колонку, а не перезаписывал бы.» Для справочных данных я бы использовал dbt snapshots (SCD2 из коробки).

3 · Normalization vs Denormalization3 · Нормализация vs Денормализация

	Normalization (3NF)	Denormalization
Goal	Eliminate redundancy, integrity	Optimize reads, avoid joins
Fits	OLTP / write-heavy / sources	OLAP / analytics / read-heavy
Risk	Many joins	Update anomalies, drift, storage

	Нормализация (3NF)	Денормализация
Цель	Устранить избыточность, целостность	Оптимизировать чтения, избежать JOIN'ов
Подходит	OLTP / write-heavy / источники	OLAP / аналитика / read-heavy
Риск	Много JOIN'ов	Аномалии обновления, рассинхронизация, хранилище

Normal forms ladder: 1NF (atomic values) → 2NF (no partial-key dependency) → 3NF (no transitive dependency).

Лестница нормальных форм: 1NF (атомарные значения) → 2NF (нет частичной зависимости от ключа) → 3NF (нет транзитивной зависимости).

Best practice: normalized core → denormalized serving layer rebuilt from it (the dbt staging → marts pattern). Denormalize derived from a single source so it can't drift.

Лучшая практика: нормализованное ядро → денормализованный serving-слой, пересобранный из него (паттерн dbt staging → marts). Денормализуй производное из единого источника, чтобы оно не могло рассинхронизироваться.

4 · Data Vault 2.0 (study-gap — foundational)4 · Data Vault 2.0 (пробел в знаниях — основополагающая тема)

An integration / raw-history modelling pattern. Not for direct querying — you build dimensional marts on top of it. Insert-only, highly auditable, integrates many sources by business key → well suited to multi-vendor economics data & revisions.

Паттерн моделирования для интеграции / сырой истории. Не для прямых запросов — ты строишь размерные marts поверх него. Insert-only, высокая аудируемость, интегрирует много источников по бизнес-ключу → отлично подходит для экономических данных от разных вендоров и ревизий.

Construct	Holds	Note
Hub	Business keys (e.g. series_id) + hash key	One row per unique key
Link	Relationships between hubs	Hash-keyed associations
Satellite	Descriptive, time-stamped attributes	Insert-only — this is where SCD2 / vintage history lives

Конструкт	Содержит	Замечание
Hub	Бизнес-ключи (например, series_id) + хеш-ключ	Одна строка на уникальный ключ
Link	Связи между хабами	Ассоциации с хеш-ключами
Satellite	Описательные атрибуты с временными метками	Insert-only — здесь живёт SCD2 / история версий

Hub(series) --< Link(series_source) >-- Hub(source) | | Sat(series_meta) Sat(source_meta) [insert-only, time-stamped = built-in vintage history]

Hub(series) --< Link(series_source) >-- Hub(source) | | Sat(series_meta) Sat(source_meta) [insert-only, time-stamped = встроенная история версий]

One-liner if asked "Vault for the integrated, audited raw layer; star schemas as the serving layer. Vault's insert-only satellites are basically purpose-built for vintages." Trade-off: more tables, not query-friendly, steeper learning curve.

Если спросят одной строкой «Vault для интегрированного, аудируемого сырого слоя; звёздные схемы как serving-слой. Insert-only satellites в Vault — по сути заточены под версии.» Компромисс: больше таблиц, не удобен для запросов, крутая кривая обучения.

5 · Metadata Management & Data Catalogs5 · Управление метаданными и каталоги данных

Three flavours of metadata

Три вида метаданных

Type	Examples
Technical	Schemas, types, partitions, formats, locations
Business	Definitions, owners, glossary, classification, semantics ("what does this series mean")
Operational	Freshness, row counts, run history, quality scores, lineage

Тип	Примеры
Technical	Схемы, типы, партиции, форматы, расположения
Business	Определения, владельцы, глоссарий, классификация, семантика («что означает этот ряд»)
Operational	Свежесть, число строк, история запусков, оценки качества, линедж

Data catalog = searchable inventory of assets + metadata. Enables discovery ("is there already a CPI series?"), trust (owner/freshness/quality), governance (classification/access), and onboarding.

Каталог данных (Data catalog) = поисковый инвентарь активов + метаданные. Обеспечивает поиск («есть ли уже ряд CPI?»), доверие (владелец/свежесть/качество), управление (классификация/доступ) и онбординг.

Tools: DataHub, OpenMetadata, Collibra, Alation, Atlan, Unity Catalog. (At Meta, the internal catalog plays this role.)

Инструменты: DataHub, OpenMetadata, Collibra, Alation, Atlan, Unity Catalog. (В Meta эту роль играет внутренний каталог.)

Why a senior cares Without a catalog, knowledge lives in heads → duplicate datasets & tech debt proliferate — exactly what the JD wants modernized.

Почему это важно для сеньора Без каталога знания живут в головах → дублирующиеся датасеты и технический долг множатся — именно то, что нужно модернизировать.

6 · Data Lineage6 · Линедж данных ★

Lineage = documented flow of data from source → every transform → consumption. Answers "where did this number come from" and "what breaks if I change this."

Линедж (Lineage) = задокументированный поток данных от источника → все трансформации → потребление. Отвечает на «откуда это число» и «что сломается, если я это изменю».

	Table-level	Column-level
Granularity	Dataset A → B → dashboard C	`fct.value = stg.raw * fx_rate`
Good for	Orchestration / dependency graph	Precise impact analysis of a schema change

	Table-level	Column-level
Гранулярность	Датасет A → B → дашборд C	`fct.value = stg.raw * fx_rate`
Для чего	Оркестрация / граф зависимостей	Точный анализ влияния изменения схемы

Why it matters — say all four

Почему это важно — говори обо всех четырёх

Trust / explainability: client asks "why did this GDP print change?" → trace to vendor revision.
Impact analysis: before changing a vendor mapping, see every downstream field / feed.
Root-cause / incident response: bad value appears → walk back to the broken upstream node.
Governance / compliance: provenance, retention, access must follow the data.

Доверие / объяснимость: клиент спрашивает «почему это значение ВВП изменилось?» → трейсим до ревизии вендора.
Анализ влияния: перед изменением маппинга вендора посмотри все downstream-поля / фиды.
Root-cause / реагирование на инциденты: появилось плохое значение → пройдись назад до сломанного upstream-узла.
Управление / соответствие: происхождение, хранение, доступ должны следовать за данными.

Produced by: parsing SQL (dbt column-level lineage via DAG + manifest.json), orchestration capture (Airflow), or a catalog (OpenMetadata, DataHub, Collibra, Atlan).

Создаётся: парсингом SQL (dbt column-level lineage через DAG + manifest.json), захватом оркестрации (Airflow) или каталогом (OpenMetadata, DataHub, Collibra, Atlan).

Gotcha Manually-maintained lineage rots. Argue for automatically derived lineage from code / query logs.

Подводный камень Вручную поддерживаемый линедж устаревает. Настаивай на автоматически выводимом линедже из кода / логов запросов.

Your story "The 6.2B-record entity-resolution fix at Meta was fundamentally a lineage problem — I traced which of 100+ downstream metrics & ML features consumed the broken join to scope the blast radius. Column-level lineage turns that from archaeology into a query."

Твоя история «Фикс entity-resolution на 6.2B записей в Meta был по сути проблемой линеджа — я отследил, какие из 100+ downstream-метрик и ML-фичей потребляли сломанный join, чтобы оценить радиус поражения. Column-level lineage превращает это из археологии в запрос.»

7 · Data Profiling7 · Профилирование данных

Profiling = analyzing data to understand structure, content & quality before/while modelling. Profiling feeds your DQ tests: it defines the expected ranges/domains you later assert.

Профилирование (Profiling) = анализ данных для понимания структуры, содержимого и качества до/во время моделирования. Профилирование питает DQ-тесты: оно определяет ожидаемые диапазоны/домены, которые ты потом проверяешь.

Dimension	What you measure
Structure	Types, formats, lengths, patterns
Content	Min/max/mean, distributions, distinct counts, null/blank rate, outliers
Relationships	Candidate keys (uniqueness), FK validity, cardinality, functional dependencies

Измерение	Что измеряешь
Структура	Типы, форматы, длины, паттерны
Содержимое	Min/max/mean, распределения, число distinct, процент null/blank, выбросы
Связи	Кандидаты в ключи (уникальность), валидность FK, кардинальность, функциональные зависимости

Tools: SQL (COUNT DISTINCT, GROUP BY, histograms), pandas .describe(), Great Expectations profiler, dbt_profiler, ydata-profiling.

Инструменты: SQL (COUNT DISTINCT, GROUP BY, гистограммы), pandas .describe(), Great Expectations profiler, dbt_profiler, ydata-profiling.

Vendor quirks to hunt Sentinel values (-999, 9999), mixed date formats, encoding issues, silently changed units, blanks-as-zero.

Особенности вендоров, которые надо выявить Sentinel-значения (-999, 9999), смешанные форматы дат, проблемы кодировки, молча изменённые единицы измерения, blanks-as-zero.

8 · Data Governance8 · Управление данными (Data Governance) ★

Data governance = the system of decision rights & accountabilities for data: who can do what, with which data, under what circumstances. Spans ownership, quality, metadata, security/access, privacy, retention, standards.

Data governance = система прав на решения и ответственностей за данные: кто может делать что, с какими данными, при каких обстоятельствах. Охватывает владение, качество, метаданные, безопасность/доступ, конфиденциальность, хранение, стандарты.

Role	RACI	Typically
Owner	Accountable — decisions, funding, sign-off	Business / domain leader
Steward	Responsible — day-to-day quality, definitions, metadata, issues	The DE / analyst (you)

Роль	RACI	Обычно
Owner	Accountable — решения, финансирование, подпись	Бизнес / руководитель домена
Steward	Responsible — ежедневное качество, определения, метаданные, проблемы	DE / аналитик (ты)

Data contracts

Контракты данных (Data contracts)

Explicit, versioned agreement between producer & consumer: schema, semantics, SLAs (freshness/volume), quality guarantees, change/deprecation policy. Enforced in CI (schema diff fails the build) so producers can't silently break consumers.

Явное, версионируемое соглашение между продюсером и консьюмером: схема, семантика, SLA (свежесть/объём), гарантии качества, политика изменений/устаревания. Проверяется в CI (diff схемы фейлит билд), чтобы продюсеры не могли тихо ломать консьюмеров.

Retention & access

Хранение и доступ

Retention/lifecycle: how long kept, archival, deletion (legal + cost). For vintages you typically never delete — PIT history is the product.
Access: least privilege, RBAC, classification (public/internal/restricted), entitlements.

Retention/lifecycle: как долго хранится, архивирование, удаление (юридически + цена). Для версий обычно никогда не удаляешь — PIT-история и есть продукт.
Доступ: минимальные привилегии, RBAC, классификация (публичное/внутреннее/ограниченное), права.

Your governance story (use it!) "At Career.io I ran a governance program without the label: forcing 8 brands onto a shared customer/account spine meant agreeing canonical definitions, ownership of the master entity, and conformed dimensions so board-level KPIs reconciled instead of double-counting. That's MDM + conformed dimensions + stewardship. The next maturity step is making those agreements explicit data contracts in CI — the direction I'd bring here."

Твоя governance-история (используй её!) «В Career.io я вёл программу управления данными без ярлыка: принудительный общий spine customer/account на 8 брендов означал согласование канонических определений, владения мастер-сущностью и conformed dimensions, чтобы KPI уровня совета директоров сходились, а не двойным счётом. Это MDM + conformed dimensions + stewardship. Следующий шаг зрелости — сделать эти соглашения явными контрактами данных в CI — то направление, которое я бы привнёс сюда.»

Embedding DQ into pipelines

Встраивание DQ в пайплайны

Validate at boundaries: on ingest (contract check), after transform (business rules), before publish (gate).

Валидируй на границах: при ingest (проверка контракта), после transform (бизнес-правила), перед publish (gate).

Check class	Examples
Schema / structural	Column presence, types, not-null, enum domains, drift detection
Volume / freshness	Row count in band, partition arrived on SLA
Statistical / profiling	Ranges, distribution drift, null %, uniqueness, RI
Domain rules	GDP growth plausible, FX > 0, sum-of-parts = total

Класс проверок	Примеры
Схема / структура	Наличие колонок, типы, not-null, enum-домены, детекция дрейфа
Объём / свежесть	Число строк в диапазоне, партиция прибыла по SLA
Статистика / профилирование	Диапазоны, дрейф распределения, % null, уникальность, RI
Доменные правила	Рост ВВП разумен, FX > 0, сумма частей = целое

Tools: dbt tests (unique, not_null, accepted_values, relationships, dbt_expectations), Great Expectations / Soda, custom Python anomaly detection.

Инструменты: dbt tests (unique, not_null, accepted_values, relationships, dbt_expectations), Great Expectations / Soda, кастомная детекция аномалий на Python.

Circuit-breaker pattern Quarantine bad partition → don't publish → alert (routed by ownership) → remediate/backfill. Distinguish blocking vs warning severity.

Паттерн circuit-breaker Карантин плохой партиции → не публикуй → алерт (роутится по владельцу) → исправь/backfill. Различай блокирующую vs предупреждающую серьёзность.

DAMA's 6 DQ dimensions Completeness, Accuracy, Consistency, Validity, Timeliness, Uniqueness. Operationalize each as a testable metric tracked over time.

6 измерений DQ по DAMA Completeness (полнота), Accuracy (точность), Consistency (согласованность), Validity (валидность), Timeliness (своевременность), Uniqueness (уникальность). Операционализируй каждое как проверяемую метрику, отслеживаемую во времени.

Data lifecycle stages

Стадии жизненного цикла данных

create/ingest → store → process/transform → use/serve → archive → destroy/retain └──────── governance · security · metadata apply at EVERY stage ────────┘

создание/ingest → хранение → обработка/transform → использование/serve → архив → уничтожение/retain └──────── governance · security · metadata применяются на КАЖДОЙ стадии ────────┘

For vintages: ingest → validate → model (revisions) → serve (latest + PIT) → archive old vintages to cold storage → rarely delete (PIT history is the product), entitlement-aware access.

Для версий: ingest → валидация → модель (ревизии) → serve (latest + PIT) → архив старых версий в холодное хранилище → редко удаляешь (PIT-история и есть продукт), доступ с учётом прав.

9 · DAMA-DMBOK & CDMP9 · DAMA-DMBOK и CDMP CORE

DAMA = Data Management Association International. DMBOK = Data Management Body of Knowledge — its reference framework.
Drawn as the DAMA Wheel: Data Governance at the hub, spokes = Architecture, Data Modelling & Design, Storage & Ops, Security, Integration & Interoperability, Document & Content, Reference & Master Data, Warehousing & BI, Metadata, Data Quality.
CDMP = Certified Data Management Professional — DAMA's certification, exam based on DMBOK. Tiers: Associate / Practitioner / Master / Fellow (gated by exam score, e.g. 60 / 70 / 80%).

DAMA = Data Management Association International. DMBOK = Data Management Body of Knowledge — эталонный фреймворк.
Рисуется как Колесо DAMA: Data Governance в центре, спицы = Architecture, Data Modelling & Design, Storage & Ops, Security, Integration & Interoperability, Document & Content, Reference & Master Data, Warehousing & BI, Metadata, Data Quality.
CDMP = Certified Data Management Professional — сертификация DAMA, экзамен на основе DMBOK. Уровни: Associate / Practitioner / Master / Fellow (по баллам экзамена, например 60 / 70 / 80%).

How to answer "do you know CDMP?" "I know DMBOK as the vocabulary and operating model for what this role touches — governance, metadata, MDM, lineage, quality. I've practised most of these hands-on; CDMP would formalize the framework and I'd be glad to pursue it. It maps almost 1:1 to this JD." Signal willingness; don't overclaim a cert you don't hold.

Как отвечать на «знаете ли CDMP?» «Я знаю DMBOK как терминологию и операционную модель для того, что затрагивает эта роль — governance, metadata, MDM, lineage, quality. Бóльшую часть этого я практиковал руками; CDMP формализовал бы фреймворк, и я с радостью его получу. Он почти 1:1 совпадает с этим JD.» Сигналь готовность; не приписывай себе сертификат, которого нет.

Master Data Management (MDM)

Управление мастер-данными (MDM)

Single, authoritative, deduplicated golden record for core entities (customer, account, security, geography), shared across systems. Components: matching/dedup, survivorship rules, reference data, stewardship workflow.

Единственная, авторитетная, дедуплицированная золотая запись (golden record) для ключевых сущностей (customer, account, security, география), разделяемая между системами. Компоненты: matching/dedup, правила выживания, справочные данные, процесс stewardship.

Your analogue: canonical series_id / geography / source dimensions shared across systems so the same indicator means the same thing everywhere. (= your Career.io spine, one level up.)

Твой аналог: каноничный series_id / география / измерения источника, разделяемые между системами, чтобы один индикатор означал одно и то же везде. (= твой spine из Career.io, уровнем выше.)

10 · Flip-to-Reveal Self-Quiz10 · Самопроверка (переворачивай карточку)

Tap a card to flip. Answer cold before flipping.

Нажми на карточку, чтобы перевернуть. Отвечай до переворота.

11 · Ranked Question Map11 · Карта вопросов по приоритетам

★ = top-5 most likely.

★ = топ-5 наиболее вероятных.

★Core Model a revisioned macro series (vintages / bi-temporal / SCD2).
★Core SCD Type 2 vs Type 1 — gotchas.
★Core Lineage: table vs column level, why it matters.
★Senior Embed DQ/validation into a pipeline (circuit breaker).
★Senior Governance: ownership, stewardship, data contracts.
Found Star vs snowflake; fact vs dimension; grain.
Found Normalization vs denormalization; surrogate vs natural key.
Senior Data Vault — when over dimensional?
Core Profiling; metadata & catalogs; lifecycle stages.
Core DMBOK / CDMP; MDM (Career.io spine).
Senior Vendor schema break; reconcile disagreeing vendors; impact analysis; idempotency; 90-day governance plan.

★Core Моделирование ревизионируемого макро-ряда (версии / bi-temporal / SCD2).
★Core SCD Type 2 vs Type 1 — подводные камни.
★Core Линедж: table vs column level, почему это важно.
★Senior Встраивание DQ/валидации в пайплайн (circuit breaker).
★Senior Governance: владение, stewardship, data contracts.
Found Звезда vs снежинка; факт vs измерение; зерно.
Found Нормализация vs денормализация; суррогатный vs натуральный ключ.
Senior Data Vault — когда вместо размерного?
Core Профилирование; метаданные и каталоги; стадии жизненного цикла.
Core DMBOK / CDMP; MDM (spine из Career.io).
Senior Ломка схемы вендора; согласование расходящихся вендоров; анализ влияния; идемпотентность; 90-дневный план governance.