Перейти к содержанию

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

Модель управления данными (Data Governance) платформы Kruma — набор политик, стандартов и процедур, обеспечивающих качество данных, соответствие нормативным требованиям и операционное совершенство.


Руководящие принципы

Принцип Описание
Контракты как код Каждый набор данных имеет машиночитаемый контракт: схема, SLA, владелец, классификация
Управление как ускоритель Политики встроены в CI/CD — governance ускоряет доставку, а не замедляет
Происхождение — источник истины Сквозное отслеживание данных от источника до потребления; ответ на «откуда это?» за 60 секунд
Качество по проекту Правила качества — исполняемые утверждения; нарушенный контракт = заблокированное развертывание
Владение доменом Явное владение продуктом данных с матрицами RACI в метаданных

Область применения

Спецификация применяется к:

  • Всем контрактам данных в contracts/domains/
  • Всем системам, производящим данные через API Gateway
  • Всем системам и приложениям, потребляющим данные
  • Всему персоналу, участвующему в производстве, валидации и потреблении данных

Архитектура данных

Концептуальный → физический уровень

Уровень Реализация в Kruma
Концептуальный Domain-Driven Design с ограниченными контекстами (contracts/domains/)
Логический Avro-схемы (schema.avsc), определяющие структуры сущностей
Физический physical_layout.yml — хранение, партиционирование, компрессия
Интеграционный Kafka-топики, Git-версионированные Avro-схемы, API Gateway

Слои архитектуры

┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐
│  Исходные системы │ ──▶ │   API Gateway     │ ──▶ │   Kafka-топики    │
│  (1C, WMS, CRM)   │     │   (mTLS + Avro)   │     │  (raw/prod/dlq)   │
└───────────────────┘     └───────────────────┘     └────────┬──────────┘
┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐
│   Data Lake       │ ◀── │   Потребители     │ ◀── │   Валидатор       │
│   (Iceberg)       │     │   (DWH, ML, BI)   │     │   качества        │
└───────────────────┘     └───────────────────┘     └───────────────────┘

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

Компонент Реализация
Бизнес-метаданные Блок metadata в контракте: описание, владелец, теги
Технические Avro-схемы в Git (schema.avsc), каталог Gravitino (Iceberg)
Операционные Отслеживание происхождения, метки обработки, метрики валидации
Репозиторий Git-репозиторий (source of truth) + каталог данных

Иерархия метаданных

contracts/domains/{namespace}/{entity}/
  contract.yaml        # Бизнес-метаданные, владение, SLA
  schema.avsc          # Технические метаданные (схема)
  quality_rules.yml    # Операционные (правила валидации)
  sla.yml              # Операционные (SLA, retention)
  physical_layout.yml  # Физические (конфигурация хранения)
  runbook.md           # Операционная документация

Безопасность данных

Компонент Реализация
Классификация Теги: pii, 152-fz, confidential, public
Контроль доступа mTLS-сертификаты для каждого producer/consumer
Маскирование Теги PII запускают политики маскирования
Аудит Все доступы и изменения логируются
Шифрование TLS при передаче, SSE при хранении (S3)

Теги классификации

Тег Описание Требования обработки
pii Персонально идентифицируемая информация Шифрование, логирование доступа
152-fz Подпадает под 152-ФЗ Согласие субъекта, локализация, уведомление РКН
confidential Коммерческая тайна Доступ по необходимости
critical Критичные для бизнеса данные Высокий SLA, приоритетная поддержка
public Публичная информация Стандартная обработка

Разделы