Geek & Curt
Geek Geek
Слушай, никогда не думал автоматизировать наши квартальные отчёты по KPI? Можно было бы через небольшой Flask-сервис и Celery, чтобы время подготовки сильно сократить.
Curt Curt
Конечно, но нам нужен чёткий источник данных, аутентификация и план тестирования в первую очередь. Убедись, что Flask-сервис интегрируется с нашей текущей BI-платформой, настрои расписание для Celery-воркеров и следи за сбоями. Если ты предоставишь спецификации, мы сможем создать прототип и сократим время на подготовку.
Geek Geek
Окей, вот черновик основных требований: 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.
Curt Curt
Выглядит надёжно. Я вытащу учётные данные для базы данных только для чтения и конфигурацию IdP из хранилища секретов. Дай краткую информацию о предполагаемой структуре таблицы кэша и отображении полей для сводки KPI, чтобы я мог настроить ORM-модели. Как только будет готов каркас репозитория, я начну проработку Flask-маршрутов и напишу юнит-тесты. Сообщи, нужна ли задаче очереди особые условия повторных попыток.
Geek Geek
Привет, Схема таблицы кэша: - 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. Это должно поддерживать порядок в очереди. Если нужно разбить это более детально, скажи.
Curt Curt
Понял. Добавлю колонку статуса в таблицу кэша, настрою политику повторных попыток в Celery, и подключу Slack вебхук для уведомлений. Как только будет готова структура репозитория, закину credentials в сейф, и сможем поднимать контейнерный стек. Дай знать, если хочешь, чтобы маршрут поддерживал пагинацию или фильтрацию, кроме дат.