Управление данными

1) Зачем это нужно

Управление данными — это операционная система работы с данными, которая соединяет людей, процессы и технологии, чтобы данные были качественными, защищенными, понятными и пригодными к использованию. Для iGaming это критично из-за высокой регуляторики (KYC/AML, ответственная игра, платежи), объема событий (ставки, спины, транзакции) и межкомандной координации (продукт, риск, маркетинг, финансы).

• Надежность метрик (единственный источник истины для GGR, LTV, ARPPU).
• Снижение рисков (штрафы, утечки, инциденты).
• Ускорение аналитики и ML (предсказание оттока, антифрод, персонализация).
• Управляемая масштабируемость (новые рынки/бренды/провайдеры).

2) Модель управления (Operating Model)

• Централизованная: единая команда данных устанавливает стандарты и реализует процессы. Плюс — скорость унификации; минус — возможная «узкая горлышко».
• Федеративная: доменные команды владеют своими наборами, общие политики — центральные. Баланс скорости и контроля.
• Data Mesh: домены — как «продукты данных» с SLO/SLI, каталогом и контрактами; сильное самоуправление + платформенная поддержка.

Совет: стартуйте с «федеративной» модели и постепенно эволюционируйте к Mesh по зрелости.

3) Роли и ответственность

Data Governance Council: кросс-функциональный орган (C-level + домены) — утверждает политики, приоритеты, KPI.
CDO (Chief Data Officer): владелец стратегии данных, качества, каталога, культуры.
DPO/Privacy Lead: защита данных, соответствие регуляторике, DPIA, инциденты.
Data Owners (по доменам): финансы, продукт, маркетинг, риск, CRM — отвечают за семантику и качество наборов.
Data Stewards: операционные «хранители» — глоссарий, метаданные, DQ-правила, тикеты качества.
Security & Compliance: шифрование, контроль доступов, аудит.
Platform/Engineering: каталог, линейдж, схема-регистры, пайплайны, MDM, Lakehouse/DWH.
Analysts/Scientists: потребители и со-владельцы доменных требований к качеству и доступности.

RACI (укороченный пример)

Политики: CDO (A), Council (R/A), DPO (C), Sec (C), Owners (C), Eng (I)

Каталог/глоссарий: CDO (A), Stewards (R), Owners (C), Eng (C)

Доступы к данным: DPO/Sec (A), Owners (R), IT (R), HR (I)

Качество данных: Owners (A), Stewards (R), Eng (C), Analysts (C)

4) Артефакты Data Governance

1. Политика управления данными (umbrella-документ): принципы, роли, контроль, эскалации.
2. Каталог данных: реестр наборов (KYC, транзакции, игровые раунды, лимиты RG, платежи, провайдерские фиды), владельцы, теги, классификация.
3. Бизнес-глоссарий: определение GGR/Net Gaming Revenue, бонусная ответственность, churn, активный игрок, VIP-сегменты.
4. Линейдж (Data Lineage): от источника (провайдеры, PSP, CRM) до витрин/моделей — для доверия и аудита.
5. Data Contracts: формальные соглашения между продюсером и потребителем данных — схемы, типы, SLA качества/своевременности.
6. Schema Registry & Versioning: эволюция схем без поломок (семвер, депрекейшн-план, обратная/прямая совместимость).
7. MDM (Master Data Management): реестры игроков, брендов, провайдеров, игр (game_id, studio, RTP, волатильность).
8. Политика хранения/удаления: сроки, Legal Hold, анонимизация/псевдонимизация.
9. Паспорта наборов данных (Data Product Canvas): назначение, потребители, инциденты, метрики качества, SLO/SLI.

5) Процессы и практики

5.1 Качество данных (Data Quality)

• Полнота, точность, валидность, согласованность, своевременность, уникальность.
• DQ-правила в пайплайнах (например, сумма ставок ≥ сумма выигрышей, формат IBAN/карты, возраст ≥ 18+).
• DQ-алерты и тикеты: при регрессе — автоэскалация владельцу домена.

5.2 Управление доступом и классификация

Классы данных: Public / Internal / Confidential / Restricted (PII/финансовые).
RBAC/ABAC: роли по задачам (анализ, продукт, риск), атрибуты (страна, бренд, проект).
Принцип наименьших прав, временные доступы (Just-in-Time), журналирование запросов.

5.3 Приватность и безопасность

Шифрование in transit и at rest; управление ключами и ротация.
Псевдонимизация для аналитики, анонимизация для исследований/песочниц.
Политика минимизации: хранить только нужное, столько, сколько нужно.
Управление инцидентами: план реакции, уведомление заинтересованных сторон.

5.4 Жизненный цикл данных

Создание → Ингест → Хранение → Обогащение → Доступ/Аналитика → Архив/Удаление.
Для iGaming: события раундов (spin/hand), сессии, платежи, лимиты игрока, тикеты саппорта, жалобы, DSAR.

5.5 Хранение, удаление, Legal Hold

Графики хранения: операционные логи — X мес., отчетность — Y лет, PII — по минимуму и по закону.
Legal Hold: заморозка удаления при расследованиях/судах.
Техники удаления: soft-delete (метка), hard-delete, криптостирание, анонимизация.

5.6 Управление изменениями данных

RFC на изменения схем/контрактов, импакт-анализ по линейджу.
Backfill-процедуры и план миграций.
Версионирование витрин и моделей (v1 → v2 с параллельным прогоном и сравнением).

6) Архитектурные принципы

Lakehouse + DWH: сырые и очищенные слои, витрины для BI/ML; форматы с транзакционностью (ACID-таблицы).
Streaming + Batch: real-time антифрод/персонализация и ежедневная отчетность.
Data Contracts по шине событий: Avro/Proto, эволюция схем, идемпотентность.
Золотые наборы (Gold): сертифицированные таблицы для ключевых KPI (GGR, DAU, удержание).
Observability данных: мониторинг свежести, объема, дрифта признаков для ML.

7) Метрики и KPI Governance

% сертифицированных наборов в каталоге.
Покрытие глоссарием (доля терминов с владельцами).
DQ-SLA: своевременность (freshness), процент успешных проверок качества.
Время подключения нового источника/доменного продукта.
Кол-во инцидентов по данным и среднее время восстановления (MTTR).
Доля запросов на доступ, обработанных в SLO.
Удовлетворенность аналитиков/DS (опросы).

8) Инструменты (примерные категории)

Catalog & Glossary & Lineage: корпоративный каталог с автосбором метаданных и графом.
Quality/Observability: правила, тесты, мониторинг свежести и аномалий.
Access & Security: централизованные политики, провизия доступов, журнал аудита.
Schema Registry / Contracts: реестр схем, проверки совместимости на CI.
MDM/Reference Data: мастер-записи игроков/игр/брендов, справочники валют, стран, провайдеров.
Workflow & Ticketing: пайплайны согласований, RACI-шаблоны, SLA-очереди.

9) Примеры доменов данных в iGaming

Игровые события: game_round, bet, win, RTP по времени/игре/провайдеру.
Платежи: депозиты, выводы, chargeback, методы (карты, крипто, локальные PSP).
Пользователи: KYC/KYB статусы, лимиты RG, самоисключение, жалобы.
Маркетинг/CRM: кампании, источники трафика, сегменты, бонусы и отыгрыш.
Риск/AML: скоринги, аномалии, алерты, расследования.
Финансы: отчеты GGR/NET, налоги, разрезы по странам и брендам.

10) Шаблоны (готово к использованию)

10.1 Карточка набора данных

• Классификация/PII: Public/Internal/Confidential/Restricted
• Схема (версия): ссылка на контракт/реестр
• Линейдж: источник → трансформации → витрина

10.2 Data Contract (эскиз)

• Схема: поля, типы, nullable, словари.
• Семантика: определения, бизнес-правила.
• SLA: задержка доставки, доступность.
• Совместимость: политика версий (SEMVER), депрекейшн-окно.
• Качество: обязательные проверки (уникальный key, диапазоны, референсные справочники).
• Безопасность: маскирование/псевдонимизация/шифрование.

10.3 Политика доступа (выдержка)

Принцип: наименьшие привилегии, обоснование запроса.
Потоки: заявка → согласование Owner/DPO → провизия → журнал.
Срок: временные доступы с автоотзывом.
Мониторинг: регулярные ревью прав.

11) Пошаговая дорожная карта внедрения

Первые 30 дней (MVP Governance)

1. Назначить Council, CDO, Owners/Stewards по доменам.
2. Принять «Политику управления данными» и минимальную модель классификации.
3. Развернуть базовый каталог + глоссарий, описать 10 критичных наборов (GGR, транзакции, KYC).
4. Включить 5–10 DQ-правил в основных пайплайнах (freshness/уникальность/валидность).
5. Запустить процесс запросов на доступ с журналированием.

60–90 дней

1. Ввести Data Contracts на событиях игрового ядра и платежах.
2. Включить Schema Registry с проверкой совместимости на CI.
3. Настроить базовый линейдж по ключевым потокам.
4. Оформить графики хранения/удаления и процедуру Legal Hold.
5. Согласовать KPI Governance и публиковать ежемесячный отчет.

3–6 месяцев

1. Сертифицировать «золотые» витрины KPI и MDM реестры (игроки/игры/провайдеры).
2. Включить observability данных (freshness, volume, drift), алерты и автотикеты.
3. Провести аудит доступов и roll-back лишних прав.
4. Каталог покрывает ≥70% активных наборов, глоссарий — топ-метрики.
5. Обучить стюардов и доменные команды (шаблоны, чек-листы, SLO).

12) Риски и анти-паттерны

«Каталог ради каталога» без владения доменами.
Скрытая «data shadow IT» (неучтенные Excel/ноутбуки с PII).
Контракты без автоматических проверок совместимости.
Слишком жесткая централизация — очереди и тормоза.
Отсутствие метрик качества и отчетности — нет обратной связи.

13) Связь с соседними практиками раздела

Качество данных, Мониторинг моделей, Дрейф данных, DSAR/Privacy, Legal Hold, Развертывание ML — все опирается на единые политики, контракты, каталог и роли.

Итог

Управление данными — это не только документы, а ежедневные ритуалы: кто владеет, как измеряем качество, по каким правилам меняем схемы, как даем доступ и когда удаляем. В iGaming выигрывает тот, у кого данные достоверны, доступны и защищены, а решения на их основе — повторяемы и проверяемы.