Data Audit Report — SoccerPredictAI¶

Date: 2026-04-24 Auditor: GitHub Copilot (Claude Sonnet 4.6) Scope: Data layer — ingestion, storage, versioning, freshness, validation boundary Method: прямой анализ кода (src/data/, src/app/tasks/export.py, src/pipelines/source.py, dvc.yaml, airflow/dags/)

1. Source & Ingestion¶

Откуда приходят данные¶

Источник: WhoScored.com (через Selenoid-браузерную сессию) Технология scraping: Celery task livescores в очереди api (src/app/tasks/livescores.py) Метод: HTTP-операторы Airflow → PATCH/GET FastAPI endpoints → Celery task dispatching

Ingestion flow¶

WhoScored.com
    │ (Selenoid browser session)
    ▼
Celery worker-api (очередь "api")
    │  scraping results (JSON)
    ▼
PostgreSQL (таблицы: match, match_raw)
    │
Airflow DAG: soccer_etl_export_matches_to_source (schedule=None, manual)
    │  GET /sources/export/{table_name}
    ▼
MinIO (bucket: MINIO_BUCKET_DATA_RAW)
    │  match.parquet + match_raw.parquet
    ▼
DVC stage: load_data_from_sources
    │  src/data/storage.py → export_data_raw()
    ▼
data/raw/match.parquet + data/raw/match_raw.parquet

Ключевые выводы¶

1. Scraping запускается через 4 отдельных DAG (etl_livescores_01–04), все с @hourly, что позволяет охватить разные временные окна
2. Экспорт PostgreSQL → MinIO (etl_export_01.py) запускается вручную (schedule=None) — нет автоматизированного trigg-а для обновления raw parquet

2. Storage Contracts¶

Canonical источники¶

Различия match.parquet и match_raw.parquet¶

⚠️ Проблема: src/data/source.py вызывает export_data_raw() для обоих файлов одинаково — оба скачиваются из MINIO_BUCKET_DATA_RAW по имени файла как ключу. Нет явного различия в семантике на уровне кода — оба ключа выводятся из local_path.name. Фактически оба файла существуют в MinIO с разными ключами (match.parquet и match_raw.parquet), но их смысловое разграничение не задокументировано в коде.

Downstream usage: - match_raw.parquet → validate_raw → export_metadata → preprocessing - match.parquet → объявлен как outs, но в downstream stages используется только match_raw.parquet

⚠️ P1 риск: match.parquet объявлен как DVC out, но не используется ни одной downstream-стадией как dep — потенциально мёртвый артефакт.

3. Data Versioning¶

Метаданные snapshot¶

В export_data_raw() (src/data/storage.py) для каждого скаченного файла создаётся .minio.json sidecar:

DVC tracking: Все .minio.json sidecar-файлы включены в DVC outs (persist: true), что обеспечивает полную цепочку происхождения.

4. Freshness & Idempotency¶

Smart-skip логика¶

changed = (
    (not local_path.exists())
    or (local_etag != remote_etag)
    or (local_size != remote_size)
)

Оценка: - ✅ Есть smart-skip по ETag + size — повторный запуск без изменений на MinIO не перезаписывает файл - ✅ Idempotency сохранена — повторный запуск с теми же данными не создаёт проблем - ✅ ETag + size сравнение надёжно для однофайловых объектов MinIO

Риски freshness¶

5. Data Validation Boundary¶

Расположение validation¶

DVC Pipeline validation stages:
  match_raw.parquet → validate_raw (GE: src/data_quality/raw.py)
  finished.parquet  → validate_finished (GE: src/data_quality/finished.py)
  future.parquet    → validate_future (GE: src/data_quality/future.py)
  features.parquet  → validate_features (GE: src/data_quality/features.py)

Оценка: - ✅ Validation перед каждой ключевой стадией — Good - ✅ GE-результаты сохраняются как JSON в data/evaluation/ - ❌ Нет validation на MinIO перед ingestion — данные скачиваются и сохраняются без schema-check - ❌ DVC stage validate_interim упомянут в contract tests (tests/contract/test_pipeline_contracts.py) как ожидаемый, но отсутствует в dvc.yaml — расхождение contracts ↔ pipeline

6. Risks¶

7. Summary¶