ss-tools/docs/scheduler-worker-orthogonal-comparison.md

# Ортогональное сравнение: Наш Scheduler + Worker vs Celery и открытые альтернативы

**Дата**: 2026-07-10  
**Контекст проекта**: superset-tools (FastAPI + Svelte).  
**Наша реализация**: APScheduler (in-process) + кастомный in-process `TaskManager`/`JobLifecycle`.

## Краткое резюме (TL;DR)

| Система              | Архитектура                  | Брокер | Распределённость | Интерактивные задачи (AWAITING_*) | Реал-тайм UI/логи | Операционная сложность | Лучше всего для |
|----------------------|------------------------------|--------|------------------|-----------------------------------|-------------------|------------------------|-----------------|
| **Наш (APScheduler + TaskManager)** | In-process (один backend) | Нет   | Только вертикальная | **Отличная** (встроенные)        | **Отличная** (WS + Task Center) | **Низкая**            | Admin tools, интерактивные фоновые задачи, LLM/backup/migration внутри одного приложения |
| **Celery + Beat**    | Producer + Broker + Workers (отдельные процессы) | Обязателен (Redis/Rabbit/...) | **Отличная**    | Сложно (требует кастомизации)    | Средняя (Flower + кастом) | Высокая               | Высоконагруженные распределённые пайплайны, CPU-bound, высокая отказоустойчивость |
| **APScheduler (standalone)** | In-process (или с jobstores) | Нет   | Ограниченная    | Через кастом                | Кастом               | Низкая                 | Простые cron-задачи внутри приложения |
| **Huey**             | Лёгкий (Redis/SQLite)       | Опционально | Хорошая         | Нет                             | Кастом               | Низкая-средняя         | Маленькие/средние приложения |
| **RQ**               | Простой Redis               | Redis | Хорошая         | Нет                             | Кастом               | Низкая                 | Простые очереди |
| **Dramatiq**         | Современный (Redis/Rabbit)  | Обязателен | Хорошая      | Нет                             | Кастом               | Средняя                | Более простая/надёжная замена Celery |
| **ARQ / Taskiq**     | Async-native (Redis-first)  | Redis | Хорошая         | Ограничено                      | Кастом               | Средняя                | FastAPI + высококонкурентные I/O-задачи |
| **Procrastinate**    | Postgres-native             | Нет (Postgres) | Хорошая   | Ограничено                      | Кастом               | Средняя                | Когда не хочется дополнительный брокер |

**Наш главный выигрыш**: глубокая интеграция с UI, человеческие состояния задач (`AWAITING_INPUT`, `AWAITING_MAPPING`), real-time логи через WebSocket и нулевая дополнительная инфраструктура.

**Главный проигрыш**: нет горизонтального масштабирования и автоматической отказоустойчивости при падении процесса.

## Что такое "наш" scheduler и worker (точные факты из кода)

### Scheduler
- Файл: `backend/src/core/scheduler.py`
- `SchedulerService` оборачивает `BackgroundScheduler` (APScheduler 3.11).
- Загрузка: `load_schedules()` очищает все jobs и пересоздаёт из:
  - Backup schedules — из `config.environments[].backup_schedule`.
  - Translation schedules — из таблицы `TranslationSchedule` (is_active).
  - Validation policies — динамический cron + `ThrottledSchedulerConfigurator` (распределение задач внутри окна).
- Триггеры: `CronTrigger.from_crontab(...)` + timezone.
- Мост: `AsyncJobRunner` (отдельный файл) — `run_coroutine_threadsafe` + `call_later` для delayed execution.
- Нет `SQLAlchemyJobStore` / persistent jobstore — расписания восстанавливаются из прикладных таблиц и конфига при старте.

### Worker / Task Execution
- `TaskManager` (фасад) + `JobLifecycle` + `TaskGraph` + `EventBus`.
- Создание: `create_task` → `asyncio.create_task(_run_task)`.
- Выполнение: `plugin.execute(...)` (async или `asyncio.to_thread`).
- Ограничение блокирующих операций: именованные `ThreadPoolExecutor` (db/file/git) — `core/utils/executors.py` (ADR-0011).
- Состояния: `PENDING → RUNNING → SUCCESS/FAILED` + `AWAITING_MAPPING` / `AWAITING_INPUT`.
- Персистентность: отдельная таблица `task_records` + `task_logs` (может быть `TASKS_DATABASE_URL` = основной или sqlite).
- Реал-тайм: `EventBus` (asyncio.Queue) → WS для логов, статуса, событий датасетов.
- Интерактивность: `resume_task_with_password`, `resolve_task` — задачи реально "парятся" и ждут пользователя.
- Деплой: **один контейнер `backend`** (docker-compose.yml). Нет отдельного worker-сервиса.

**ADR-0011** явно отвергает multiprocessing workers и брокер в пользу async + bounded executors внутри процесса.

## Ортогональные проекции (13 измерений)

### 1. Architecture & Deployment Model
**Наш**: Монолитный процесс (API + scheduler + executor).  
**Celery**: Три отдельных роли (app, beat, worker(s)) + брокер.  
**ARQ/Taskiq**: Async workers как отдельные процессы/контейнеры.  
**Huey/RQ**: Лёгкие отдельные worker-процессы.  
**APScheduler standalone**: Обычно в том же процессе, что и приложение.

**Вывод**: Наш — самый простой в деплое (один сервис).

### 2. External Dependencies & Operational Surface
**Наш**: Только основная БД (опционально отдельная для задач). APScheduler — чисто in-memory.  
**Celery**: Брокер + результат + мониторинг (Flower) + beat.  
**Dramatiq/ARQ**: Брокер обязателен.  
**Procrastinate**: Только Postgres.

**Наш выигрывает** по операционной простоте.

### 3. Scheduling (Cron + Dynamic jobs)
**Наш**: Полноценный Cron + динамическое добавление/удаление/перезагрузка из нескольких источников. Throttling внутри окон.  
**Celery Beat**: Cron/interval + `django-celery-beat` для динамики.  
**APScheduler**: Лучший в классе триггеров (date/interval/cron) + jobstores.  
**Huey**: Periodic tasks через `huey.contrib`.  
**RQ**: Нет встроенного — внешний планировщик или rq-scheduler.

**Наш**: Очень удобен для пользовательских расписаний (translate, validation, backup).

### 4. Task Execution Model & Concurrency
**Наш**: asyncio + bounded thread pools внутри event loop. Плагины выполняются в контексте приложения.  
**Celery**: Отдельные процессы (prefork/eventlet/gevent).  
**ARQ/Taskiq**: Нативный asyncio в worker'ах.  
**Dramatiq**: Sync-first (можно с gevent).

Для I/O-heavy (LLM, HTTP к Superset, Git) async-модели (наш + ARQ) эффективнее по вертикали.

### 5. Scalability & Distribution
**Наш**: Только вертикальная (добавить CPU/RAM одной ноде). При нескольких backend'ах — дублирование расписаний.  
**Celery / большинство очередей**: Линейное горизонтальное масштабирование (добавляй workers).  
**APScheduler с RedisJobStore**: Ограниченная распределённость.

**Наш** не предназначен для десятков тысяч задач в минуту.

### 6. Reliability, Resilience & Fault Tolerance
**Наш**:
- Расписания восстанавливаются при рестарте.
- Задачи сохраняют состояние.
- **Проблема**: RUNNING задачи при падении процесса не возобновляются автоматически. AWAITING_* требуют ручного рестарта.
- Нет встроенных ретраев на уровне очереди.

**Celery**: Ack, redeliver, retries, max_retries, dead-letter, result backend.  
**Dramatiq**: Хорошие ретраи по умолчанию.  
**Procrastinate**: Надёжность Postgres.

**Критично для нас**: если задача "перевода 200k строк" упала вместе с backend — нужно перезапускать вручную.

### 7. Task Lifecycle Richness & Advanced Features
**Наш** — лидер в своей нише:
- AWAITING_INPUT (пароли БД)
- AWAITING_MAPPING (разрешение ресурсов)
- TaskContext для structured logging
- Отмена, resume, resolve через API

**Celery**: canvas (chain/group/chord), routing, priority, eta/countdown, rate_limit, task_revocation.  
Остальные: базовые retry + простые очереди. Интерактивность почти ни у кого нет "из коробки".

**Это одно из самых сильных конкурентных преимуществ** нашего решения для инструмента администратора.

### 8. Observability, Monitoring & UX Integration
**Наш**: 
- Нативный Task Status Center (spec 034)
- WebSocket real-time логи + статус
- Фильтры, summary, drawer с логами
- RBAC на уровне задач

**Celery**: Flower (отдельное приложение), Prometheus экспортеры, кастом.  
Другие: обычно только логи + кастомный дашборд.

**Наш** выигрывает для пользователей продукта (не только DevOps).

### 9. Persistence (Schedules + Task State/Results/Logs)
**Наш**: 
- Расписания — в прикладных таблицах + config.
- Задачи/логи — `task_records` / `task_logs` (JSON + отдельная таблица логов).
- Высокопроизводительная батчевая запись логов.

**Celery**: Результаты в отдельном backend (Redis/Postgres/…). Задачи обычно не хранят детальные логи внутри.
**APScheduler + SQLAlchemyJobStore**: Полная персистентность расписаний.
**Huey**: Опционально SQLite/Redis.

### 10. Resource Footprint, Isolation & Performance Profile
**Наш**: Низкий overhead. Всё в одном процессе. Bounded pools дают backpressure.  
**Celery prefork**: Выше потребление памяти, хорошая изоляция.  
**Async workers (ARQ)**: Отличная плотность I/O-задач на ядро.  
**CPU-bound задачи**: Процессные модели лучше (изоляция GIL).

Для наших задач (LLM, Superset API, Git, batch SQL) in-process async + pools работает отлично.

### 11. Ease of Development, Testing & Integration (FastAPI)
**Наш**: Плагины просто реализуют `execute`. Всё в одном codebase. Легко тестировать с TaskContext.  
**Celery**: Отдельный app, сериализация, импорт проблем, тесты сложнее.  
**ARQ/Taskiq**: Хорошая интеграция с FastAPI (async-native).  
**APScheduler**: Самый простой для простых cron.

### 12. Ecosystem, Maturity & Maintenance Burden
- **Celery**: Самая зрелая, огромная экосистема, но репутация "сложная и полна сюрпризов".
- **APScheduler**: Зрелая, активно поддерживается.
- **Dramatiq**: Создавалась как "лучше Celery".
- **ARQ**: От автора Pydantic/FastAPI — отличный современный выбор.
- **Huey/RQ**: Простые, меньше "магии".

Наш — полностью кастомный слой поверх APScheduler. Поддержка ложится на команду проекта.

### 13. Best-fit Use Cases & Trade-off Summary
**Идеально для нас сегодня**:
- Инструмент администратора Superset.
- Задачи с человеческим участием.
- Реал-тайм обратная связь важнее горизонтального масштаба.
- Минимальная операционная нагрузка.

**Когда стоит рассмотреть Celery/ARQ/Dramatiq**:
- Появятся десятки тысяч фоновых задач.
- Нужна настоящая отказоустойчивость (задача должна дожить до выполнения даже при рестарте всего кластера).
- CPU-heavy работа (большие вычисления, не I/O).
- Несколько независимых сервисов, которые должны шарить очередь.

**Гибрид возможен**: оставить текущий механизм для UI-driven и scheduled admin-задач, а тяжёлые batch-операции вынести в отдельную очередь.

## Сравнительная матрица (сводка)

(См. TL;DR таблицу выше + детальные проекции.)

## Рекомендация для superset-tools

**Оставить текущую архитектуру как основную.**

Причины:
- Отлично соответствует текущим потребностям (переводы, бэкапы, валидации, миграции, git).
- Уникальные фичи (AWAITING_*, TaskContext, нативный красивый Task Center) очень ценны для пользователей.
- Низкая операционная сложность — большое преимущество.
- ADR-0011 и вся эволюция проекта сознательно шли в эту сторону.

**Что можно улучшить без революции** (опционально):
- Добавить `SQLAlchemyJobStore` или RedisJobStore для расписаний (защита от потери при странных рестартах).
- Добавить автоматический "reconcile" для зависших RUNNING задач при старте (по таймауту или heartbeat).
- Для очень тяжёлых переводов — рассмотреть возможность выноса в отдельный worker позже.

**Не переходить на Celery "на всякий случай"** — это добавит значительную сложность без немедленной пользы.

## Источники

- Код проекта: `backend/src/core/scheduler.py`, `task_manager/*`, `ADR-0011-async-backend.md`, docker-compose.
- Внешние сравнения:
  - APScheduler vs Celery Beat (leapcell.io, 2025) [web:3].
  - Reddit 2026: "Choosing a Python task queue library".
  - Dramatiq motivation page.
  - ARQ adoption stories и бенчмарки (см. также [web:0], [web:9]).
  - StackShare / официальная документация.

---

*Сравнение выполнено ортогонально — по независимым измерениям, без навязывания одного "лучшего" решения.*