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

1) Назначение и принципы

Цель: обеспечить предсказуемое, комплаентное и экономичное движение данных от момента появления до их окончательного удаления, поддерживая аналитические, операционные и регуляторные сценарии.

• Data as a Product: у каждого набора есть владелец, контракт, SLO, документация.
• Schema-first: схемы обязательны; изменения — через версионирование.
• Privacy-by-Design: минимизация PII, псевдонимизация, региональное хранение.
• Observability-by-Default: метрики, логирование доступа, lineage.
• Cost-aware: уровни хранения, TTL, семплирование, компрессия.

2) Фазы жизненного цикла

2.1 Создание и сбор (Create/Collect)

Источники: продукты (веб/мобайл), бэкенды, платежи, KYC/AML провайдеры, игры/студии, маркетинг, операционные логи.
Идентификаторы: `event_id`, `user.pseudo_id`, `session_id`, `trace_id`.
Контракты: JSON/Avro схемы, AsyncAPI/OpenAPI.
Качество на входе: валидация схем, обязательные поля, лимиты размера, анти-дубликаты.
Приватность: токенизация чувствительных полей, гео-маршрутизация ingest (EEA/UK/BR).

2.2 Прием и первичное хранение (Ingest & Raw)

Транспорт: HTTP/gRPC → Edge → шина (Kafka/Redpanda).
Raw-слой (Bronze): append-only, неизменяемые payload’ы (для форензики), партиционирование по времени/рынку/тенанту.
Политики: дедуп по `(event_id, source)`, DLQ для «битых» событий, Legal Hold метки.

2.3 Обработка и очистка (Refine)

Нормализация (Silver): типизация, дедупликация, справочники, FX/таймзоны, обогащение.
Качество (DQ): полнота/уникальность/диапазоны/референтная целостность.
Reprocessing: идемпотентные конвейеры, time-travel, контролируемые backfill’ы.

2.4 Потребление и сервинг (Serve/Use)

Gold-витрины: BI/отчетность (GGR, RG, AML), продуктовые и риск-модели, real-time витрины.
Доступ: SQL/Trino, семантический слой метрик, API/GraphQL, Feature Store.
SLA свежести: например, Gold-ежедневные витрины готовы до 06:00 локального времени.

2.5 Обмен и распространение (Share/Publish)

Внутренние потребители: Аналитика, Продукт, Риск, Комплаенс, Маркетинг, Финансы.
Внешние выгрузки: регуляторы, партнеры/провайдеры; неизменяемые пакеты (PDF/CSV/JSON + hash).
Контролируемые каналы: подписанные артефакты, аудит загрузок/экспортов.

2.6 Архивирование и хранение (Archive/Retain)

Политики хранения: по типам данных и юрисдикциям (напр., регуляторные — 5–7 лет).
Слои хранения: hot/warm/cold, WORM/Object Lock для неизменяемости.
Индексация архива: каталоги, метки версий/рынков, быстрый поиск метаданных.

2.7 Удаление и финал (Dispose)

Обычное удаление: TTL/ретеншн; безопасная очистка, обновление индексов.
Правовые операции: DSAR/RTBF (право на забвение), исключения по законной обязанности хранения, Legal Hold (заморозка удаления).
Верификация: отчеты об удалении, журнал аудита, контроль кросс-реплик.

3) Классификация и каталог

Категории чувствительности: public / internal / confidential / restricted.
Домены: Payments, Gameplay, Compliance/AML, RG, Marketing, Ops, Finance.
Каталог данных: описание, владелец, SLA свежести, схемы, lineage, уровни доступа.
Теги: `jurisdiction`, `tenant`, `pii_class`, `retention_class`, `legal_hold`.

4) Модель Lakehouse и схемы

Bronze/Silver/Gold: четкие правила превращений и ответственности.
Форматы: Parquet + табличный формат с ACID (Delta/Iceberg/Hudi).
Эволюция схем: семантические версии, лонгитюдная совместимость, миграции с двойной записью для breaking-изменений.
Registry: Schema Registry, CI-валидация контрактов, consumer-driven tests.

5) Качество данных (DQ)

• Completeness (полнота): доля фактически полученных событий/строк.
• Validity: доля записей, прошедших схемную валидацию.
• Uniqueness: контроль дубликатов.
• Consistency: соответствие справочникам и связям.
• Freshness: задержка поступления/материализации.

• Правила DQ как код (YAML/SQL-тесты), дашборды, алерты SLO.
• Авто-фоллбэк при деградации (последний корректный срез).

6) Приватность и комплаенс

Минимизация PII: хранить псевдо-ID, вынести маппинги в изолированный контур.
Маскирование и RLS/CLS: на уровне столбцов/строк; динамические политики.
Регионализация: data residency по рынкам; раздельные каталоги/ключи шифрования.
DSAR/RTBF: управляемые проекции, селективные редактирования, аудит выдач.
Legal Hold: метки заморозки, неизменяемые архивы, протоколирование доступа.

7) Доступ и безопасность

Аутентификация/авторизация: SSO, RBAC/ABAC, атрибуты юрисдикций и ролей.
Шифрование: TLS in-transit; at-rest через KMS/CMK; ротация ключей.
Журналы доступа: кто/что/когда/откуда; алерты на массовые экспорт/сканы.
Разделение обязанностей: разные роли для прод/аналитики/админов/ревьюеров.

8) Линейность (lineage) и наблюдаемость

Технический lineage: от источника → трансформации → витрины → отчеты.
Операционный lineage: связи с релизами, фичфлагами, моделями, правилами AML/RG.
Метрики платформы: throughput, lag, failure-rate, cost/query, cost/GB.
Трейсинг: передача `trace_id` из приложений до витрин/алертов.

9) Модели времени и ретропроцессы

Event-time vs Processing-time: приоритет event-time, watermarks/allowed lateness.
Backfill и reprocessing: идемпотентные pipeline’ы, time-travel, контроль «двойного учета».
Сохранение состояний: TTL, снапшоты, восстановление после сбоев.

10) Экономика и cost-контроль

Партиционирование (дата/рынок/тенант), кластеризация/Z-ordering.
Семплирование для высокочастотной аналитики (не для транзакций/комплаенса).
Многослойное хранение (hot/warm/cold), автоматические TTL.
Budget/chargeback по командам, лимиты на тяжелые запросы и backfill.

11) Процессы и RACI

R (Responsible): Data Platform (ингест/хранилища/оркестрация), Data Engineering (трансформации), Доменные владельцы (Contracts/DQ/SLO).
A (Accountable): Head of Data/Chief Data Officer.
C (Consulted): Compliance/Legal/DPO, Архитектура, SRE, Security.
I (Informed): BI/Продукт/Маркетинг/Финансы/Операции.

12) SLO/SLI (примерные цели)

13) Дашборды

Тепловая карта свежести по доменам/рынкам.
Completeness/Validity по потокам.
Стоимость хранения и запросов (по слоям и командам).
Карта lineage для критичных отчетов (регуляторка, GGR, RG/AML).
Очереди DSAR/RTBF, статусы Legal Hold.

14) Шаблоны политик хранения (пример)

Фактические сроки определяются Legal/DPO и локальным правом.

15) Документация и стандарты

Data Product page: владелец, назначение, SLA, схемы, DQ-правила, контакты.
Change log: версии схем/логики, влияние (impact analysis), миграции.
Runbooks: reprocessing, backfill, аварийные сценарии, фриз-кнопка.

16) Дорожная карта внедрения

1. Каталог данных и классификация (топ-домены), базовые схемы и регистр.

2. Lakehouse Bronze/Silver, ingestion с валидацией и дедупом.

3. 1–2 Gold-витрины (например, GGR и конверсия).

4. Минимальные DQ-правила и дашборд Freshness/Completeness.

5. Политики хранения и RBAC на доступ.

• Линедж, семантический слой метрик, DSAR/RTBF процедуры.
• Регионализация (EEA/UK), WORM для регуляторных артефактов, Legal Hold.
• Оптимизация стоимости, алерты SLO, отчетность по бюджету.

• Data Mesh (доменные продукты), consumer-driven contracts и тесты.
• Автосимуляция impact при изменении схем/логики, реплеи.
• Единая панель соответствия (регуляторка, доступ, DQ, lineage).

17) Чек-лист перед продом

• Схемы утверждены, контракты в регистре, тесты на совместимость.
• DQ-правила активны, алерты сконфигурированы, SLO заданы.
• RBAC/ABAC: роли проверены, журналы доступа включены.
• Политики хранения/удаления/архива подтверждены Legal/DPO.
• Процедуры DSAR/RTBF/Legal Hold документированы и протестированы.
• Линедж/метрики/стоимость отображаются в дашбордах.
• Runbooks для backfill/reprocessing/DR готовы.

18) Частые ошибки и как их избежать

Нет единой классификации и каталога: вводите обязательные карточки Data Product.
Сырые данные без схем: schema-first + CI-валидация.
Отсутствие удаляемости: проектируйте TTL и процессы RTBF с самого начала.
Смешение PII и аналитики: храните маппинги отдельно, применяйте маскирование.
Gold без владельца и SLO: назначайте owner и цели свежести.
Неуправляемая стоимость: партиции, компрессия, tiered-storage, квоты.

19) Глоссарий (кратко)

DSAR/RTBF — запрос субъекта данных/право на удаление.
Legal Hold — заморозка удаления по юридическим основаниям.
Lineage — прослеживаемость происхождения и трансформаций.
Data Product — управляемая продуктовая единица данных со SLA.
DQ — правила и метрики качества данных.
Lakehouse — объединение data lake и ACID-таблиц.

20) Итог

Жизненный цикл данных — это управляемая система договоренностей, а не просто склад файлов. Четкие контракты и схемы, классификация и каталог, измеримое качество, приватность и безопасность, экономная архитектура хранения и прозрачный lineage делают данные надежным активом, который поддерживает продукт, комплаенс и аналитику без сюрпризов и «скрытых» рисков.