Tuesday, March 7, 2017

О проекте 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. тщательное профилирование и поиск того что на самом деле медленно работает, а только затем оптимизация.
Надеюсь вам нравится результат.

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

No comments:

Post a Comment