Специфика оперативной аналитической обработки данных. Оперативная аналитическая обработка (OLAP). Аналитические технологии бизнес- процессов

Меня зовут Анна Пономарева, я Game Analyst в Plarium Kharkiv. В этом году наш департамент запустил мобильный RPG-проект Stormfall: Saga of Survival и теперь занимается его поддержкой. Моя задача в проекте - оперативно анализировать игровые процессы и предоставлять отчеты для корректной настройки баланса.

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

Важно не просто показать информацию, а сделать это максимально понятно и прозрачно для заказчика, выделив ключевые показатели. Как именно это сделать, я и постараюсь рассказать в статье.

Как не надо делать

Часто в попытке выжать из имеющейся информации всё мы можем получить нечто несуразное и пугающее.

Или еще хуже.

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

Этапы анализа данных

Прежде чем приступить к визуализации, рассмотрим все этапы анализа данных.

Формулирование цели

Каждое исследование должно отвечать на ряд поставленных вопросов - не нужно плодить исследования для исследований.

Сбор данных

На этом этапе аналитик или работает с уже собранными данными, или участвует в процессе постановки задания на сбор данных (фактически решает, какая информация ему необходима и в каком виде).

В первом случае особое внимание стоит уделить правильной интерпретации данных, которые записаны в базу, и зачастую смириться с существующим форматом данных, дизайном таблиц и т. д. Во втором случае аналитик сталкивается с проблемой построения грамотного сценария сбора данных - он может особенно перестараться в планировании А/В-тестов, логировании событий и т. п. Здесь важна коммуникация с программистами, которые могут помочь в понимании процессов и оценке масштабов планируемых записей.

Подготовка данных

«Мусор на входе - мусор на выходе» - правило, о котором всегда нужно помнить. Структурирование, устранение ошибок, изменение форматов содержимого, разбор аномальных результатов, очистка от выбросов, устранение дубликатов, интеграции данных из разных источников - одни из важнейших пунктов в анализе данных.

Иногда требуется расширение метрик, например добавление вычислительной информации (прирост, ранг, номер и т. п.). Иногда следует сократить количество признаков (переменных) или перейти к вспомогательным переменным, принимающим одно из двух значений: true (1)/false(0).

На этом этапе сырые данные превращаются в полезную входную информацию для моделирования и анализа.

Исследование данных

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

Визуализация и построение выводов

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

Время, затрачиваемое аналитиком на каждую фазу, зависит от многих переменных: начиная от опыта работы и уровня знания данных, заканчивая перечнем используемых инструментов и технических характеристик ПК.

Необходимо также понимать, что процесс анализа данных имеет итерационный характер и может быть представлен циклом.

Чтобы сформулировать окончательные выводы, иногда необходимо пройтись по циклу несколько раз. Каждый раз уточняя данные, перестраивая модели обработки и представления данных, получая всё новые знания об анализируемой сущности. Чтобы уменьшить количество итераций этого цикла и время, затрачиваемое на анализ, аналитик должен быть не только специалистом в области Big Data, но и хорошо знать свою предметную область (будь то игровые механики или интернет вещей).

При этом только опыт помогает понять, какие данные и методы анализа нужны в каждом отдельном случае и как интерпретировать результаты.

Выбор диаграмм для визуализации

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

Джин Желязны в книге «Говори на языке диаграмм» пишет, что (почти) каждая идея может быть выражена с помощью сравнения. Требуется лишь определить тип сравнения данных:

• покомпонентное: процент от целого;
• позиционное: соотношение объектов;
• временное: изменения во времени;
• частотное: число объектов в интервалах;
• корреляционное: зависимость между переменными.

Если проводить классификацию по объектам, то можно выделить такие типы визуализации:

• детерминированные зависимости: графики, диаграммы, временные ряды;
• статистические распределения: гистограммы, матрицы диаграмм рассеяния, график «ящик с усами»;
• иерархии: диаграммы связей, дендрограммы;
• сети: графы, дуговые диаграммы;
• геовизуализация: карты, картограммы.

Чтобы упростить себе работу, я использую схему по выбору диаграмм Эндрю Абела, в которую внесла некоторые правки и адаптировала под свои задачи.

Оригинальную схему Эндрю Абела можно посмотреть .

Выбор диаграммы на конкретном примере

Мне необходимо было создать дашборд для контроля income/outcome-ресурсов, которые игроки добывают, находят или получают в награду. Это была достаточно сложная задача, требующая собрать воедино несколько таблиц, учесть множество нюансов и не упустить из виду ни одного источника/потребителя ресурсов.

Сначала я расписала, как собрать данные, какие показатели необходимо рассчитать и как именно это сделать, как должна выглядеть визуализация. Затем специалисты из Game BI Department (отвечают за базу данных для всех наших проектов) проверили правильность алгоритма сбора, оптимизировали запрос и сформировали дашборд по моему дизайну.

Для выбора диаграммы я использовала методику, описанную выше.

1. Сравниваем 2 признака (количество получаемых и затрачиваемых ресурсов) - значит используем столбчатую диаграмму.
2. У нас несколько источников для получения ресурсов и способов их расхода - поэтому добавляем структуру к столбчатой диаграмме (каждый источник и потребитель обозначаем своим цветом).
3. Отслеживаем, как изменяется приход и расход ресурсов в зависимости от игрового дня, - горизонтальной оси задаем соответствующий параметр.
4. Для удобного чтения все income-действия (приход) отображаем сверху горизонтальной оси, а outcome (расход) - снизу. Это позволяет визуально оценить величину разницы.
5. Чтобы было понятно, в какие периоды жизни игрока возникает профицит, а в какие дефицит того или иного ресурса, накладываем на столбчатую диаграмму линейный график, который визуализирует вычисляемое поле разницы.

Пример выявленного профицита предмета (линейный график выше столбцов).

Пример жизненного цикла ресурса и его перехода из профицитной категории к дефицитной (линейный график ниже горизонтальной оси).

В итоге наша диаграмма показывает приход и расход ресурсов в разные игровые дни и демонстрирует наличие дефицита или профицита ресурсов.

Также мы хотели посмотреть, как на движение ресурсов влияют корректировки баланса игры. Для этого мы дополнили дашборд диаграммой изменения структуры ресурсов во времени, где по горизонтальной оси теперь была выбрана дата. Так мы обеспечили мониторинг жизненного цикла ресурсов в нескольких признаковых разрезах: жизненного цикла игрока и во временном.

Периодичность

Большинство выводов по исследованиям теряют актуальность со временем. Некоторые данные необходимо уточнять ежедневно, некоторые мониторить ежемесячно и т. д. Необходимо сразу четко классифицировать признаки с точки зрения частоты обновления:

• требующие непрерывного мониторинга (стандартные показатели retention, конверсии и т. п.);
• данные, динамику которых следует оценивать периодически (результаты А/В-тестов, динамику набора уровней и т. п.).

Опять таки, волшебной таблетки в этой задаче не существует, ведь признаки, которые требуется отслеживать, очень привязаны к предметной области (к жанру игры, реализованным механикам и т. д.).

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

4.1. Звуковое расширенние визуальной аналитики

Одним из современных эффективных методов анализа различных научных данных является метод компьютерной визуализации этих - метод научной визуализации.

Решение задач анализа научных данных методом научной визуализации заключается:

1. В получении представления анализируемых данных в виде их некоторого графического изображения (задача визуализации исходных данных). Для получения такого графического изображения необходимо данным поставить в соответствие пространственную сцену (совокупность пространственных объектов), а точнее говоря, ее геометрическое и оптическое (текстурное) описания (модели), а затем получить графическое изображение этой пространственной сцены (рендеринг), которое можно вывести на монитор, на принтер и другие устройства вывода для последующего анализа.
2. В визуальном анализе полученного графического изображения анализируемых данных. При этом результаты анализа интерпретируются по отношению к исходным данным. Эта задача решается непосредственно самим пользователем. Под визуальным анализом графического изображения подразумевается визуальный анализ упомянутой пространственной сцены. Человек может делать суждения о взаимном расположении пространственных объектов, их форме и текстурном покрытии.

Рис. 4.1. Метод звуковой расширенной научной визуализации.

Рассмотрим возможность подключения в процессе визуального анализа другого органа чувств - органа слуха. Для того, чтобы осуществить анализ исходных данных посредством звука, соответственно необходимо:

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

На рис.4.1 представлена структурная схема алгоритма расширенной визуализации, т.е. совместного получения графического изображения и звукового отображения исходных данных.

Рис. 4.2. Структурная схема алгоритма расширенной научной визуализации.

Такой алгоритм реализуется с использованием компьютера путем написания прикладной программы визуализации на некотором входном языке программирования используемого инструментального средства (совокупности средств) в виде некоторого программного продукта или совокупности программных продуктов.

Рассмотрим основные характеристики метода расширенной научной визуализации применительно к определенному классу задач анализа научных данных, когда в качестве таких данных используются описания тех или иных скалярных полей.

4.2. Звуковая расширенная визуальная аналитика скалярных полей.

Исходные данные

Эти данные представляют собой описание скалярного поля на некотором прямоугольном отсеке трехмерного физического пространства, представленное в файле. В качестве описания используется математическая модель скалярного поля в виде значений функции 3-х переменных вида F(x,y,z) в узлах заданной трехмерной прямоугольной сетки.

Отфильтрованные данные

В качестве отфильтрованных данных используется интерполяционная функции f(x,y,z), использующая значения исходной функции в узлах сетки. Для получения функции f(x,y,z), заданной на рассматриваемой области определения (параллелепипеде) нами была использована трилинейная интерполяция.

Описание пространственной сцены

Это описание включает в себя 3 составляющие:

1. Описание изоповерхности функции f(x,y,z) в виде: f(x,y,z)=с, при этом совместно принимаемые значения x,y,z принадлежат указанной выше области определения функции f(x,y,z), а с – задаваемое пользователем вещественное число, соответствующее некоторому значению анализируемого скалярного поля.
   Данная изоповерхность является 1-ым компонентом вводимой в рассмотрение пространственной сцены.
2. Оптическое описание, т.е. описание текстурного покрытия упомянутой изоповерхности, задаваемого пользователем.
3. Звуковое описание, т.е. описание вводимого в рассмотрение точечного источника звука. Его расположение (значения координат x0,y0,z0) задается пользователем, а частота исходящего звука w связана со значением функции f(x,y,z) следующим образом: w = k*f(x0,y0,z0), где значение коэффициента k задается пользователем.
   Данный точечный источник звука является 2-ым компонентом вводимой в рассмотрение пространственной сцены.

Графическое изображение и звуковое отображение пространственной сцены

Результатом выполнения рендеринга являются соответственно:

• проекционное графическое изображение изоповерхности на используемом графическом терминале,
• звуковая волна, генерируемая используемым звуковым терминалом.

Следует пояснить, что частота звуковой волны воспринимается пользователем как тон звука.

Инструменты класса OLAP (On-Line Analytical Processing, традиционный русский перевод – «оперативная аналитическая обработка») на сегодняшний день являются популярными аналитическими средствами, без которых практически невозможно представить информационно-аналитическую систему. Сам термин OLAP был введен в 1993 году Коддом, который рассмотрел недостатки реляционной модели с точки зрения корпоративных аналитиков. Средством, которое должно было исправить эти недостатки, и стала концепция OLAP. Справедливости ради нужно сказать, что подход, аналогичный OLAP (а именно, многомерное представление данных) использовался и до введения этого термина, но толчком к повсеместному распространению технологии и внедрению ее во множество аналитических продуктов, стала статья Кодда.

Среди недостатков реляционной модели и реляционных СУБД применительно к задачам анализа Кодд отметил следующие. Во-первых, аналитические запросы достаточно сложны, и связаны с выполнением большого количества относительно медленных реляционных операций соединения. Во-вторых, составление запросов к реляционным базам данных недоступно корпоративным аналитикам (в дальнейшем будем называть их «лицами, принимающими решение», или ЛПР). Второй недостаток обусловливает достаточно длинный цикл получения нужных сведений ЛПР – необходимо, к примеру, обратиться в информационную службу, где подготовят форму отчета с соответствующей информацией, а затем уже использовать отчеты этой формы. Решение этих проблем Кодд видел в аналитическом инструменте, поддерживающим многомерную модель, как понятную ЛПР. То есть, выделяется несколько измерений, в контексте которых рассматриваются различные показатели деятельности предприятия. Такая модель, в силу своей наглядности и интуитивности, должна позволить ЛПР самому обращаться к необходимой информации. С другой стороны, ответы на запросы должны генерироваться достаточно быстро (это требование и обусловливает часть «On-Line» акронима OLAP).

Кодд также сформулировал 12 правил, которым должна удовлетворять OLAP-система. Позднее, эти правила были переработаны в 18 свойств, разбитых на 4 группы. Данный набор правил не пользуется успехом. Возможно, в силу того, что в отличие от широко известного манифеста Кодда 1970 года, описывающего реляционную модель данных, статья 1993 года содержала гораздо меньше фундаментальных обоснований, и была менее выверена теоретически. Кроме того, она публиковалась под эгидой одного солидного поставщика аналитических систем и правила, сформулированные в ней, могут не быть универсальными, а учитывать специфику продуктов этого поставщика. Так или иначе, большей популярностью пользуется так называемый тест FASMI, который и можно принять за определение OLAP. FASMI является аббревиатурой, которая расшифровывается следующим образом:

Fast (быстрый) – время отклика системы должно измеряться секундами. Как показывают независимые исследования, время ожидания пользователем ответа от компьютера около 20 секунд. По истечении этого периода, у пользователя появляется чувство дискомфорта. Бесспорно, добиться выполнения любых запросов к большим массивам информации за секунды является сложной задачей для производителей OLAP инструментов. Собственно, это одно из основных направлений развития в этой области. Однако, как показывают некоторые опросы, неудовлетворительная скорость работы до сих пор является одной из главных претензий пользователей к инструментам этого класса.

Analisys (анализ) – система предназначена для всестороннего исследования данных, причем это исследование может содержать элементы бизнес-логики, поддерживать зависимости, определяемые пользователем и так далее.

Shared (разделяемый, многопользовательский) – система должна поддерживать многопользовательскую работу, обеспечивая при этом необходимый уровень конфиденциальности. Если допускается исправление данных пользователем, то оно должно управляться известными механизмами блокировок на нужном уровне.

Multidimensional (многомерный) – данные должны быть представлены в многомерной форме. Это главная часть определения OLAP.

Information (информация) – эта составляющая намекает на то, что результатом анализа становится информация (в противовес данным, хранящимся в реляционной базе).

Тест FASMI, как и правила Кодда, устанавливает некоторый эталон - «идеальный инструмент OLAP». В действительности, различные продукты можно сравнивать по тому, насколько удовлетворяют этим положениям. Продуктов, которые бы полностью им удовлетворяли, на данный момент не существует.

Связь OLAP и ХД

Хранилища данных отражают современную тенденцию к сбору и очистке данных транзакционных систем и сохранение их для задач анализа. Появление технологии ХД отчасти обусловлено теми же предпосылками, что и OLAP – разницей в аналитических запросах и типичных запросах к учетным системам. Кроме того, весьма актуальным оказалось желание сбора данных из всех источников на предприятии для создания более целостной информационной картины.

Разновидностью хранилищ данных являются витрины данных (или киоски данных). Их отличие от хранилищ данных заключается, в основном, в размерах. Если в ХД стекаются данные предприятия, то витрина представляет данные, относящиеся только к одному подразделению, службе или филиалу. Витрина может создаваться как независимо, так и представлять собой подмножество корпоративного хранилища данных.

Собранные из разных источников, согласованные, а иногда и обобщенные данные идеальны для анализа. Поэтому в большинстве случаев инструменты OLAP разворачиваются именно на базе хранилища или витрины данных, и предназначены для анализа содержащихся там данных. Это настолько общая тенденция, что в некоторых источниках понятия Хранилища данных (витрины данных) и OLAP не различаются. Однако из методологической потребности различие делать все-таки нужно. Технология ХД в большей степени ориентирована на сбор, очистку, и хранение данных, а OLAP – на их обработку и представление.

Похожая информация.

В основе концепции OLAP лежит принцип многомерного представления данных. В 1993 году в статье E. F. Codd рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

В большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД . Вообще говоря, это неверно, поскольку сам Кодд отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP". Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что не совсем корректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP, как это и сделано в .

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2).

Рис. 2. Измерения и направления консолидации данных