Подход к проектированию сервиса GeoEvent схож с разработкой модели геообработки в ModelBuilder в ArcGIS Pro. По сути, вы определяете последовательность операций рабочего процесса, связанных потоком обработки. Эти операции могут выполняться последовательно или параллельно, в зависимости от способа компоновки рабочего процесса обработки событий. Решения, которые вы принимаете, напрямую влияют на количество записей событий, которые вы можете ожидать будут проходить через сервис GeoEvent каждую секунду. Чтобы получить представление о количестве записей событий, которые может разумно обработать сервис GeoEvent, необходимо рассмотреть количество и сложность операций рабочего процесса в целом.
Каждая операция, включенная в сервис GeoEvent, требует некоторого времени обработки для завершения. Например, операция фильтрации может занять всего миллисекунду (или меньше) для сравнения значения атрибута записи события с пороговым значением, чтобы решить, следует ли отбросить событие или передать его на следующий этап обработки. В то время как одна операция обогащения объекта может занять до 100 миллисекунд для обработки и завершения. Независимо от того, являются ли ваши операции обычными, как фильтр, или сложными, как обогащение полей, в каждой данной секунде есть только 1000 миллисекунд.
Рассмотрим следующий пример: предположим, что общая задержка, создаваемая фильтрами и процессорами в сервисе GeoEvent, составляет 10 миллисекунд. Этот сервис сможет маршрутизировать только 100 записей событий через сервис GeoEvent каждую секунду (1000 мс в каждой секунде, разделенные на стоимость 10 мс за запись события, дают 100 записей событий в секунду).
Таким образом, чем больше фильтров и процессоров используется в сервисе GeoEvent, тем сложнее становится сервис GeoEvent. Чем сложнее сервис GeoEvent, тем больше задержка вводится с каждой операцией и тем меньше записей событий вы можете обрабатывать каждую секунду. Чем больше сервисов GeoEvent вы создадите и опубликуете, тем меньше записей событий сможет обработать GeoEvent Server в целом.
Сообщения в GeoEvent Server
Все сервисы GeoEvent имеют общую базовую шину сообщений. Таким образом, разрабатываемые вами сервисы GeoEvent либо успешно работают, либо задерживаются вместе, поскольку конкурируют друг с другом за возможность взять записи событий из очереди входных данных и начать выполнять свой рабочий процесс обработки.
Например, рассмотрим следующий простой сервис GeoEvent:
Работая в одиночку, предположим, что сервис А в GeoEvent может обрабатывать в среднем несколько тысяч событий в секунду. Теперь предположим, что вы настроили второй, очень сложный сервис GeoEvent, Сервис В в GeoEvent. Этот сервис использует те же входные и выходные данные, что и сервис A GeoEvent.
При запуске сервиса В GeoEvent общая пропускная способность записей событий, скорее всего, снизится с тысяч записей событий в секунду до нескольких записей событий в секунду для каждого сервиса GeoEvent. Поскольку два сервиса GeoEvent используют одни и те же входные и выходные данные, при запуске более ресурсоемкого сервиса GeoEvent конкуренция на одной шине сообщений снижает пропускную способность событий для обоих сервисов GeoEvent.
Оптимизация или упрощение сервисов GeoEvent
Часто задаваемый вопрос заключается в том, лучше ли моделировать рабочий процесс обработки событий с помощью нескольких различных процессоров и фильтров – или было бы лучше упростить рабочий процесс обработки событий, чтобы исключить маршруты и вилки. Например, в сложном сервисе В GeoEvent, показанном выше, существует 12 различных путей, по которым событие может пройти до получения выходных данных.
Вопрос в том, будет ли разделение этого сервиса GeoEvent на 12 различных сервисов обеспечивать лучшую производительность? В текущих версиях GeoEvent Server ответ, скорее всего, будет нет (исключение см. в разделе параллельная обработка по сравнению фильтрацией входных объектов ниже). По соображениям производительности обычно не имеет значения, использует ли рабочий процесс обработки событий один сложный сервис GeoEvent или он разбит на отдельные сервисы GeoEvent.
Однако существуют веские причины для использования нескольких простых сервисов GeoEvent вместо одного сложного сервиса: простота поддержки и отладки. Сложные сервисы GeoEvent могут быть громоздкими, и их логика может быть трудна для понимания. Поддержка сервиса GeoEvent может становиться все более трудоемкой по мере увеличения сложности его обработки, особенно когда за эту задачу отвечают многие пользователи. Кроме того, проверка и отладка сложного сервиса GeoEvent может быть тяжела. Разделение и упрощение рабочих процессов обработки на несколько простых сервисов GeoEvent облегчает поддержание и проверку желаемых результатов.
Параллельная обработка и фильтрация входных данных
Когда в сервисе GeoEvent используется несколько фильтров для принятия ряда решений, легко построить сервис GeoEvent, операции фильтрации которого будут выполняться параллельно. Однако по возможности следует избегать разработки сервиса GeoEvent, который направляет записи событий либо в набор процессоров, либо в фильтры параллельно.
Рассмотрим следующие два проекта сервиса GeoEvent:
Предположим, что входные данные в сервисы GeoEvent, показанные выше, опрашивали внешний веб-сайт для получения данных, записи которых относятся к одному из трех различных типов – легковые автомобили, легкие грузовики и коммерческие грузовики. Каждый тип транспортного средства должен обрабатываться по-разному, поэтому в сервисе С GeoEvent используются три фильтра для разделения транспортных средств на группы по типу. Для выполнения конкретной операции дискретной фильтрации служба GeoEvent должна направить копию каждой записи события в каждый фильтр. По существу, полный набор записей событий направляется в каждый из трех отдельных фильтров. Это означает, что на базовой шине сообщений обрабатывается в три раза больше записей.
Каждый фильтр сконфигурирован для выбора некоторой части данных, которые он получает, отбрасывая записи событий, которые не удовлетворяют его критериям, а затем он маршрутизирует события, представляющих интерес, к выходным данным. Каждый фильтр должен обрабатывать свою собственную копию данных, чтобы принять решение о том, какие записи событий хранить и какие записи событий отбрасывать.
Рассмотрим следующий пример: предположим, что для входных данных 123 поглощается 1000 событий в секунду, сервис С GeoEvent фактически должен обрабатывать 3000 событий в секунду. Увеличенный объем ограничит общее количество операций, которые GeoEvent Server может выполнять с входными данными событий каждую секунду во всех настроенных сервисах GeoEvent, поскольку для всех входных, выходных данных и сервисов GeoEvent используется одна шина сообщений.
Сервис D GeoEvent выполняет в целом ту же операцию, но без каких-либо настроенных фильтров. Вместо этого задача разделения данных событий на различные группы обрабатывается тремя отдельными потоками входных данных, предназначенных для каждого типа записи событий. Эта стратегия проектирования сервиса GeoEvent является предпочтительней. Большинство веб-сервисов позволяют разделять данные на различные группы с помощью параметров запроса. Настроив три различных потока входных объектов, каждый из которых содержит параметр запроса для опроса данных определенного типа транспортного средства, сервис GeoEvent можно упростить, чтобы исключить маршрутизацию в рабочем процессе обработки событий.
Понимание времени и затрат операции
Понимание того, как фильтры и процессоры выполняют свои настроенные операции, является ключом к пониманию задержки (и, следовательно, стоимости обработки), связанной с сервисом GeoEvent. Рассмотрим три сервиса GeoEvent, показанные ниже.
Предположим, что сервис GeoEvent с большинством процессоров будет иметь самые высокие эксплуатационные расходы. Однако необходимо изучить это подробнее.
Сервис 3 GeoEvent имеет больше всего процессоров, вместе с Обогащением полей, Калькулятором полей и Инспектором, которые применяются для выполнения пространственной проверки геометрии событий в отношении к геометрии геозон. Рассмотрение выполняемых операций покажет, что Обогащение полей запрашивает сервис объектов, а затем кэширует записи объектов. При первом получении записи события с определенным идентификатором трека существует относительно большая стоимость извлечения связанного объекта, но после этого первого вызова обогащение из кэша записей объекта, хранящегося в памяти, имеет очень небольшую стоимость. Строковые или арифметические операции, обычно выполняемые Калькулятором поля, также, как правило, недороги. Геометрия геозон хранится в памяти, чтобы сделать пространственные операции как можно быстрее. Таким образом, три процессора в сервисе 3 GeoEvent не имеют значительной задержки или стоимости.
В сервисе 2 Geoevent существует два различных типа геометрических процессоров. Первый – это процессор Проецирование, который берет геометрию записи события и проецирует ее в другую пространственную привязку и систему координат. Если геометрия записи события представляет собой сложный многоугольник со множеством вершин, то геометрическая проекция может быть относительно дорогостоящей операцией. Второй процессор, Упрощение, выполняет геометрическое упрощение, чтобы удалить и, возможно, изменить порядок внешних изгибов и вершин, сохраняя при этом основную форму геометрии. Опять же, для более крупных и сложных геометрий это может быть относительно дорогостоящей операцией, так как она не может использовать кэшированные данные для выполнения. Для небольших, менее сложных линейных или полигональных геометрий этот сервис GeoEvent может работать очень хорошо. Но для больших, более сложных линейных или полигональных геометрий задержка может быть намного выше.
Сервис 1 GeoEvent – это самый простой сервис GeoEvent с одним процессором;однако он потенциально является самым дорогостоящим. Процессор Калькулятор области обслуживания не является готовым процессором в GeoEvent Server, но доступен в галерее ArcGIS GeoEvent Server в качестве примера процессора,который можно создать с помощью пакета SDK GeoEvent Server. Этот процессор использует сервис сетевого анализа для вычисления полигона, граница которого представляет собой время, необходимое для перемещения из центральной точки в любую точку по периметру полигона. Его выполнение занимает значительное время (секунды, а не миллисекунды), так как пользовательский процессор вызывает сервис геообработки, чтобы проанализировать улично-дорожную сеть и вычислить полигон времени движения. Добавьте к вычислительному времени сетевую задержку выполнения запроса к сервису сетевого анализа и получения ответа. Эта операция не приемлема для большого объема событий в минуту.
Подводя итог, Сервис 1 Geoevent кажется простым сервисом GeoEvent, но из-за выполнения им сложной операции обработки он имеет самую высокую стоимость задержки среди трех примеров.