О проекте TapVisor
Предназначение системы
Система предназначена для сбора информации с распределённой сети датчиков, хранения информации о событиях и обработке данных - выдачи уведомлений о наступлении тех или иных событий, построении отчётов, выдаче аналитических срезов.
Система ориентирована на B2B и представляет из себя SaaS. Клиент создаёт в системе организацию к которой подключаются источники данных, собирающие информацию на торговых точках или точках автоматизации.
Система спроектирована максимально абстратно, таким образом можно собирать самую разнообразную информацию и автоматизировать такие задачи как:
- контроль температурного диапазона;
- контроль влажности;
- сбор информации о торговле товаром;
- контроль налива жидкого товара;
- контроль наличия объекта на базе - например для проката.
В данный момент система собирает такую информацию:
- события о продажах вина и пива;
- прокат туристического оборудования на точках проката;
- температуру на большом количестве пивных кранов в пабе.
При необходимости, к системе могут быть подключены новые источники данных. Например, если клиенту необходимо считать сколько человек проходит сквозь дверной проход, мы можем разработать контроллер для подсчёта проходящих людей и передачи событий на центральный сервер. После чего клиент сможет в веб-интерфейсе просматривать информацию о количестве людей, прошедших сквозь дверной проход.
Если бизнес-процессы клиента связаны с контроллем влажности, например это может быть хранение и торговля сигарами, торговля гигроскопичным товаром и т.д., может быть создано решение, предоставляющее контроль за режимом влажности и информирование о выходе показаний влажности за границы допустимого режима.
Для сбора информации могут быть использованы как специализированные контроллеры так и решение с необслуживаемыми компьютерами -
Raspberry Pi, Orange Pi, etc. Такое решение позволяет максимально быстро выполнить автоматизацию объекта, а в дальнейшем, при необходимости произвести специализированный контроллер.
Система изначально проектировалась для работы с клиентами из разных часовых зон, события в центральной БД имеют несколько атрибутов дата/время, с учётом временных зон. При проектировании контроллеров и кеширующих узлов на базе RPi максимальное внимание было уделено работе в среде с задержками и сбоями при передаче данных. Для обеспечения безопасности, передача данных осуществляется с использованием RSA + PKCS1_v1_5 + AES (для мощных кеширующих узлов) либо с использованием алгоритма
Speck для слабых контроллеров.
Где и как это можно увидеть
В системе предусмотрен демо-режим, позволяющий ознакомиться с интерфейсом, для полученя доступа к демо-режиму можно войти в систему
http://tapvisor.com с таким данными:
Login : "demo" (без кавычек)
Password : "demo" (без кавычек)
В этом режиме можно увидеть часть функциональности, доступной владельцу организации подключённой к сервису TapVisor. Эта демо-организация состоит из трёх торговых точек по продаже пива:
- Cork / Пробка
- Roger's Place / У Роджера
- The Pub / Пивбар
и торгуёт такими товарами:
- Ginger Beer / Имбирное
- Lager Beer / Светлое
- Light Ale / Эль
- Porter / Тёмное
Среди виджетов можно отметить такие:
- Sales - выручка по магистралям за сегодня и вчера;
- Dashboard - аналитика по продажам, более подробно вы можете прочитать тут http://tapvisor-help-ru.aminis.com.ua/dashboard
- Charts - здесь можно построить графики о продажах по часам, по дням;
- Reports/Sales-products - информация о продажах товара с возможностью наложения фильтров по точкам, дням;
- Director of the world - карта с отметками всех точек. Цветом и текстом можно визуализировать самую важную информацию: выручку за день, состояние остатков, то насколько был выполнен план на день и т.д.;
- Stock/Parameters - контроль остатков на точке, предоставляется информацию о том сколько товара того или иного типа осталось на магистралях точки;
- Reports/All events - список все событий, происходящих на точке
Особенности режима:
- в этом режиме нет доступа к изменению настроек;
- предоставляется доступ к данным с 2017-02-20;
- предоставлен доступ не ко всем виджетам;
- возможности системы и распределение возможностей по тарифам можно посмотреть тут: http://tapvisor.com/tariffs
Как это устроено внутри
Back-end
Система написана на Python, используя Flask и SQLAlchemy. В качестве СУБД используется PostgreSQL, для LRU кеша использован Redis. Используется связка nginx и uwsgi.
Для оптимизации скорости выполнения запросов используется:
- roll-up's (свертки) для событий, используемых для построения Dashboard;
- sharding - на базе Citus single-machine cluster с некоторым количеством worker'ов, обрабатывающих шарды. Шардинг используется в режиме multi-tenant application c table co-location, что обеспечивает обработку SQL запросов в пределах одного шарда;
- фоновое вычисление данных которые могут в будущем понадобиться пользователю;
- кеширование результатов запросов и тех данных, что могут понадобиться пользователю в Redis;
- концепция "горячего архива" - архив за последние несколько дней для "горячих клиентов" (активных пользователей). Более старые события хранятся в "обычном/холодном архиве";
Используемая OS - Debian.
Настроена автоматическая репликация баз данных, автоматическое создание и передача резервных копий БД.
Front-end
Используется TypeScript и Bootstrap, позволяющий корректно отображать сайт на старых версиях iOS и обеспечивающий совместимость с максимальным количеством браузеров.
Используемые библиотеки: Nodejs + webpack + typescript + jQuery + bootstrap
Визуализация таблиц (с поддержкой тонких настроек рендеринга, pagination и динамической подгрузки данных) -
DataTables.
Как это было сделано
Для управления проектом использовалась такие инструменты как:
- Redmine - управление проектом;
- git - контроль версий;
- Google Drive/Google Docs - хранение протоколов, документации на узлы системы, описание протоколов взаимодействия узлов системы.
Подобный подход позволил максимально эффективно, с наименьшим уровнем бюрократии и минимальной тратой времени, выполнять действия и координировать работу всех разработчиков.
После того как в системе были накоплены данные мы приступили к оптимизации, проходившей по следующему алгоритму:
- мы выявляли медленно работающие виджеты и сопоставляли фактически обнаруженное с нашими предсказаниями о том, что и как будет замедляться;
- выполняли профилирование;
- искали методики, позволяющие выполнить оптимизацию;
- тестировали и внедряли решение по оптимизации.
Что самое важное в оптимизации? Можно отметить такие моменты как:
- накопление данных в БД, при этом параллельно необходимо выдвигать предположения о том какие ожидаются результаты по работе того или иного виджета;
- тщательное профилирование и поиск того что на самом деле медленно работает, а только затем оптимизация.
Надеюсь вам нравится результат.
Приятного использования.