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

МЕТОДЫ ВИЗУАЛИЗАЦИИ ДАННЫХ

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

Сервис агрегации данных предусматривает визуализацию данных на карте. Дело в том, что сообщения из социальных сетей могут содержать в себе специальные метки, которые означают географическое положение на планете. Такие метки называются геотеги [17]. Они могут проставляться как пользователем вручную, так и автоматически устройством, с которого совершен вход в социальную сеть. Это может быть и мобильный телефон при отправке сообщения, и при фотосъемке, и автоматическое определение местоположение по Wi-Fi сетям. Стоит отметить, что GPS навигация на сегодняшний день достаточно точно определяет месторасположение устройств с точностью до 3 метров. Такой точности вполне достаточно для определения адреса или объекта, откуда производится отправка сообщения. Социальная сеть может соотносить координаты на карте и объекты из базы данных, например, ночные клубы, музеи, выставки, театры и кино. Это делается для более удобного восприятия информации о месте, где находился пользователь на момент публикации сообщения.

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

В итоге мы имеем информацию об объектах из открытых данных и месторасположение, где был сделан пост в социальной сети. Такую информацию очень удобно анализировать не в текстовом виде, а на карте. Если рассматривать вопрос в общем, то спектр задач с географическими картами постоянно расширяется. Уже давно стали обыденностью сервисы по визуализации пробок, по построению маршрутов, по поиску такси в реальном времени. Именно поэтому развиваются новые технологии инфографики и карт. Существуют несколько типов визуализации точек на карте. К первому виду можно отнести обычную метку. Метка может быть в виде точки, маркера или любого другого изображения, определенного разработчиком. Это самый простой вид визуализации, поскольку не требует никаких специальных программных требований, так как представляет собой только лишь пару координат. Ко второму виду можно отнести линию на карте. Самый простой вариант - это отрезок, который характеризуется двумя точками, а в общем случае - массив точек, соединенных последовательно. На карте такой тип широко распространен в интернете. Его можно встретить на картах маршрутов, на картах пробок. Карты, которые поддерживают панорамный вид, выделяют линиями те участки дорог, на которых есть снятые панорамы. К третьему виду относятся более сложные структуры, которые содержат в себе не только координаты точек, но и дополнительную информацию. На карте они могут быть изображены как круги с изменяемым радиусом. Иногда такой тип используется для визуализации населения городов, где радиус круга соотносится с числом жителей города. Такой вид хоть и считается распространенным, но все поставщики карт в интернете его поддерживают. Следующим видом визуализации данных на карте является тепловая карта. Изначально она использовалась только для обозначения температуры в какой-либо точке пространства, о чем свидетельствует ее название. Однако она получила применение и во многих других сферах деятельности, в том числе и на географических картах. С помощью нее, например можно наглядно показать неравномерную плотность населения планеты. Для обозначения различной плотности используется не ее координаты и не ширина линий, а цвет. Именно параметр цвета несет в себе дополнительную информацию, привязанную к координатам. Последним видом визуализации является граф. Ребра графа могут нести в себе дополнительную информацию об объекте описания. В дискретной математике эту величину называют весом ребра. На географических картах такой вид также нашел применение. Например, граф с весами может изобразить все аэропорта страны или мира, где вес ребра будет означать время перелета. В виду сложной программной реализации, а также неоднозначного формата входных данных, далеко не все существующие поставщики карт в интернете поддерживают такой формат визуализации.

Далее следует рассмотреть, какие поставщики карт бывают. Существует несколько решений, которые являются наиболее популярными среди пользователей карт в интернете. Ими являются Google Maps, Яндекс.Карты и OpenStreetMap [7][32][15]. У каждого решения есть свои достоинства и свои недостатки. Начнем с карт от Google, поскольку они является самыми распространенными в мире в виду своей огромной аудитории. Карты впервые появились в 2005 году, поэтому имеют наибольший опыт среди всех остальных рассмотренных вариантов. Корпорация Google уделяет пристальное внимание мелочам на своих картах и каждый год старается улучшить качество своего сервиса. Помимо визуализации схемы и вида со спутника, в этих картах доступны построение маршрутов, размещение фотографий в привязке к месторасположению, панорамные виды и многое другое. К тому же Google Maps предложила пользователям возможность пройтись по улицам городов в виде функции «Просмотр улиц» (Google Street View). В настоящее время выполнена съемка большинства крупных и средних по размеру городов мира, а также некоторые достопримечательности. Далее рассмотрим Яндекс.Карты. Во многом они повторяют функционал карт от Google, поскольку почти всегда выступали в роли «догоняющих». Тем не менее, все элементы сервиса выполнены качественно, а в надежности работы не уступают своим конкурентам. В России существует ряд сервисов, которые завязаны на картах от Яндекс и используют его как основную технологию бизнеса. К ним относятся в основном транспортные компании и таксопарки. На них также существует возможность просматривать панорамы улиц, добавлять фотографии с привязкой к геолокации. Более того, кому-то даже больше нравятся смотреть карты от Яндекс, которые показывают загруженность дорог в больших городах, чем на картах конкурентов. Затем идут карты OpenStreetMap. Основной чертой этих карт является использование только свободного программного обеспечения, а также весь проект выполнен как проект с открытым исходным кодом. Поскольку он был основан некоммерческой организацией, его целью никогда не было получение прибыли. Главной идеей этого проекта стало свободный доступ каждого пользователя в интернете к достоверной карте мира, так как не существет организации, которая бы контролировала бы ее содержание и активность пользователей. На этих картах также имеется возможность просмотра карты мира, рельефа со спутников, панорам улиц. Тем не менее, скорость работы сервиса оставляет желать лучшего. Это можно понять, поскольку хостинг серверов оплачивается, в том числе и за счет добровольцев, кто не равнодушен к идее свободного программного обеспечения. Это влияет и на разработку собственных сервисов на их основе. В лицензии сказано, что запрещается использование карт в качестве основы для коммерческого продукта, и это невозможно без разрешения правообладателя. Однако не это является препятствием для разработки новых сервисов, а отсутствие механизма расширения базового функционала. Любые изменения должны быть отражены в исходном коде OpenStreetMap, после тщательного рассмотрения заявок, которые выполняются месяцами, к тому же их могут отклонить. Именно поэтому они не используются в качестве средства визуализации нестандартной информации на картах в интернете. Далее в работе этот сервис не будет рассматриваться.

Сравнивая оставшихся поставщиков картографических сервисов можно выявить и различия. В основном они кроются в программном интерфейсе сервиса. Для разработчиков дают одинаковые точки расширения карт путем подключения своих или сторонних плагинов, однако некоторый функционал доступен только для владельцев платного доступа к картам. Таким образом, для пользователя не будет никакой разницы, посмотрит от на те или иные карты, но для разработчика, как для поставщика сервиса, стоимость будет разной. В основном стоимость будет складываться из числа запросов в сутки; если определенный порог был превышен, за каждый следующий запрос будет взиматься плата. Это распространенная практика ведения бизнеса в виде предоставления программного обеспечения как сервиса. Величина этого порога регулирует характер бесплатного использования. Если порог будет низкий, то приложение можно будет использовать лишь в ознакомительных целях. Если порог будет выше, то он прекрасно подойдет для небольших сервисов с небольшим количеством пользователей. Наконец, если порог будет высоким, то такой подход подойдет и среднему, и малому бизнесу, однако плата будет взиматься с крупных предприятий. Проанализировав ценовую политику Google и Яндекс, можно сказать, что Яндекс допускает большее число бесплатных запросов, нежели его конкурент. Из этого можно сделать вывод, что именно это карты лучше всего подойдут для сервиса агрегации открытых данных и данных из социальных сетей с последующей визуализацией в виде веб сервиса.

Рассмотрев основные способы визуализации данных на карте, можно сделать вывод, что для задачи сервиса агрегации данных лучше всего подходит метод построения тепловых карт. Он отвечает следующим условиям: этот метод сохраняет информацию о географическом месторасположении, что крайне важно, когда пользователи имеют дело с геотэгами. Также метод тепловых карт показывает плотность сообщений на карте. Это достигается за счет градации цветов, которые передают плотность активности в той или иной точке карты. Где активности нет, там цвет не выделяется, показывается только карта. Там где активность есть низкая, там используется спокойные зеленные оттенки. По мере роста активности цвет будет постепенно меняться к агрессивному красному, что покажет максимальную концентрацию активности на карте. Здесь стоит отметить, почему не подходит метод агрегации в виде кружков. Во-первых, размер круга должен зависеть от степени активности пользователей в социальных сетях. Однако это можно достичь только за счет схлопывания нескольких точек в одну, вследствие чего теряется точность данных о месторасположении. К тому же на карте будет показываться только одна точка вместо площади, как будет на самом деле. Более того, смотря на карту, невозможно сразу сказать, где находится максимальная активность пользователей, поскольку размер круга легко спутать, если они похожи. К тому же возможна ситуация, когда можно просто не заметить круг большей площади где-нибудь в другом месте карты. С тепловой картой такая ситуация почти невозможна, так как цвет воспринимается однозначно, и сразу можно сказать, где место максимального скопления активности пользователей социальных сетей.

Google Maps и Яндекс.Карты поддерживают возможность отображения тепловых карт [7][32]. В первом случае такой тип карт поддерживается корпорацией официально. Это значит, что Google не только гарантирует стабильную работу сервиса при использовании тепловых карт, но и поддержку по любым вопросам, связанным с ними. К тому же это говорит о том, что они были тщательно протестированы. Однако доступ к ним имеется только у владельцев платного доступа. Другая ситуация обстоит у Яндекса. Они еще не добавили тепловую карту как базовый функционал сервиса, однако разработчики-энтузиасты опубликовали свободное расширение для их построения. Таким образом, тепловые карты можно строить путем добавления стороннего плагина, который поставляется бесплатно. Недостатком такого способа является тот факт, что разработчики пользуется им на условиях «как есть» и не могут претендовать на поддержку в случае возникновения проблем или вопросов. Тем не менее, это расширение хорошо себя показало, и было рекомендовано Яндексом к использованию. Таким образом, выбор технологии остановился на использовании Яндекс.Карт и визуализацией с помощью тепловых карт, поскольку этот вид является наиболее релевантным данной работе.

ГЛАВА 2. РАЗРАБОТКА СИСТЕМЫ

ВЫБОР ИСТОЧНИКА ОТКРЫТЫХ ДАННЫХ

В России существует небольшое количество порталов открытых данных. Большая часть из них является проектами, реализованными самим государством. Дело в том, что в нашей стране у каждого субъекта Российской Федерации ест свой портал открытых данных. На этих сайтах правительство публикует множество наборов данных. Во многом они представлены различными наборами на тему демографии, здравоохранения, культуры, ЖКХ и безопасности. Главной целью создания подобных порталов является упрощение доступа к данным, которые являются необходимым для современного общества. Также целью является предоставление прозрачного контроля действий органов исполнительной власти.

Двумя крупнейшими порталами является «портал открытых данных Правительства Москвы» и «портал открытых данных Российской Федерации». Это можно объяснить тем, что столица должна подавать пример остальным субъектам страны, как должна происходить публикация данных, какие примеры таких наборов могут быть опубликованы и поощрять эту деятельность. Помимо того, что эти два сайта являются наиболее крупными, наборы данных в них регулярно обновляются и расширяются. Несмотря на то, что «портал открытых данных Российской Федерации» содержит в себе большое количество наборов данных, они представляют всю страны в целом. Дело в том, что визуализация на карте будет крайне непоказательная из-за масштаба страны. Активность пользователей будет сокращаться до точки, что, в свою очередь, не даст представления о распределении месторасположении пользователей и объектов из открытых данных. Исходя из того факта, что масштаб карты для визуализации не должен быть слишком большим, было решено ограничиться одним городом. «Портал открытых данных Правительства Москвы» как раз содержит различные наборы данных о нашей столице, которые удобно накладывать на карту и совмещать с активностью пользователей. Некоторые наборы данных пересекаются с первым порталом, тем не менее, именно этот сайт содержит наиболее полную и релевантную информацию об объектах различных сфер жизни. Таким образом, в качестве источника открытых данных был выбран «Портал открытых данных Правительства Москвы» [27][28].

ВЫБОР НАБОРОВ ОТКРЫТЫХ ДАННЫХ

После определения источника открытых данных, необходимо выбрать, какие именно объекты будут показываться на карте сервиса. На «Портале открытых данных Правительства Москвы» существует множество наборов открытых данных, от здравоохранения до пешеходной инфраструктуры. Касательно сервиса агрегации, в первую очередь будут интересны разделы, в которых присутствует перечень объектов с геолокацией. К ним относятся различные места досуга, объекты культурного наследия, заведения питания. Одним словом, места, где люди могут проявить свою активность в социальных сетях. На данном портале можно выделить следующие категории:

· Досуг и отдых;

· культура;

· общественное питание.

В каждой из этих категорий есть более двух десятков наборов данных. Однако не каждый набор подходит для использования в сервисе агрегации. Так, некоторые разделы содержат лишь перечень объектов, среди полей которых отсутствует информация об их географическом расположении. Наиболее интересные разделы, которые имеют данные о геолокации в категории «Культура»:

· музеи;

· театры;

· объекты культурного наследия;

· выставочные залы.

В категории «Досуг и отдых» можно выделить несколько наиболее релевантных сервису агрегации:

· кинотеатры;

· места для досуга и отдыха с детьми;

· места для пикника;

· парковые территории.

В категории «Общественное питание» наиболее интересными и содержащими в себе информацию о расположении являются:

· кафе;

· кофейни;

· рестораны;

· бары.

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

СОЦИАЛЬНЫЕ СЕТИ ДЛЯ ИЗВЛЕЧЕНИЯ ДАННЫХ

В мире существует множество социальных сетей на любой вкус. Вероятно, даже самый искушенный пользователь интернета найдет социальную сеть по своим интересам. Тем не менее, на мировой арене уже давно наметились явные лидеры данного сегмента. Речь идет о бессменном лидере Facebook, набирающем обороте Instagram, крайне популярном Twitter и всемирно известном видео хостинге YouTube. Каждая социальная сеть заполнила свою нишу и удерживает там лидирующие позиции. Например, Facebook является универсальной сетью, которая сочетает в себе элементы микроблога, сообщества, возможность делиться видео и фото, широкие возможности общения между пользователями. В то же время остальные сети более четко выделили для себя целевую аудиторию. Так, изначально Twitter был нацелен исключительно на обмен короткими сообщениями. Впоследствии там добилась возможность публикации фото, тем не менее, эта функция является дополнительной опцией. Социальная сеть Instagram ориентирована на пользователей с активной жизненной позицией. Сервис направлен на обмен фотографиями и короткими видео. Дело в том, что фотографии являются центральной сущностью портала; невозможно выложить пост, состоящий исключительно из текста. Далее расположился YouTube, известный как сервис видео хостинга. Несмотря на то, что данная платформа является социальной сетью, рассматривать в данной работе она не будет по причине отсутствия геолокации.

Учитывая популярность вышеперечисленных социальных сетей, стоит отметить, что в России существуют локальные игроки, которые с успехом замещают мировых лидеров. Ими являются социальные сети «Вконтакте», «Одноклассники», «Мой Мир» и «RuTube». Самой посещаемой в России является социальная сеть «Вконтакте» с месячной аудиторией более 46 миллионов человек. Принимая во внимание тот факт, что в России, а в частности в Москве, большей популярностью пользуются локальные социальные сети, необходимо рассмотреть все возможные варианты подключения социальных сетей к сервису агрегации.

Следующим этапом будет сравнение программных интерфейсов социальных сетей. Дело в том, что простота и удобство в использовании играют важную роль при разработке сервисов, работающих в режиме реального времени. Также важное место занимает надежность платформы и обновление версий. Каждая социальная сеть заинтересована в том, чтобы как можно больше разработчиков создавали новые сервисы на основе их программных интерфейсов. Из-за этого зачастую сами компании поставляют фреймворки для самых востребованных языков программирования. Лидером по удобству и функциональности является социальная сеть Twitter. Она поддерживает множество фильтров, в том числе отсечение по месторасположению. Более того, там предусмотрен потоковый режим извлечения контента. Потоковый программный интерфейс является идеальным решением для сервиса в режиме реального времени. Кроме этого, существуют программные реализации интерфейсов под все популярные языки программирования, в частности Java. Именно этот язык программирования используется при реализации данного проекта. Далее следует социальная сеть Instagram с максимально понятной, доступной и полной документацией. Наряду с этим, у нее присутствуют клиенты под различные языки программирования, в том числе под Java. Что касается остальных социальных сетей, с реализацией клиентов под эти платформы связаны некоторые трудности. Они могут проявляться в жесткой политике социальной сети в отношении количества запросов в минуту, отсутствия фреймворка под нужный язык программирования или отсутствие официальной поддержки. Также они могут выражаться в постоянно меняющихся версиях программного интерфейса без сохранения обратной совместимости, что затруднит поддержку проекта в дальнейшем. В итоге для первого варианта сервиса агрегации данных быди выбраны социальные сети Twitter и Instagram.

ОГРАНИЧЕНИЕ ГЕОГРАФИЧЕСКОЙ ЛОКАЦИИ

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

Стоит отметить, что социальные сети, поддерживающие геотеги, имеют собственную привязку координат к объектам из своих баз данных. Для реализации сервиса агрегации данных из социальных сетей необходимо иметь координаты, которые можно привязать к какому-либо объекту или точке. Например, человек сделал фотографию и хочет поделиться ею со своими подписчиками. В результате на опубликованном фото будет метка о расположении с названием места, где оно было сделано. То есть другие пользователи вместо двух абстрактным чисел координат, которые большинству людей будут непонятны, будет виднеться надпись «ПКиО им. Горького». Формат, который понятен любому пользователю, является крайне важным элементом любой социальной сети. Тем не менее, для того, чтобы система могла оперировать с географическим положением пользователя, текстовый формат является неприемлемым. Во-первых, список таких объектов даже в небольших городах может составлять десятки тысяч записей. Во-вторых, этот список является динамическим, поскольку он может время от времени пополняться и модернизироваться. Более того, такой список необходимо постоянно отправлять программному интерфейсу социальной сети для фильтрации нерелевантных записей.

Решением данной проблемы является использование исключительно числовых параметров координат. При таком подходе будет полностью игнорироваться текстовое обозначение мест и привязки к объектам. Они попросту будут отсеиваться при извлечении данных из социальной сети. Как уже было сказано выше, две координаты на плоскости будут задавать ту область, которая соответствует городу на карте. Разумеется, город Москва имеет не прямоугольные границы, однако прямоугольная форма полностью покрывает ее территорию и захватает близлежащие немногочисленные жилые поселки. С таким допущением легко смириться, поскольку оно никак не влияет на визуализацию пользовательской активности и не несет в себе большую дополнительную загрузку. Более того, выставления фильтра в виде только одного набора координат повышает временную эффективность инструментов поиска социальной сети, поэтому фильтр по геолокации будет срабатывать быстро. Несмотря на то, что алгоритм поиска является внешней системой по отношению к сервису агрегации, необходимо учитывать, что на стороне социальной сети существуют дополнительные системы мониторингов против действий, направленных на дестабилизацию портала. К таким действиям можно отнести и запросы, время выполнения которых превышает установленные нормы. При точном выделении границ города Москвы, набор координат будет насчитывать несколько сотен пар. Чтобы каждое сообщение соответствовало фильтрам, выставленным сервисов агрегации, необходимо проверить геолокацию по каждой паре координат. Из-за того, что система разрабатывается с функционированием в реальном времени, время выполнения таких запросов может превысить установленные ограничения. Превышение по времени выполнения запроса может повлечь за собой обрыв связи в лучшем случае и блокировку аккаунта сервиса в наихудшем. В любом случае, такой риск является неприемлемым при разработке сервиса агрегации.

Также необходимо учитывать, что некоторые сообщения отправляются без геотегов, однако они автоматически заполняются социальной сетью. Даже при выключенной GPS-навигации в мобильных устройствах социальная сеть способна распознать расположение пользователя с точностью до населенного пункта. Автоматическое заполнение геотегов в таком случае является еще одной проблемой для визуализации данных агрегации. Дело в том, что подобные сообщения попадают под критерии запроса по месторасположению пользователя, однако не обладают достаточной точностью координат. В таких случаях социальная сеть проставляет вместо расположения пользователя координаты центра населенного пункта. Несмотря на то, что пользователи проявили свою активность в интересующем нас городе, такие сообщения нельзя визуализировать на карте, поскольку методу тепловых карт нужны точные координаты. Исходя из этого, такие геотеги будут также фильтроваться, даже если они будут соответствовать городу Москве.

ФОРМАТ ХРАНЕНИЯ ДАННЫХ

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

Далее следует проанализировать формат сообщений, который приходит от социальных сетей, а также данные, которые нужны сервису агрегации для корректного хранения и визуализации информации о расположении. Как правило, большое количество сервисов в интернете использует формат JSON в пересылаемых сообщениях. Социальные сети не исключение. Такое распространение обуславливается широкой поддержкой данного формата, а также тем, что для языка программирования JavaScript, который является стандартом в мире веб-программирования, он является родным. Во-первых, необходимо выделить все поля, которые являются общими для социальных сетей. К ним относятся время публикации, текст сообщения, геотег, автор сообщения. Во-вторых, необходимо установить, какие поля нужны разрабатываемому сервису. Помимо вышеперечисленных свойств, объект должен быть уникальным, то есть обладать идентификатором. Поскольку у всех социальных сетей формат идентификаторов разный, и, теоретически, они могут пересекаться, было решено генерировать его автоматически на стороне разрабатываемого сервиса. Также необходимо добавить поле источника, откуда было получено сообщение. С помощью него можно будет в дальнейшем проводить анализ, в каких пропорциях поступают сообщения из каждой социальной сети.

В результате работы сервиса необходимо адаптировать каждый источник данных в универсальный формат. Во-первых, необходимо корректно конвертировать время публикации сообщения. Самым распространенным форматом времени в интернете является «Unix Timestamp», который представляет собой число секунд, прошедших с 1 января 1970 года. Его широкое распространение обуславливает простота формата, так как время выражено одним числом. Тем не менее, он не учитывает часовые пояса в явном виде, поэтому среди разработчиков принято указывать время по Гринвичу, то есть с нулевым сдвигом. Однако социальная сеть Twitter не поддерживает такой формат и передает время в текстовом формате UTC [18]. В сообщении от социальной сети можно получить следующее:

"created_at":"Wed Apr 08 13:08:45 +0000 2017"

В результате сервис должен автоматически приводить время публикации сообщения из разных социальных сетей к общему виду формата Unix Timestamp. Также у всех социальных сетей разные форматы отображения геолокации пользователя. На примере Twitter можно показать, какой вид имеет сообщение от этой сети [18]:

"place":

{

"attributes":{},

"bounding_box":

{

"coordinates":

[[

[-77.119759,38.791645],

[-76.909393,38.791645],

[-76.909393,38.995548],

[-77.119759,38.995548]

]],

"type":"Polygon"

},

"country":"United States",

"country_code":"US",

"full_name":"Washington, DC",

"id":"01fbe706f872cb32",

"name":"Washington",

"place_type":"city",

"url": "http://api.twitter.com/1/geo/id/01fbe706f872cb32.json"

}

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

{

"id": "fb4u39gf793hfur3ngru03rhg0r3ijgr3",

"sourceType": "TWITTER",

"text": "The message",

"location":

{

"longitude": 53.12812355641,

"latitude": 37.58165423456

},

"timestamp": 1404854660168

}

Для корректного хранения адаптированных данных необходимо также выбрать подходящую мазу данных. Выбор свободно распространяемых и бесплатных серверов не является широким, тем не менее для любого вида данных найдется своя база данных. Наиболее распространенные на сегодня: MySQL, PostgreSQL, Oracle, Redis, MongoDB. Первые три относятся к реляционным базам данных, что осложняет представление вышеописанной модели, поскольку каждый объект должен иметь вложенную структуру в виде координат. Redis является не реляционной базой данных, но она представляет собой хранилище типа ключ-значение. У нее есть большое преимущество в виде скорости работы за счет хранения всей информации в оперативной памяти. Именно поэтому она зачастую используется в качестве сервера-кэша. С другой стороны, это является и ее недостатком. Дело в том, что существует риск безвозвратной потери данных при сбое программы, что исключается при работе с традиционными СУБД. Последний вариант MongoDB позиционирует себя как база данных для документов. Главным преимуществом для этого проекта является тот факт, что вся хранимая информация представляет собой JSON объекты. Это значит, что выбранный формат хранения не надо дополнительно конвертировать для сохранения в базу и извлечения из нее информации. Благодаря этому исключается риски неверной обработки данных и увеличивается скорость работы системы в целом.

АРХИТЕКТУРА СИСТЕМЫ

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

Однако такой подход имеет свои недостатки. Во-первых, единое приложение является одновременной точкой отказа для всех частей программы. Другими словами, если ошибка появляется в любом из частей программы, она сказывается на работе всех остальных ее частей. Из этого следует, что если не работает хотя бы одна часть программы, не работает и вся система в целом. Из этого недостатка вытекает следующий недочет: при необходимости исправить ошибку или при обновлении версии программы нужно перезапускать всю программу целиком. Таким образом, даже те части программы, в которых не было ошибок или которые не нуждались в обновлении, будут также перезапущены. Это ведет к частичной потере данных при простое. Как уже было упомянуто выше, архитектура монолита используется, когда есть потребность в обработке и обмене большим количеством данных. Однако при перезапуске приложения будут остановлены все части программы, и в это время будет полностью отсутствовать функционирование системы. Для некоторых приложений это является неприемлемым недостатком. Более того, такая архитектура заставляет создавать большие по объему и сложные системы. Сложность программы неизбежно ведет к появлению большего количества ошибок. Бороться с ними можно путем постоянного написания модульных тестов, однако, отсутствие модулей значительно затрудняет тестирование. К тому же, для выполнения всех автоматических тестов необходимо каждый раз поднимать контекст целого приложения, что заставляет использовать мощное железо даже на сервере сборки. Последним, но не менее важным недостатком является повышенные требования к ресурсам компьютера. Поскольку система выполнена как единый модуль, он должен запускаться на одном сервере. Отсюда следует, что для корректной и быстрой работы программного комплекса нужно иметь достаточное количество вычислительных ресурсов, а именно: объем оперативной памяти, объем жесткого диска, количество ядер процессора и тактовой частоты процессора. Серверное железо и сейчас является дорогим, делая его доступным только для крупного бизнеса. Это пагубно сказывается на малом и среднем бизнесе, заставляя их идти на компромиссы по ресурсной и временной эффективности программного обеспечения.

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

Существует и другой подход к построению программного обеспечения. Это, так называемая, микросервисная архитектура [11]. Ее характерной особенностью является тот факт, что каждая логическая часть системы должна быть выполнена в виде отдельного программного модуля. Все модули представляют собой исполняемый файл или архив, который можно запустить независимо от других частей системы. Основная идея микросервисной архитектуры состоит в том, что каждый отдельный модуль должен выполнять одну единственную задачу. Когда программа отвечает только за одну задачу, гораздо выше вероятность того, что она выполняет ее хорошо. Такой подход известен еще с публикации философии UNIX, который гласил примерно схожую идею. Таким образом, система состоит из нескольких независимых модулей, которые должны взаимодействовать между собой. Здесь могут быть использованы любые протоколы передачи данных, которые лучше всего подходят под определенные требования. Также могут использоваться любые шины данных для обмена сообщениями между модулями, поскольку выбор не ограничен целостностью системы. Из этого всего можно выделить следующие преимущества микросервисной архитектуры:

· Всегда проще разрабатывать небольшой сервис, который ответственен за решение одной задачи. Такой модуль легко покрывать тестами и поддерживать;

· Возможность использовать любые протоколы передачи данных между сервисами системы;

· Поскольку при такой архитектуре каждый модуль является независимым, существует возможность распараллеливания разработки сервисов между разработчиками;

· Небольшие изолированные сервисы легко масштабируются, таким образом можно создать распределенную систему из отдельных микросервисов;

· Для каждого сервиса можно выбирать любую технологию и язык программирования, которая лучше всего подходит под решение конкретной задачи;

· Некоторые микросервисы, такие как веб-серверы, нет необходимости разрабатывать самому, поскольку они уже существуют в открытом доступе;

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

Как и в любой архитектуре программных систем, микросервисы также не лишены недостатков. Во-первых, большое количество отдельных модулей сложнее развертывать на серверах. Для каждого сервиса необходимо писать свой собственный конфигурационный файл, где должны быть собраны все стартовые настройки приложения. Во-вторых, большое количество сервисов сложнее администрировать во время эксплуатации. Возникает необходимость в использовании сторонних утилит мониторинга процессов, на адаптацию и изучение которых нужно также потратить время. В-третьих, мониторинг сервисов предполагает сбор метрик по логам, поэтому необходимо внедрить их написание в сами сервисы. Это распространенная практика, тем не менее, на качественный анализ логов необходимо будет завести свой набор сервисов по мониторингу. Более того, микросервисная архитектура предполагает свою собственную доменную модель для каждого отдельного модуля. Из этого следует, что, если разные модули пользуются одними и теми же объектами, то неизбежно появятся дубликаты кода. Однако проблемой является не это, а то, что при обнаружении ошибки либо при необходимости изменения доменной модели, надо будет вносить изменения в каждый отдельный модуль, где используются такие типы объектов. Также при обновлении доменной модели каждый сервис надо будет перезапустить. Разумеется, такая архитектура подойдет не к каждому проекту. Тем не менее, для сервиса агрегации данных из социальных сетей преимущества значительно перевешивают недостатки, снижая время разработки, улучшая поддержку и добавляя дополнительную гибкость приложению. Помимо этого, при микросервсиной архитектуре существует возможность поместить каждый отдельный модуль в контейнер. Это позволяет настраивать образы сервисов и облегчает их горизонтальное масштабирование. К тому же, большинство облачных хостингов переходит на поддержку контейнеров, поскольку это облегчает развертывание распределенных систем, а также позволяет гибко настраивать окружение приложение.

ПОСТРОЕНИЕ СИСТЕМЫ

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

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

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

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

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

Рисунок 1. Архитектура системы

ГЛАВА 3. РЕЗУЛЬТАТЫ

ОПИСАНИЕ И АНАЛИЗ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ

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

Общий вид сервиса представляет собой веб-сайт, центральной сущностью которого является тепловая карта активности пользователей социальных сетей. В общем виде карта выглядит следующим образом (рис. 2):

Рисунок 2. Общий вид тепловой карты

Как видно на тепловой карте, цвет в каждой точке характеризует плотность пользовательской активности. Зеленый цвет соответствует низкой активности, красный - высокой, бесцветные участки говорят о том, что там не было проявлено активности в социальных сетях в целом. Стоит отметить, что практическую значимость сервиса сложно переоценить. Карта может показывать, какие участки города Москвы чаще всего оказываются в центре внимания среди пользователей социальных сетей. Глядя на карту, можно сказать, какие достопримечательности и объекты всегда пользуются спросом, по количеству сообщений и постов с меткой о расположении, сделанных в этих местах. Еще одним применением сервиса может быть выявление явных статистических отклонений от среднего количества сообщений в каждом конкретном объекте из набора открытых данных. Разберем подробнее этот способ на примере праздника Дня победы 9 мая. На этом случае стоит остановиться, поскольку он является наглядным примером того, как визуализация данных помогает выявлять резкие всплески активности пользователей. На рис. 3 изображена активность пользователей социальных сетей 9 мая 2017 года в период с 22:00 до 23:59. На изображении четко видно, что в «Парке Победы» на Поклонной горе было сделано множество постов в социальных сетях. Это объясняется тем, что городские власти в честь праздника устраивали салют в нескольких точках Москвы, в частности в этом месте.

Рисунок 3.Активность пользователей в Парке Победы на Поклонной горе 9 мая

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

Рисунок 4. Активность пользователей в Парке Победы на Поклонной горе 10 мая

Еще одним способом применения данного сервиса является тот факт, что его можно использовать для выявления корреляции активности пользователей с месторасположением объектов из набора открытых данных. Это можно объяснить на примере парков и скверов. В Москве существуют более 650 официальных парковых территорий. Из них лишь несколько являются действительно крупными и популярными среди посетителей. В частности, к ним можно отнести ЦПКиО им. Горького и Измайловский парк, которые ежедневно собирают в себе тысячи людей. Тем не менее, для проявления пользовательской активности важен не размер парковых территорий, а то, какие впечатления можно оттуда вынести. Так, парк Царицыно ежедневно открыт для всех посетителей. Судя по тепловой карте сервиса и среднему значению количества сообщений, он вызывает больше эмоций, нежели Измайловский парк. Скорее всего, это вызвано тем, что там располагается красивый и ухоженный пруд, а также Большой дворец, который изначально был спроектирован для царицы в 18 веке, а сейчас является музеем. Очевидно, наличие таких отличительных особенностью привлекает посетителей, а также вызывает у них желание поделиться своими фотографиями или мыслями на этот счет. В этом случае сервис даст понять, какие парки и скверы люди находя наиболее интересными. С другой стороны, это также дает понимание менее популярным паркам, что для того, чтобы там было больше посетителей и пользовательской активности, необходимо завлекать людей с помощью необычных арт-объектов, памятников и прочих заслуживающих внимания вещей.

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