Материал: Разработка сервиса агрегации открытых данных и данных из социальных сетей

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

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

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

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

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

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

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

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

·        культура;

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

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

·        музеи;

·        театры;

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

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

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

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

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

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

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

·        кафе;

·        кофейни;

·        рестораны;

·        бары.

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

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

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

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

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

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

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

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

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

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

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

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

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