Comments 5
Линк на flowmap в интро: https://app.flowmap.city/public/74c17089-9745-4a1c-9ef1-0237d498b16b
Интересное решение отказаться от Kafka. Согласен, что для pull-паттерна с фиксированным интервалом это overhead. Но если в будущем API 3TM перейдёт на push-модель или добавятся другие источники событий (например, инциденты на дорогах) — не придётся ли переосмыслить архитектуру? Или заложен какой-то запас под это?
Сдаётся мне, что сжав телеметрию в PostGIS LineString вы потеряли кучу полезных данных для анализа и сопоставления (паттерны пробок, заторов, простоев и пр.) Не пробовали PostGIS + TimescalеDB для хранения телеметрии с временными метками?
И при очистке данных использование фактора отклонения от маршрута на 200 метров — тоже довольно спорное решение (объезд заторов, сход с маршрута..) Хотя конечно зависит от задачи - если нужно только прогнозировать прибытие на остановках — то Ок, а если с позиций управления хозяйством, то не не очень)
Сжатие телеметрии нужно для упрощения аналитических вычислений. Детальная телеметрия хранится в слое ODS максимум 7 дней учитывая ограничение диска. Насчет TimescaleDB - думал над реализацией, но не стал сильно заморачиваться из-за MVP.
Насчет очистки данных - вы правы, это всё зависит от цели задачи :)
Как я обрабатываю 15 миллионов GPS-пингов в день для системы транспортной аналитики Ташкента