Целостность данных

1) Что такое целостность данных

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

2) Типы целостности и где они живут

Сущностная (Entity): уникальные первичные ключи, отсутствие дубликатов.
Ссылочная (Referential): корректные связи FK; отсутствие “висячих” ссылок.
Доменная (Domain): допустимые диапазоны и форматы (тип, длина, справочники).
Бизнес-правила: инварианты предметной области (баланс ≥ 0, сумма проводок = 0 и т. п.).
Временная: монотонность и согласованность временных меток, корректные тайм-зоны.
Политики доступа: RLS/CLS не нарушают логическую согласованность видимых данных.

3) Контракты данных и схемы (источник истины)

Задаем формальные контракты для наборов и событий; применяем их на входе и после каждой трансформации.

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id schema:
- {name: txn_id, type: string, unique: true}
- {name: user_id, type: string, not_null: true}
- {name: amount, type: decimal(18,2), min: 0}
- {name: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4) Транзакционные гарантии и изолированность

ACID для OLTP: атомарность, консистентность, изолированность, долговечность.
Уровни изоляции: Read Committed / Repeatable Read / Serializable — выбирайте под риск “грязных”/неповторимых/фантомных чтений.
OLAP и lakehouse: атомарные коммиты таблиц (transaction log), idempotent sink и schema-evolution с контролем совместимости.
Согласованность формул KPI: семантический слой → одна истина для отчетов и API.

5) Распределенные системы: порядок, повторы, идемпотентность

Порядок событий: используем `event_time` + `ingested_at`, watermarks и допуск lateness; агрегаты на основании event time.
Повторная доставка (at-least-once): глобальный `event_id`, таблицы idempotency keys, upsert/merge по устойчивому ключу.
Out-of-order: перерасчет окон, стратегия задержек, компенсации.
Exactly-once по смыслу: транспорт может быть at-least-once, приемник — идемпотентный.

6) Валидация целостности (DQ) на каждом слое

• Freshness/Completeness/Uniqueness/Valid Values/Referential Integrity.
• Аномалии: всплески дубликатов, разрывы времени, резкие сдвиги распределений.
• Контроль формул KPI: версионность расчетов и тесты на совпадение результатов (golden sets).
• Контроль экспорта: запрет выдачи наборов с нарушениями (quarantine).

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7) Финансовая и операционная целостность

Double-entry (двойная запись): дебет/кредит в балансе; сводные сверки в cut-off.
Итоговые инварианты: сумма выплат = сумма списаний + комиссии + корректировки.
Операционные инварианты: SLA/guardrail-метрики не ломают бизнес-правила (например, авто-ремонт не создает дубликатов).

8) Линеедж, аудит и воспроизводимость

Линидж: от источника до витрин/фич; видимость трансформаций и владельцев.
Аудит-трейлы: кто изменил, что, когда и зачем; версии схем/формул/джобов.
Снепшоты/контрольные точки: возможность пересчитать и подтвердить прошлые отчеты.
Repro: одинаковый запрос на одинаковом срезе → одинаковый результат (версии и слои).

9) Безопасность и приватность без потери целостности

RLS/CLS: фильтры строк/колонок не должны нарушать инварианты (например, сумма по видимой выборке должна совпадать с заявленной).
Маскирование/токенизация: детерминированные стратегии, чтобы дедуп и референциальная целостность сохранялись.
Шифрование: в канале и “на диске” после сжатия; управление ключами и аудит доступов.
DSAR/Retention: удаление/анонимизация не ломают связность (каскадная политика).

10) Самообслуживание и автоматика ремонта

Quarantine: изоляция подозрительных партиций/батчей; потребителям — “чистая” ветка.
Replay/Backfill: переигровка окна из неизменяемого raw-журнала.
Reconcile: сверки слоев и систем (raw↔curated↔marts; источник↔DWH).
Dedup/Compaction/Rebuild: системные процедуры ремонта индексов/агрегатов.
Policy-as-code: “какая аномалия → какое действие → пороги → эскалация”.

11) Практики моделирования и хранения

Стабильные ключи: суррогатные PK (UUID/ULID), неизменные натуральные ключи в справочниках.
Нормализация↔денормализация: FK-связи в источниках, денормализованные витрины с контролем версии логики.
SCD1/SCD2: управляемая история для измерений.
Сортировка/кластеризация: улучшает RLE/zone-maps и упрощает сверки.
Хеши и контрольные суммы: проверка целостности файлов/партиций.

12) Целостность во времени и в отчетности

Версии формул: отчет за январь 2025 должен быть воспроизводим формулой версии X.
Cut-off и “закрытие периода”: заморозка витрин и архивных срезов.
Late arriving facts: механика дозаливки и пересчетов с отметкой версии отчета.
Документирование переопределений: ручные корректировки — только с аудитом.

13) Интеграции и API

Контракт API: схемы, типы, обязательные поля, коды ошибок; версионирование (v1/v2).
Валидация на входе: reject плохие payload’ы, не “чинить молча”.
Идемпотентные POST: ключ идемпотентности, повтор безопасен.
Экспорт в файлы: согласованность партиций, хэши, подписи.

14) Антипаттерны

SELECT в прод-запросах и вьюхах — ломается при MINOR-эволюции.
FK “на словах”: отсутствие реальной проверки ссылок.
Молчаливые исправления данных без аудита и отчетности.
Смешение TZ и форматов времени в одном наборе.
Переопределения KPI “ручками” без версий и журналов.
Единственный ключ дедупликации без запасных стратегий.
Удаление по DSAR без каскадной проверки связей.

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

1. Inventory & критичность: карта наборов/событий, владельцы, риски, инварианты.
2. Контракты и схемы: формализовать типы/ограничения/FK, CI-проверки совместимости.
3. DQ в пайплайне: Freshness/Completeness/Uniqueness/RI, quarantine, алерты.
4. Транзакционная основа: atomic-sink, upsert/merge, SCD-история, версионность формул.
5. Линеедж и аудит: каталог, трассировка, change-logs, access-logs.
6. Политики ремонта: replay/backfill/dedup/reconcile как код; runbook’и и SLO MTTR-data.
7. Безопасность/priv: RLS/CLS, маскирование, шифрование, DSAR-процессы.
8. Отчетность: cut-off, freeze-срезы, управление версиями KPI.

16) Чек-лист перед релизом набора/витрины

• PK/FK и доменные ограничения заданы и проходят тесты.
• Версионирование схем/формул включено; schema-diff зеленый.
• DQ-правила (свежесть/полнота/уникальность/диапазоны/RI) зеленые.
• Идемпотентные записи: upsert/merge, ключ идемпотентности (для событий).
• Время: `event_time` и `ingested_at`, TZ=UTC; политика late data.
• Линеедж и аудит видны; включены quarantine и алерты.
• RLS/CLS/маскирование не нарушают инварианты и RI.
• DSAR/Retention протестированы; cut-off/архив готов.

17) Мини-шаблоны

SQL: проверка ссылочной целостности

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

Политика quarantine/repair (псевдо-YAML)

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

Схема SCD2 для измерения

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) Итог

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