Самовідновлювані дані

1) Визначення та цілі

Самовідновлювані дані - це підхід до інженерії даних, при якому дефекти виявляються автоматично, а коригувальні дії (ремонт, повторна доставка, відкат, реконсиляція, переіндексація) виконуються без участі людини або з мінімальним втручанням (human-in-the-loop для чутливих кейсів).
Цілі: зниження MTTR даних, підвищення довіри, стійкість до дрейфу і збоїв, передбачувана вартість володіння.

2) Типові збої, від яких потрібно лікуватися

Схеми та контракти: несумісні зміни, зниклі стовпці, типові конфлікти.
Якість/цілісність: дублікати, пропуски, порушення унікальності/референціальної цілісності.
Час і свіжість: затримки інжесту, «дірки» по вікнах, розсинхронізація TZ/локалей.
Ідентифікатори та ключі: зміна генератора ID, колізії, плаваючі натуральні ключі.
Порядок подій: запізнілі події, перевпорядкування, повторна доставка (at-least-once).
Сховища: деградація партій, биті файли/блоки, перекіс шардингу.
Права/безпека: некоректні маски/шифрування, витоки PII у вивантаженнях.

3) Стовпи самовідновлення

1. Контракти даних (schemas + правила) з автоматичними тестами.
2. Ідемпотентні пайплайни (повторний запуск без подвійних ефектів).
3. Журналювання та відтворюваність (raw/bronze незмінні, lineage).
4. Механізми ремонту (replay, backfill, compaction, merge-repair, rebuild).
5. Спостережуваність і SLO (свіжість, повнота, унікальність, латентність).
6. Політики прийняття рішень (коли автофіксимо, коли ескалуємо).

4) Контракти та тести якості

Контракт описує: схему, допустимі діапазони, унікальності, RLS/маскування, SLA свіжості.

yaml dataset: payments 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: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

Тести виконуються на кожному кроці: інжест → стагінг → вітрина. Порушення правил активує авто-ремонт (див. нижче) та/або карантин.

5) Ідемпотентність і детермінізм

Upsert/Merge за стабільними ключами (SCD2 для історії, SCD1 для зрізів).
Детерміновані трансформації: один вхід → один вихід при однакових параметрах.
Контроль версій: фіксуйте версію коду/схем/шарів і мітку даних (watermark).
Idempotent sink: запис через staging + atomic swap/rename.
Exactly-once за змістом: прийнятно «at-least-once» транспорту + ідемпотентний приймач.

6) Механізми авто-ремонту (repair toolkit)

Replay/Backfill: повторна доставка за вікно't ∈ [T0, T1]'з незмінного журналу (raw).
Reconciliation (звірка): порівняння агрегатів/ключів між шарами (raw ↔ curated ↔ marts) і між системами (джерело ↔ DWH).
Deduplication: window-dedup за ключем (txn_id, event_id) + евристика відстаней (fuzzy для «брудних» ключів).
Compaction: перекладка дрібних файлів у великі партії (Parquet/ORC), переіндексація.
Merge-repair: при конфлікті записів - предикати пріоритету (за джерелом/часом/версією).
Rebuild індексів/матеріалізацій: перерахунок агрегатів/cube/roll-up.
Quarantine/Shadow: підозрілі партії ізолюються; споживачі читають «чисту» гілку.
Schema mediation: автоматичний селектор проекцій (заповнення дефолтів, обчислювані колонки) при мінорних змінах.

7) Захист зберігання і цілісність

Чек-суми і валідація блоків (CRC, паритет).
Кворум-сховища (RAFT/Paxos-сумісні системи, quorum reads/writes).
Кодування стирання (erasure coding) для економічної надмірності.
Версіонування об'єктів (object store versioning, undelete).
Atomic commit в Lakehouse (transaction log, ACID-таблиці: Delta/Iceberg/Hudi).

8) Порядок подій і «брудна реальність»

Запізнілі події: тримайте lateness-window, використовуйте watermark'і; перерахунок вікон.
Повторна доставка: dedup по глобальному'event _ id', таблиці idempotency-keys.
Зміщений час: нормалізація TZ, зберігання'ingested _ at'і'event _ time'.
Out-of-order: агрегати на основі event_time з коригуванням по watermark.

9) Логіка прийняття рішень (policy engine)

Правило: «яка аномалія → яка дія → які пороги → хто власник».

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) Спостережуваність і SLO для даних

• Свіжість (Freshness) вітрини ≤ 15 хв.
• Повнота (Completeness)> 99. 5% по ключових полях.
• Унікальність ключів (Uniqueness): дублікати <0. 01%.
• Латентність розрахунку: p95 <5 хв.
• Стійкість ремонту: MTTR-data <30 хв.

Метрики та алерти: експонуйте в Prometheus/Grafana; будуйте пріоритетну стрічку інцидентів даних.

11) Реконсиляція та звірки (практики)

Звірка агрегатів: 'count/sum/min/max'між шарами/системами на ковзному вікні.
Звірка ключів: симетрична різниця множин'Δ = (A\B) ∪ (B\A)'.
Періодичний «audit job»: порівняння з джерелом, вибіркова перевірка на первинці.
Платежі/фінанси: подвійний запис (double-entry), денні cut-off звірки, журнал коригувань.

12) Управління схемами та еволюція

SemVer для схем: MAJOR (ламає )/MINOR (додає )/PATCH (виправляє).
Контракти в CI/CD: schema-diff, сумісність, автогенерація міграцій.
Backfill-хук: при MINOR додати дефолти/обчислювані поля, перерахувати вітрини.
Гнучкі проекції: читачі читають підмножини колонок; забороняємо «SELECT».

13) Безпека, приватність, комплаєнс

RLS/CLS: фільтри рядків/стовпчиків, особливо в repair-гілках та експортах.
PII-маскування: детерміноване (tokenization) для стійкої дедуплікації.
Аудит доступу/експорту: хто бачив, що експортував, куди відправив.
DSAR/Retention: авто-видалення/анонімізація в repair-процесах; відкати враховують правові вимоги.

14) Вартість і продуктивність

Cost-aware backfill: обмеження ширини вікон (наприклад, ковзні 3-7 днів).
Матеріалізації та кеші: повторний розрахунок тільки змінених партій (incremental).
Пріоритизація: спочатку критичні вітрини (фінанси, ризики), потім аналітичні.
Off-peak ремонти: нічні вікна/низький пріоритет в планувальнику.

15) Тестування та симуляції інцидентів

Chaos-data-testing: навмисно ламайте партії/схеми на стейджі.
Фальшиві затримки: симулюйте пропуски батчів, out-of-order, дублікати.
Golden datasets: еталони для звірки після ремонту.
GameDays: регулярні тренування команди з runbook'ам.

16) Антипатерни

«Невидимі» виправлення: мовчазні правки без аудиту та звітності.
Непротокольовані backfill'и: немає джерела істини/версії формул.
Важкі live-запити до OLTP при ремонті: добиваєте прод.
SELECT в споживачах: ламається при будь-якій MINOR-зміні.
Єдиний ключ дедуплікації: відсутність fallback-ключів/хеш-сигнатур.

17) Дорожня карта впровадження

1. Discovery: критичні набори/метрики, ризики, власники; Карта залежностей.
2. Контракти та тести: формалізуйте схеми/правила в CI; publish глосарій.
3. Ідемпотентність: перепишіть ключові пайплайни на upsert/merge, atomic sink.
4. Raw-журнал і lineage: незмінний шар, повні метадані, watermark'і.
5. Repair-механіки: backfill/replay, dedup, compaction, quarantine; policy engine.
6. Спостережуваність і SLO: дашборди якості, алерти, пріоритетна стрічка.
7. Chaos-data і тренування: регулярні навчання + runbook'і.
8. Оптимізація вартості: інкрементальні перерахунки, пріоритизація вікон.

18) Чек-лист перед релізом

• Контракти даних і тести якості покривають критичні набори.
• Пайплайни ідемпотентні; є atomic commit і відкати.
• Налаштовані backfill/replay і quarantine, прописані політики ескалації.
• Метрики Freshness/Completeness/Uniqueness/Latency і алерти в проді.
• Включено аудит правок/ремонтів; зберігаються версії формул і вітрин.
• DSAR/Retention дотримуються при ремонті і відкатах.
• Є runbook'і, проведені навчання, MTTR-цільовий зафіксований.
• Вартість backfill'ів обмежена бюджет-гвардами.

19) Приклади автодій (шаблони)

«Провал свіжості вітрини X» → backfill (last_2h) → якщо не ок за 30 хв → quarantine + сторінка on-call.
«Сплеск дублікатів txn_id» → включити строгий dedup + звірка з джерелом → звіт про причини.
«MINOR-зміна схеми» → згенерувати обчислюване поле-дефолт → rebuild агрегатів.
«Втрата партій» → відновити з версіонованого об'єкта → верифікація чек-сумою.

Підсумок: самовідновлювані дані - це не один «скрипт ремонту», а системна архітектура: формальні контракти, ідемпотентні пайплайни, надійне журналювання, автоматизовані механіки ремонту і прозора спостережуваність зі строгими SLO. Така система не тільки лагодить себе, але і перетворює інциденти в керовані події зі зрозумілою вартістю і часом відновлення.