Что под капотом у Умного Ташкента?

Привет, Хабр! Вот, прошли майские праздники, и я готов поделиться с вами подробностями нашего проекта по цифровизации Ташкента. В конце концов, наша референсная модель может помочь в цифровизации других городов. И в этом посте мы подробнее разберем вопросы интеграции между различными компонентами, механику взаимодействия с Visiology BI и Геоинтеллект, а также ряд интересных на мой взгляд технических вопросов. Я покажу, как в нашей системе реализована поддержка процессов укладки асфальта, аналитики по видео, загрузки огромных массивов данных из различных ведомств.

После публикации первого поста мне очень приятно было получить столько позитивных откликов, и я надеюсь, что подобные ситуационные центры появятся в городах Узбекистана, России и других стран. А значит, чтобы сэкономить время коллегам, нужно немного подробнее рассказать об архитектуре решения. К тому же, я уверен, что она может быть использована для реализации других внедрений геоинформационных сервисов или адаптации Visiology BI для обработки больших объемов постоянно меняющейся информации. Итак, если вы уже читали предыдущий пост, то давайте сразу к делу.

Интеграционная шина ГРАФИТИШ

Чтобы экосистема микросервисов работала стабильно, мы создали дополнительную интеграционную шину. Сначала это решение не выглядело слишком очевидным, ведь между подсистемами “Цифрового Ташкента” изначально существовала возможность интеграции через Rest API. Однако кроме удачной стыковки API 67 систем (а это довольно много) требовали пристального мониторинга. И реализовать их без единой шины было бы сложно.

К тому же часть данных мы получаем через государственную шину данных Министерства связи. Межправительственная интеграционная платформа (МИП) была создана для того, чтобы дублировать все данные госорганов и снизить количество подключений к серверам ведомств. Ее задача — помочь госорганам избежать проблем с постоянной нехваткой мощностей, и это хорошо. Но для нас это означало, что с МИП тоже нужно выстраивать обмен данными. Чтобы все работало корректно, мы должны выставлять периоды скачивания данных (часто это ночное время из-за большой нагрузки на интернет канал днем у тех ведомств, от которых мы получаем информацию), а также перестыковывать API, если типы данных или форматы меняются.

Назвали мы ее ГРАФИТИШ. Тут уже нет никакой дополнительной поэтичности — просто добавили к названию ГРАФИТ словосочетание Интеграционная Шина. Создавалась она почти столько же, сколько и сам ГРАФИТ, так как нельзя создать интеграционную шину и закончить её. Это не свечка, произвел вот тебе готовый продукт и продал…или воспользовался и забыл. Тут приходится снова и снова подстраиваться под постоянно меняющиеся технологии, под новые виды данных которые появляются с достаточно высокой частотой. Вы можете все настроить и автоматизировать затем просто обслуживать её чистить от логов и т.д, но все равно придет время и вам придется снова засучить рукава, чтобы спроектировать еще более эффективную архитектуру для работ с данными, которые со временем изменили ваш ландшафт.

Нет, вы, конечно, можете этого не делать. Зачем, ведь все работает? Но стоит посмотреть на скорость работы СУБД, когда их объемы перевалят за петабайты однородных и терабайты неоднородных данных…и ответ напрашивается сам собой. Если быть точным, то основная архитектура шины была написана за 3-4 месяца, а затем добавляли новые модули для интеграции. В результате вся система была построена полностью на нашем собственном решении.

Создавая шину данных мы стремились сделать все возможное, чтобы не превращать ГРАФИТ в огромную махину, которую нельзя будет потом сдвинуть с места. Нужно было предусмотреть, как реагирует вся экосистема, если какой-то из шлюзов отключается, одна из виртуальных машин перестанет функционировать или происходит что-то еще непредвиденное. В результате интеграционная шина ГРАФИТИШ позволяет подключать различные виды данных в нашу ГИС- и BI-системы. Так как информации много (очень много), шина начала оправдывать свое наличие еще на начальном этапе проекта.

На сегодняшний день ГРАФИТИШ объединяет порядка 60 источников данных. Часть информации  мы на лету превращаем в геоданные и отображаем в ГРАФИТе на базе ПО “Геоинтеллект”, а другая часть уходит Visiology для построения дашбордов и визуализаций.

Все данные госорганов проходят по защищенному каналу МСПД через стыкующиеся веб сервисы (API) и через ГРАФИТИШ передаются в базу данных Visiology. Обработанные данные попадают в ГРАФИТ и на сайт, на котором размещены дашборды для отображения данных BI-системы.

Как данные попадают в Visiology. Подробнее

Разберем этот процесс пошагово:

1. Делаем запрос на интеграцию с организациями.
2. Получаем API (get/post запрос). В случае get, мы отправляем в параметрах дату запрашиваемых данных…либо контрагент отправляет нам всю актуальную базу. В случае post, мы договариваемся насчет json структуры и получаем только измененные или добавленные данные. Далее мы записываем их в базу одним из следующих способов в зависимости от вложенности json:
   1. В первом случае, если нет вложенных массивов или json’ов используем библиотеки requests, pandas, sqlalchemy.
   2. Во втором случае, если есть вложенные массивы или json’ы, то мы вручную делаем распрарсинг.

Для контроля ETL используем библиотеку airflow для python.

Определяем период загрузки данных. Это зависит от самого поставщика данных, а именно — как часто в их базе происходят изменения. Обычно это происходит раз в день. Но в некоторых случаях — в онлайн режиме.

3. Visiology тянет всю базу в ViQube. Для этого движок отправляет запрос в СУБД и вытягивает данные в свое временное хранилище. Запрос происходит через postgres connection ODBC. Затем настраивается тип данных, задаем измерения и показатели и загружаем в Visiology.

Что касается базы данных, вся информация изначально размещалась в PostgreSQL, и размещается там сегодня. Мы установили для себя самый приемлемый и понятный инструмент, чтобы в какой-то момент не возникло зоопарка разных видов БД. Тут не о чем спорить. Думаю, всем и так понятно, почему мы выбрали открытую СУБД. Это решение было хорошо знакомо всей команде, и мы прекрасно понимали, на что она способна, и как с ней работать. Так что весь департамент сразу занял позицию: “PostgreSQL и точка”.

Загрузка данных в Visiology

Для передачи данных в аналитическую базу Visiology предусмотрено несколько типов загрузчиков:

1. Самый простой способ получения данных – это загрузка простой таблицы в CSV или XLSX формате, причем работает этот механизм достаточно удобно — файл может быть загружен из сетевой папки.

2. Для загрузки данных из СУБД используются SQL-запросы. ViQube совместим с любой реляционной СУБД, предоставляющей JDBC драйвер, например, Microsoft SQL Server, Oracle, MySQL, PostgreSQL, HP Vertica и другими.

Но если с загрузкой простой таблицы всё интуитивно понятно, то передачей данных через API в СУБД стоить немного поработать. API приходится настраивать программистам с обеих сторон (получателя и отправителя данных). После настройки API, аналитики производят первичный осмотр данных на предмет наличия некорректных значений. И этот предпроцессинг обязателен.

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

Расчетливый и одновременно творческий подход аналитика позволяет построить с помощью Visiology информативный и легко читаемый дашборд. Это очень интересная возможность, и я хочу еще раз отдельно остановиться на таком функционале Visiology BI, как конструктор дашбордов. Он позволяет быстро создавать интерактивные и красочные отчёты практически любой сложности на основе объединенных данных из различных источников – учетных систем, различных СУБД, систем обработки Big Data, а также данных, собранных вручную через Excel или с помощью Smart Forms. На сегодняшний день мы используем самую актуальную версию Visiology Platform 2.26, которая обеспечивает ряд оптимизаций, в том числе более гибкую работу с данными при создании дашборда, возможность отмены неактуальных запросов, улучшения сортировки при сборе в Smart Forms и так далее. Для интересующихся, более подробно новшства платформы описаны здесь.

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

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

Интеграция между Visiology BI и Геоинтеллект

Теперь несколько слов о совместной работе BI и геоаналитики. В ПО Visiology имеется картографическая подложка, как и в любой другой развитой BI-системе. Но в работе нашего Ситуационного Центра сделан упор на геоаналитику. А функционал геоинформационной системы — шире, чем отображение картограмм в BI. Чтобы продвинуться в этом направлении нам пришлось изучить западный опыт, который показал, что  вендоры BI и GIS часто интегрируются и продают совместные решения. В последнее время появляется даже новый класс систем Location Intelligence, которые решают отраслевые задачи со всеми преимуществами GIS и BI.

Чтобы добиться такой синергии, мы проводили интеграцию между двумя основными системами ГРАФИТа — Visiology и Геоинтеллект. Задача решалась в два этапа.

1. Первый этап — внедрение единой системы идентификации для пользователей обеих платформ. Для работы с визуализаций в едином пространстве мы запустили отдельный сайт. На нем стали размещаться все дашборды, и именно через этот сайт был предоставлен доступ к отчетам для обычных пользователей. Кроме этого, так как сайт с дашбордами является нашей собственной разработкой, нам было удобнее и быстрее подстроить его под требования Геоинтеллект’а, а не наоборот. Такой подход позволил нам быстро и достаточно удобно реализовать единую идентификацию для обоих платформ.

В результате ГРАФИТе был создан единый механизм SSO (Single sign on) который можно подключить к любому сервису, а также варьировать параметры входа. Единственное, что обязательно — указать при регистрации ПИНФЛ, Серию паспорта, Эл. почту и пароль это первый этап после завершения всех работ будет достаточно лишь указать дату рождения, серию паспорта и эл. почту. В дальнейшем данный механизм планируется внедрить в большую часть наших сервисов, чтобы создать некое подобие единого доступа в экосистему. Аутентификация позволяет привязать активность каждого пользователя с контролем личности — требуется предоставить серию и номер паспорта, дату рождения и, конечно, актуальный номера телефона.

2. Второй этап – это встраивание дашбордов Visiology на платформе Геоинтеллект. Для второго этапа в Геоинтеллекте нужно было создать новый функционал для выведения дашбордов разных размеров через iframe. Над этой задачей мы ещё работаем, но результаты уже можно показать.

Например, если нам надо понять статистику по району (Махаля) во времени, нам больше не надо прибегать к сложным разработкам, библиотекам и т.д. Достаточно из картографического веб-приложения на базе ПО Геоинтеллект вызвать скомпонованный график из ПО Visiology. Подобное стало возможным благодаря тому, что ГРАФИТ — это конструктор. Именно такой принцип мы и закладывали в Архитектуру.

ИТ-ресурсы

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

В целом на весь “Цифровой ташкент” на сегодня уходит вот столько ресурсов

Вся инфраструктура подключена к системе мониторинга, которая логирует все виртуальные девайсы. Для этого мы использовали опенсорсное решение с визуализацией через Grafana.

Интеграция с другими ИС

Как я уже говорил, ГРАФИТ подключен к десяткам ведомственных информационных систем. Но в госорганах процесс интеграции жестко регламентирован, и поэтому сложности были в основном на этапе согласования документации. Пришлось поработать над “Техническими инструкциями” по интеграции одной системы с другой. В таких документах нужно сразу описать все этапы и типы файлов, которые нужно передавать.

В основном у нас были требования под REST API с форматом JSON или GeoJSON и проблем с ними не возникало. Были отдельные случаи с теми ведомствами, у которых данных слишком много (Налоговый Комитет, Центральный банк). С ними мы отдельно прописывали часы работы сервиса под закачку данных. Также приходилось использовать elasticsearch. Может быть, неочевидное, но весьма эффективное решение для этой задачи.

Когда данные состоят из множества массивов, которые могут потерять актуальность в любое время, можно выйти из положения следующим способом: мы загружаем всю информацию из базы данных, структуру которой мы заранее согласовали с передающим данные ведомством, через API. Далее они сами (это лучше делать передающей стороне, чтобы общая нагрузка на их базу не была большой) настраивают elasticsearch, скажем, с поиском глубиной в 24 часа только по тем массивам данных, которые были обновлены, и складывают эти данные в файл или JSON формат данных. После всех процедур они отправляют нам эти обновления один раз в день. Как показала практика, такой подход намного эффективнее и менее ресурсозатратен по сравнению с ежедневными автоматическими запросами в базу для полной проверки всех строк на наличие обновлений.

Вообще у нас со всеми API указаны свои времена для закачки данных, чтобы не нагружать их и наши сервера (в основном их, так как их системами пользуются много кто).

Была отдельная достаточно сложная система интеграции с Информационной системой городского Кадастра. У них учёт кадастровой информации ведется  на 1C, и нам пришлось написать дублирующий модуль (который берёт слепок с базы и дополняет ее теми массивами данных которые необходимы нам для стандартизации адресного реестра) на 1С для стыковки с ИС Кадастра. А уже потом этот модуль был интегрирован с ГРАФИТом для работы в нужном нам режиме (24/7).

Немного дополнительной настройки

В любом сложном проекте возникают задачи, требующие тонкой перенастройки системы, которую можно сделать только с помощью программирования. Платформа Visiology предоставляет JavaScript API для настройки существующих или создания новых виджетов, а также SDK для разработки бизнес-логики отчетов для языков Python и C#, причем скрипты на этих языках могут загружаться в систему на лету.

В ПО “Геоинтеллект” мы тоже добавили ряд модулей. Основной — это воркфлоу. Он предназначен для автоматизации бизнес-процессов при взаимодействии между нами, как оператором и госслужбами города.

Укладка асфальта. Простой пример реализации воркфлоу – укладка асфальта. Процесс укладки асфальта включает в себя большое количество участников: администрацию города, коммунальные службы, службе благоустройства города по асфальтированию.

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

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

То есть, если на определённом участке дороги на улице будут проводиться аварийные работы по устранению протечки в магистральной трубе горячей воды, другие заинтересованные организации будут предупреждены через модуль в системе ГРАФИТ.

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

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

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

Работа с операторами колл-центра организована следующим образом: все полученные звонки превращаются в заявки и сохраняются в базу данных портала xalqnazorati.uz, а заявки на портале автоматически структурируются по теме и геокодируются для проведения геоаналитики и через API планируется передавать в ГРАФИТ в виде точек с атрибутами (тема жалобы, статус) для построения тепловых карт.

Видеонаблюдение. Кроме этого в ГРАФИТ интегрированы камеры с центральных улиц. В связи с этим, “рядом” с ГРАФИТом работает система, обслуживающая камеры фиксации нарушений правил дорожного движения.

Данные с камер мы используем исключительно для планирования строительства дорог и подсчете трафика. Наш Ситуационный центр не занимается обработкой видео потоков для выписывания протоколов о нарушении ПДД. Данные с камер мы не храним у себя, для этого понадобилось бы намного большее хранилище, чем у нас есть (и возникла бы еще куча дополнительных задач). Вместо этого наши системы имеют доступ к просмотру всего архива записей в режиме реального времени. Отсутствие задач по хранению и обработке видеопотока позволяет нам заниматься чистой аналитикой — и это хорошо, потому что задач у нас и так хватает.

Энергопотребление. Еще одним вызовом для нас стали огромные массивы сырых данных по энергопотреблению. Однако с их помощью можно создать очень ёмкие аналитические тепловые карты и четко определить, где в городе идет повышенное потребление энергии. После того как API были состыкованы, началось скачивание информации. Процесс был строго регламентирован в часовом диапазоне, так как данных было много и они могли забить канал передачи данных. Но за счет ГРАФИТИШ мы настроили передачу и структурировали эти данные. Теперь ими могут пользоваться наши дата-саентисты, а визуализация доступна в BI системе. После того как мы превратили все данные в графики, идёт превращение этого массива информации в географический слой для наложения на карту. В будущем мы хотим отслеживать превышение потребление энергии в режиме реального времени по всему городу.

Какие выводы мы вынесли из проекта

Сейчас, когда основные этапы проекта уже позади, я хочу сделать несколько выводов, исходя из правильно принятых решений и ошибок, а также сложностей, с которыми мы столкнулись. Они могут оказаться полезными тем, кто будет создавать аналогичные системы, интегрировать геосервисы, встраивать BI-технологии Visiology или других гибких BI-платформ и тому подобное.

1. Нанимайте профессионалов (только не тех кто говорит, что он профессионал) При этом желательно, чтобы вендоры умели быть гибкими. К сожалению, нечасто можно найти и гибких, и профессионалов. А это бывает нужно, потому что в сложных проектах могут потребоваться модификации решений.
2. Хорошенько продумайте архитектуру для проекта в котором может случиться всё что угодно. Даже те сценарии которые вы не можете себе представить. Вы не учтете всё, но зато учтете хотя бы часть. Старайтесь ставить в приоритет ту систему которая будет выполнять основные задачи. Поэтому нужно заложить “конструктор” с самого начала, а значит сразу найти подходящее ПО, готовое меняться вместе с вашим “конструктором”.
3. Старайтесь быть максимально независимыми: свои разработчики, тестировщики, инженеры БД, админы сети и devops. Растите своих, заложите R&D центр, чтобы ни от кого не зависеть.
4. Стоит по максимуму использовать решения, не требующие вмешательства программистов. Например, нам серьезно облегчил жизнь Конструктор Дашбордов Visiology, так как аналитики практически не приходили к нам с запросами на модификации средств визуализации.
5. И, конечно, никогда не забывайте про безопасность.

Планы развития

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

В Геоинформационную часть ГРАФИТ мы хотим добавить ещё 18 новых модулей, 10 инструментов и 9 крупных изменений в интерфейсе. Подробно об этом пока рассказать не могу. По части BI системы тоже ожидается интеграция ещё как минимум с 29 информационных систем и ресурсов в каждом в среднем по 28 видов строк. В этом контексте нам очень на руку возможности масштабирования Visiology простым расширением кластера.

Несмотря на то, что ГРАФИТ это уже большая информационная система, новые инструменты получается внедрять  в короткие сроки. Используя наш конструктор на микросервиcах мы добавляем новшества практически без изменений в уже готовом коде. Но, тем не менее, с каждой новой фичей или инструментом, модулем или функционалом приходится учитывать связи с остальными модулями и алгоритмами, которые там применены. Так что я уже сейчас понимаю что в какой-то момент всё равно придётся провести архитектурную оптимизацию. Наверное, это придется делать года через три. Но сегодня на уровне ГРАФИТА и шины ГРАФИТИШ нет невыполнимых задач, и они решаются для того, чтобы в будущем из маленьких преобразований город стал лучше для жителей.