Цілісність даних

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; istochnik↔DWH).
Dedup/Compaction/Rebuild: системні процедури ремонту індексів/агрегатів.
Policy-as-code: «яка аномалія → яка дія → пороги → ескалація».

11) Практики моделювання та зберігання

Стабільні ключі: сурогатні PK (UUID/ULID), незмінні натуральні ключі в довідниках.
Normalizatsiya↔denormalizatsiya: 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) Підсумок

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