Хранение, архивирование и утилизация данных

Введение

Сценарий: FinSecure Bank (ФинСекьюр Банк)

FinSecure хранит 2.5 ТБ клиентских данных. Рост — 15% ежегодно, затраты на хранение выросли на 40% за год. Регуляторы требуют хранить финансовые данные 7 лет. GDPR требует удаления персональных данных по запросу клиента. Юридический отдел: “Мы храним всё, потому что удалить страшнее.” Результат: 30% данных — дубликаты или данные с истёкшим retention-сроком, которые никто не чистил.

“Мы храним всё, потому что удалить страшнее” — типичная позиция организаций без retention governance. Но бесконечное хранение — это не осторожность, а governance failure: данные без retention-политики — это liability (юридический риск), а не asset.

В этом уроке мы разберём три этапа жизненного цикла данных после их активного использования: Retention (хранение), Archiving (архивирование) и Disposal (утилизация/уничтожение). Предварительно рекомендуем повторить урок 07 этого модуля (Freshness и Observability) и урок 05 модуля M05 (классификация данных).

Data Retention Policy Design

Регуляторные требования

Retention-политика определяется пересечением регуляторных и бизнес-требований:

Classification-Driven Retention Tiers

Retention-срок привязывается к классификации данных (урок M05-05):

Архивирование: Hot/Warm/Cold Lifecycle

Storage Tiers

Не все данные одинаково активны. Архивирование — это перемещение данных между уровнями хранения по мере снижения активности:

Archive Triggers

Данные перемещаются между tiers на основе governance-правил:

# Archive policy rules
ARCHIVE_TRIGGERS = {
    "hot_to_warm": {
        "condition": "last_accessed > 90 days",
        "action": "Move to read replica / cold storage",
        "approval": "Automated (Data Engineer review weekly)"
    },
    "warm_to_cold": {
        "condition": "last_accessed > 180 days AND past active_retention",
        "action": "Move to S3 Infrequent Access",
        "approval": "Data Owner approval"
    },
    "cold_to_archive": {
        "condition": "past active_retention AND within total_retention",
        "action": "Move to S3 Glacier",
        "approval": "Data Owner + Compliance approval"
    },
    "archive_to_dispose": {
        "condition": "past total_retention AND no legal_hold",
        "action": "Initiate disposal workflow",
        "approval": "Data Owner + Legal + CDO"
    }
}

Searchability и Restore SLA

Архивированные данные не исчезают из governance:

Сценарий: BioGenesis Lab (БиоГенезис Лаб)

Клинические данные trial Phase III архивированы в Cold storage 2 года назад. FDA запрашивает данные для post-market review. Требование: восстановить в течение 4 часов. BioGenesis определила Restore SLA для clinical data: Cold -> 4 часа, Archive -> 12 часов. Регулярное тестирование восстановления (ежеквартально) подтверждает, что SLA соблюдается.

Data Disposal/Purging Governance

Методы безопасного удаления

Удаление данных — не просто DELETE FROM. Governance требует гарантии полного уничтожения:

Crypto-shredding — наиболее эффективный метод для cloud-среды: если данные зашифрованы per-record ключом, удаление ключа делает данные нечитаемыми без физического удаления.

Disposal Verification

Backup Governance: RPO/RTO

Определения

• RPO (Recovery Point Objective): максимально допустимая потеря данных. RPO=0 означает zero data loss (синхронная репликация). RPO=24h означает допустимую потерю данных за последние 24 часа.
• RTO (Recovery Time Objective): максимально допустимое время простоя. RTO=1h означает восстановление в течение часа.

RPO/RTO по критичности данных

Governance: кто определяет RPO/RTO

Business Owner, не DBA, определяет RPO/RTO. DBA реализует техническое решение. Data Council утверждает.

Сценарий: FinSecure Bank

Core Banking: RPO=0, RTO=1h. Потеря даже одной транзакции — регуляторное нарушение. Стоимость: synchronous replication across AZ ($$$). Analytics: RPO=24h, RTO=48h. Потеря дневных данных — задержка отчётов, не catastrophe. Стоимость: daily pg_dump ($). Governance-решение: RPO/RTO определяет Business Owner (VP Banking для core, VP Analytics для BI). DBA предлагает технические варианты с cost estimate. Data Council утверждает бюджет.

Тестирование Recovery

Recovery без тестирования — fiction. Governance требует:

Quarterly Recovery Testing Schedule:
  Q1: Core Banking full recovery drill (target: RTO < 1h)
  Q2: Payment Processing failover test (target: RPO < 5 min)
  Q3: Analytics restore from backup (target: RTO < 48h)
  Q4: Full disaster recovery simulation (all systems)

Each test:
  1. Simulate failure (controlled)
  2. Execute recovery procedure
  3. Measure actual RPO/RTO
  4. Document gaps vs target
  5. Update runbook if needed

Storage Classification Matrix

Сводная матрица связывает классификацию данных с storage governance:

Сценарий: DataTech Solutions (ДатаТех Солюшенз)

DataTech строит первую Storage Classification Matrix. При ограниченном бюджете доступны только два storage tier: Hot (SSD) и Cold (HDD). Маппинг: Restricted + Internal (active) -> Hot (быстрый доступ для governance-проверок, шифрование, частые backups). Public + Internal (archived) -> Cold (низкая стоимость, longer restore SLA допустим). Ключевой фактор — governance requirements, не объём данных.

Автоматизация Retention Enforcement

Policy-as-Code: TTL и автоматическое удаление

Ручное retention enforcement не масштабируется. Автоматизация:

# Automated retention enforcement
def enforce_retention(table_name, classification, retention_policy):
    """Проверить и применить retention policy для таблицы."""
    records = get_records_past_retention(table_name, retention_policy)

    if not records:
        return {"table": table_name, "action": "none", "reason": "all within retention"}

    # Check legal hold
    if has_active_legal_hold(table_name):
        return {"table": table_name, "action": "hold", "reason": "active legal hold"}

    # Determine disposal method by classification
    disposal_methods = {
        "public": "standard_delete",
        "internal": "secure_overwrite",
        "confidential": "crypto_shredding",
        "restricted": "crypto_shredding_with_audit"
    }

    method = disposal_methods.get(classification, "manual_review")

    # Create disposal ticket for approval
    return {
        "table": table_name,
        "action": "dispose",
        "records": len(records),
        "method": method,
        "requires_approval": classification in ("confidential", "restricted")
    }

Compliance Reporting

Ежемесячный retention compliance report:

Retention Compliance Report -- March 2026
==========================================
Total datasets:           200
Within retention:         170 (85%)
Past retention (pending):  20 (10%)  <- requires disposal workflow
Past retention (overdue):   5 (2.5%) <- governance violation
Under legal hold:           5 (2.5%) <- retention suspended

Overdue datasets:
  - raw_campaigns_2022 (Internal, expired 2025-01, 14 months overdue)
  - staging_temp_exports (Public, expired 2024-06, 21 months overdue)
  - ...

Action required: CDO review of 5 overdue datasets by March 31.

Итоги

• Retention Policy: classification-driven сроки хранения (Public 1 год -> Restricted 7-15 лет)
• Archiving Lifecycle: Hot -> Warm -> Cold -> Archive -> Dispose с governance-правилами на каждом переходе
• Disposal Governance: crypto-shredding для Confidential/Restricted, disposal verification checklist, backup rotation
• RPO/RTO: Business Owner определяет, DBA реализует. Квартальное тестирование recovery
• Storage Classification Matrix: связывает classification с storage tier, encryption, disposal method, backup frequency
• Automated Enforcement: policy-as-code для TTL, scheduled purge с approval workflow, compliance reporting
• “Храним всё навсегда” — governance failure: regulatory risk + cost + security exposure

Это завершает модуль M04: Качество Данных и Observability. Вы изучили: шесть измерений качества, обнаружение нарушений, дедупликацию, автоматизацию тестов с dbt и Great Expectations, Data Observability, и governance жизненного цикла данных от retention до disposal. В следующем модуле мы перейдём к M05: Приватность и Compliance.