Квартальный harvest НСПД не догоняет устаревание: 50 кварталов в неделю на 11 048 — покрытие сходится к 6% #3175

New issue

Open

opened 2026-08-27 22:02:51 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-08-27 22:02:51 +00:00

Collaborator

Выделено при закрытии #2956 (27.08). Не следствие блокировки НСПД — было верно и до неё.

Арифметика

backend/app/workers/beat_schedule.py:464-469:

schedule["nspd-harvest-stale-quarters"] = {
    "schedule": _parse_cron("0 4 * * mon"),        # раз в неделю
    "kwargs": {"region_code": 66, "max_age_days": 90, "batch_size": 50},
}

50 кварталов в неделю. Кварталов в cad_quarters_geom — 11 048. Дампов накоплено за всё время — 669 (589 успешных, 80 с ошибкой).

Полное первичное покрытие при таком темпе: 11 048 / 50 = 221 неделя ≈ 4,2 года. При этом max_age_days = 90 означает, что дамп протухает через 13 недель — то есть темп обновления вчетверо медленнее темпа устаревания. Стационарное покрытие не достигается вообще: доля свежих дампов сходится не к 100%, а к величине порядка 650 / 11 048 ≈ 6%.

Почему это стоит поправить

Комментарий прямо над расписанием говорит: «при 11k+ кварталов в cad_quarters_geom полный backfill займёт несколько недель». Расхождение с фактом — примерно в пятьдесят раз. Это не опечатка в комментарии, а расхождение модели с реальностью: тот, кто выбирал batch_size, считал по другой оценке объёма.

Практическое следствие: §6 отчёта и всё, что строится на тер-зонах квартала, для 94% кварталов области опирается на ленивый триггер при генерации отчёта, а не на предварительно собранные данные. Ленивый путь работает, но платит задержкой в момент показа отчёта пользователю и не защищён от блокировки источника.

Что решить

Либо поднять темп до величины, при которой покрытие сходится (порядок сотен кварталов в неделю или ежедневный тик), либо честно признать, что предварительный сбор покрывает только приоритетное подмножество, и записать, какое именно — например, кварталы с активными участками или те, по которым уже были отчёты.

Первое упирается в аппетит НСПД (batch_size выбран как защита от WAF rate-limit burst — и, судя по августу, защита не лишняя). Второе честнее и дешевле, но требует явного критерия приоритета.

Решение за владельцем: оба пути — размен между полнотой и риском снова получить блок.

Приёмка

Выбран путь: догоняющий темп или явно ограниченное подмножество
Комментарий у расписания приведён в соответствие с фактической арифметикой
Если поднимается темп — измерено, при каком значении НСПД начинает отвечать таймаутами, и оставлен запас
Видно, какая доля кварталов покрыта свежими дампами (метрика, а не разовый запрос)

Refs #2956, #3078

Выделено при закрытии #2956 (27.08). Не следствие блокировки НСПД — было верно и до неё. ## Арифметика `backend/app/workers/beat_schedule.py:464-469`: ``` schedule["nspd-harvest-stale-quarters"] = { "schedule": _parse_cron("0 4 * * mon"), # раз в неделю "kwargs": {"region_code": 66, "max_age_days": 90, "batch_size": 50}, } ``` 50 кварталов в неделю. Кварталов в `cad_quarters_geom` — **11 048**. Дампов накоплено за всё время — **669** (589 успешных, 80 с ошибкой). Полное первичное покрытие при таком темпе: 11 048 / 50 = **221 неделя ≈ 4,2 года**. При этом `max_age_days = 90` означает, что дамп протухает через 13 недель — то есть темп обновления вчетверо медленнее темпа устаревания. Стационарное покрытие не достигается вообще: доля свежих дампов сходится не к 100%, а к величине порядка 650 / 11 048 ≈ **6%**. ## Почему это стоит поправить Комментарий прямо над расписанием говорит: «при 11k+ кварталов в `cad_quarters_geom` полный backfill займёт несколько недель». Расхождение с фактом — примерно в пятьдесят раз. Это не опечатка в комментарии, а расхождение модели с реальностью: тот, кто выбирал `batch_size`, считал по другой оценке объёма. Практическое следствие: §6 отчёта и всё, что строится на тер-зонах квартала, для 94% кварталов области опирается на ленивый триггер при генерации отчёта, а не на предварительно собранные данные. Ленивый путь работает, но платит задержкой в момент показа отчёта пользователю и не защищён от блокировки источника. ## Что решить Либо поднять темп до величины, при которой покрытие сходится (порядок сотен кварталов в неделю или ежедневный тик), либо честно признать, что предварительный сбор покрывает только приоритетное подмножество, и записать, какое именно — например, кварталы с активными участками или те, по которым уже были отчёты. Первое упирается в аппетит НСПД (`batch_size` выбран как защита от WAF rate-limit burst — и, судя по августу, защита не лишняя). Второе честнее и дешевле, но требует явного критерия приоритета. Решение за владельцем: оба пути — размен между полнотой и риском снова получить блок. ## Приёмка - [ ] Выбран путь: догоняющий темп или явно ограниченное подмножество - [ ] Комментарий у расписания приведён в соответствие с фактической арифметикой - [ ] Если поднимается темп — измерено, при каком значении НСПД начинает отвечать таймаутами, и оставлен запас - [ ] Видно, какая доля кварталов покрыта свежими дампами (метрика, а не разовый запрос) Refs #2956, #3078

bot-backend added the

labels 2026-08-27 22:02:51 +00:00

bot-backend commented

2026-09-02 06:58:06 +00:00

Author

Collaborator

Точный замер армейского аудита 02.09 (подтверждён скептиком на проде): stale-кварталов 10 553, за всю историю харвеста покрыто 669 различных, свежих (< 90 дн) — 495. Потолок арифметики: 50/нед × 90дн/7 ≈ 643 квартала — примерно и наблюдаем. Вдобавок ORDER BY cad_number (nspd_sync.py:426-443) гоняет один и тот же префикс: 94% кварталов не харвестились НИ РАЗУ. Компенсирующих механизмов нет. То есть проблема не «не догоняет», а «по построению не может догнать» — нужна либо ставка ×16, либо явное решение сузить надзор до подмножества и написать это в UI.

Точный замер армейского аудита 02.09 (подтверждён скептиком на проде): stale-кварталов **10 553**, за всю историю харвеста покрыто **669 различных**, свежих (< 90 дн) — **495**. Потолок арифметики: 50/нед × 90дн/7 ≈ **643 квартала** — примерно и наблюдаем. Вдобавок `ORDER BY cad_number` (nspd_sync.py:426-443) гоняет один и тот же префикс: 94% кварталов не харвестились НИ РАЗУ. Компенсирующих механизмов нет. То есть проблема не «не догоняет», а «по построению не может догнать» — нужна либо ставка ×16, либо явное решение сузить надзор до подмножества и написать это в UI.