Как я обрабатываю 15 миллионов GPS-пингов в день для системы транспортной аналитики Ташкента

[root_ogg]

Линк на flowmap в интро: https://app.flowmap.city/public/74c17089-9745-4a1c-9ef1-0237d498b16b

[erkinov_wiz]

Интересное решение отказаться от Kafka. Согласен, что для pull-паттерна с фиксированным интервалом это overhead. Но если в будущем API 3TM перейдёт на push-модель или добавятся другие источники событий (например, инциденты на дорогах) — не придётся ли переосмыслить архитектуру? Или заложен какой-то запас под это?

[root_ogg]

У меня микросервисная архитектура. При смене стека можно просто модифицировать определенный “Loader” и все :)

[Adgh]

Сдаётся мне, что сжав телеметрию в PostGIS LineString вы потеряли кучу полезных данных для анализа и сопоставления (паттерны пробок, заторов, простоев и пр.) Не пробовали PostGIS + TimescalеDB для хранения телеметрии с временными метками?

И при очистке данных использование фактора отклонения от маршрута на 200 метров — тоже довольно спорное решение (объезд заторов, сход с маршрута..) Хотя конечно зависит от задачи - если нужно только прогнозировать прибытие на остановках — то Ок, а если с позиций управления хозяйством, то не не очень)

[root_ogg]

Сжатие телеметрии нужно для упрощения аналитических вычислений. Детальная телеметрия хранится в слое ODS максимум 7 дней учитывая ограничение диска. Насчет TimescaleDB - думал над реализацией, но не стал сильно заморачиваться из-за MVP.

Насчет очистки данных - вы правы, это всё зависит от цели задачи :)

[keinohrhasen_pitersky]

Сардор, привет!

Визуализация выглядит симпатично + для транспортных инженеров даже такие данные были бы полезны. В России некоторые города пошли чуть другим путем и накрутили на камеры модуль матриц корреспонденций. По ГРЗ, цвету и т.д. вполне можно сопоставить куда, где и когда идет автобус. Правда, мы еще вместе с тем исследовали занятость общественного транспорта, опять же, через камеры. В общем, спасибо. Было интересно