Geek & Curt
Слушай, никогда не думал автоматизировать наши квартальные отчёты по KPI? Можно было бы через небольшой Flask-сервис и Celery, чтобы время подготовки сильно сократить.
Конечно, но нам нужен чёткий источник данных, аутентификация и план тестирования в первую очередь. Убедись, что Flask-сервис интегрируется с нашей текущей BI-платформой, настрои расписание для Celery-воркеров и следи за сбоями. Если ты предоставишь спецификации, мы сможем создать прототип и сократим время на подготовку.
Окей, вот черновик основных требований:
1. Источник данных: Нужно выгружать необработанные таблицы KPI из BI-хранилища SQL-Server через пользователя с правами только на чтение. Используй ORM-слой (SQLAlchemy), чтобы Flask-приложение могло запрашивать данные с помощью простых объектов модели.
2. Аутентификация: Оберни Flask-endpoints в OAuth2, используя корпоративный IdP. Сервис будет запрашивать токен короткой жизни, проверять его при каждом запросе и регистрировать пользователя для аудита.
3. API: Разверни один GET-endpoint `/kpi-summary`, возвращающий JSON. Он принимает необязательные параметры start/end dates; по умолчанию – последний финансовый квартал.
4. Celery workers:
– Используй Redis в качестве брокера.
– Запланируй ежедневную задачу на 02:00 UTC для предварительного вычисления KPI summary за предыдущий день.
– Workers записывают результаты в таблицу кэша в BI-хранилище.
5. Мониторинг:
– Отправляй Celery heartbeat в Prometheus.
– Оповещай об ошибках задач, длине очереди > 10 или задержке worker > 5 секунд.
– Логгируй каждый API-запрос/ответ с request ID, пользователем и временем обработки.
6. План тестирования:
– Unit-тесты для Flask-маршрутов (с подменой DB).
– Integration-тесты: поднимай тестовую DB, запускай Celery-задачу, проверяй таблицу кэша.
– Load-тест: 100 одновременных GET `/kpi-summary` запросов, обеспечь 99.5% в пределах 200 мс.
7. Развертывание: Контейнеризируй с Docker, присвой версию, отправляй в registry, запускай с Docker-Compose (Flask, Celery worker, Redis, Prometheus exporter).
Если это соотносится с тем, что тебе нужно, я могу начать создание структуры репозитория и написать первый маршрут. Просто дай мне учетные данные DB и детали IdP.
Выглядит надёжно. Я вытащу учётные данные для базы данных только для чтения и конфигурацию IdP из хранилища секретов. Дай краткую информацию о предполагаемой структуре таблицы кэша и отображении полей для сводки KPI, чтобы я мог настроить ORM-модели. Как только будет готов каркас репозитория, я начну проработку Flask-маршрутов и напишу юнит-тесты. Сообщи, нужна ли задаче очереди особые условия повторных попыток.
Привет,
Схема таблицы кэша:
- id BIGINT PRIMARY KEY auto_increment
- kpi_id INT NOT NULL (ссылка на основной список KPI)
- period_start DATE NOT NULL
- period_end DATE NOT NULL
- metric_value DECIMAL(18,4) NOT NULL
- generated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
Поля сводки KPI (JSON, возвращается из /kpi-summary):
- kpiId (int) → kpi_id
- period (объект) с startDate/endDate (dates) → period_start, period_end
- value (float) → metric_value
- source (“BI_warehouse”) и timestamp (generated_at)
Логика повторных попыток: Celery должен повторять неудавшиеся задачи KPI до 5 раз с экспоненциальной задержкой (2, 4, 8, 16, 32 секунды). Если задача все еще не выполняется, отмечай в таблице кэша колонкой статуса (0=ok, 1=error) и отправь уведомление в Slack. Это должно поддерживать порядок в очереди. Если нужно разбить это более детально, скажи.
Понял. Добавлю колонку статуса в таблицу кэша, настрою политику повторных попыток в Celery, и подключу Slack вебхук для уведомлений. Как только будет готова структура репозитория, закину credentials в сейф, и сможем поднимать контейнерный стек. Дай знать, если хочешь, чтобы маршрут поддерживал пагинацию или фильтрацию, кроме дат.