О проекте TapVisor

О проекте TapVisor 

Предназначение системы

Система предназначена для сбора информации с распределённой сети датчиков, хранения информации о событиях и обработке данных - выдачи уведомлений о наступлении тех или иных событий, построении отчётов, выдаче аналитических срезов.

Система ориентирована на B2B и представляет из себя SaaS. Клиент создаёт в системе организацию к которой подключаются источники данных, собирающие информацию на торговых точках или точках автоматизации.

Система спроектирована максимально абстратно, таким образом можно собирать самую разнообразную информацию и автоматизировать такие задачи как:

1. контроль температурного диапазона;
2. контроль влажности;
3. сбор информации о торговле товаром;
4. контроль налива жидкого товара;
5. контроль наличия объекта на базе - например для проката.

В данный момент система собирает такую информацию:

1. события о продажах вина и пива;
2. прокат туристического оборудования на точках проката;
3. температуру на большом количестве пивных кранов в пабе.

При необходимости, к системе могут быть подключены новые источники данных. Например, если клиенту необходимо считать сколько человек проходит сквозь дверной проход, мы можем разработать контроллер для подсчёта проходящих людей и передачи событий на центральный сервер. После чего клиент сможет в веб-интерфейсе просматривать информацию о количестве людей, прошедших сквозь дверной проход.

Если бизнес-процессы клиента связаны с контроллем влажности, например это может быть хранение и торговля сигарами, торговля гигроскопичным товаром и т.д., может быть создано решение, предоставляющее контроль за режимом влажности и информирование о выходе показаний влажности за границы допустимого режима.

Для сбора информации могут быть использованы как специализированные контроллеры так и решение с необслуживаемыми компьютерами - Raspberry Pi, Orange Pi, etc. Такое решение позволяет максимально быстро выполнить автоматизацию объекта, а в дальнейшем, при необходимости произвести специализированный контроллер.

Система изначально проектировалась для работы с клиентами из разных часовых зон, события в центральной БД имеют несколько атрибутов дата/время, с учётом временных зон. При проектировании контроллеров и кеширующих узлов на базе RPi максимальное внимание было уделено работе в среде с задержками и сбоями при передаче данных. Для обеспечения безопасности, передача данных осуществляется с использованием RSA + PKCS1_v1_5 + AES (для мощных кеширующих узлов) либо с использованием алгоритма Speck для слабых контроллеров.

Где и как это можно увидеть

В системе предусмотрен демо-режим, позволяющий ознакомиться с интерфейсом, для полученя доступа к демо-режиму можно войти в систему http://tapvisor.com с таким данными:

Login    : "demo" (без кавычек)

Password : "demo" (без кавычек)

В этом режиме можно увидеть часть функциональности, доступной владельцу организации подключённой к сервису TapVisor. Эта демо-организация состоит из трёх торговых точек по продаже пива:

1. Cork / Пробка
2. Roger's Place / У Роджера
3. The Pub / Пивбар

и торгуёт такими товарами:

1. Ginger Beer / Имбирное
2. Lager Beer / Светлое
3. Light Ale / Эль
4. Porter / Тёмное 

Среди виджетов можно отметить такие:

• Sales - выручка по магистралям за сегодня и вчера;
• Dashboard - аналитика по продажам, более подробно вы можете прочитать тут http://tapvisor-help-ru.aminis.com.ua/dashboard
• Charts - здесь можно построить графики о продажах по часам, по дням;
• Reports/Sales-products - информация о продажах товара с возможностью наложения фильтров по точкам, дням;
• Director of the world - карта с отметками всех точек. Цветом и текстом можно визуализировать самую важную информацию: выручку за день, состояние остатков, то насколько был выполнен план на день и т.д.;
• Stock/Parameters - контроль остатков на точке, предоставляется информацию о том сколько товара того или иного типа осталось на магистралях точки;
• Reports/All events - список все событий, происходящих на точке

Особенности режима:

1. в этом режиме нет доступа к изменению настроек;
2. предоставляется доступ к данным с 2017-02-20;
3. предоставлен доступ не ко всем виджетам;
4. возможности системы и распределение возможностей по тарифам можно посмотреть тут: http://tapvisor.com/tariffs

Как это устроено внутри

 Back-end

Система написана на Python, используя Flask и SQLAlchemy. В качестве СУБД используется PostgreSQL, для LRU кеша использован Redis. Используется связка nginx и uwsgi.

Для оптимизации скорости выполнения запросов используется:

1. roll-up's (свертки) для  событий, используемых для построения Dashboard;
2. sharding - на базе Citus single-machine cluster с некоторым количеством worker'ов, обрабатывающих шарды. Шардинг используется в режиме multi-tenant application c table co-location, что обеспечивает обработку SQL запросов в пределах одного шарда;
3. фоновое вычисление данных которые могут в будущем понадобиться пользователю;
4. кеширование результатов запросов и тех данных, что могут понадобиться пользователю в Redis;
5. концепция "горячего архива" - архив за последние несколько дней для "горячих клиентов" (активных пользователей). Более старые события хранятся в "обычном/холодном архиве";

Используемая OS - Debian.

Настроена автоматическая репликация баз данных, автоматическое создание и передача резервных копий БД.

Front-end

Используется TypeScript и Bootstrap, позволяющий корректно отображать сайт на старых версиях iOS и обеспечивающий совместимость с максимальным количеством браузеров.

Используемые библиотеки: Nodejs + webpack + typescript + jQuery + bootstrap 

 

Для визуализации графиков используются  Highcharts

Визуализация таблиц (с поддержкой тонких настроек рендеринга, pagination и динамической подгрузки данных) -  DataTables.

Как это было сделано

Для управления проектом использовалась такие инструменты как:

1. Redmine - управление проектом;
2. git - контроль версий;
3. Google Drive/Google Docs - хранение протоколов, документации на узлы системы, описание протоколов взаимодействия узлов системы.

Подобный подход позволил максимально эффективно, с наименьшим уровнем бюрократии и минимальной тратой времени, выполнять действия и координировать работу всех разработчиков.

После того как в системе были накоплены  данные мы приступили к оптимизации, проходившей по следующему алгоритму:

1. мы выявляли медленно работающие виджеты и сопоставляли фактически обнаруженное с нашими предсказаниями о том, что и как будет замедляться;
2. выполняли профилирование;
3. искали методики, позволяющие выполнить оптимизацию;
4. тестировали и внедряли решение по оптимизации.

Что самое важное в оптимизации? Можно отметить такие моменты как:

1. накопление данных в БД, при этом параллельно необходимо выдвигать предположения о том какие  ожидаются результаты по работе того или иного виджета;
2. тщательное профилирование и поиск того что на самом деле медленно работает, а только затем оптимизация.

Надеюсь вам нравится результат.

Приятного использования.