System Audit Report — SoccerPredictAI¶

[WhoScored.com]
       │  (Selenoid browser session)
       ▼
[Celery worker-api]  (очередь "api")
       │  ── scraping results ──►  [PostgreSQL]
       │                                │
[Airflow DAGs]                    [export_data_raw task]
(5 DAGs, @hourly / manual)              │
trigger via PATCH/GET + X-Token    [MinIO "data-raw"]
    │                                   │
    └──► [FastAPI]                 [DVC Pipeline]  ← params.yaml / Hydra conf/
              │                    (15 stages, see §3.3)
        [RabbitMQ]                      │
        /        \              [MLflow Tracking + Registry]
[worker-api]  [worker-ml]               │
                  │             [PredictionService]
            [MLflow Registry]   (загружается при старте worker-ml)
                  │                     │
            [FeatureLookupService]  [Redis (result backend)]
           match_features.parquet        │
           (MinIO predictions bucket)    │
                                 [FastAPI /predict /livescores]
                                         │
                                 [Nginx (K8s Ingress)]
                                         │
                                 [Streamlit UI]
                                 (внешний VPS, HTTPS)
                                         │
                                   [End User]

WhoScored.com
  → Selenoid (browser automation)
  → Celery worker-api (очередь "api")
  → PostgreSQL (match_raw, match tables)
  → Celery export_data_raw
  → MinIO s3://data-raw/match.parquet + match_raw.parquet   [+ .minio.json metadata]
  → DVC: load_data_from_sources (always_changed: true)
  → data/raw/match_raw.parquet
  → validate_raw (GE gate) → data/evaluation/ge_raw.json
  → export_metadata → data/metadata/*.json (stageId, tournamentId, regionId, seasonId, teamIds)
  → preprocessing (score_outlier_pct=0.9999)
  → data/interim/finished.parquet + future.parquet
  → validate_finished / validate_future (GE gates)
  → feature_engineering
  → data/features/features.parquet + features_meta.parquet
  → validate_features (GE gate, sample_rows=500)
  → split_data (test_start=2024-01-01, folds 2022–2024)
  → data/processed/dataset.parquet + splits/train_ids/test_ids/folds.parquet

data/interim/finished.parquet
  → src/features/stats_matches.py
      (rolling windows: [1,2,3,5,10], cols: win/draw/loss/goals_for/goals_against, side=diff)
  → src/features/elo.py
      (ELO per tournamentId, k=32, initial=1500, home_adv=50)
  → data/features/features.parquet          [все исторические матчи]
  → data/features/features_meta.parquet     [контракт: имена, типы, окна]

Для serving (batch_inference, независимая ветка):
  data/interim/future.parquet + finished.parquet + features_meta.parquet
  → src/pipelines/inference.py
  → data/predictions/match_features.parquet
  → MinIO predictions bucket
  → FeatureLookupService (serving)

data/processed/dataset.parquet + splits + features_meta
  → classification_models (screening с fracs_for_train=[0.001, 0.002])
  → data/models/run_id.json (лучший MLflow run)

data/models/run_id.json + xgb_best_params.json
  → final_train (retrain на полном train set + isotonic calibration)
  → data/models/final_run_id.json
  → MLflow Registry (алиас "champion", name "soccer_clf")

MLflow Registry
  → PredictionService.load() (при worker_process_init сигнале)
  → predict_match Celery task (ml queue)
  → INFERENCE_LATENCY, PREDICTION_CONFIDENCE, MODEL_INFO (Prometheus)

Ручной / CI:
  dvc repro → 15 stages → MLflow → register_model → (ручной деплой worker-ml)

Production ETL (scheduled):
  Airflow @hourly → PATCH /sources/livescores/ (X-Token) → Celery api → PostgreSQL

Production export (manual trigger):
  Airflow manual → GET /sources/export/{table} → Celery api → MinIO

Inference:
  Streamlit UI → POST /predict/ → Celery ml (sync, timeout=30s) → PredictionService → MLflow model
  Streamlit UI → GET /predict/{match_id} → FeatureLookupService → match_features.parquet
  Streamlit UI → POST /predict/async/ → task_id → polling /monitoring/task_status/{task_id} → Redis

Что соединяет: S3 object storage ↔ 15 DVC stages
Как: DVC remote (content-addressed) + boto3 (src/data/storage.py)
  load_data_from_sources: always_changed=true (всегда тянет из MinIO)
  batch_inference: пишет в data/predictions/match_features.parquet
Надёжность: высокая (idempotent DVC stages)
Риски: нет retry на DVC уровне при network failure; credentials через env vars

Что соединяет: classification_models / final_train / register_model → MLflow
Как: mlflow.sklearn.log_model, MlflowClient.create_model_version, алиас "champion"
Надёжность: высокая (идемпотентная регистрация)
Риски: нет quality gate перед register; smoke params могут дать некачественную модель

Что соединяет: MLflow Registry → PredictionService (in-process)
Как: mlflow.pyfunc.load_model("models:/soccer_clf@champion") при worker_process_init
Надёжность: высокая при запуске; нет hot-reload
Риски: cold start при первом деплое (download from MinIO); отставание версий при деплое

Что соединяет: serving ↔ batch_inference artifact
Как: boto3 head_object (LastModified check ≤60s) → read_parquet from MinIO
Надёжность: средняя (кэш in-process, проверка по времени)
Риски: stale features при задержке batch_inference; падение при отсутствии файла

Что соединяет: ETL scheduler → scraping HTTP triggers
Как: HttpOperator (PATCH/GET) + HttpSensor (polling task_id из xcom)
Auth: X-Token через Airflow Variable SOCCER_FASTAPI_HEADER_TOKEN
Retry: 3×5min
Надёжность: средняя
Риски: Airflow в отдельном namespace; зависимость от K8s Ingress; нет circuit breaker

Что соединяет: HTTP layer ↔ async task execution
Как: celery_app.send_task() → RabbitMQ → worker-api / worker-ml
Queues: "api" (scraping/export), "ml" (inference)
Celery config: task_acks_late=True, task_reject_on_worker_lost=True (at-least-once)
Надёжность: высокая (acks_late, retry)
Риски: нет dead-letter queue; дублирование при worker crash + retry

[WhoScored.com] ←(Selenoid)─ [Celery worker-api] ─► [PostgreSQL]
                                                           │
[Airflow DAGs] ──PATCH/GET + X-Token──► [FastAPI]   [Celery export_data_raw]
                                            │               │
                                       [RabbitMQ]     [MinIO data-raw]
                                       /        \          │
                              [worker-api]   [worker-ml]  [DVC Pipeline]
                                                  │       (15 stages)
                                          [MLflow Registry]     │
                                          (soccer_clf@champion) │
                                                  │        [MLflow Tracking]
                                          [PredictionService]
                                          (model in memory)
                                                  │
                             [FeatureLookupService]──[MinIO predictions]
                                                  │
[Streamlit UI] ──HTTPS──► [Nginx+Ingress] ──► [FastAPI]
                                               │        │
                                          /predict  /livescores
                                          /monitoring /healthcheck
                                                  │
                                             [Redis]
                                        (result backend + cache)

DVC pipeline          ← зависит от → MinIO data-raw
DVC pipeline          ← зависит от → MLflow (tracking + registry)
Celery worker-ml      ← зависит от → MLflow Registry (при запуске)
Celery worker-ml      ← зависит от → MinIO predictions (FeatureLookupService)
FastAPI /predict      ← зависит от → Celery worker-ml (sync 30s timeout)
FastAPI /predict/{id} ← зависит от → FeatureLookupService → MinIO predictions
Airflow DAGs          ← зависит от → FastAPI (через K8s Ingress)
Streamlit UI          ← зависит от → FastAPI HTTPS
Serving freshness     ← зависит от → своевременного запуска batch_inference + register_model

System maturity: medium-high

Сильные стороны:
- Чёткое разделение offline (DVC pipeline, 15 stages) и online (FastAPI/Celery) путей
- feature contract через features_meta.parquet (один код для training и serving)
- Great Expectations на 3 уровнях pipeline (raw, interim, features)
- Полная воспроизводимость: DVC + params.yaml + MLflow run tracking
- Детальная документация с явным implemented/planned/planned разграничением
- 32 test файла (~5100 строк): unit, property, contract, load
- Prometheus метрики на всех serving компонентах (FastAPI + worker :9091)
- Airflow ETL с retry (3×5min) и X-Token auth
- task_acks_late=True, task_reject_on_worker_lost=True — защита от потери задач
- Изолированные очереди Celery: "api" vs "ml" (ресурсная изоляция)

Основные риски:
- params.yaml в smoke-режиме (n_trials=2, fracs_for_train=[0.001, 0.002]) — production deploy с игрушечной моделью
- Ручной запуск DVC pipeline — нет автоматической цепочки data update → retrain → deploy
- Нет hot-reload модели (только перезапуск worker-ml)
- stats router (src/app/routers/stats.py) существует, но не подключён в main.py
- CORS allow_origins=["*"] в production FastAPI
- Нет Staging→Production quality gate перед register_model
- Serving зависит от freshness batch_inference artifact без SLA
- Нет drift detection (Evidently — planned)
- Grafana dashboards не задеплоены — мониторинг пассивный
- Single-node K8s без HA

Что требует углублённого аудита:
- 01: схема данных PostgreSQL vs parquet contract (нет явной валидации на границе)
- 03: реальные метрики при smoke params vs production params
- 04: корректность всех 15 DVC stage зависимостей
- 05: политика продвижения моделей в MLflow Registry
- 06: полная проверка train/serve feature contract через features_meta.parquet
- 07: поведение FeatureLookupService при отсутствии match_features.parquet