Домены данных и владение
Введение
Когда организация определила governance-роли и создала Data Council, следующий вопрос: какими данными мы управляем и кому они принадлежат? Ответ начинается с определения Data Domain (доменов данных) — логических областей бизнес-данных, каждая из которых имеет владельца и набор правил управления.
Что такое Data Domain
Data Domain (домен данных) — это логическая область бизнес-данных, объединённая общей предметной областью. Типичные домены: Клиенты, Продукты, Финансы, HR. В подходе Data Mesh каждый домен управляется автономной командой.
Домен — это не просто набор таблиц. Это бизнес-понятие, которое включает:
- Данные — таблицы, API, файлы, относящиеся к этой области
- Владелец — бизнес-руководитель, отвечающий за данные домена
- Steward — специалист, контролирующий качество данных домена
- Правила — стандарты именования, качества, доступа для этого домена
- Потребители — кто использует данные этого домена
Зачем выделять домены
Без доменов ownership (владение данными) остаётся неопределённым. Классическая проблема: “кто отвечает за таблицу customers?” В маленькой компании ответ кажется очевидным, но когда customers используется в 5 системах и 3 командах, без формального домена начинаются конфликты.
Сценарий: DataTech маппит домены впервые
Сценарий: DataTech Solutions (ДатаТех Солюшенз)
В DataTech 200+ таблиц в PostgreSQL, десятки dbt-моделей в ClickHouse и 80 дашбордов в Metabase. Никто не знает, какие данные к какому бизнес-домену относятся. Data Engineer Алексей получил задачу провести первичный маппинг таблиц по доменам.
Алексей обнаружил типичный хаос:
- Таблица
ordersотносится и к домену “Клиенты”, и к “Финансы”- Таблица
etl_logs— это операционные данные, но кому они принадлежат?- Таблицы
dim_customerиfact_ordersв ClickHouse — аналитические копии, но с другим владельцем- 15% таблиц не подходят ни под один очевидный домен
Правила классификации по доменам
Для классификации таблиц по доменам используются простые правила на основе имён и префиксов:
| Паттерн | Домен | Примеры |
|---|---|---|
customer*, dim_customer* | Customer | customers, customer_addresses |
product*, inventor* | Product | products, product_categories, inventory |
gl_*, invoice*, payment* | Financial | gl_accounts, invoices, payments |
etl_*, job_*, system_* | Operational | etl_logs, job_schedules |
report_*, fact_* | Analytics | report_daily_sales, fact_orders |
Таблицы, не попадающие ни в один домен (orders, order_items), требуют ручного анализа. В DataTech orders решили отнести к Customer Domain, так как основной потребитель — команда клиентского сервиса.
Модели владения данными
Как определить, кто владеет данными каждого домена?
1. Бизнес-владение
Владелец данных (Data Owner) — руководитель бизнес-подразделения. Например, Head of Marketing владеет данными клиентов, CFO — финансовыми данными. Это рекомендуемая модель по DMBOK2.
2. Техническое владение
Data Engineer или DBA владеет таблицами. Эта модель типична для организаций Level 1, но создаёт проблему: технические специалисты не знают бизнес-контекст данных.
3. Совместное владение
Data Owner (бизнес) + Data Steward (операционный контроль) + Data Custodian (хранитель данных) (техническая инфраструктура). Три уровня ответственности для полного покрытия.
| Роль | Отвечает за | Пример решения |
|---|---|---|
| Data Owner | Бизнес-правила, приоритеты | ”Клиентские данные — конфиденциальные” |
| Data Steward | Качество, метаданные | ”Email должен быть валидным, null не допускается” |
| Data Custodian | Инфраструктура, хранение | ”Шифрование AES-256, бэкап каждые 6 часов” |
Практика: классификация Data Domain
В этом модуле вы встретите код-челлендж CC-02 (Data Domain Classifier): Python-функция, которая классифицирует список таблиц по доменам на основе паттернов имён. Задание использует те же правила классификации, что описаны выше, и проверяет корректность маппинга.
Классификация данных по уровням конфиденциальности
Помимо доменов, данные классифицируются по уровню конфиденциальности. Это критично для access control и compliance:
| Уровень | Описание | Примеры | Доступ |
|---|---|---|---|
| Public | Открытые данные | Каталог продуктов, публичные отчёты | Все |
| Internal | Внутренние данные | Метрики продаж, KPI | Сотрудники |
| Confidential | Конфиденциальные | Email клиентов, адреса | По запросу |
| Restricted | Ограниченные | Платёжные данные, медицинские записи | Только авторизованные |
Для сравнения: БиоГенезис Лаб
В BioGenesis Lab (БиоГенезис Лаб) классификация данных особенно критична: геномные данные пациентов — Restricted, клинические данные — Confidential, исследовательские результаты — Internal. Проблема: исследователи в JupyterHub имеют доступ ко всем датасетам без разграничения по проектам, что нарушает принцип наименьших привилегий.
Domain-Driven Governance
Современный подход к governance — domain-driven: каждый домен имеет автономную команду, которая управляет своими данными по единым стандартам. Этот подход близок к концепции Data Mesh:
- Доменная автономия — каждый домен сам определяет внутреннюю структуру данных
- Центральные стандарты — именование, классификация, качество едины для всех доменов
- Data Products — каждый домен предоставляет данные как продукт для других доменов
- Федеративное управление — Data Council координирует, но не диктует
Для DataTech на Level 1 domain-driven подход — целевое состояние на Level 3-4. Первый шаг — просто определить домены и назначить владельцев.
Итоги
- Data Domain — логическая область бизнес-данных с владельцем, steward и правилами
- Классификация таблиц по доменам использует паттерны имён и ручной анализ для неочевидных случаев
- Три модели владения: бизнес, техническое, совместное — рекомендуется совместное (Owner + Steward + Custodian)
- Данные классифицируются по конфиденциальности: Public, Internal, Confidential, Restricted
- Domain-driven governance — целевой подход для зрелых организаций (Level 3+)
В следующем уроке мы рассмотрим Business Case для Data Governance — как обосновать инвестиции в программу governance и оценить зрелость организации.