Несмотря на все достоинства использования Hadoop, в современном мире он имеет ряд недостатков. Дело в том, что дизайн его системы проектировался тогда, когда оперативная память была очень дорогой. Из-за недостатка оперативной памяти все результаты вычислений вынуждены сохраняться на диске. Любые операции с диском являются самым медленным звеном в цепочке вычислений. На сегодняшний день цена на оперативную память стала более доступной, а ее скорость в тысячи раз превышает скорость работы с дисковыми накопителями. Именно это дало толчок к развитию новых технологий, производящих вычисления в оперативной памяти. Наиболее популярным решением, которое стремится избавиться от подобной проблемы, является Apache Spark [3]. Данный фреймворк также является проектом с открытым исходным кодом, написан на Scala. Главной особенностью является то, что Spark сочетает в себе гибридную технологию, которая способна при достаточном количестве оперативной памяти весь массив данных держать как можно «ближе» к процессору. За счет этого экономится время на транспортировку данных к обработчику и сохранение результатов вычислений. Тем не менее, если вдруг окажется, что во время выполнения программы памяти оказалось недостаточно, фреймворк сможет перейти на режим работы с диском. Данная особенность позволяет работать максимально быстро при относительно небольших объемов данных, которые ограничены лишь размером оперативной памяти. В то же время Spark является отказоустойчивым решением, поскольку даже при нехватке памяти он будет способен продолжить работу по обработке. Данная технология считается надстройкой над Hadoop, однако это мнение ошибочно. Разработчики этого фреймворка решили в корне пересмотреть подход к обработке данных. В ходе посроения архитектуры системы они ушли от повсеместно используемого классического алгоритма MapReduce и оставили его только на специфический ряд задач. В результате масштабной переработки и переосмысления произведения вычислений синтетические тесты показали, что решения на основе Spark в 100 раз превосходят аналогичные решения на основе Hadoop. Достигается это не только путем максимального использования возможностей оперативной памяти, поскольку если переключить фреймворк в режим работы с диском, то достигается ускорение до 10 раз. Все эти показания справедливы для пакетной обработки данных, но разработчики ввели новую технологию. Поскольку все чаще можно встретить у компаний требования к продукту в виде построения отчетности и аналитике систем в реальном времени, было решено внедрить потоковую обработку данных. Реализована она была в виде модуля Spark Streaming. Основная идея была в том, чтобы эффективно перевести пакетную обработку данных на потоковую обработку путем создания микро пакетов. Здесь необходимо ввести понятие скользящего окна. Было решено, что окном будет называться единица времени, которая важна для приближения анализа к режиму близкому к реальному времени. Другими словами, она равняется количеству времени, сколько готов ждать бизнес для получения результатов после получения данных. Во многих случаях хватает одной минуты, однако создатели фреймворка не ограничивают в величине окна и оставляют его определения на разработчика. Таким образом, данные в течение времени не складируются в хранилище, где ожидают дальнейшей обработки, а поступают сразу к обработчику. Такой потоковый режим значительно упрощает объем вычислений, поскольку существует ряд задач, где легче обрабатывать данные «на лету», чем держать их в хранилище. Еще одним преимущества данного фреймворка является простота в использовании. Из расчета на массовое использование этой технологии создатели позаботились о мультиплатформенности и наличии программных реализации на нескольких языках программирования: Java, Scala, R и Python [22]. Также вниманием не обделили и синтаксис описания обработки данных. Он в чем-то похож на синтаксис структурированного языка запросов SQL. Этот язык является стандартом в отрасли информационных технологий и знаком практически каждому человеку, кто в ней работает. Не смотря на то, что в коде описывается набор данных как единое целое, фреймворк позволяет обращаться к данным, которые располагаются на разных серверах или узлах так, как будто все они расположены локально. Создатели фреймворка также сделали модули для находящихся в тренде технологий: это потоковая обработка данных и машинное обучение. Хоть машинное обучение и не получило до сих пор широкого распространения среди пользователей фреймворка, этот модуль продолжает активно развиваться и, возможно, в ближайшем будущем составит конкуренцию текущим лидерам в этой области. Данный факт является еще одним преимуществом данной технологии: все эти модули идет «из коробки», они легки в настройке и использовании и органично сочетаются между собой. Как уже было сказано, Spark не является надстройкой над Hadoop и может запускаться в самостоятельном режиме. Тем не менее, если требуется запускать Spark задачи на существующем Hadoop кластере, он также умеет это делать. Помимо этого, Spark может запускаться совместно с Cassandra, Mesos, HBase и другими популярными продуктами по распределенной обработке данных и дополнять их. В технологии Spark также не обходится без недостатков. Преимущества фреймворка могут обернуться и большой проблемой для небольших компаний. Заключаются они в том, что для эффективного использования технологии обработки данных внутри оперативной памяти до сих пор узким местом является ее цена и объем. Небольшие компании на сегодняшний день не способны купить дорогостоящую память в достаточном количестве, чтобы обрабатывать даже не очень крупные по меркам больших данных массивы. Это не говоря уже о самостоятельных разработчиках, которые пользуются стационарными компьютерами, где максимальный объем памяти не превышает 16Гб. В какой-то степени проблема может решиться с массовым распространением облачных вычислений и их дальнейшим удешевлением, однако на данный момент она остается.
У всех решений на основе Hadoop или Spark есть один общий недостаток - они преимущественно для масштаба предприятий. Когда речь идет о технологическом стеке Hadoop или Spark, подразумевается, что должна быть развитая информационная инфраструктура. Имеется в виду, что должна быть развернута распределенная файловая система HDFS, распределенные базы данных, например Cassandra, для потоковой обработки данных в качстве источника сообщений используется Kafka. Касательно Kafka также следует отметить, что должен быть еще сервис, который преобразовывает сообщения в записи нужного формата для загрузки в очередь, чаще всего это самостоятельные приложения, на разработку и тестирование которых также необходимо ресурсы и время. Проблема в том, что установка и развертывание всей инфраструктуры - задача сложная и требующая релевантного опыта. К тому же время на развертывание может занимать недели. А поскольку это критически важно для произведения эффективных распределенных вычислений, инфраструктура является ключевым фактором для использования технологий Hadoop и Spark. Еще одним аспектом является не только их развертывание, но и грамотная настройка каждого компонента в отдельности. В распоряжении могут иметься различные сервера с разными характеристиками. Необходимо подобрать подходящую конфигурацию сервера на каждый узел, а не копировать одну и ту же настройку на всех. Иначе может возникнуть ситуация, когда один мощный сервер производит расчеты очень быстро, и дет время простоя, когда ждет результаты от медленного узла. Крайне важно давать релевантную нагрузку на каждый узел с учетом их технических характеристик и вычислительной мощности. Более того, для получения временной выгоды от распределенных вычислений необходимо иметь более одного узла в своей инфраструктуре. Это значит, что для эффективного использования параллельных операций нужно иметь как минимум два физических сервера. Разумеется, это не проблема для компаний любых масштабов, тем не менее, индивидуальным разработчикам не всегда является возможным иметь такую конфигурацию машин. Кроме этого, существуют такие операции над данными, которые плохо подвергаются параллельным вычислениям или невозможны вообще. Такие виды вычислений должны выполняться на одной машине без использования технологий, наподобие Hadoop или Spark.
Еще одним решением по обработке данных стало Java Stream API. Он стал доступен в Java с версии 1.8 и получил широкое распространение в виду ряда причин. В качестве основной идеи данная технология выделила термин канала (pipeline) [2]. Идея в том, что на входе в поток данные могут проходить различные обработчики, которые выполняются исключительно последовательно, но внутренняя реализация каждого допускает и параллельное выполнение. Также характерной особенностью является то, что использование «ленивых» вычислений может радикально сократить время выполнения вычислений. Так, к примеру, если в ходе описания обработчиков на выходе ожидается получить только один элемент, когда на входе был целый массив, нет необходимости проделывать весь ряд операций над всеми элементами массива. Такой обработчик вступает в силу только после выполнения терминальной операции, которая дает понять, что необходимо начать вычисления. В ходе анализа некоторые обработчики могут игнорироваться, если система решит, что они бесполезные. Например, если разработчик по ошибке напишет метод сортировки более одного раза, система проигнорирует остальные обработчики, поскольку появится статус потока как сортированный. Более того, если учитывать архитектурные особенности построения процессора, то можно также получить ощутимый прирост в производительности. Например, требуется над входным массивом провести операцию фильтрации ненужных элементов с последующей сортировкой. В таком случае можно сначала массив отсортировать, а потом, используя правило выбора ветки в процессоре (branch prediction), без проблем пройтись по всем элементам массива и определить, подходят ли они по критерию или нет. Еще одним преимуществом технологии является ее расширяемость. Разработчики могут самостоятельно разрабатывать нужные компоненты, которые сразу же можно будет использовать в потоковой обработке данных. Такой возможности нет ни у Hadoop, ни у Spark, поскольку все возможности фреймворков определяются их создателями. Уже существуют отдельные бесплатные библиотеки с открытым исходным кодом, которые стремятся разнообразить стандартный программный интерфейс и расширить его базовые возможности. Одной из таких является StreamEx, которая сочетает в себе простоту использования и полезные функции. Несмотря на перечисленные преимущества, данная технология не лишена недостатков. Внутреннее устройство Java Stream довольно сложное, и не всегда поведение оказывается очевидным при выполнении. Даже когда версия языка стала публично доступной и имела статус релиза, разработчики находили такие особенности реализации, которые в некоторых случаях оказывались ошибками. Самое опасное для тех разработчиков, которые только начинают знакомиться с возможностями языка и этой технологии в частности, является тот факт, что некоторые ошибки исправляются добавление строки в документацию с пояснением, какие именно странности могут возникнуть при использовании. Дело в том, что не все опытные разработчики прибегают к чтению документации, не говоря уже о спецификации языка, которая изложена на сотнях страниц. Это сделано по одной единственной причине, что Java возлагает на себя ответственность за обратную совместимость версий. Это значит ровно то, что любое написанное приложение должно работать абсолютно одинаково и на новых версиях языка. Также недостатком является тот факт, что Java Stream не определяет, откуда брать данные и куда их складывать. Очень многие функции эта технология перекладывает на разработчика. В таком случае технология может сосредоточиться на качественном выполнении одной конкретной задачи и не нести ответственности за то, что будет дальше. Такой подход содержится в дизайне языка в целом, и здесь это не исключение. Также в потоках существует возможность параллельного выполнения операций, тем не менее такой подход далеко не всегда может принести временную выгоду, к тому же он более требователен к ресурсам компьютера. Дело в том, что технология сама старается распределить вычисления по физическим ядрам процессора, и не всегда она делает это эффективно.
Рассмотрев основные виды обработки данных можно увидеть, что главной
задачей обработки данных является преобразование их к удобному для
использования виду. В конечном итоге, какую бы технологию ни выбрать, их
результат должен быть одинаков. Каждая технология имеет свои преимущества и
свои недостатки, требуют свою настройку и конфигурацию оборудования. Можно
сказать, что эти технологии были созданы специально под определенный круг
задач, который они успешно выполняют. Тем не менее, главным выводом можно считать
то, что развитие технологий обработки данных должно идти в непрерывной
связанности аппаратного и программного обеспечения для достижения максимальных
результатов. Крайне важно, чтобы развитие технологий шло параллельно, органично
дополняя друг друга.
Выбор правильного метода визуализации данных трудно переоценить. Доказано, что визуальная информация воспринимается в сотни раз быстрее, чем при чтении. В современном мире, где темп жизни с каждым годом становится все быстрее, становится критически важным максимально сократить время на получение новой информации без потери смысла. В данном разделе работы будут рассматриваться возможные виды визуализации данных на географической карте.
Сервис агрегации данных предусматривает визуализацию данных на карте. Дело в том, что сообщения из социальных сетей могут содержать в себе специальные метки, которые означают географическое положение на планете. Такие метки называются геотеги [17]. Они могут проставляться как пользователем вручную, так и автоматически устройством, с которого совершен вход в социальную сеть. Это может быть и мобильный телефон при отправке сообщения, и при фотосъемке, и автоматическое определение местоположение по Wi-Fi сетям. Стоит отметить, что GPS навигация на сегодняшний день достаточно точно определяет месторасположение устройств с точностью до 3 метров. Такой точности вполне достаточно для определения адреса или объекта, откуда производится отправка сообщения. Социальная сеть может соотносить координаты на карте и объекты из базы данных, например, ночные клубы, музеи, выставки, театры и кино. Это делается для более удобного восприятия информации о месте, где находился пользователь на момент публикации сообщения.
Что касается портала открытых данных, то там есть наборы данных, которые содержат в себе списки различных объектов. Это могут быть парки, скверы, кинотеатры, магазины, аптеки, маршруты патрулирования машин эвакуации. Каждый из объектов содержит в себе такие же метки о географическом месторасположении. Более того, для определенных наборов данных, чья площадь достаточно большая, может указываться не точка координат, а целый полигон. Полигон представляет собой массив координат, последовательно упорядоченных против часовой стрелки. Это сделано для того, что в некоторых случаях используется технология рендеринга изображения с помощью видеокарт, где такая последовательность является строго определенной.
В итоге мы имеем информацию об объектах из открытых данных и месторасположение, где был сделан пост в социальной сети. Такую информацию очень удобно анализировать не в текстовом виде, а на карте. Если рассматривать вопрос в общем, то спектр задач с географическими картами постоянно расширяется. Уже давно стали обыденностью сервисы по визуализации пробок, по построению маршрутов, по поиску такси в реальном времени. Именно поэтому развиваются новые технологии инфографики и карт. Существуют несколько типов визуализации точек на карте. К первому виду можно отнести обычную метку. Метка может быть в виде точки, маркера или любого другого изображения, определенного разработчиком. Это самый простой вид визуализации, поскольку не требует никаких специальных программных требований, так как представляет собой только лишь пару координат. Ко второму виду можно отнести линию на карте. Самый простой вариант - это отрезок, который характеризуется двумя точками, а в общем случае - массив точек, соединенных последовательно. На карте такой тип широко распространен в интернете. Его можно встретить на картах маршрутов, на картах пробок. Карты, которые поддерживают панорамный вид, выделяют линиями те участки дорог, на которых есть снятые панорамы. К третьему виду относятся более сложные структуры, которые содержат в себе не только координаты точек, но и дополнительную информацию. На карте они могут быть изображены как круги с изменяемым радиусом. Иногда такой тип используется для визуализации населения городов, где радиус круга соотносится с числом жителей города. Такой вид хоть и считается распространенным, но все поставщики карт в интернете его поддерживают. Следующим видом визуализации данных на карте является тепловая карта. Изначально она использовалась только для обозначения температуры в какой-либо точке пространства, о чем свидетельствует ее название. Однако она получила применение и во многих других сферах деятельности, в том числе и на географических картах. С помощью нее, например можно наглядно показать неравномерную плотность населения планеты. Для обозначения различной плотности используется не ее координаты и не ширина линий, а цвет. Именно параметр цвета несет в себе дополнительную информацию, привязанную к координатам. Последним видом визуализации является граф. Ребра графа могут нести в себе дополнительную информацию об объекте описания. В дискретной математике эту величину называют весом ребра. На географических картах такой вид также нашел применение. Например, граф с весами может изобразить все аэропорта страны или мира, где вес ребра будет означать время перелета. В виду сложной программной реализации, а также неоднозначного формата входных данных, далеко не все существующие поставщики карт в интернете поддерживают такой формат визуализации.
Далее следует рассмотреть, какие поставщики карт бывают. Существует несколько решений, которые являются наиболее популярными среди пользователей карт в интернете. Ими являются Google Maps, Яндекс.Карты и OpenStreetMap [7][32][15]. У каждого решения есть свои достоинства и свои недостатки. Начнем с карт от Google, поскольку они является самыми распространенными в мире в виду своей огромной аудитории. Карты впервые появились в 2005 году, поэтому имеют наибольший опыт среди всех остальных рассмотренных вариантов. Корпорация Google уделяет пристальное внимание мелочам на своих картах и каждый год старается улучшить качество своего сервиса. Помимо визуализации схемы и вида со спутника, в этих картах доступны построение маршрутов, размещение фотографий в привязке к месторасположению, панорамные виды и многое другое. К тому же Google Maps предложила пользователям возможность пройтись по улицам городов в виде функции «Просмотр улиц» (Google Street View). В настоящее время выполнена съемка большинства крупных и средних по размеру городов мира, а также некоторые достопримечательности. Далее рассмотрим Яндекс.Карты. Во многом они повторяют функционал карт от Google, поскольку почти всегда выступали в роли «догоняющих». Тем не менее, все элементы сервиса выполнены качественно, а в надежности работы не уступают своим конкурентам. В России существует ряд сервисов, которые завязаны на картах от Яндекс и используют его как основную технологию бизнеса. К ним относятся в основном транспортные компании и таксопарки. На них также существует возможность просматривать панорамы улиц, добавлять фотографии с привязкой к геолокации. Более того, кому-то даже больше нравятся смотреть карты от Яндекс, которые показывают загруженность дорог в больших городах, чем на картах конкурентов. Затем идут карты OpenStreetMap. Основной чертой этих карт является использование только свободного программного обеспечения, а также весь проект выполнен как проект с открытым исходным кодом. Поскольку он был основан некоммерческой организацией, его целью никогда не было получение прибыли. Главной идеей этого проекта стало свободный доступ каждого пользователя в интернете к достоверной карте мира, так как не существет организации, которая бы контролировала бы ее содержание и активность пользователей. На этих картах также имеется возможность просмотра карты мира, рельефа со спутников, панорам улиц. Тем не менее, скорость работы сервиса оставляет желать лучшего. Это можно понять, поскольку хостинг серверов оплачивается, в том числе и за счет добровольцев, кто не равнодушен к идее свободного программного обеспечения. Это влияет и на разработку собственных сервисов на их основе. В лицензии сказано, что запрещается использование карт в качестве основы для коммерческого продукта, и это невозможно без разрешения правообладателя. Однако не это является препятствием для разработки новых сервисов, а отсутствие механизма расширения базового функционала. Любые изменения должны быть отражены в исходном коде OpenStreetMap, после тщательного рассмотрения заявок, которые выполняются месяцами, к тому же их могут отклонить. Именно поэтому они не используются в качестве средства визуализации нестандартной информации на картах в интернете. Далее в работе этот сервис не будет рассматриваться.
Сравнивая оставшихся поставщиков картографических сервисов можно выявить и различия. В основном они кроются в программном интерфейсе сервиса. Для разработчиков дают одинаковые точки расширения карт путем подключения своих или сторонних плагинов, однако некоторый функционал доступен только для владельцев платного доступа к картам. Таким образом, для пользователя не будет никакой разницы, посмотрит от на те или иные карты, но для разработчика, как для поставщика сервиса, стоимость будет разной. В основном стоимость будет складываться из числа запросов в сутки; если определенный порог был превышен, за каждый следующий запрос будет взиматься плата. Это распространенная практика ведения бизнеса в виде предоставления программного обеспечения как сервиса. Величина этого порога регулирует характер бесплатного использования. Если порог будет низкий, то приложение можно будет использовать лишь в ознакомительных целях. Если порог будет выше, то он прекрасно подойдет для небольших сервисов с небольшим количеством пользователей. Наконец, если порог будет высоким, то такой подход подойдет и среднему, и малому бизнесу, однако плата будет взиматься с крупных предприятий. Проанализировав ценовую политику Google и Яндекс, можно сказать, что Яндекс допускает большее число бесплатных запросов, нежели его конкурент. Из этого можно сделать вывод, что именно это карты лучше всего подойдут для сервиса агрегации открытых данных и данных из социальных сетей с последующей визуализацией в виде веб сервиса.
Рассмотрев основные способы визуализации данных на карте, можно сделать вывод, что для задачи сервиса агрегации данных лучше всего подходит метод построения тепловых карт. Он отвечает следующим условиям: этот метод сохраняет информацию о географическом месторасположении, что крайне важно, когда пользователи имеют дело с геотэгами. Также метод тепловых карт показывает плотность сообщений на карте. Это достигается за счет градации цветов, которые передают плотность активности в той или иной точке карты. Где активности нет, там цвет не выделяется, показывается только карта. Там где активность есть низкая, там используется спокойные зеленные оттенки. По мере роста активности цвет будет постепенно меняться к агрессивному красному, что покажет максимальную концентрацию активности на карте. Здесь стоит отметить, почему не подходит метод агрегации в виде кружков. Во-первых, размер круга должен зависеть от степени активности пользователей в социальных сетях. Однако это можно достичь только за счет схлопывания нескольких точек в одну, вследствие чего теряется точность данных о месторасположении. К тому же на карте будет показываться только одна точка вместо площади, как будет на самом деле. Более того, смотря на карту, невозможно сразу сказать, где находится максимальная активность пользователей, поскольку размер круга легко спутать, если они похожи. К тому же возможна ситуация, когда можно просто не заметить круг большей площади где-нибудь в другом месте карты. С тепловой картой такая ситуация почти невозможна, так как цвет воспринимается однозначно, и сразу можно сказать, где место максимального скопления активности пользователей социальных сетей.