Содержание к диссертации
Введение
1 Технологии больших данных для выполнения композитных приложений 6
1.1 Технологии выполнения композитных приложений 6
1.2 Технологии организации хранения больших данных 15
1.3 Методы планирования выполнения высокопроизводительных приложений 29
1.4 Методы оптимизации хранения научных данных 34
1.5 Выводы к главе 1 37
2 Технология организации многомасштабных вычислений на основе шаблонов в неоднородной вычислительной среде 39
2.1 Современные методы многомасштабного моделирования 41
2.2 Программные инструменты организации многомасштабных вычислений 45
2.3 Шаблоны распределенных вычислений для многомасштабного моделирования 48
2.4 Параметрические модели производительности приложений многомасштабных моделей 53
2.5 Схема оптимизации многомасштабного моделирования 61
2.6 Экспериментальные исследования алгоритма оптимизации многомасштабного моделирования 68
2.7 Выводы к главе 2 69
3 Технология хранения больших данных с применением семантической модели предметной области 71
3.1 Семантическая модель предметной области 72
3.2 Технология хранения и обработки данных на основе семантической модели 76
3.3 Адаптация хранилища для сценариев использования 80
3.4 Выводы к главе 3 91
4 Разработка технологии организации многомасштабного моделирования с применением семантической модели предметной области 92
4.1 Архитектура DMMENGINE 93
4.2 Гидрометеорологическое приложение 104
4.3 Урбанистическое приложение 111
4.5 Экспериментальные исследования DMMENGINE 117
4.6 Выводы к главе 4 122
Заключение 123
Список литературы 128
Приложение 143
- Технологии организации хранения больших данных
- Параметрические модели производительности приложений многомасштабных моделей
- Адаптация хранилища для сценариев использования
- Урбанистическое приложение
Введение к работе
Актуальность темы исследования обусловлена интенсивным проникновением технологий распределенных вычислений и систем в различные области науки и технологий через инструментарий eScience и eEngineering. В силу разнообразия требований предметных областей и решаемых ими задач необходимо создавать методы и средства автоматизации процессов построения и исполнения пользовательских приложений в распределенных вычислительных средах. В России данное направление представлено в работах А.П. Афанасьева, В.П. Иванникова, В.А. Ильина, В.В. Коренькова и других исследователей. В отличие от классических суперкомпьютерных задач, допускающих масштабируемую декомпозицию с использованием несложных методов статической или динамической балансировки нагрузки, в распределенных средах актуальна организация многомасштабных вычислений. Это подразумевает наличие набора взаимосвязанных моделей и источников данных на различных узлах распределенной среды, априори не подчиняющихся единой схеме декомпозиции. Как следствие, ключевой задачей становится организация условий исполнения приложения в распределенной среде таким образом, чтобы обеспечить наибольшую вычислительную эффективность за счет согласования условий параллельной реализации отдельных модулей и компонентов с учетом обменов данных между ними. В настоящее время такая задача часто решается вручную, что может быть оправданно для промышленных приложений, используемых на идентичных наборах данных, но теряет смысл при исследовательских расчетах. Как следствие, необходимо создавать методы и технологии, автоматизирующие процесс исполнения таких приложений за счет использования априорных сведений о внутренней организации вычисления моделей и о структуре самих данных.
Целью исследования является разработка математического, алгоритмического и программного обеспечения для оптимизации исполнения многомасштабных вычислительных приложений в распределенных средах с учетом особенностей организации данных и вычислений.
Задачи исследования:
определение требований к объекту исследований на основе обзора технологий организации многомасштабных приложений, хранения и обработки больших данных, а также методов планирования в облачной среде;
формализация общего подхода к управлению исполнением многомасштабных приложений в логике кодизайна с учетом вида вычислительного шаблона и семантической структуры данных, а также разработка реализующих его алгоритмов;
разработка информационной технологии организации и исполнения многомасштабных композитных приложений в распределенной вычислительной среде, использующей разработанные алгоритмы;
экспериментальное исследование эффективности предложенных алгоритмов и информационной технологии на характерных задачах многомасштабного моделирования, сопоставление с известными аналогами.
Методы исследования включают в себя методы теории алгоритмов, эволюционных вычислений, дискретной математики, теории вероятностей и математической статистики, имитационного моделирования, инженерии программного обеспечения и анализа программного обеспечения.
Научная новизна исследования заключается в том, что предложенные алгоритмы и технологии оптимизации исполнения многомасштабных приложений основаны на принципах кодизайна, обеспечивающих одновременное управление условиями распределения задач и данных и характеристиками самой вычислительной среды за счет использования априорных знаний о семантических особенностях структур данных и логике организации вычислений в форме параметрических моделей производительности.
Практическая значимость результатов исследования заключается в создании программной системы, расширяющей возможности облачной платформы CLAVIRE и обеспечивающей эффективную работу с практически значимыми задачами, представимыми в виде многомасштабных вычислительных приложений.
На защиту выносятся:
семейство алгоритмов семантической оптимизации вычислительного процесса на основе априорных знаний об организации многомасштабных приложений, формализованных в виде вычислительных шаблонов;
информационная технология организации и исполнения многомасштабных приложений в распределенной облачной среде с интегрированными алгоритмами семантической оптимизации вычислений, а также семантическими технологиями работы с большими данными.
Достоверность научных результатов и выводов подтверждается корректным использованием методов исследования, обоснованием постановки задач и экспериментальными исследованиями разработанных технологий и алгоритмов оптимизации, в том числе сравнением с существующими аналогами.
Внедрение результатов работы. Результаты работы использованы при выполнении следующих НИОКР: «Вычислительные шаблоны для высокопроизводительных многомасштабных вычислений» (соглашение № 14.587.21.0024 от 18.11.2015 г.), «Аналитическая платформа выявления и прогнозирования девиантного поведения пользователей социальных сетей на основе композиции и сопоставления неструктурированных данных различных медиаресурсов» (Соглашение № 14.578.21.0196 от 03.10.2016 г.), «Технологии распределенных облачных вычислений для моделирования процессов большого города» (договор № НК 15-29-07034U5 от 22.07.2015 г.), «Исследования и разработка быстродействующей кластерной системы хранения и обработки сверхбольших объемов данных» (соглашение № 14.578.21.0077 от 24 ноября 2014 г.), «Технологии больших данных для проектов в области мега-сайенс» (договор № 14.Z50.31.0024 от 14 мая 2014 г.).
Апробация работы. Полученные результаты обсуждались на девяти международных научных конференциях, включая International Conference on
Computational Science (Сан-Диего, США, 2016), International Conference on Computational Science (Цюрих, Швейцария, 2017), International Conference on Cloud and Big Data Computing (Лондон, Великобритания, 2017), International Conference on Soft Computing Models in Industrial and Environmental Applications (Леон, Испания, 2017).
Публикации. По материалам диссертации опубликовано 18 научных работ (в том числе 1 статья - в издании из перечня ведущих рецензируемых научных журналов и изданий ВАК РФ, 17 - в изданиях, индексируемых Scopus и Web of Science), получено 3 свидетельства о государственной регистрации программ.
Личный вклад автора в работах, выполненных в соавторстве, заключается в: выполнении аналитического обзора в предметной области диссертационной работы; обосновании требований к алгоритмам планирования наборов композитных приложений в неоднородных распределенных вычислительных средах; формализации постановки задачи планирования композитных приложений для распределенных сред; разработке методов планирования наборов композитных приложений с ограничениями по срокам завершения и по стоимости ресурсов; разработке алгоритмического и программного обеспечения планирования наборов композитных приложений на базе вышеозначенных методов; проектировании и реализации технологии выполнения многомасштабных приложений на основе платформы CLAVIRE; формализации постановки задачи хранения данных на основе семантической модели предметной области; разработке методов представления и распределения данных исходя из специфических особенностей последних; разработке алгоритмического и программного обеспечения для распределенного хранения данных на основе семантической модели предметной области; проведении экспериментальных исследований и интерпретации их результатов. Из работ, выполненных в соавторстве, в диссертацию включены результаты, которые соответствуют личному участию автора.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения и списка литературы (187 источников), содержит 149 страниц текста, включая 46 рисунков и 4 таблицы.
Технологии организации хранения больших данных
Современные технологии создания и выполнения композитных приложений требуют не только интеграции с различными высокопроизводительными системами, но и взаимодействия с эффективными инструментами обработки и хранения больших данных, способными за секунды обеспечить доступ к петабайтам распределенной информации.
В таблице 1.2 по разным критериям (разнородность и мощность запросов к данным, в том числе специализированные типы; наличие механизмов индексации; возможность чанкинга; сжатие данных и хранение с контролируемой потерей качества данных; также надежность, масштабируемость, как вертикальная, так и горизонтальная; инструментальная и программная поддержка) проанализированы наиболее перспективные и распространенные технологии организации работы с большими данными.
Apache Cassandra [30] - это универсальное распределенное NoSQL-хранилище со своим языком запросов CQL (Cassandra Query Language). Основными функциями Cassandra является обеспечение линейной масштабируемости и отказоустойчивости. Cassandra предоставляет множество возможностей изменения модели хранения данных. Также возможно удаление данных по истечении их срока годности, что актуально для чтения данных в реальном времени.
По критерию масштабируемости Cassandra считается одной из лучших баз данных, однако линейная масштабируемость обусловливает существенные задержки при операциях записи и чтения. Поддерживаются две стратегии репликации данных:
- простая стратегия позволяет задать фактор репликации, который, в свою очередь, определяет, сколько узлов будут хранить реплику каждой строки. Подразумевается, что все узлы идентичны, и отношение к ним эквивалентно;
- стратегия топологии сети позволяет устанавливать свой фактор репликации для каждого дата-центра в кластере и в большинстве случаев является предпочтительной для простоты последующего добавления, например, виртуальных дата-центров.
Cassandra поддерживает компромисс между согласованностью и доступностью на каждую операцию через так называемые уровни согласованности. По сути уровень согласованности операции определяет, сколько реплик должно отвечать координатору, чтобы операция считалась успешной.
PostgreSQL [31] является системой управления объектно-реляционными базами данных (ORDBMS) с акцентом на соответствие требованиям расширяемости. Основными функциями данной системы являются надежное хранение данных и их возврат в ответ на запросы других программных приложений. Система может эффективно работать и с небольшими однопроцессорными приложениями, и с большими, web-ориентированными, с множеством параллельных пользователей.
PostgreSQL поддерживает встроенную двоичную репликацию, основанную на отправке изменений для репликации узлов асинхронно, с возможностью запуска запросов только для чтения с этими реплицируемыми узлами. Это позволяет эффективно распределять поток чтения среди нескольких узлов. PostgreSQL также поддерживает встроенную синхронную репликацию, которая гарантирует, что для каждой транзакции записи master ждет, пока по крайней мере один узел не запишет данные реплики в свой журнал транзакций. В отличие от других систем управления подтверждение транзакций (будь то асинхронная или синхронная) может быть указана для каждой базы данных, для каждого пользователя, сеанса или транзакции. Это может быть полезно для рабочих нагрузок, которые не имеют особенных требований или эти требования должны быть применены не для всех данных, если это будет иметь негативное влияние на производительность в связи с заданным требованием подтверждения транзакций.
SAP HANA [32]. Платформа для хранения и обработки данных SAP HANA основана на технологии вычислений in-memory, данные хранятся в оперативной памяти электронно-вычислительной машины (ЭВМ). В платформу входят система управления базами данных (СУБД), web-сервер и система контроля версий. СУБД ориентирована на поколоночное хранение данных, архитектура обеспечивает как высокоскоростную обработку транзакций, так и работу со сложными аналитическими запросами. Разрабатываемая компанией SAP система доступна и как устанавливаемое программное обеспечение (SAP Business Warehouse), и как сервис (SAP Cloud Platform).
Технология In-Memory в СУБД SAP HANA позволяет хранить и обрабатывать данные в оперативной памяти. Запросы к данным находятся в сжатом виде в памяти RAM. В SAP HANA реализован подход Unified Tables, который обеспечивает высокую скорость чтения и записи данных в таблицу колоночного хранения. Поэтому одним из главных преимуществ SAP HANA является возможность выполнять аналитические запросы сразу на транзакционных данных, которые добавляются в реальном времени. При этом система автоматически берёт на себя обеспечение прозрачного доступа к данным. Таким образом, новые данные в таблице сразу доступны для анализа без предварительной обработки.
SciDB [33] - это постреляционная аналитическая СУБД, рассчитанная на хранение и обработку сверхбольших объёмов многомерных научных данных. SciDB объединяет в себе базу данных и среду обработки и анализа данных. Проект с открытым исходным кодом разрабатывается компанией Paradigm4.
Для работы с данными (массивами) в SciDB используется декларативный язык AQL (Array Query Language). AQL схож с SQL (Structured Query Language), но оперирует не таблицами, а массивами данных. Также AQL позволяет анализировать не только конкретные точки, но и их окрестности.
SciDB использует архитектуру независимых узлов (shared-nothing architecture). Узлы не имеют общей памяти или дискового пространства. В системе отсутствует единый центр, что ведёт к естественной горизонтальной масштабируемости. Вся база данных (БД) хранится на распределённом кластере серверов, на каждом из которых установлено приложение SciDB. Один из серверов при этом выступает в роли координатора, который распределяет выполнение запросов и выдачу результатов внутри кластера, за который ответствен этот сервер-координатор. Одна установленная система SciDB (installation) может включать в себя несколько кластеров.
Apache Kudu [34] представляет собой гибрид высокопроизводительных систем хранения с последовательным доступом (таких как Hadoop Distributed File System, HDFS) и систем с произвольным доступом с низкой задержкой (таких как Ffflase или Cassandra). В настоящее время Kudu не предоставляет вторичных индексов или ограничений уникальности кроме первичного ключа. Kudu предлагает только операцию сканирования для извлечения данных из таблицы. При проверке пользователь может добавить любое количество предикатов для фильтрации результатов, но поддерживается только два типа предикатов: сравнение столбца с постоянным значением и диапазоны составных первичных ключей. Эти предикаты интерпретируются как клиентом, так и сервером, чтобы эффективно определять данные, передаваемые с диска и по сети. Архитектура Kudu предполагает наличие master-узла и slave-узлов. Master-сервер отвечает за метаданные, и в качестве slave-узлов доступно произвольное число серверов, отвечающих за данные. Узел может быть реплицирован для отказоустойчивости, поддерживая очень быстрое восстановление после выполнения всех функций в случае сбоя. Разделение данных между slave-серверами осуществляется с помощью частей таблицы, сформированных по значению первичного ключа на основании некоторого правила.
DataStax [35] - это система для комплексного управления данными. DataStax Enterprise (DSE) предоставляет облачные приложения, которые требуют распространения данных в центрах обработки данных и облаках, используя защищенную платформу, построенную на Apache Cassandra.
Параметрические модели производительности приложений многомасштабных моделей
Приложения многомасштабного моделирования в общем виде содержат одновременно и вертикальное, и горизонтальное представление. Данные представления и должны определять основную специфику многомасштабных приложений при описании параметрических моделей производительности. Прежде чем определять параметрические модели многомасштабных приложений, необходимо определить модели обычных приложений и потоковых (в соответствии с рисунком 2.2).
Модель производительности обычного композитного приложения (базовый тип моделей, предполагающий выполнение задач в пакетном режиме) основана на следующем выражении [177]:
Выражение (2.2) описывает простое представление модели производительности, однако в случае с многомасштабными приложениями оно неприменимо напрямую, так как необходимо переходить на уровень выполнения отдельных итераций самого моделирования, т.е. взаимодействие моделей осуществляется именно в рамках итерации. Эта модель схожа с моделями производительности потоковой обработки [178], где главным критерием становится не время выполнения приложения Техес, а производительность приложения Рарр (условное число операций выполнения одной итерации) вида
Однако в отличие от потоковой обработки необходимо учитывать структуру многомасштабных приложений (см. рисунок 2.2), что расширяет применимость формулы (2.3). Пусть для упрощения модели многомасштабное приложение имеет вид бинарного дерева, где каждый уровень потомков соответствует уровню вертикального представления, а общее время выполнения итерации равно времени выполнения корня как инициализирующего элемента и времени выполнения поддеревьев. В данной структуре присутствует только вертикальное представление, в котором головной узел выполняет свою итерацию и передает информацию двум потомкам, те, в свою очередь, выполняют свои итерации и передают информацию потомкам (в соответствии с рисунком 2.3).
Таким образом, модели производительности (2.3)-(2.6) представляют базовое описание процесса выполнения приложений в потоковой форме с учетом основной специфики многомасштабности, однако для понимания особенностей моделей производительности шаблонов ES, RC и НМС необходимо более детально рассмотреть их структуру.
Модели ES-шаблона. Для того чтобы описать время выполнения итерации шаблона ES, необходимо выделить основной принцип его формирования, а именно концентрацию оптимизации на одном «экстремальном» уровне, обеспечивающем 99 % предполагаемых вычислительных и временных затрат (рисунок 2.4).
Исследования параметрической модели ES-шаблона. В ходе анализа параметрической модели шаблонов ES были проведены эксперименты для расчетной задачи 10000x10000 элементов с вкладом последнего уровня в 99 % относительно остальных масштабов. Также были сохранены компонент генерации шума амплитудой в 5% и сетевые накладные расходы. Взаимодействие текущего блока модели с соседними определялось через граничную зону (т.е. периметр области). Результаты анализа для меняющейся глубины представлены на рисунке 2.5.
Как видно, динамика сходимости общего времени счета быстро выходит на горизонтальную прямую, т.е. при двухуровневой модели (коричневая линия), трехуровневой (зеленая), как, впрочем, и при четырехуровневой (синяя) необходимо наличие хорошо параллелизуемых прикладных задач. На рисунке 2.6 представлена функция времени выполнения итерации в случае значимых межмодельных связей в рамках одного уровня (ES).
Значимость выражалась в объеме передаваемых данных, пропорциональном обрабатываемым (в простейшем случае - отношение площади моделируемой области к периметру). Коричневый график соответствует четырем связям у каждой модели уровня ES, зеленый - 32, а синий - 64. Как видно, все графики сходятся к величине, которая определяется через постоянные накладные расходы и не зависит от самих данных.
Модели RC-шаблона. В данном шаблоне RC акцент смещается с поддержки «экстремального» уровня на экстенсивные вычисления, где основным критерием служит минимальный объем счета за определенное время (рисунок 2.7).
Для простейшего бинарного дерева выражение (2.10) определяет наиболее быстрые поддеревья и работает только с ними с целью выполнить необходимое число расчетов в указанные временные рамки tconstl. С другой стороны, tconsU может быть критерием ограничения выполнения отдельных вычислительных узлов на отдельных уровнях.
Исследования параметрической модели RC-шаблона. На рисунке 2.8 представлены результаты с ограничением времени выполнения в 5 % (в), 2,5 % (б) и без ограничения времени выполнения в задаче RC-шаблона.
Необходимо оценить зависимость качества моделирования всего приложения от фиксированного времени выполнения каждой итерации моделей каждого уровня данной топологии приложения. В рамках вложенного моделирования время делится пропорционально на каждую модель. При анализе применялась модель производительности (2.8) с амплитудой шума 2,5, 5, 7,5%. Как видно, чем выше кратность узлов, тем больше доля выполненных моделей, так как число узлов растет экспоненциально с каждым уровнем, а вероятность прохождения временного порога у последних уровней выше. С другой стороны, очевидно, что при большем пороге (7,5%) больше моделей выполняет итерации в срок.
Модели НМС-шаблона Модель производительности для шаблона НМС реализуется путем выделения вертикального представления через связи блоков, тем самым акцентируется важность самого межмасштабного взаимодействия (рисунок 2.9).
Адаптация хранилища для сценариев использования
С целью оценки эффективности разработанного решения для хранения специализированных данных был выбран сценарий обработки метеорологических данных в формате NetCDF. NetCDF является двоичным форматом, ориентированным на хранение массивов, который хранит переменные и их измерения внутри файлов. Эти переменные обычно содержат непрерывные данные, к которым можно обращаться по их измерениям. Все массивы в файле NetCDF являются плоскими, то есть в случае, когда переменные имеют несколько измерений, массив, содержащий данные этих переменных, является линейным. Для того чтобы получить значение какой-либо переменной в выбранной точке, достаточно знать измерения этой переменной. Это позволяет извлечь значение, используя смещения в плоском массиве без чтения всего массива. Доступ к переменным осуществляется также через смещения, которые указаны в заголовке файла. Описанные свойства позволяют работать с переменными и значениями файла NetCDF без чтения всего файла в память, что позволяет создавать большие файлы, хранящие много взаимосвязанных данных. На сегодняшний день формат NetCDF используется более чем в 1300 образовательных, исследовательских и правительственных организациях.
Поскольку сам по себе формат NetCDF не накладывает на пользователей никаких ограничений в плане формирования внутренней структуры файлов, а целевой предметной областью является метеорология, семантическая модель создавалась на основе климатических и прогнозных конвенций метаданных [183]. Эти конвенции определяют четыре возможных измерения для переменных - долготу, широту, вертикальный уровень и время. Используя ориентированную на массивы природу NetCDF, имплементация интерфейса распаковщика разбивает каждый файл на срезы, где каждый срез представляет одно поле переменной на каком-то вертикальном уровне в определенный момент времени. Возможность считывания значения в какой-либо точке поля с использованием смещений позволяет не выполнять дальнейшее разделение на отдельные точки и тем самым значительно уменьшить объем хранилища. Схема разбиения файла на фрагменты представлена на рисунке 3.4 (Р, Т и V обозначают имена переменных). Переменные в файлах в основном имеют различные числовые типы (float, integer, byte), но имена переменных являются символьными и могут также использоваться для индексирования данных. В имплементации интерфейса распаковщика для файлов NetCDF имена переменных используются в качестве ключей наборов блоков данных. Это позволяет хранить поля одних и тех же переменных вместе.
После распаковки каждый срез данных индексируется с использованием хэша на основе временной метки, который является одномерным случаем кривой Мортона, и разделяется по узлам хранения согласно имени переменной. Измерения переменных хранятся внутри каждого среза данных, чтобы сделать его самодостаточным и обеспечить быстрый поиск точек в нем. При выполнении пользовательских запросов результат упаковывается в исходный формат через процесс упаковки и преобразуется в набор файлов NetCDF.
Чтобы проверить применимость разработанного хранилища для реальных сценариев, мы сравнили его производительность для типичных операций над файлами NetCDF с двумя широко принятыми корпоративными решениями - HDFS и Cassandra. В экспериментах использовались три типа файлов: малые (8 МБ, 1 переменная, 3 измерения), средние (30 МБ, 17 переменных, 3 измерения в каждой) и большие (400 МБ, 103 переменных, по 3 измерения в каждой). Все решения были развернуты в кластере, содержащем три высокопроизводительных сервера. Во всех экспериментах время передачи файла между клиентом и хранилищем было исключено из итогового времени. Каждый эксперимент повторялся 20 раз для обеспечения статистической значимости.
Для демонстрации важности правильной структуры управления индексами были созданы две различные реализации индексов для Exarch: оптимизированная древовидная и неоптимизированная хэш-таблица. Оптимизированная реализация - это В-дерево, узлы которого представляют собой координаты кривой Мортона, что позволяет использовать его в качестве многомерного индекса. Неоптимизированная реализация использует примитивную хэш-таблицу и координаты кривой Мортона в качестве ее значений.
Следует отметить, что для Cassandra и Exarch использовались одинаковые процедуры упаковки и распаковки для того, чтобы сравнить механизмы хранения и эффективность индексирования без каких-либо накладных расходов на трансформацию.
В первом эксперименте файлы загружались в хранилище через его собственный интерфейс. Результаты теста на загрузку данных представлены на рисунке 3.5. Можно видеть, что оптимизированная версия Exarch превосходит другие решения во всех сценариях. Для загрузки небольших файлов оптимизированная версия Exarch работает в семь раз быстрее, чем HDFS (0,3 секунды против 2,1 секунды). Для больших файлов производительность выше в два раза, потому что в этом случае операции упаковки занимают больше времени, тогда как для HDFS единственной операцией является загрузка файла в хранилище. 100
Во втором эксперименте производились поиск набора полей и их выгрузка из хранилища через его собственный интерфейс. Результаты теста загрузки представлены на рисунке 3.6. Из экспериментов видно, что во всех случаях обе версии Exarch обеспечивают лучшую производительность, чем FIDFS и Cassandra. Оптимизированный Exarch генерирует большой файл за 134 с, в восемь раз быстрее, чем HDFS (1128 с) и в два раза быстрее, чем Cassandra. Такое значительное улучшение было достигнуто благодаря более легковесной архитектуре Exarch и специализированному индексу для поиска и обработки данных. Влияние правильно реализованной двухуровневой индексации можно наблюдать в сравнении оптимизированной и неоптимизированной версий Exarch, которое показывает, что продвинутая схема реализации индекса позволяет добиться почти трехкратного прироста скорости генерации файлов
Урбанистическое приложение
Приложение Urban mobility предназначено для многомасштабного моделирования городской мобильности в круглосуточном режиме. Актуальность приложения определяется необходимостью воспроизведения цельной картины городской мобильности с детализацией до активности отдельных жителей по фрагментарным данным неогеографических сервисов, социальных медиа, социологических исследований, публичных камер видеонаблюдения и других источников возможных данных.
Практическую значимость представляет анализ и прогноз городской мобильности с воспроизведением как типовой картины для рабочего и выходного дня, так и городской мобильности на конкретную дату. Результаты моделирования могут использоваться в качестве входных данных для различных оптимизационных сервисов, таких как маршруты общественного транспорта, скорая и неотложная медицинская помощь, вывоз мусора и т.п. Преимуществом подхода является возможность вычислять параметры мобильности с детализацией до отдельного дома без необходимости непосредственного моделирования каждого дома в отдельности. Это обеспечивается за счет многомасштабного характера модели и существенно снижает вычислительные затраты при проведении расчетов. Модель реализуется на трех уровнях: макро-, мезо-, микро-.
На макроуровне осуществляется моделирование перемещения жителей города между муниципальными образованиями (МО) с шагом по времени один час. Результатом моделирования является доля людей, перемещающихся между любой парой МО в каждый момент времени. На мезоуровне осуществляется перемещение отдельных индивидов (жителей города) между основными точками притяжения (дом-работа-шоппинг-досуг) в объемах, соответствующих макромодели, без детализации способов перемещения между точками.
На микроуровне осуществляется микромасштабное моделирование перемещения отдельных индивидов с пространственной детализацией до метров и временной до долей секунды, с учетом способов перемещения между точками (пешеходная мобильность, общественный транспорт и т.д.).
На рисунке 4.11 приведена принципиальная схема многомасштабного приложения городской мобильности с указанием вложенности моделей.
Муниципальные округа объединяются в районы, параметры мобильности которых естественным образом пересчитываются по параметрам мобильности МО. Модель динамики городского населения формирует притоки и оттоки для каждого муниципального округа в течение дня, в результате чего численность населения в различных округах колеблется в значительных диапазонах, что характерно как для спальных, так и для центральных районов города. Вследствие специфики различных городов выбор того или иного города в значительной степени определяет параметры модели и входные данные (например, в крупных городах доминирующим способом перемещения жителей по городу является использование метрополитена, а в городах меньшего масштаба метрополитен, как правило, отсутствует). Результаты моделирования, а также управляющие мобильностью параметры показаны на примере Санкт-Петербурга, который состоит из 111 МО. В соответствии с модельными результатами в некоторые центральные муниципальные округа города может приезжать примерно вдвое больше людей, чем проживает в самих МО.
В модели рассматриваются два вида активности - отправление из дома и возвращение домой. Время между этими событиями группа проводит вне своего МО: на работе, учебе, в магазине, кинотеатре и др. При этом учитывается, что часть жителей остается внутри своего муниципального округа, что характерно для определенных групп населения: дети, школьники, пенсионеры. Процент активного населения в округе характеризуется настраиваемым коэффициентом модели
Значения О; (1-5) устанавливают эксперты на основе характеристик каждого МО (1 - очень привлекательный, 2 - достаточно привлекательный, 3 - в средней степени привлекательный, 4 - скорее не привлекательный, 5 - абсолютно не привлекательный).
Существует дисбаланс между округами, возникающий в основном за счет внутридневной миграции населения между спальными (преимущественно на окраинах города) и офисно-рабочими районами (располагаются преимущественно в центре города). В результате в дневные часы (примерно с 11 до 18) плотность населения в центре сильно повышается, а на окраинах уменьшается.
Алгоритм работы приложения описывается следующим образом:
- запуск сценария (выбор города, района(ов), здания(ий) для моделирования);
- после запуска нового сценария клиентским приложением отправляется запрос на серверное приложение на осуществление процесса моделирования;
- серверное приложение запускает процесс моделирования, где макромодель (перемещение групп людей между МО) взаимодействует с несколькими мезомоделями (локализованные территории масштабом от 50 м), а модель мезоуровня взаимодействует с одной или несколькими моделями микроуровня (перемещение людей внутри зданий).
На рисунке 4.13 представлена схема приложения с адаптациями, необходимыми для его выполнения с учетом шаблонов.
В данном приложении можно выделить шаблон НМС. Однако подразумевается постепенная генерация блоков, отвечающих за реализацию мезо- и микророуровня. Таким образом, приложение может быть адаптировано под данный шаблон с использованием правил генерации новых блоков, т.е. путем введения служебного блока, содержащего правило (в данном случае получения события о завершении моделирования мезоуровня) и реагирующего изменением структуры КП на данное событие. Также это потребует соответствующей поддержки от подсистемы планирования многомасштабных КП. Каждый из программных блоков, реализующих моделирование, должен быть модифицирован - он должен предоставлять реализацию специального интерфейса для взаимодействия с DMMEngine. Данное взаимодействие подразумевает прием и передачу данных, представляющих собой результаты работы отдельных блоков, запуск и прерывание вычислений согласно логике синхронизации шаблона и самого приложения для отдельных блоков; запросы на создание новых необходимых блоков и удаление существующих и более не нужных. Также каждый из блоков должен быть снабжен модулем, организующим передачу данных и сетевое взаимодействие между отдельными блоками приложения и служебными подсистемами DMMEngine, отвечающими за создание новых блоков и планирование их размещения и выполнения. Последнее требует либо включения указанного модуля в состав блока моделирования, либо, в соответствии с рисунком 4.8, включения каждого блока моделирования в специальную программную обертку, содержащую необходимые модули. Это может потребовать конвертации самого блока моделирования из исполняемого файла в программную библиотеку. Необходимость в создании блоков «на лету» также может потребовать реализации определенной логики блоков моделирования для управления количеством блоков.
При планировании приложения нужно учитывать следующее. Обмен данными между блоками одного уровня в рамках шаблона происходит только через блок более высокого уровня. При этом объем передаваемых данных между блоком микромодели и блоком мезомодели в общем случае будет больше, чем между блоком мезомодели и блоком макромодели. Также число микромоделей для одной мезомодели может быть существенно больше, чем число мезомоделей у макромодели. Все вышесказанное требует оптимизации размещения вычислительных блоков с учетом структуры самого приложения и шаблона и принятия во внимание параметров приложения, определяющих объем передаваемых данных между моделями различных масштабов, что потребует применения параметрических моделей производительности. В частности, размещение микромоделей может потребовать организации отдельных кластеров, состоящих из одной мезомодели и набора микромоделей, что должно учитываться во время планирования. Вторым моментом является необходимость учета возможности генерации новых блоков во время выполнения приложения, что, в свою очередь, должно влиять на количество запрашиваемых ресурсов, часть из которых может быть зарезервирована и использована только при необходимости.