Текст работы - Высшая школа экономики
advertisement
Правительство Российской Федерации Федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики" Отделение программной инженерии Кафедра Управления разработкой программного обеспечения ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА На тему Исследование методов многомерного хранения данных для извлечения и анализа процессов Студента группы № 272 МУРПО Богословского Егора Максимовича Научный руководитель Доцент Брейман Александр Давидович Консультант без ученого звания Антимонов Сергей Григорьевич 1 Аннотация Настоящая работа посвящена исследованию методов хранения многомерных данных для извлечения и анализа процессов. В рамках данной работы ставились задачи предложить метод записи, хранения и обращения к хранилищу данных, содержащему процессные данные, а также дать характеристику методов, используемых в технологии OLAP применительно к процессным данным. В качестве результата проведённого исследования был создан программный продукт, способный создать и заполнить хранилище данных на основе выполненного анализа, и предоставляющий возможность применить некоторые из методов технологии OLAP к процессным данным. В тексте данной работы приводится описание процесса проектирования структуры хранилища данных, описание основных алгоритмов, используемых при анализе файла, исследование применимости методов OLAP для процессных данных, а также обзор созданного программного продукта. В конце данной работы приводится заключение и обзор достигнутых результатов. 2 Оглавление Аннотация ......................................................................................................................................................... 2 Введение ........................................................................................................................................................... 5 Хранилище данных....................................................................................................................................... 7 OLAP ............................................................................................................................................................... 7 Многомерное хранение данных ................................................................................................................. 8 Процессные данные ..................................................................................................................................... 9 Стандарт XES ................................................................................................................................................. 9 BI Решения................................................................................................................................................... 12 Исследовательская часть ............................................................................................................................... 14 Выбор формата входных данных .............................................................................................................. 14 Создание структуры хранилища данных .................................................................................................. 15 Описание таблиц и полей полученного хранилища данных: ................................................................ 18 Таблица FACT .......................................................................................................................................... 18 Таблица TRACE ........................................................................................................................................ 18 Таблица TPROPERTY ................................................................................................................................ 19 Таблица EVENT ........................................................................................................................................ 19 Таблица EPROPERTY ................................................................................................................................ 20 Применение технологий, характерных для многомерных данных ....................................................... 21 Нарезание (Dice) ..................................................................................................................................... 23 Срез (slice) ............................................................................................................................................... 24 Развернуть и сжать (drill down, drill up) ................................................................................................ 25 Вращение (pivot) ..................................................................................................................................... 26 Выводы исследовательской части ............................................................................................................ 26 Практическая часть ......................................................................................................................................... 28 Анализ лога ................................................................................................................................................. 28 Создание запросов к хранилищу .............................................................................................................. 31 Визуализация процесса ............................................................................................................................. 32 Разработанное программное решение .................................................................................................... 32 Приветственный экран ........................................................................................................................... 32 Экран загрузки ........................................................................................................................................ 34 Рабочая область ...................................................................................................................................... 34 Экран обучения....................................................................................................................................... 38 3 Анализ полученных результатов ............................................................................................................... 38 Методы улучшения разработанного решения ........................................................................................ 41 Заключение ..................................................................................................................................................... 42 4 Введение Предмет данной магистерской диссертации состоит в исследовании методов многомерного хранения данных для извлечения и анализа процессов. Анализ процессных данных является важным направлением развития анализа данных. Задача процессного анализа - это оптимизация полученных во время обработки процессов. Входными данными для проведения анализа является описание процессов и их свойств. Частным случаем подобного рода описания, использующегося в данной работе, является лог в формате XES. Промежуточными данными для работы представленного программного продукта является хранилище данных, построенное на основе динамического анализа данных лога. Стоит заметить, что источником данных для аналитических функций представленного инструмента является не файл лога, а хранилище данных, построенное на базе анализа данного лога. Этот подход обладает следующими преимуществами: Изменение аналитических условий не ведет к повторному анализу файла лога; Возможность параллельного анализа нескольких срезов полученных данных; Возможность использования механизмов агрегации индексирования и партиционирования данных по заданному показателю. Результатом анализа процессных данных является процесс или группа процессов, описываемых в виде направленных графов или, как частный случай, - сетями Петри. Данные, полученные в результате анализа процессных данных, используются для анализа бизнес процессов. В рамках практического решения, отражённого в данной работе, результатом анализа данных является направленный невзвешенный граф, представляющий собою сумму возможных последовательностей цепочек событий, упорядоченных по вероятности их 5 возникновения с учетом заданных условий. Другими словами, разработанный инструмент позволяет производить не только аналитику процессных данных, но также задавать критерии отбора и вероятностную оценку возможности результирующего процесса. Современные инструменты, созданные для анализа процессных данных, работают с логами систем, в частности, с логами, оформленными в рамках стандарта XES. Все существующие инструменты содержат большой набор функциональных аналитических инструментов, но обладают схожим недостатком - обработка процессных данных производится напрямую из файлов. То есть каждая итерация в процессе анализа данных сопровождается чтением и повторным анализом файла лога с дополнительными условиями. На небольших объёмах данных вышеуказанный подход работает стабильно, но, в случае работы с большим количеством логов, повторное считывание и обработка с применением дополнительных условий занимает сравнительно большой промежуток времени. Еще одним из аспектов, рассматриваемых в рамках данной работы, является возможность представления процессных данных в виде многомерных данных и применения к ним методик анализа, характерных для аналитики, с использованием BI решений. Так как направление процессного анализа сравнительно молодое ответвление направления анализа данных, то многие методы, широко используемые, к примеру, для нечисловых данных, еще не находили своего применения в анализе процессных данных. Для более подробного рассмотрения проделанной в рамках данной магистерской диссертации работы необходимо дать определение следующим используемым терминам: «многомерные данные», «процессные данные», а также терминам, являющимся производными от рассмотренных ранее технологий, таким как: «хранилище данных», «стандарт XES», «OLAP кубы», «таблица фактов», «таблицы измерений», «BI решения». Итак, рассмотрим данные понятия. 6 Хранилище данных Хранилище данных представляет собой базу данных, используемую для создания отчётности и проведения анализа. Хранилище данных может содержать информацию, собранную из различных систем, объединяемых работой с одним и тем же объектом или процессом с различных ракурсов. Обычно загрузка данных в хранилище производится из систем, поддерживающих работу с OLTP базами данных, и, как частный случай, из ERP систем. Использование хранилищ данных обладает рядом преимуществ: Агрегация информации в одной базе даёт возможность для многокритериального анализа; В хранилище данных есть возможность использования исторических данных; Композиция данных в хранилище позволяет сосредоточить данные на нужды бизнеса, а не на нужды конкретной системы; В хранилище данных возможно объединить различные понятия и термины, которые используются в различных системах, в единые справочники; Архитектура в хранилищах данных позволяет использование больших объёмов информации без существенного замедления процесса анализа; Агрегация показателей за временные промежутки позволяет аналитику получить тот же результат, который может быть получен без агрегатов, но с меньшей нагрузкой на базу данных. OLAP Online Analytical Processing или аналитическая обработка данных в реальном времени — это технология, применяемая к хранилищам данных, подразумевающая использование структуры типа «звезда» (Star) или типа «снежинка» (Snowflake). Названия структур отображают отношения связи 7 таблиц. Так, при использовании структуры «звезда», в случае представления таблиц в виде направленного графа, граф будет иметь два уровня, а при использовании структуры «снежинка» граф будет иметь два и более уровней. Можно сказать, что структура «звезда» может являться частным случаем структуры «снежинка». Также важно заметить, что хранилище данных, структура которого построена на базе структуры «снежинка», может быть приведено с сохранением функционала до структуры «звезда». Считается, что хранилища данных, построенные с использованием структуры «снежинка», являются более нормализованными. Под нормализацией хранилища, в данном случае, понимается снижение количества дублирующих данных в хранилище. Также считается, что хранилища данных, построенные с использованием структуры «снежинка», являются более производительными, но и более требовательными к ресурсам. Это - следствие того, что структура хранилища «звезда» является многоуровневой, и, как следствие, размер таблиц является небольшим относительно хранилища «звезда». Центральной таблицей в хранилище данных является таблица фактов, которая содержит агрегированные данные. Остальные таблицы называются «таблицы измерений». Таблицы измерений должны представлять собой совокупность различных критериев, по которым можно выбрать и агрегировать показатели таблицы фактов. Так как агрегация данных чаще всего проводится над числовыми данными, в основу таблицы фактов обычно кладут числовые показатели. Результатом запросов к OLAP должен быть объект или группа объектов из таблицы фактов, отобранные по результатам применения условий к связанным таблицам измерений. Многомерное хранение данных Многомерное хранение данных — это хранение данных с использованием структуры данных технологии OLAP. Можно сказать, что в этом случае таблица фактов, или основной артефакт, рассматриваемый в созданном OLAP кубе, может быть исследован через несколько его измерений или срезов. Под 8 измерениями, в данном случае, понимаются таблицы измерений или таблицы, которые содержат информацию, по которой данные из таблицы фактов могут быть выбраны и агрегированы. Процессные данные Процессные данные — это данные, содержащие в себе информацию о процессе и его свойствах. Обычно процессные данные являются результатом работы ERP систем или систем, поддерживающих OLAP хранилище данных. Результатом обработки такого типа данных должен являться направленный граф, как описатель происходивших процессов или группы процессов. Процессные данные широко используются для аналитики процессов в целях их последующей оптимизации. Стандарт XES Стандарт XES, разработанный в Технологическом Университете Эйндховена, является функциональным расширением стандарта MXML, который, в свою очередь, является функциональным расширением стандарта XML для описания процессных данных. Данный стандарт имеет 4 типа объектов, таких как: Лог — объект, описывающий общую информацию о передаваемой группе процессов и используемых расширениях формата; Трейс (Trace) — объект, содержащий описание группы событий. Данный объект является дочерним объектом лога; Событие (Event) — объект, содержащий описание каждого события, произошедшего в рамках трейса. Данный объект является дочерним объектом от трейса; Мета (Meta) — объект, содержащий мета-информацию о логе. Описанный стандарт является расширяемым. Обычно используются 9 следующие расширения стандарта: Концепт (Сoncept) — данное расширение распространяется на объекты «лог», «трейс» и «событие». Расширение дополняет названные объекты двумя показателями: имя (Name) — именованный описатель объекта, экземпляр (Instance) — уникальный описатель объекта. Все добавленные свойства имеют строчный тип. Жизненный цикл (Lifecycle) — данное расширение распространяется на объекты «лог» и «событие». Для лога расширение добавляет свойство «модель» (Model), показывающий описатель транзакционной модели в логе. Для события добавляется свойство «состояние» (Transition). Состояние описывает переходы внутри одного и того же события. События бывают следующих типов: ◦ Отложено (Schedule); ◦ Назначено (Assign); ◦ Отменено (Withdraw); ◦ Переназначено (Reassign); ◦ Запущенно (Start); ◦ Приостановлено (Suspend); ◦ Продолжено (Resume); ◦ Процесс прерван (Pi_abort); ◦ Активность прервана (Ate_abort); ◦ Завершено (Complete); 10 ◦ Пропущено автоматически (Autoskip); ◦ Пропущено (Manualskip); ◦ Неизвестно (Unknown). Все добавленные свойства имеют строчный тип. Организация (Org) — данное расширение распространяется только на события. В события добавляются свойства «ресурс» (Resource), «роль» (Role) и «группа» (Group), отвечающие за обозначение тех лиц, кем данное событие выполнялось. Все добавленные свойства имеют строчный тип. Время (Time) — данное расширение распространяется только на события. В события добавляется свойство «временная отметка» (Timestamp), показывающая, когда именно данное событие произошло. Временная отметка, стоит заметить, ставится в соответствии со стандартом ISO 8601. Семантика (Semantic) — данное расширение распространяется на все типы объектов. Оно добавляет свойство «ссылка» на модель (ModelReference). Добавленное свойство имеет строчный тип. Идентификатор (Identity) — данное расширение распространяется на все типы объектов. Оно добавляет свойство «уникальный идентификатор» (Id). Данное свойство имеет целочисленный тип. Цена (Cost) — данное расширение распространяется на объекты «трейс» и «событие». Они добавляют свойства «сумма» (Total), которое, применительно к событию, показывает стоимость события, а применительно к трейсу - суммарную стоимость совокупности событий, и свойство «валюта» (Currency), которое показывает единицу исчисления для свойства суммы. Свойство суммы имеет тип «число с плавающей точкой», а валюта является строчным литералом. 11 Количество (Amount) — данное расширение распространяется на объект типа «мета». Оно добавляет свойство «количество» (Amount), показывающее совокупную стоимость транзакций, описанных в файле. Количество имеет тип число с плавающей точкой. Тип (Type) — данное расширение распространяется на объект типа «мета». Оно добавляет свойство «тип» (Type), показывающее единицу измерения добавленного расширения «количество». Тип представляется строчным литералом. Стандарт XES может расширяться приложением не только благодаря описанным расширениям. Эта практика активно применяется, так как для каждого рода событий, для описания которых применим данный формат, может требоваться дополнительное описание, не содержащиеся в списке допустимых расширений. В качестве примера пользовательских расширений можно рассмотреть следующую ситуацию: допустим, формат XES используется для описания процесса починки мобильных телефонов. Так, для этапов бизнес процесса важно описание таких свойств, как марка телефона и тип поломки. Поскольку не существует предложенных расширений, которые описывают подобный тип свойств события, принято использовать пользовательские расширения. BI Решения BI (Business Intelligence) — это совокупный набор теорий, методологий, структур, методов анализа и методов трансформации данных для потребностей бизнеса. BI решения, в свою очередь, - это программные комплексы для работы с OLAP, созданные для анализа данных и принятия решений. Зачастую BI решения работают с данными из хранилища данных. Также они способны использовать в качестве источника несколько баз данных и даже различные файловые форматы. Этот подход не очень распространён, поскольку для выполнения сложных операций с кубами, построенными на основе разных 12 источников, BI решение вынуждено выгружать все данные из используемых таблиц источников данных и производить манипуляции с ними в памяти вместо того, чтобы использовать встроенные в базы данных механизмы. В современных компаниях использование BI решений широко распространено. Дело в том, что большая часть из коммерческих BI решений содержит визуальные редакторы запросов и поддерживает витрины данных, тем самым делая эти инструменты удобными в использовании специалистами в области маркетинга. Витрины данных — это динамически наполняемые отчёты, которые позволяют сконцентрировать некоторое число таблиц и графиков для демонстрации ситуации в рамках одного показателя, к примеру, - «продажи». Разработанное решение в рамках данной магистерской диссертации можно классифицировать, как BI решение, так как оно обладает всеми свойствами, необходимыми для этого класса решений: 1. Созданное решение работает с хранилищем данных; 2. Созданное решение генерирует предметные области автоматически; 3. Созданное решение обладает графическими инструментами для выполнения запросов к хранилищу. 13 Исследовательская часть В рамках теоретической части данной работы ставились следующие цели: выбрать формат входных данных для анализа, определить, какой должна быть структура полученного хранилища данных, а также ответить на вопрос — каким образом можно использовать технологии, характерные для многомерных данных, к процессным данным. Выбор формата входных данных Процессные данные могут передаваться в различных форматах. Самый распространённый формат записи процессных данных — это текстовые логи. У данного формата существует множество положительных характеристик. Так, текстовый формат: является самым ёмким; прост в создании и дополнении; удобен в чтении; легко разбивается на меньшие файлы. Несмотря на то, что у тестового формата существует масса положительных сторон, он не достаточно удобен для анализа по следующим причинам: Он не стандартизован. Каждая система создает уникальные логи; Он не расширяем. То есть, в случае изменения формата записи одной строчки лога изменяется весь формат выдачи лога. Так как для проведения анализа требуется некоторая доля стандартизации входных данных, в рамках проекта был выбран стандарт XES, созданный в Технологическом Университете Эйндховена, который является функциональным расширением формата XML. Стоит заметить, что у логов, 14 которые пишутся в XML, существует набор недостатков, таких как: большой размер файла; затруднённое чтение и запись. XML логи также обладают набором преимуществ: Они стандартизованы; Они бесконечно расширяемы; Они поддерживают бесконечную вложенность; Они способны передать большое количество дополнительной информации. Основной причиной, почему был выбран именно формат XES, является то, что вне зависимости от системы, которая производит эти файлы, и цепочек бизнес процесса, которые данная система сопровождает, методика анализа данного типа файлов остается неизменной. Создание структуры хранилища данных При проектировании хранилищ данных основное внимание было уделено тому, какие данные должны быть результатом выполняемого анализа, или, другими словами, какие именно данные должны являться наполнением таблицы фактов. Отталкиваясь от полученного результата, стало возможным определить, как именно должны выглядеть измерения для данной таблицы фактов. В целях ответа на этот вопрос обратимся к краткому определению процессного анализа. Процессный анализ — это техника, позволяющая производить анализ бизнес процессов, построенных на основе логов систем (процессных данных). Другими словами, продуктом анализа процессных данных должен являться процесс. На основе данного определения можно сделать вывод, что аналитика, которая проводится на основе хранилища данных, построенного благодаря анализу логов систем, должна возвращать 15 процесс. Под процессом, в данном случае, понимается последовательность событий. Иначе говоря, процесс — это тот агрегируемый показатель, который должен лечь в основу таблицы фактов. В случае, если в качестве наполнения таблицы фактов будет использоваться процесс, то возникает следующая проблема: поскольку в исходном логе процесс представляет собой последовательность событий, имеющих различные свойства, должен ли процесс, содержащийся в таблице фактов, обладать этими свойствами сам по себе? Для решения этой проблемы потребовалось обратиться к одному из свойств структур OLAP, а именно: в таблице фактов не должно быть ключей, являющихся внешними ключами для таблиц измерений. То есть, если считать, что полученный процесс должен сам по себе содержать свойства всех событий, которые имеются в этом процессе, то либо мы должны хранить информацию о всех вложенных событиях в таблице фактов, либо необходимо создать таблицу, в которой будет содержаться внешний ключ из таблицы фактов. Оба данных подхода нарушают методологию построения хранилища. Очевидно, что полученный процесс не должен, сам по себе, обладать какими либо свойствами, и все его свойства должны содержаться в таблицах измерений. Иначе говоря, наполнением таблиц измерений должны стать все возможные свойства процесса. Следующий вопрос состоит в том, что если процесс не обладает свойствами сам по себе, каким образом можно связать свойства, которыми обладает каждое событие в процессе, и результирующий процесс? Если вопрос с тем, как хранить свойства всего процесса, т.е. свойства, которые в логе содержат тэг «трейс» (Trace), становится прозрачным (необходимо создать измерение трейсов, и связать его с таблицей фактов ключом), то создание аналогичного ключа к таблице событий не принесет ожидаемого результата по двум причинам: 1. Процесс по отношению к событию - более крупный показатель; 16 2. Невозможно будет установить отношение между трейсами и событиями. Вторая причина содержит в себе готовое решение. Если для хранилища данных критично иметь отношение элементов, то следует сделать трейс родительским элементом, а событие – дочерним. Последний вопрос состоит в том, что не ясно, какие поля должны содержаться в таблицах трейсов и событий. В случае со свойствами, описанными в допустимых расширениях стандарта, стало понятно, что именно они должны лечь в основу полей данных таблиц. Однако возникает проблема: как хранить данные, которые используются в логе, но не являются частью стандартных расширений, а, напротив, являются пользовательским расширением. Известно, что все стандартные расширения распространяются на все объекты указанного типа, но пользовательские определённых событиях, расширения то есть могут структура содержаться событий только может в быть неконсистентной. В данном случае сложилось понимание, что требуется использовать парадигму наследования из объектно-ориентированных языков программирования, другими словами, абстрактное событие должно быть родителем частных случаев событий с разным набором полей. Но, увы, данный подход сегодня не применим в отношении таблиц баз данных. Один из вариантов решения данной проблемы состоит в создании в таблицах трейсов и событий всех возможных свойств, содержащихся у данных объектов в логе. Минусом данного подхода является то, что он может сильно повредить производительности системы. В рамках настоящей работы было принято решение о создании двух дополнительных таблиц расширений, дочерних для таблицы событий и трейсов соответственно. Данные таблицы содержат в себе пары «ключ — значение», используемый тип данных, а также ссылку на поле расширяемой таблицы. 17 Описание таблиц и полей полученного хранилища данных: Таблица FACT Описание: Таблица фактов, содержащая агрегированные показатели по процессам. Поля: Название Описание TRACE_ID Идентификатор трейса PROCESS Агрегированный процесс Таблица TRACE Описание: Таблица, содержащая свойства трейса, прописанные в стандарте и в его расширениях. Поля: 18 ID Уникальный идентификатор TRACE_ID Вспомогательный идентификатор NAME Название трейса. Поле расширения XES MODELREFERENCE Ссылка на модель. Поле расширения XES Таблица TPROPERTY Описание: таблица пользовательских расширений трейсов. Поля: ID Уникальный идентификатор TRACE_ID Идентификатор трейса KEY Название пользовательского параметра VALUE Значение пользовательского параметра DATATYPE Используемый тип данных Таблица EVENT Описание: Таблица, содержащая свойства события, прописанные в стандарте и в его расширениях. Поля: 19 ID Уникальный идентификатор EVENT_ID Идентификатор события TRACE_ID Идентификатор трейса NAME Название события. Поле расширения XES RESOURCE Исполнитель. Поле расширения XES ROLE Роль исполнителя. Поле расширения XES GROUP Группа исполнителя. Поле расширения XES TRANSITION Состояние события. Поле расширения XES. TIMESTAMP Время начала события. Поле расширения XES Таблица EPROPERTY Описание: Таблица пользовательских расширений событий Поля ID Уникальный идентификатор EVENT_ID Идентификатор события KEY Название пользовательского параметра 20 VALUE Значение пользовательского параметра DATATYPE Используемый тип данных Применение технологий, характерных для многомерных данных Известно, что OLAP куб - это массив из нескольких измерений, в которых измеряемый показатель содержится в таблице фактов, а показатели условия содержатся в предметных областях, созданных из каскадов таблиц измерений. Все операции с многомерными данными производятся над OLAP кубом. Для рассмотрения вопроса о применимости технологий анализа многомерных данных к процессным данным в рамках построенной модели требовалось соотнести элементы, необходимые для проведения многомерного анализа, и полученные элементы результирующей модели. Для проведения многомерного анализа, исходя из определения OLAP куба, должны существовать следующие объекты: таблица фактов, содержащая информацию, над которой можно производить агрегацию, и несколько таблиц измерений. В созданном хранилище данных наполнением таблицы фактов является не числовой показатель, а именно процесс, поэтому, на первый взгляд, не было ясно, каким образом можно производить агрегацию данных этого показателя. Иначе говоря, необходимо было ответить на вопрос — что является операцией суммирования различных процессов. В рамках данной работы было установлено, что суммой двух процессов является процесс, обладающий всеми этапами и переходами суммируемых процессов. С введением определения суммы двух процессов можно считать, что данный показатель может быть агрегирован, поэтому процесс, содержащийся в таблице фактов, может быть результатом анализа методами OLAP. Следующая группа объектов, которая была соотнесена с полученным 21 хранилищем, — это предметные области. В полученном хранилище данных содержится четыре таблицы измерений, две из которых являются описанием свойств трейса, а две другие - описанием свойств события. Класс, являющийся объединением групп таблиц, может являться предметной областью. Получается, что построенное хранилище, применительно к процессным данным, может обладать только двумя предметными областями, а именно, предметной областью свойств трейса и предметной областью свойств события. При появлении понятия суммирования процессов стоит обратить внимание на то, что при выполнении запроса к хранилищу данных возвращаемым результатом является не процесс, а группа процессов, которые суммируются для целей агрегации. На основании этого факта можно выделить еще одну характеристику, которая является, по сути, еще одной предметной областью, состоящей из одного показателя, - вероятность появления данного процесса. Если сумма всех возможных процессов по заданному условию составляет сто процентов, то можно заметить, что вероятности возникновения отдельных групп процессов разные, и существуют доминирующие процессы, которые встречаются чаще других. При проведении анализа также будет полезно изменять значение вероятности появления итогового процесса. В данном случае это реализовано следующим образом: после выполнения запроса осуществляется подсчёт количества появлений каждого процесса, в результате чего производится подсчёт вероятностей. Полученный результат сортируется, и вычисляется скользящая сумма вероятности процесса от больших значений к меньшим. Теперь, когда все группы объектов, необходимых для выполнения операций над OLAP кубом, определены, необходимо понять, каким образом основные методы для работы с кубами могут быть применены для работы с процессными данными. Существует несколько широко используемых методов. В рамках данной работы реализованы не все из них, а лишь наиболее важные. Операции для работы с OLAP следующие: 22 1. Dice; 2. Slice; 3. Drill Down; 4. Roll up; 5. Pivot. Рассмотрим применимость каждой из этих операций подробнее. Нарезание (Dice) Нарезание — это операция фильтрации значений полей предметных областей, по которым проводится анализ. В данном примере было выбрано три показателя предметной области. Операция нарезания для одной из предметных областей состоит в сокращении количества возвращаемых результатов применением фильтра. Для процессных данных эта операция идентична операции над обычным OLAP кубом. В рамках данной работы функция фильтрации значений полей предметных областей была реализована следующим образом: при конструировании запросов к хранилищу данных можно произвести выбор значений выбранного поля предметной области, задав одну из двух предложенных операций. 23 Срез (slice) Срез — это изменение значений показателя, по которому производится агрегация данных. В приведённом примере куб до среза должен содержать агрегированные показатели за 2004 — 2006 года, а после агрегации - только за 2004 год. Надо заметить, что приведённый пример отражает тот факт, что показатель, по которому проводится анализ, не изменился после применения среза, то есть, изменялся только в процессе 2004 года, а в остальное время оставался неизменным. Аналогичной операцией применительно к кубу, построенному на основе процессных данных, является изменение вероятности результирующего процесса. В процессе изменения вероятности переход граничных значений будет изменять полученный процесс. Надо заметить, что создаваемый в программе граф является невзвешенным. Это означает, что в случае, если показатель вероятности будет проходить граничные значения, но в полученном описателе графа не будет присутствовать изменений, относящихся к элементам графа или к переходу между этими элементами, то граф перестроен не будет. 24 Развернуть и сжать (drill down, drill up) Операции развёртывания и сжатия — это операции выделения кубов верхнего или нижнего уровней из исходного куба. Использование этих операций подразумевает наличие иерархических отношений между развёртываемыми и сжимаемыми полями предметных областей, с которыми производятся эти операции. Текущий стандарт XES не содержит упоминания о возможности задания полей с различным уровнем иерархии, однако наличие вложенности в структуре XML документа позволяет отразить вложенность полей объектов. Иначе говоря, поддержка подобного рода операций возможна и легко реализуема для процессных данных, но данный функционал требует либо адаптации формата XES для отражения иерархических отношений между элементами предметных областей, либо сопровождения лога XES файломописателем, предоставляющим дополнительную информацию о рассматриваемых объектах. В разработанном решении вышеуказанные методы не используются. 25 Вращение (pivot) Вращение — это операция смены показателя предметной области, используемого для фильтрации, и показателя предметной области, используемого для агрегации. В случае разработанного программного продукта данная операция не поддерживается. Выводы исследовательской части В рамках исследовательской части было выявлено следующее: 26 1. XES является наиболее удобным для работы форматом входных данных; 2. Операции, характерные для OLAP, в большинстве своём могут быть применимы к процессным данным. Каждой из характерных операций было дано определение в контексте процессных данных. Также в рамках исследовательской части была выбрана оптимальная структура хранилища данных и полей таблиц хранилища данных. 27 Практическая часть Практическая часть данной магистерской диссертации состоит в создании программного решения, выполняющего следующие функции: 1. Анализ лога в формате XES; 2. Создание и наполнения хранилища данных на базе анализа лога; 3. Предоставление пользователю механизма создания и выполнения запросов к полученному хранилищу данных. Механизм должен реализовывать некоторые методы, характерные для технологии OLAP; 4. Визуализацию полученного процесса. Анализ лога Для цели анализа лога существовала возможность воспользоваться одним из двух методов: использованием открытой библиотеки OpenXES, разработанной в Технологическом Университете Эйндховена, или созданием собственного механизма анализа логов XES. У указанных подходов имеются плюсы и минусы: OpenXES Плюсы Минусы Инструмент, разработанный в Технологическом Однопотопный (не высокая Университете Эйндховена скорость работы) Встроенные процесса функции вычленения объектов Фиксированная структура Сложность расширения 28 Собственный механизм Плюсы Минусы Многопоточность Отсутствие учета расширений формата Свободное расширение Трудоемкость создания некоторых Для данного проекта было принято решение создать собственный механизм анализа логов. Использование собственного механизма позволило значительно ускорить работу аналитической функции и создать более плотное взаимодействие с другими компонентами полученного приложения. Обработка лога производится с помощью технологии XQUERY, так как лог представлен в формате XML. Общая последовательность действий при обработке лога выглядит следующим образом: Анализ входных параметров; ◦ Подключённые расширения; Создание списка трейсов; Хвостовая рекурсия для анализа трейсов и событий: ◦ для каждой записи в трейсе: ▪ определение расширения; ◦ создание списка событий; ◦ Хвостовая рекурсия для анализа событий; ▪ Для каждой записи в событии: определение расширения; 29 создание объекта события; ▪ Запись событий в хранилище; ◦ Запись трейса в хранилище; Создание вспомогательных таблиц. Перед началом записи событий в хранилище данных программа оценивает приблизительное время записи, используя следующую формулу: tn = (t1 * n * 2 ) / Q , где t1 — это скорость записи 1 события; n — это количество событий; Q - это количество используемых процессоров. Для ускорения записи в программе используется параллельная запись. Далее приведена упрощённая блок-схема работы алгоритма. 30 Создание запросов к хранилищу Запросы к хранилищу строятся с использованием встроенного визуального редактора запросов. Визуальный редактор позволяет: 1. Выбрать поле интересующего измерения; 2. Выбрать значение поля для создания подзапроса; 3. Выбрать условие для поля (=, <>); 4. Задать отношение подзапроса к родительской части запроса (INTERSECT, UNION); 31 5. Создать вложенные запросы. Также визуальный редактор содержит помощника построения запросов. Визуализация процесса Процесс визуализации отображается в виде направленного графа. Во время работы с приложением можно менять значение вероятности прохождения по данному графу. Это работает следующим образом: при выполнении запроса хранилище данных возвращает набор процессов, которые подходят под заданное условие. Затем полученный набор процессов сортируется и взвешивается, и на выходе алгоритма получается взвешенная бегущая вероятностная оценка. Данная оценка представляет собой список, отсортированный по значениям чистых вероятностей в обратном порядке. Визуализация данного процесса производится от значений с наивысшей вероятностью к значениям с более низкой вероятностью. При выборе вероятности процесса в 99,99% будет выведен граф, содержащий в себе все возможные сценарии прохождения. Разработанное программное решение Разработанная программа состоит из нескольких экранов: 1. Приветственный экран; 2. Экран загрузки; 3. Рабочая область; 4. Экран обучения. Далее следует краткий обзор экранов. Приветственный экран Приветственный экран - это экран, демонстрируемый при входе в программу. Данный экран состоит их нескольких окон: 32 1. Окно соединения с БД. В этом окне требуется заполнить параметры для соединения с БД, в которой будет создано новое хранилище данных. На данный момент программа поддерживает работу только с базой данных Postgres. В случае, если база данных находится на удалённом сервере, требуется ввести URL и порт для соединения, а в случае, если работа ведётся на локальном компьютере, требуется ввести localhost. Порт по умолчанию, который использует Postgres, - 5432. В нижней части окна для ввода информации о соединении с БД можно проверить работу соединения. При нажатии будет показано сообщение «Succeeded» при удачном подключении, либо «Failed» при неудачном. 2. Диалоговое окно для выбора рабочей папки. В процессе работы программа создает файлы в формате .dot, как описатель графа, и в формате .png, в качестве визуализации. Для работы программы требуется выделить папку для создания этих файлов. В дистрибутиве программы создана папка для складирования файлов, но пользователю может потребоваться, к примеру, размещение папок на удалённом сервере или на внешнем носителе. 3. Окно выбора анализируемого лога. Программа поддерживает работу с логами в формате XES, которые используют расширения «концепт», «жизненный цикл», «организация», «время», «семантика», а также с любыми пользовательскими расширениями объектов «трейс» и «событие». 33 Экран загрузки Экран загрузки будет отображаться в те моменты, когда работа с программой не доступна из-за производимой аналитики и записи в хранилище данных. В процессе анализа лога на экране загрузки будет отображаться индикатор загрузки с процентным значением. Эта процедура происходит достаточно быстро. В процессе записи в хранилище из-за параллельной записи отображение процесса загрузки невозможно, однако пользователю будет отображено планируемое время ожидания. В правой верхней части экрана загрузки содержится кнопка для перехода в режим обучения, где кратко будет рассказано о каждом из компонентов рабочей области. Рабочая область Рабочая область - это основной экран в приложении. На данном экране производится анализ и работа с полученным хранилищем данных. Рабочая область состоит из следующих элементов: 1. Окно вывода. В данном окне отображается вся активность в рамках данной 34 программы. Каждое сообщение в виде заголовка имеет время добавления. В тексте данного окна можно получить информацию о планируемом времени записи событий в хранилище, о совокупном количестве элементов для записи, о реально затраченном времени. Также в данном окне появится запись, если запрос, составленный к хранилищу данных, не содержит результатов. 2. Окно предметных областей. В данном окне содержатся допустимые для процессных данных измерения («трейс» и «событие») и поля данных предметных областей, которые можно выбрать для анализа. При нажатии на интересующее поле измерения в окне выбора значений появятся допустимые значения выбранного поля. В данном окне намеренно не делается разбиения полей на стандартные и пользовательские расширения, так как эта информация не существенна для анализа. 3. Окно выбора значений. Это окно состоит из четырёх элементов: - заголовок окна, в котором указывается поле предметной области, тип данных анализируемого поля; - страницы с возможными значениями данного поля. Заданное количество элементов на странице равняется восьми; - перечень страниц; - операция. Доступно два типа операций: «равно» и «не равно». При нажатии на значение поля в окно конструктора запросов будет добавлен новый элемент с условием, соответствующим выбранной операции. 4. Конструктор запроса. Данное окно позволяет создавать запросы к хранилищу данных. Значение запроса по умолчанию — базовый запрос или запрос всех значений из хранилища. В случае, если ни одно из условий не будет задано в конструкторе, в качестве результата программа вернёт граф, построенный на всех допустимых значениях хранилища. Каждый элемент конструктора состоит из четырех частей: кнопки удаления запроса «Х», кнопок понижения уровня иерархии запроса на 1 уровень « ->» или повышения на уровень «<-», 35 кнопки выбора операции с вышестоящим множеством («пересечение» или «объединение») и текстом выбранного запроса. При добавлении и изменении элементов конструктора в соседнем окне помощник запросов будет обновляться. Кнопка изменения иерархии позиции запроса используется для создания сложных подзапросов. 5. Помощник запроса. Это окно, в котором будет отображаться структура созданного в конструкторе запроса. При наведении курсора на элемент помощника отображается запрос, который выполняет соответствующий блок. 6. Главное рабочее окно. На нем будет отображаться полученный при запросе граф. Элемент главного рабочего окна состоит из двух частей: краткий текст запроса, на основе которого был построен данный граф, и сам граф. 7. Инструмент изменения вероятности полученного графа. Он состоит из двух элементов: элемента прокрутки для изменения вероятности и индикатора, показывающего текущее положение элемента прокрутки. При изменении значения элемента прокрутки, в случае, если один или несколько элементов графа будут содержать значения, меняющие его отображение, данные элементы будут перестроены. Минимальное значение элемента прокрутки составляет 50 процентов, поскольку значения менее указанного уровня имеют низкую ценность для анализа. 36 8. Элемент «боковое меню». Он вызывается при нажатии на кнопку «<». Данное меню содержит следующие опции: выбор рабочей директории, выбор нового лога для анализа, изменение размера текста в отображаемом графе, смену цветового режима (доступны светлый и тёмный цвета) и индикатор включения/ выключения звука при завершении анализа. Стоит заметить, что при выборе нового лога его анализ будет начат незамедлительно. Также стоит отметить, что изменение размера шрифта будет задействовано только для новых графов. 37 Экран обучения Во время работы процесса анализа и записи данных на экране загрузки в правом верхнем углу можно вызвать небольшой встроенный экран обучения для разъяснения работы с данной программой. Анализ полученных результатов В рамках написания данной работы были поставлены следующие задачи: 1. Создание алгоритма анализа процессных данных; 2. Создание структуры хранилища данных; 3. Запись проанализированных логов в хранилище данных; 4. Создание механизма обращения и работы с созданным хранилищем; 5. Создание механизмов, позволяющих применять методы OLAP к созданным процессным данным. При работе над поставленными в рамках магистерской диссертации задачами были получены следующие существенные результаты: 1. В рамках исследовательской части был выявлен следующий факт: наиболее удобным для пользователя форматом входных файлов является формат XES. Данный формат обладает чёткой структурой, а также определяет основные понятия, используемые в рамках анализа процессов, такие как: «лог», «трейс», «событие» и «мета». Так как данный формат стандартизован, то любые системы, производящие информацию в формате XES, могут поставлять разработанной программе лог для анализа. Ко всему прочему, существуют возможности расширять данный формат, и разработанная программа имеет возможность работать не только с заявленными разработчиками расширениями, но и с пользовательскими. Это делает вышеупомянутый формат крайне гибким. Несмотря на все положительные стороны формата, существует и несколько негативных сторон, таких как: большой размер лога в формате XES, некоторое количество избыточной информации, которая не имеет ценности в рамках анализа процессов, а также 38 недостаточность данного формата в целях предоставления всех необходимых данных для работы со всеми методами технологии OLAP. Так, из-за отсутствия информации об иерархии свойств трейсов и событий, применение операции свёртывания и развёртывания куба не представляется возможным, хотя данная операция может выполняться над процессными данными. 2. Созданная структура хранилища данных удовлетворяет потребностям анализа и способна содержать в себе информацию о XES логе любого наполнения, а также о любом описанном процессе в целом. С другой стороны, структура хранилища данных получилась достаточно небольшой, что может негативно сказаться в случае наличия больших объёмов данных. Одной из примечательных особенностей структуры полученного хранилища является то, что в качестве основного наполнения таблицы фактов, или, другими словами, агрегируемого элемента выступают не счётные данные. Программное определение операции агрегации над этим типом данных способствовало появлению нового предмета анализа, а именно, - вероятностной оценки прохождения по полученному процессу. Помимо данных, необходимых для создания OLAP куба, в хранилище данных записывается информация для расшифровки процесса в таблице фактов, а также другие системные таблицы. Это сделано для того, чтобы в случае добавления функционала по дозаливке данных в хранилище или использования хранилища без анализа файла лога, но используя готовые данные, можно было без повторного анализа хранилища считывать данные таблицы фактов и анализировать их. 3. Успешно использован механизм параллельной записи в хранилище данных. Запись данных лога в хранилище данных происходит в несколько этапов. Сначала определяется примерное время выполнения операции. Время определяется приблизительно, поскольку используется механизм многопоточной параллельной записи. Время tn при таком способе записи находится в интервале [t1*n/q ; t1*n], где: t1 — время записи 1 события, n количество событий, а q — количество используемых ядер процессора. 39 Оценка - интервальная, так как в различное время на рабочем устройстве загрузка может быть разной, но в общем случае принято сообщать время, равное tn = (t1 * n * 2 )/ q. При этом предполагается, что половина ядер занимается какой-либо другой работой. После завершения оценки времени выполнения записи происходит сама запись в хранилище данных. 4. Разработана структура хранилища процессных данных. Для создания механизмов работы с хранилищем данных требовалось, чтобы на базе таблиц данного хранилища можно было создать предметные области, пригодные для обращения. На этапе анализа хранилища данных, который происходит после анализа и записи файла лога, программа строит две предметных области, пригодные для создания запросов: трейсы и события. Эти предметные области конструируются из двух типов частей: все поля основных таблиц и уникальные значения полей таблиц расширений. Уникальные поля таблиц расширений представляют собой все различные элементы пользовательских расширений и их типов. Эти данные интегрируются в соответствующие предметные области без разделения для конечного пользователя, поскольку их разделение не удобно для конечного пользователя. При выборе поля из предметной области пользователю становится доступным выбор уникальных значений этих полей для создания запросов. Операции, которые поддерживает текущая версия программы, две - равенство и неравенство. В окне выбора значений в один момент доступен выбор восьми значений. Значения отсортированы по возрастанию. В случае, если пользователь выберет значение элемента предметной области, то в окне конструктора запросов появится новый элемент с указанной операцией и выбранным значением. Для элемента конструктора пользователь может изменять иерархию, другими словами выделять подзапросы из большого запроса. Еще одна из операций, доступных для пользователя, — это выбор правила пересечения множеств полученных процессов в результате выполнения подзапроса. Доступно две операции над множествами — это пересечение и объединение. После выполнения составленного запроса, в случае, если 40 результат запроса не составляет пустое множество, на основную рабочую область будет добавлен граф с кратким описанием. Над полученными графами можно производить операцию изменения вероятности. В случае, если при изменении вероятности прохождения по графу наполнение графа меняется, то граф будет перестроен, в противном случае граф останется без изменений. 5. Разработана методология применения технологии OLAP к процессным данным. Для применения методов OLAP к процессным данным требовалось найти соответствие объектов, полученных в результате анализа, и объектов, необходимых для построения OLAP. Так, было выявлено, что для дальнейшего анализа требуется определить понятие агрегации процесса. Побочным продуктом определения операции суммирования процессов явилось появление новой предметной области, состоящей из одного элемента, а именно, - вероятности прохождения по данному событию. Также были разработаны методы создания бегущего показателя вероятности процессов. Исследование методов OLAP показало, что не все из них применимы к процессным данным, так как операция поворота куба в рамках созданной модели не применима. С другой стороны, операции среза (Slice) и нарезания (Dice) куба применимы в данной модели, и анализ лога даёт достаточно информации для применения этих методов. Единственные информации, для организации которых не хватило в методы XES логе, - это операции свёртывания и развёртывания куба. В случае, если дополнительная информация о свойствах объектах лога будет предоставлена, к примеру, отдельным файлом, данный метод будет применим в рамках разработанной модели. Методы улучшения разработанного решения Разработанное решение выполняет все возложенные на него функции, но, тем не менее, обладает некоторым количеством пространства для улучшения. Полученный программный продукт можно усовершенствовать в следующих 41 направлениях: 1. Анализ файла лога. Разработанный для анализа лога алгоритм обладает следующей особенностью: алгоритм занимается обработкой всего лога в памяти, а не читает его построчно. Для файлов сравнительно небольшого размера это не существенно, но в случае, если объем файла будет достигать нескольких сотен мегабайт, могут возникнуть трудности, связанные с недостаточным количеством оперативной памяти. 2. Поддержка всех операций стандарта SQL для выбора значения поля предметной области. В данной версии программы в демонстрационных целях добавлена поддержка только оператора равенства и неравенства. 3. Создание возможности добавления данных в уже существующее хранилище. На сегодняшний момент данная функция не реализована, и каждый раз, когда пользователь выбирает новый лог для обработки, старое хранилище данных удаляется и создаётся новое хранилище. 4. Оптимизация хранилища данных. Для ускорения работы хранилища можно предпринять несколько шагов: запустить функцию БД по сбору аналитики, добавить индексы в таблицы расширений, партиционировать таблицы расширений по строковым значениям. Заключение Процессный анализ является сравнительно молодым направлением анализа данных, поэтому многомерный подход к исследованию процессов и методология OLAP для работы с процессами до сих пор не применялись. В результате проведённого исследования было выявлено, что большая часть методов OLAP применима к процессным данным, а разработанная программа демонстрирует аналитические возможности применения данного аппарата. На мой взгляд, добавление инструментов процессного анализа в современные BI решения может сильно повысить эффективность деятельности аналитиков. 42