Введение
Этот урок — фиксированный набор «предполагается известным». Если хотя бы одно понятие из ниже описанных вызывает у вас «впервые слышу» — рекомендуем сначала пройти соответствующий урок data-governance-course. Каждая секция ссылается на конкретный DG-урок.
Курс не повторяет содержание DG-курса — он строит поверх. Если просто читать дальше без foundation, будет ощущение, что урок про контроли (M5) или evidence (M7) перескакивает шаги. Это потому что эти шаги — DG, и они уже у вас должны быть.
Что обязательно знать
1. Модель ownership: Owner / Steward / Custodian
Три роли с разной ответственностью за один data asset:
| Роль | Отвечает за | Типичный человек |
|---|---|---|
| Data Owner | Бизнес-смысл, retention policy, классификация, решения о доступе | VP / Director бизнес-юнита (CFO для финансовых данных, COO для operations) |
| Data Steward | Quality rules, поддержка бизнес-глоссария, разрешение споров | Senior analyst или знающий данные бизнес-партнёр |
| Data Custodian | Хранение, шифрование, backup, инфраструктура | Data platform engineer / DBA |
Ключевое правило: один Owner на каждый data asset. Два Owners — размытая ответственность. Без Owner — нет accountable party для регуляторного запроса.
В DRG-курсе мы расширим эту модель: для каждого CDE дополнительно появятся Control Owner (тот, кто реализует контроль), Evidence Producer (тот, кто генерирует артефакт для аудита) и Attester (тот, кто подписывает результат). Подробнее — M5 и M7.
См. DG-курс M1.3 «Организационная структура и ответственность» и M1.4 «Домены данных и владение».
2. Data Lineage
Data Lineage — это направленный граф «откуда» → «куда» для данных. Узлы — datasets / columns / fields. Рёбра — трансформации (SQL, dbt model, Spark job, ETL pipeline).
Уровни гранулярности:
- Dataset-level — таблица A питает таблицу B. Дёшево, обычно автоматически из metadata.
- Column-level — колонка
gross_amountизtripsпитает колонкуrevenue_eurвrevenue_daily. Дороже, требует SQL parsing или OpenLineage event с column-fact. - Field-level / record-level — конкретная запись из источника попадает в конкретную запись в target. Очень дорого; нужно только для специфических аудиторских кейсов.
В DRG-курсе lineage перестаёт быть «приятно иметь» и становится audit-evidence. Без lineage нельзя ответить на вопрос «откуда взялась цифра $40M ECL в материалах совета директоров за Q4» — а это первый вопрос ECB JST или senior manager Big 4 на walkthrough.
См. DG-курс M3.4 «Data Lineage: от dataset до column-level» и M3.5 «OpenLineage и Marquez».
3. 6 DQ-dimensions
Стандартная шкала Data Quality (DAMA-DMBOK 2 + DCAM v3):
| Dimension | Вопрос | Метрика |
|---|---|---|
| Accuracy | Соответствует ли значение реальности? | % записей, прошедших cross-reference check с authoritative source |
| Completeness | Все ли необходимые записи / атрибуты присутствуют? | 1 − (null rate) |
| Consistency | Совпадают ли значения через системы? | % записей, сверенных между source и downstream |
| Timeliness | Доступны ли данные вовремя для use case? | latency: max(arrival_time) − required_time |
| Uniqueness | Нет ли дубликатов? | 1 − (duplicate rate) |
| Validity | Соответствует ли значение формату / диапазону / domain? | % записей, прошедших schema/constraint validation |
Часто добавляют Integrity (referential — FK violations) как 7-ю, но 6-мерная шкала — мейнстрим.
В DRG-курсе каждый CDE получает DQ tolerances — конкретные пороги для каждой dimension, согласованные с Data Owner и зафиксированные в registry. Эти tolerances становятся основой для контролей. Подробнее — M5 и M7.
См. DG-курс M4.1 «Data Quality dimensions» и M4.2 «DQ-метрики и SLI».
4. Metadata Catalog
Metadata Catalog — центральная система, хранящая metadata о всех data assets организации: имя, owner, business definition, technical schema, ссылки lineage, теги, уровень классификации.
Категории metadata:
- Technical metadata — schema, типы, partition layout, storage location.
- Business metadata — определение, owner, steward, классификация, retention policy.
- Operational metadata — last update, row count, freshness, результаты DQ-check.
- Social metadata — usage, запросы, popularity, рейтинги.
Ландшафт вендоров (нет в DG-курсе, но важно для DRG): Atlan, Collibra, Alation, Informatica, IBM (Leaders в Gartner MQ Metadata Management Nov 2025). Open-source: OpenMetadata, DataHub, Apache Atlas (legacy).
В DRG-курсе catalog получает дополнительные обязанности: CDE flag, ссылки на контроли, ссылки на evidence-артефакты. Каталог становится evidence-якорем для аудита.
См. DG-курс M3.1 «Что такое metadata catalog», M3.2 «OpenMetadata: архитектура» и M3.3 «Atlan/Collibra/Alation: сравнение».
5. Бизнес-глоссарий
Бизнес-глоссарий (Business Glossary) — словарь бизнес-терминов с определениями, синонимами, owners и привязкой к техническим assets. Цель — устранить неоднозначность. Когда CFO говорит «active customer», CRM-команда говорит «active customer», но это два разных набора данных — это сбой глоссария.
Базовый артефакт glossary entry:
- Term (например, “Gross Booking Value”)
- Definition (1-2 предложения, утверждено Data Owner)
- Synonyms / aliases ("GMV", “Gross Merchandise Value”)
- Owner / Steward
- Связанные термины (что цитируется)
- Связанные технические assets (какие datasets / columns реализуют этот term)
- Effective date, статус (draft / approved / deprecated)
В DRG-курсе глоссарий становится основой для маппинга на регуляции. Когда BCBS 239 Principle 3 говорит «accurate aggregated risk data», вопрос «что именно есть risk data» решается через глоссарий, привязанный к CDE registry.
См. DG-курс M3.6 «Business Glossary и Reference Data».
6. Access Control: RBAC vs ABAC
RBAC (Role-Based Access Control) — права назначаются ролям; пользователи получают роли. Простая модель, легко аудитится, но негибкая: для тонких ограничений (по проекту, по региону, по чувствительности) требуется размножение ролей.
ABAC (Attribute-Based Access Control) — права вычисляются по атрибутам субъекта, ресурса и контекста через policies. Гибче, но сложнее в аудите и отладке. Используется через policy engines (OPA, Cedar) и data-specific frameworks (Snowflake row-access policies, Databricks Unity Catalog ABAC, BigQuery column-level security).
В DRG-курсе access control — это домен ITGC access management. Аудитор требует evidence: provisioning workflow, своевременность deprovisioning (обычно 24-48h после увольнения), periodic user-access reviews (квартально), segregation of duties. Подробнее — M5 (controls design) и M8 (operating model).
См. DG-курс M6.1 «RBAC: принципы и реализация» и M6.2 «ABAC и policy-as-code».
Чего DG-курс НЕ закрывает (и почему этот курс существует)
Перечисленные шесть зон — это необходимое, но не достаточное для regulatory-grade governance. DG строит операционную модель для повседневной работы с данными; DRG строит операционную модель для audit-grade работы с данными. Различие — на следующих осях:
| Аспект | DG-курс | DRG-курс |
|---|---|---|
| Цель governance | Сделать данные usable и trusted | Сделать данные defendable перед аудитором / регулятором |
| Охват assets | Все данные организации | CDE — критические элементы, обычно 50-400 на крупную организацию |
| DQ-checks | Регулярные, для self-service health | Контроли с design + operating effectiveness, retention доказательств |
| Lineage | Полезно для impact analysis | Обязательно для audit walkthrough; column-level от source до report |
| Каталог | Discovery + metadata | Плюс: CDE-flag, ссылки на контроли, evidence anchors |
| Роли | Owner / Steward / Custodian | Плюс: Control Owner, Evidence Producer, Attester |
| Регуляторы | Минимум (GDPR, 152-ФЗ упомянуты) | Центральная тема: SOX, BCBS 239, DORA, EU AI Act, PCI-DSS, AMLR, IFRS 9/17, MAR, FATF |
| Аудит | Внутренний DG-аудит | Внешний Big 4 + инспекции регуляторов (ECB JST, PCAOB, FCA, SEC) |
| Tooling | Catalog + DQ tool | Плюс: GRC platform (Workiva, ServiceNow GRC), policy engines, evidence stores |
Если DG-курс — про «данные как актив», DRG-курс — про «данные как audit-defendable evidence в регулируемой среде».
Краткое резюме: что вы должны знать к концу этого урока
Если хотя бы один пункт ниже вызывает «впервые слышу» — пройдите соответствующий DG-урок и вернитесь:
- Знаете роли Owner / Steward / Custodian и их типичных носителей.
- Понимаете dataset-level vs column-level lineage, знаете OpenLineage / Marquez как референсные инструменты.
- Можете назвать 6 DQ-dimensions и привести пример метрики для каждой.
- Знаете три категории metadata (technical / business / operational) и зачем catalog их хранит.
- Понимаете, чем бизнес-глоссарий отличается от data dictionary.
- Можете объяснить, когда RBAC достаточен и когда нужен ABAC.
Если все галки стоят — переходите к уроку 4 (знакомство со SwiftRide), и далее в M1.
Итоги
- DG-foundation требуется обязательно: Owner / Steward / Custodian, lineage, 6 DQ-dimensions, каталог, бизнес-глоссарий, RBAC/ABAC.
- Каждая из шести зон в DRG-курсе расширяется: добавляются Control Owner / Evidence Producer / Attester, ссылки на контроли в каталоге, DQ tolerances для каждого CDE, обязательный lineage source-to-report, глоссарий как regulatory anchor.
- DG-курс ≠ DRG-курс по аудитории (DG — все, DRG — audit-defensible setup), охвату assets (все vs CDE), строгости DQ (health vs evidence) и tooling.
- Дальше — знакомство со SwiftRide: бизнес-профиль, регуляторный охват, болевые точки, драматургия.