Глоссарий — Data Governance

Структурированный каталог бизнес-терминов организации с согласованными определениями, владельцами и связями. Является ключевым артефактом Data Governance, обеспечивающим единое понимание терминологии между бизнесом и IT.

Свод знаний по управлению данными, разработанный DAMA International. DMBOK2 определяет 11 областей знаний Data Management и является де-факто стандартом для построения программ Data Governance. Русское издание ISBN 978-5-9693-0404-8.

11 областей DMBOK2:
1. Data Governance
2. Data Architecture
3. Data Modeling & Design
4. Data Storage & Operations
5. Data Security
6. Data Integration & Interoperability
7. Document & Content Management
8. Reference & Master Data
9. Data Warehousing & BI
10. Metadata Management
11. Data Quality

Набор данных, имеющий ценность для организации и управляемый как актив. Data Asset имеет владельца, описание в каталоге, определённый жизненный цикл и метрики качества. Примеры: таблица клиентов, реестр транзакций, справочник продуктов.

Совокупность ценностей, практик и поведения в организации, определяющих отношение к данным как к стратегическому активу. Зрелая Data Culture предполагает, что сотрудники принимают решения на основе данных, заботятся о качестве данных и соблюдают политики управления.

Логическая область бизнес-данных, объединённая общей предметной областью. Типичные домены: Клиенты, Продукты, Финансы, HR. В Data Mesh каждый домен управляется автономной командой, которая владеет и поставляет свои data products.

Типичные Data Domains:
- Customer Domain: клиенты, контакты, сегменты
- Product Domain: продукты, SKU, категории
- Finance Domain: транзакции, счета, бюджеты
- HR Domain: сотрудники, должности, оргструктура

Область, изучающая моральные аспекты сбора, хранения и использования данных. Включает вопросы предвзятости алгоритмов, прозрачности принятия решений, справедливого использования персональных данных и социальной ответственности при работе с данными.

Структурированный набор принципов, политик, процессов и инструментов для организации программы управления данными. Фреймворк определяет роли, ответственности, метрики и механизмы контроля. Примеры: DAMA-DMBOK, DCAM, кастомные корпоративные фреймворки.

Система принятия решений, определения прав и ответственности в отношении данных как актива организации. Data Governance устанавливает политики, стандарты, роли и процессы, обеспечивающие качество, безопасность, доступность и соответствие данных требованиям бизнеса и регуляторов.

Компоненты программы Data Governance:
1. Организационная структура (Data Council, Stewards)
2. Политики и стандарты (naming conventions, retention)
3. Процессы (data request, issue resolution)
4. Метрики (DQ scores, compliance rates)
5. Технологии (data catalog, quality tools)

Способность сотрудников читать, понимать, создавать и коммуницировать с помощью данных. Программы Data Literacy включают обучение работе с аналитическими инструментами, интерпретации метрик и критическому осмыслению данных.

Комплекс процессов по планированию, разработке, исполнению и контролю операций с данными на протяжении всего их жизненного цикла. Data Management шире Data Governance: включает архитектуру, хранение, интеграцию, качество, безопасность и другие области DMBOK2.

Описание того, как организация структурирует людей, процессы и технологии для управления данными. Определяет степень централизации (централизованная, федеративная, гибридная), распределение ролей и взаимодействие между командами.

Три модели:
1. Централизованная: единая команда DG, единые стандарты
2. Федеративная: доменные команды, координация через совет
3. Гибридная: центральные политики + доменная автономия

Формальный документ, определяющий правила и ограничения в отношении данных организации. Политики покрывают классификацию данных, контроль доступа, retention, качество, конфиденциальность. Каждая политика имеет владельца, область применения и механизм контроля исполнения.

Пример политики retention:
{
  "policy": "data-retention-policy",
  "version": "2.1",
  "rules": [
    {
      "data_class": "PII",
      "retention_period": "3 years",
      "action_after": "anonymize"
    },
    {
      "data_class": "logs",
      "retention_period": "90 days",
      "action_after": "delete"
    }
  ]
}

Набор фундаментальных утверждений, определяющих отношение организации к данным. Принципы формируют основу для политик и стандартов. Типичные принципы: данные -- актив организации, данные должны быть доступны, данные должны быть защищены.

Согласованные правила именования, форматирования, хранения и обмена данными. Стандарты обеспечивают единообразие и интероперабельность данных между системами. Включают naming conventions, форматы дат, кодовые справочники, стандарты API.

Примеры стандартов:
- Naming: snake_case для таблиц и колонок
- Даты: ISO 8601 (2024-01-15T10:30:00Z)
- Валюта: ISO 4217 (RUB, USD, EUR)
- Страны: ISO 3166-1 alpha-2 (RU, US, DE)
- API: OpenAPI 3.0 для описания контрактов

Долгосрочный план организации по использованию данных как стратегического актива для достижения бизнес-целей. Стратегия определяет приоритеты, инвестиции, целевую архитектуру и roadmap программы Data Management.

Экономическая и стратегическая ценность данных для организации. Оценка Data Value включает прямые выгоды (оптимизация решений, монетизация), снижение рисков (compliance, качество) и возможности (новые продукты, аналитика).

Принцип, определяющий конечную ответственность за данные. В отличие от responsibility (исполнение), accountability означает, что конкретное лицо отвечает за результат и последствия решений в отношении данных. В RACI-матрице Accountable -- всегда один человек.

Специалист, преобразующий бизнес-требования в технические спецификации для данных. В контексте Data Governance участвует в определении бизнес-правил качества данных, формулировании требований к отчётности и валидации бизнес-глоссария.

Руководитель высшего звена, ответственный за стратегию данных и программу Data Governance в организации. CDO определяет Data Strategy, руководит Data Office, отчитывается перед CEO/COO. В зрелых организациях CDO входит в C-suite.

Организационная модель, в которой все решения по управлению данными принимаются центральной командой (Data Governance Office). Обеспечивает единообразие стандартов, но может замедлять принятие решений и плохо масштабироваться в крупных организациях.

Ответственный за защиту персональных данных. Обязательная роль по GDPR (статья 37) и 152-ФЗ для организаций, обрабатывающих персональные данные в значительном объёме. DPO контролирует compliance, консультирует по DPIA и взаимодействует с регуляторами.

Специалист, проектирующий целевую архитектуру данных организации: модели данных, схемы интеграции, стандарты хранения, потоки данных. Обеспечивает техническое соответствие Data Strategy и поддерживает Enterprise Data Model.

Управляющий орган программы Data Governance, состоящий из представителей бизнеса и IT. Принимает стратегические решения по политикам данных, приоритетам инициатив, разрешению конфликтов. Обычно заседает ежемесячно или ежеквартально.

Техническая роль, ответственная за физическое хранение, обслуживание и техническую защиту данных. В отличие от Data Owner (определяет политики) и Data Steward (контролирует качество), Custodian реализует технические меры: бэкапы, шифрование, контроль доступа на уровне инфраструктуры.

Специалист, реализующий пайплайны данных, ETL/ELT процессы и инфраструктуру для хранения и обработки данных. В программе Data Governance Data Engineer имплементирует технические стандарты, data quality checks и механизмы lineage.

Формальный орган принятия решений по вопросам управления данными. Включает Data Owners, CDO, представителей бизнес-подразделений и IT. Утверждает политики, стандарты, разрешает эскалации и контролирует KPI программы Data Governance.

Постоянное подразделение, координирующее операционную деятельность программы Data Governance. Обеспечивает исполнение политик, обучение сотрудников, мониторинг метрик качества, поддержку Data Stewards и подготовку отчётов для Data Council.

Роль, ответственная за операционное управление качеством данных в конкретном домене. Data Steward определяет бизнес-правила качества, курирует метаданные, разрешает проблемы с данными, поддерживает бизнес-глоссарий. Является связующим звеном между бизнесом и IT.

Обязанности Data Steward:
- Определение и документирование бизнес-правил качества
- Курирование метаданных в каталоге данных
- Разрешение инцидентов качества данных
- Участие в Data Quality Review
- Поддержка бизнес-глоссария домена
- Валидация изменений схемы данных

Организационная модель, в которой решения по данным принимаются на уровне доменов, а центральная команда координирует общие стандарты и политики. Баланс между автономией доменных команд и единообразием на уровне организации. Подход Data Mesh основан на федеративной модели.

Инструмент распределения ответственности: Responsible (исполняет), Accountable (отвечает за результат), Consulted (консультирует), Informed (информируется). В Data Governance RACI определяет роли для каждого процесса: кто создаёт политику, кто утверждает, кого привлекают.

RACI для процесса Data Quality Review:
| Действие           | Owner | Steward | Engineer | Council |
|---------------------|-------|---------|----------|---------|
| Определение правил  |   A   |    R    |    C     |    I    |
| Имплементация       |   I   |    C    |    R     |         |
| Мониторинг          |   I   |    R    |    C     |    I    |
| Эскалация           |   A   |    R    |    C     |    I    |

Бизнес-роль, несущая конечную ответственность (accountability) за данные конкретного домена. Data Owner утверждает политики доступа, определяет допустимые уровни качества, авторизует изменения схемы. Обычно это руководитель бизнес-подразделения.

Полный перечень всех data assets организации с атрибутами: расположение, владелец, классификация, уровень качества, зависимости. Inventory является основой для Impact Analysis и планирования Data Governance инициатив.

Процесс и инструменты для поиска, идентификации и понимания доступных данных в организации. Автоматизированная Data Discovery включает сканирование источников, профилирование данных, классификацию PII и построение связей между datasets.

Визуализация и отслеживание пути данных от источника до потребителя через все трансформации. Data Lineage отвечает на вопросы: откуда пришли данные, как они трансформировались, кто их использует. Критически важен для Impact Analysis и debugging.

Пример lineage цепочки:
PostgreSQL (orders) 
  -> dbt model (stg_orders) 
    -> dbt model (fct_orders) 
      -> BI Dashboard (Revenue Report)

При изменении схемы orders lineage показывает
все downstream зависимости, которые затронет изменение.

Процесс оценки последствий изменений в данных, схемах или процессах на downstream системы и потребителей. Использует Data Lineage для определения всех затронутых объектов. Обязателен перед миграциями, изменениями схемы и выводом источников из эксплуатации.

Централизованный реестр метаданных организации с поиском, классификацией и социальными функциями. Каталог данных объединяет технические метаданные (схемы, lineage), бизнес-метаданные (описания, владельцы, теги) и операционные метаданные (свежесть, качество). Примеры: OpenMetadata, DataHub, Alation.

Структура записи в каталоге:
{
  "name": "customers",
  "type": "table",
  "database": "analytics_prod",
  "owner": "customer-domain-team",
  "tags": ["PII", "tier-1"],
  "description": "Мастер-таблица клиентов",
  "columns": 24,
  "freshness": "updated daily at 03:00 UTC",
  "quality_score": 94.5
}

Согласованные правила описания метаданных: обязательные атрибуты, форматы, словари терминов. Стандарты обеспечивают единообразие метаданных между системами и командами. Включают schema для описания таблиц, API-контрактов, дашбордов.

Область DMBOK2, охватывающая сбор, хранение, интеграцию и использование метаданных. Включает автоматический сбор технических метаданных из источников, ручное курирование бизнес-метаданных, обеспечение актуальности и согласованности.

Данные о данных. Описывают структуру, происхождение, качество, правила использования и контекст данных. Метаданные делятся на технические (схемы, типы), бизнес-метаданные (описания, владельцы, glossary) и операционные (время обновления, объём, статистика выполнения).

Три типа метаданных таблицы customers:

Технические:
  - schema: public
  - columns: id (bigint), email (varchar), created_at (timestamp)
  - indexes: idx_customers_email (unique)

Бизнес:
  - owner: Customer Domain Team
  - description: Мастер-таблица клиентов
  - classification: PII

Операционные:
  - row_count: 2,450,000
  - last_updated: 2024-01-15T03:00:00Z
  - avg_query_time: 120ms

Метаданные, описывающие текущее состояние и историю операций с данными: время последнего обновления, объём записей, длительность ETL-процессов, статистика запросов, история изменений схемы.

Централизованное хранилище версионированных схем данных (Avro, Protobuf, JSON Schema). Обеспечивает совместимость между производителями и потребителями данных, валидацию сообщений, эволюцию схем без breaking changes.

# Confluent Schema Registry API

# Регистрация схемы
curl -X POST http://schema-registry:8081/subjects/orders-value/versions \
  -H 'Content-Type: application/json' \
  -d '{"schema": "{\"type\": \"record\", ...}"}'

# Проверка совместимости
curl http://schema-registry:8081/compatibility/subjects/orders-value/versions/latest

Детальное описание структуры данных: таблицы, колонки, типы, ограничения, допустимые значения, связи. В отличие от каталога данных, словарь фокусируется на технической структуре. Может быть частью каталога или отдельным артефактом.

Механизм категоризации data assets с помощью меток. Теги бывают пользовательские (проектные, доменные) и системные (PII, Confidential, Tier-1). Классификация обеспечивает автоматическое применение политик: PII-tagged данные автоматически маскируются при экспорте.

Иерархия классификации:
- Public (открытые данные)
- Internal (внутренние)
- Confidential (конфиденциальные)
  - PII (персональные данные)
  - Financial (финансовые)
  - Health (медицинские)
- Restricted (ограниченный доступ)
  - Credentials (учётные данные)
  - Encryption Keys (ключи шифрования)

Метаданные, описывающие физическую структуру данных: схемы таблиц, типы колонок, индексы, foreign keys, партиции, форматы файлов. Автоматически собираются инструментами каталога данных через crawlers и API интеграции.

Метаданные, придающие бизнес-контекст данным: описания на человеческом языке, владельцы, домены, теги, связи с бизнес-процессами. Курируются вручную Data Stewards и бизнес-пользователями в каталоге данных.

Измерение качества данных, определяющее степень соответствия данных реальному состоянию объекта. Точный email -- это email, действительно принадлежащий клиенту. Точность проверяется сравнением с эталонным источником (reference data validation).

-- Проверка точности: email format
SELECT COUNT(*) AS invalid_emails
FROM customers
WHERE email NOT LIKE '%_@_%.__%';

-- Проверка точности: cross-reference с внешним источником
SELECT c.inn, c.company_name
FROM customers c
LEFT JOIN egrul_reference r ON c.inn = r.inn
WHERE r.inn IS NULL; -- INN не найден в ЕГРЮЛ

Автоматическое выявление отклонений в данных от ожидаемых паттернов: резкие изменения объёмов, появление unexpected значений, нарушение статистических распределений. Используется в Data Observability для раннего обнаружения проблем качества.

Измерение качества данных, определяющее долю заполненных (non-null) значений в обязательных полях. Полнота 95% означает, что 5% записей имеют пропуски в обязательных полях. Измеряется на уровне колонок, таблиц и datasets.

-- Измерение полноты по колонкам
SELECT
  COUNT(*) AS total,
  COUNT(email) AS email_filled,
  COUNT(phone) AS phone_filled,
  ROUND(100.0 * COUNT(email) / COUNT(*), 1) AS email_completeness_pct,
  ROUND(100.0 * COUNT(phone) / COUNT(*), 1) AS phone_completeness_pct
FROM customers;

Измерение качества данных, определяющее отсутствие противоречий между связанными данными в разных системах или таблицах. Пример нарушения: клиент помечен как active в CRM, но deleted в биллинге.

-- Проверка согласованности между системами
SELECT
  crm.customer_id,
  crm.status AS crm_status,
  billing.status AS billing_status
FROM crm_customers crm
JOIN billing_customers billing ON crm.customer_id = billing.customer_id
WHERE crm.status != billing.status;

Процесс обнаружения и исправления ошибок, дубликатов, неполных и некорректных данных. Включает стандартизацию форматов, дедупликацию, заполнение пропусков, исправление опечаток. Может быть автоматическим (правила) или ручным (Data Steward review).

Способность понимать состояние данных и data pipelines в реальном времени. По аналогии с observability в DevOps, включает пять столпов: freshness, volume, schema changes, distribution, lineage. Инструменты: Monte Carlo, Elementary, Soda.

5 столпов Data Observability:
1. Freshness: данные обновились вовремя?
2. Volume: количество записей в ожидаемом диапазоне?
3. Schema: структура не изменилась неожиданно?
4. Distribution: значения в допустимом распределении?
5. Lineage: зависимости не нарушены?

Анализ данных для выявления их структуры, содержания и качества: типы данных, распределения значений, паттерны, аномалии, уникальность, null rates. Профилирование -- первый шаг при подключении нового источника данных.

-- Базовое профилирование таблицы
SELECT
  COUNT(*) AS row_count,
  COUNT(DISTINCT customer_id) AS unique_customers,
  MIN(created_at) AS earliest,
  MAX(created_at) AS latest,
  AVG(order_total) AS avg_total,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY order_total) AS median_total,
  COUNT(*) FILTER (WHERE order_total IS NULL) AS null_totals
FROM orders;

Область DMBOK2, охватывающая планирование, мониторинг и улучшение качества данных. Качество измеряется по 6+ dimensions: accuracy, completeness, consistency, timeliness, validity, uniqueness. Высокое качество данных -- необходимое условие для data-driven решений.

Визуальное представление метрик качества данных: агрегированные scores по доменам, тренды, алерты, топ проблемных таблиц. Служит инструментом мониторинга для Data Stewards и отчётности для Data Council.

Стандартные категории для оценки качества данных. Базовые 6 dimensions по DMBOK2: Accuracy, Completeness, Consistency, Timeliness, Validity, Uniqueness. Расширенные dimensions: Integrity, Relevance, Accessibility, Interpretability.

Количественные показатели, измеряющие качество данных по каждому dimension. Метрики выражаются в процентах или абсолютных числах и агрегируются в Data Quality Score. Типичная метрика: completeness_rate = (non_null / total) * 100.

Формализованные проверки, определяющие допустимые значения, форматы и связи данных. Правила реализуются как автоматические тесты в dbt, Great Expectations или custom скриптах. Каждое правило привязано к dimension и имеет severity (critical, warning, info).

# Great Expectations rule (YAML)
expectations:
  - expectation_type: expect_column_values_to_not_be_null
    kwargs:
      column: customer_id
    meta:
      dimension: completeness
      severity: critical

  - expectation_type: expect_column_values_to_be_between
    kwargs:
      column: order_total
      min_value: 0
      max_value: 1000000
    meta:
      dimension: validity
      severity: warning

Соглашение об уровне обслуживания, определяющее минимально допустимые показатели качества данных. Пример: completeness >= 99%, freshness <= 1 hour, accuracy >= 95%. Нарушение SLA триггерит алерты и эскалацию к Data Owner.

Open-source фреймворк для валидации, профилирования и документирования данных. Позволяет описывать ожидания (expectations) к данным в декларативном формате и автоматически проверять их на каждом запуске pipeline.

# Great Expectations Checkpoint
import great_expectations as gx

context = gx.get_context()

# Определение expectation suite
suite = context.add_expectation_suite("orders_suite")
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="total", min_value=0
    )
)

# Запуск валидации
result = context.run_checkpoint("orders_checkpoint")
print(f"Success: {result.success}")

Систематический процесс определения первоначальной причины проблемы с качеством данных. Использует Data Lineage, логи ETL, историю изменений схемы для отслеживания момента и причины деградации. Метод: 5 Whys, Fishbone diagram.

Измерение качества данных, определяющее доступность данных в требуемые сроки. Данные считаются timely, если они обновлены к моменту принятия решения. Метрика: время между событием и его отражением в аналитической системе (data latency).

Измерение качества данных, определяющее отсутствие дубликатов. Каждая запись должна представлять уникальную сущность. Нарушение уникальности приводит к искажению агрегатов и дублированию коммуникаций с клиентами.

-- Поиск дубликатов по email
SELECT email, COUNT(*) AS cnt
FROM customers
GROUP BY email
HAVING COUNT(*) > 1
ORDER BY cnt DESC;

Измерение качества данных, определяющее соответствие значений заданным правилам формата, диапазона и допустимых значений. Валидный email содержит @ и домен, валидный возраст находится в диапазоне 0-150.

-- dbt test для validity
-- tests/assert_valid_status.sql
SELECT *
FROM {{ ref('stg_orders') }}
WHERE status NOT IN ('pending', 'confirmed', 'shipped', 'delivered', 'cancelled');

Федеральный закон Российской Федерации "О персональных данных". Определяет правила сбора, хранения, обработки и передачи персональных данных граждан РФ. Требует согласия субъекта, уведомления Роскомнадзора, локализации данных на территории РФ.

Хронологическая запись всех действий с данными: кто, когда, что изменил, с какого IP, по какому основанию. Audit Trail обязателен для compliance (GDPR Article 30, 152-ФЗ) и расследования инцидентов безопасности.

Система учёта, хранения и проверки согласий субъектов данных на обработку их персональных данных. Consent Management отслеживает: что согласовано, когда, на какие цели, с каким сроком действия. Обязателен по GDPR (Article 7) и 152-ФЗ.

Передача персональных данных в другие юрисдикции. GDPR разрешает передачу в страны с адекватным уровнем защиты или при наличии Standard Contractual Clauses. 152-ФЗ требует локализации данных граждан РФ на территории РФ.

Формальная оценка рисков обработки персональных данных, обязательная по GDPR Article 35 при высоком риске для субъектов данных. DPIA оценивает необходимость обработки, пропорциональность, риски для прав субъектов и меры митигации.

Инцидент безопасности, в результате которого персональные данные стали доступны неавторизованным лицам. GDPR требует уведомления регулятора в течение 72 часов (Article 33) и субъектов данных при высоком риске (Article 34). 152-ФЗ также требует уведомления Роскомнадзора.

Процесс категоризации данных по уровню конфиденциальности и критичности. Типичные уровни: Public, Internal, Confidential, Restricted. Классификация определяет требования к хранению, доступу, шифрованию и retention для каждого уровня.

Матрица классификации:
| Уровень       | Шифрование | Доступ       | Retention  | Пример             |
|---------------|------------|--------------|------------|--------------------||
| Public        | Нет        | Все          | Unlimited  | Пресс-релизы       |
| Internal      | At rest    | Сотрудники   | 5 лет      | Внутренние отчёты  |
| Confidential  | At rest+transit | По ролям  | 3 года     | PII клиентов       |
| Restricted    | At rest+transit+app | Named users | 1 год  | Ключи шифрования   |

Принцип GDPR (Article 5), требующий обрабатывать только те персональные данные, которые необходимы для конкретной цели. Запрещает сбор данных "про запас". Реализуется через review процессов сбора данных и удаление избыточных полей.

Юридически обязывающий договор между контроллером и процессором данных, определяющий условия обработки персональных данных. Обязателен по GDPR Article 28. Включает цель обработки, категории данных, меры безопасности, обязательства сторон.

Политики и процессы, определяющие сроки хранения данных и действия по их истечении (архивация, анонимизация, удаление). Retention определяется регуляторными требованиями, бизнес-необходимостью и классификацией данных.

Физическое лицо, чьи персональные данные обрабатываются. Субъект данных обладает правами по GDPR (доступ, исправление, удаление, переносимость, ограничение обработки) и 152-ФЗ (отзыв согласия, получение информации об обработке).

Регламент Европейского Союза о защите персональных данных, действующий с мая 2018 года. Устанавливает правила обработки ПД граждан ЕС, права субъектов данных, обязанности контроллеров и процессоров, штрафы до 4% глобального оборота или 20 млн евро.

Данные, позволяющие прямо или косвенно идентифицировать физическое лицо. Прямые PII: ФИО, паспорт, ИНН, email. Косвенные PII: IP-адрес, геолокация, поведенческие данные. PII требуют повышенной защиты и контроля доступа.

Категории PII:

Прямые идентификаторы:
- ФИО, дата рождения
- Паспортные данные, ИНН, СНИЛС
- Email, номер телефона
- Номер банковской карты

Косвенные идентификаторы:
- IP-адрес, cookies
- Геолокация
- Идентификатор устройства
- Поведенческий профиль

Любая информация, относящаяся к определённому или определяемому физическому лицу (статья 3 152-ФЗ). Шире понятия PII: включает биометрические данные, данные о здоровье, политические взгляды, религиозные убеждения (специальные категории по GDPR Article 9).

Систематическая оценка рисков для приватности при внедрении новой системы, процесса или технологии. Шире DPIA: включает не только compliance, но и этические, репутационные и операционные риски. Рекомендуется проводить до начала разработки.

Принцип, требующий учитывать защиту приватности на этапе проектирования систем, а не добавлять её постфактум. 7 принципов Ann Cavoukian: проактивность, приватность по умолчанию, встроенность, win-win, полная защита жизненного цикла, прозрачность, уважение к пользователю.

Обеспечение соответствия обработки данных законодательным и нормативным требованиям: GDPR, 152-ФЗ, PCI DSS, SOX, HIPAA и отраслевым стандартам. Compliance требует документирования процессов, регулярных аудитов, обучения сотрудников.

Право субъекта данных требовать удаления своих персональных данных (GDPR Article 17). Организация обязана удалить данные, если они более не нужны для первоначальной цели, отозвано согласие, или данные обрабатывались незаконно. Исключения: юридические обязательства, архивирование в общественных интересах.

Модель контроля доступа, основанная на атрибутах субъекта (должность, отдел, уровень допуска), объекта (классификация, владелец) и среды (время, IP-адрес). Более гибкая, чем RBAC: позволяет создавать fine-grained политики без комбинаторного взрыва ролей.

# OPA Rego policy (ABAC)
package data.access

allow {
  input.user.department == input.resource.domain
  input.user.clearance >= input.resource.classification_level
  input.environment.time_hour >= 9
  input.environment.time_hour <= 18
}

Совокупность механизмов, ограничивающих доступ к данным на основе политик безопасности. Включает аутентификацию (кто ты), авторизацию (что тебе разрешено) и аудит (что ты сделал). Реализуется через RBAC, ABAC, ACL или их комбинации.

Неизменяемый журнал всех действий с данными и системами: вход, запросы, изменения, экспорт. Audit Log должен содержать: who (пользователь), what (действие), when (время), where (источник), why (основание). Хранится отдельно от основных данных с ограниченным доступом.

Преобразование данных в нечитаемый формат с использованием криптографических алгоритмов. At rest (на диске): AES-256. In transit (при передаче): TLS 1.3. At application level: field-level encryption для отдельных колонок с PII.

-- PostgreSQL: Transparent Data Encryption (TDE)
-- Шифрование at rest
ALTER SYSTEM SET ssl = on;
ALTER SYSTEM SET ssl_cert_file = '/etc/ssl/server.crt';

-- Field-level encryption с pgcrypto
INSERT INTO customers (email_encrypted)
VALUES (pgp_sym_encrypt('[email protected]', 'encryption_key'));

Стратегия и инструменты для обнаружения и предотвращения несанкционированного копирования, передачи или утечки конфиденциальных данных. DLP мониторит email, облачные хранилища, USB-устройства, API и применяет политики блокировки или маскирования.

Система управления цифровыми идентификациями пользователей: создание, аутентификация, авторизация, деактивация учётных записей. Включает Single Sign-On (SSO), Multi-Factor Authentication (MFA), federation. Инструменты: Keycloak, Okta, Azure AD.

Процессы и инструменты для генерации, хранения, ротации и отзыва криптографических ключей. Ключи хранятся в Hardware Security Module (HSM) или Key Management Service (KMS). Ротация ключей -- обязательная практика для compliance.

Техника замены реальных конфиденциальных данных на реалистичные, но фиктивные значения. Отличается от анонимизации (обезличивания) тем, что маскированные данные сохраняют формат и статистические свойства. Применяется для тестовых, аналитических и demo-сред.

-- Динамическое маскирование в PostgreSQL
CREATE VIEW masked_customers AS
SELECT
  id,
  CONCAT(LEFT(first_name, 1), '***') AS first_name,
  CONCAT(LEFT(last_name, 1), '***') AS last_name,
  REGEXP_REPLACE(email, '(.)(.*)(@.*)', '\1***\3') AS email,
  CONCAT('***-***-', RIGHT(phone, 4)) AS phone
FROM customers;

-- Результат: И*** П*** i***@mail.ru ***-***-1234

Подход, при котором политики безопасности и доступа описываются программным кодом, версионируются в Git и применяются автоматически. Позволяет тестировать политики в CI/CD, делать review через pull requests и обеспечивать audit trail изменений.

# OPA Rego: Row-Level Security policy
package data.rls

# Пользователь видит только данные своего региона
filter_rows[row] {
  row := data.customers[_]
  row.region == input.user.region
}

# Администраторы видят все данные
filter_rows[row] {
  row := data.customers[_]
  input.user.role == "admin"
}

Повышенный уровень доступа к данным и системам, предоставляемый администраторам, DBA и service accounts. Privileged Access Management (PAM) включает just-in-time доступ, сессионную запись, ротацию паролей и approval workflows.

Модель контроля доступа, при которой разрешения назначаются ролям, а роли -- пользователям. Наиболее распространённая модель в корпоративных системах. Роли определяются по функциям (analyst, engineer, admin) или доменам (finance_viewer, hr_editor).

-- PostgreSQL RBAC
CREATE ROLE data_analyst;
CREATE ROLE data_engineer;

-- Аналитик: только чтение
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO data_analyst;

-- Инженер: чтение + запись
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA staging TO data_engineer;

-- Назначение ролей пользователям
GRANT data_analyst TO alice;
GRANT data_engineer TO bob;

Механизм ограничения доступа к данным на уровне отдельных строк таблицы. Пользователь видит только те записи, которые соответствуют его политике (по региону, отделу, роли). Встроен в PostgreSQL, Snowflake, BigQuery.

-- PostgreSQL Row-Level Security
ALTER TABLE customers ENABLE ROW LEVEL SECURITY;

CREATE POLICY region_isolation ON customers
  FOR SELECT
  USING (region = current_setting('app.user_region'));

-- Пользователь из региона 'RU' видит только клиентов из RU
SET app.user_region = 'RU';
SELECT * FROM customers; -- только записи с region='RU'

Формальный документ, определяющий правила защиты данных: классификация, контроль доступа, шифрование, мониторинг, реагирование на инциденты. Security Policy является частью программы Data Governance и обновляется при изменении регуляторных требований.

Замена конфиденциальных данных на уникальный токен (ссылку), не имеющий самостоятельной ценности. В отличие от шифрования, токен не может быть обратно преобразован без доступа к токен-хранилищу. Применяется для номеров карт (PCI DSS) и PII.

Архитектурный подход к безопасности, при котором ни один пользователь или система не получает доверие по умолчанию, даже внутри корпоративной сети. Каждый запрос аутентифицируется, авторизуется и шифруется. Принцип: never trust, always verify.

Сравнение уровня зрелости Data Governance организации с отраслевыми эталонами или конкурентами. Benchmarking помогает определить разрывы, приоритизировать улучшения и обосновать инвестиции перед руководством.

Пятиуровневая шкала зрелости процессов: 1-Initial (хаотичный), 2-Managed (базовые процессы), 3-Defined (стандартизированные), 4-Quantitatively Managed (измеряемые), 5-Optimizing (непрерывное улучшение). Применяется для оценки зрелости Data Governance.

Уровни зрелости Data Governance:

Level 1 - Initial:
  Нет формальных процессов, данные в silos

Level 2 - Managed:
  Базовые политики, назначены Data Owners

Level 3 - Defined:
  Стандарты, каталог данных, метрики качества

Level 4 - Quantitatively Managed:
  SLA качества, автоматический мониторинг, KPI

Level 5 - Optimizing:
  ML-driven quality, proactive governance, data marketplace

Формальная оценка текущего состояния Data Management capabilities организации по областям DMBOK2. Результат -- heatmap зрелости по 11 областям с рекомендациями по приоритетным улучшениям.

Фреймворк управления данными от DAMA International, описывающий 11 областей знаний и их взаимосвязи. DMBOK2 (второе издание, 2017) -- де-факто стандарт для построения программ Data Management. Русское издание переведено при участии DAMA Russia.

Модель оценки зрелости Data Management от EDM Council, ориентированная на финансовый сектор. DCAM оценивает 8 компонентов: стратегия, программа, бизнес-кейс, архитектура, технология, качество, стандарты, governance. Включает 37 capabilities и 140+ sub-capabilities.

Количественная оценка текущего уровня развития процессов управления данными. Измеряется по шкале CMM (1-5) для каждой области DMBOK2. Результат -- baseline для планирования улучшений и отслеживания прогресса программы Data Governance.

Enterprise Data Management Council -- глобальная ассоциация, продвигающая стандарты управления данными в финансовой индустрии. Разработчик DCAM, Cloud Data Management Capabilities (CDMC) и бенчмарков зрелости Data Management.

Оценка зрелости именно компонента Data Governance (не всего Data Management): наличие ролей, политик, метрик, процессов эскалации, культуры данных. Governance Maturity -- один из компонентов общей Data Management Maturity.

Международный стандарт качества данных, определяющий требования к мастер-данным и обмену данными. ISO 8000 формализует процессы обеспечения качества, требования к provenance и синтаксической/семантической точности данных.

Фреймворк для оценки текущего состояния и планирования развития Data Management capabilities. Модели зрелости определяют уровни (обычно 1-5), критерии для каждого уровня и путь перехода. Примеры: CMM, DCAM, Stanford Data Governance Maturity Model.

Коммерческая платформа для каталога данных и Data Governance. Сильные стороны: NLP-поиск, collaborative features, integration с BI-инструментами, automated data quality. Популярна в enterprise-сегменте.

Open-source data discovery engine, разработанный в Lyft. Фокус на поиске и навигации по данным. Использует Neo4j для хранения графа метаданных и Elasticsearch для поиска. Проект передан в LF AI & Data Foundation.

Open-source фреймворк для управления метаданными и Data Governance в экосистеме Hadoop. Обеспечивает классификацию данных, lineage, поиск по метаданным. Часть Apache Software Foundation, популярен в on-premise Hadoop-инсталляциях.

Modern data workspace, объединяющий каталог данных, lineage, collaboration и governance. Отличается UX-ориентированным подходом, embedded collaboration (как Google Docs для данных) и интеграцией с modern data stack (dbt, Snowflake, Looker).

Enterprise-платформа для Data Intelligence: каталог данных, бизнес-глоссарий, Data Governance workflows, privacy management, data quality. Лидер в Gartner Magic Quadrant для Active Metadata Management. Популярна в крупных корпорациях и финансовом секторе.

Open-source платформа метаданных от LinkedIn (Acryl Data). Обеспечивает каталогизацию, lineage, governance, observability. Архитектура на основе event-driven metadata graph. Поддерживает 50+ интеграций с источниками данных.

Open-source сервис для сбора, хранения и визуализации Data Lineage, разработанный в WeWork. Реализует OpenLineage стандарт. Интегрируется с Apache Airflow, Spark, dbt для автоматического сбора lineage информации.

Платформа для Data Observability, обеспечивающая мониторинг качества данных и data pipelines. Автоматически обнаруживает аномалии в freshness, volume, schema changes и распределениях. Концепция: Data Reliability Engineering по аналогии с SRE.

Open-source движок для policy-as-code, использующий язык Rego для описания политик доступа. OPA принимает решения авторизации на основе входных данных и политик. Применяется для RBAC/ABAC в микросервисах, Kubernetes, API gateways и Data Governance.

# OPA Rego: политика доступа к данным
package data.governance

# Разрешить доступ к PII только для ролей с clearance
allow {
  input.action == "read"
  input.resource.classification != "PII"
}

allow {
  input.action == "read"
  input.resource.classification == "PII"
  input.user.clearance >= 3
}

# Запись только для Data Engineers
allow {
  input.action == "write"
  input.user.role == "data_engineer"
}

Open-source платформа для Data Discovery, Governance, Quality и Collaboration. Объединяет каталог данных, lineage, data quality, glossary, policies и team collaboration. Выбрана для лабораторных работ курса благодаря низким требованиям к ресурсам (4-6 GB RAM).

Open-source инструмент для трансформации данных в аналитических хранилищах. dbt реализует принцип analytics-as-code: модели на SQL, тесты качества, документация, lineage. В контексте Data Governance: dbt tests обеспечивают автоматическую валидацию правил качества данных.

# dbt model с тестами качества
# models/staging/stg_orders.sql
SELECT
  order_id,
  customer_id,
  status,
  total
FROM {{ source('raw', 'orders') }}
WHERE order_id IS NOT NULL

# schema.yml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled']
      - name: total
        tests:
          - dbt_utils.expression_is_true:
              expression: ">= 0"