«Легковесная» аналитика

Автоматизация небольших предприятий обычно включает в себя создание систем бухгалтерского учета, управления ресурсами и планирования. Их важным элементом является модуль генерации отчетов, структура которых фиксирована, а алгоритм построения жестко закодирован. Однако такая ситуация неприемлема для аналитической работы, требующей подготовки нестандартных отчетов, и хотя на малых предприятиях аналитика часто сводится к гипотезам о возможных закономерностях, их также требуется проверить с помощью генератора отчетов. Таким образом, на предприятиях малого и среднего бизнеса возникает необходимость в системах анализа (прежде всего в OLAP), применяемых в качестве универсального генератора произвольных отчетов. Небольшим предприятиям не стоит рассматривать многомерный анализ как «высшие материи», предназначенные исключительно для крупных корпораций, а разработчикам небольших систем не следует считать принципы работы модулей многомерного анализа «тайной за семью печатями», доступной только «избранным».

Однако все имеющиеся сегодня подходы к аналитике ориентированы на системы многомерного анализа, использовать которые экономически целесообразно только на крупных предприятиях. С позиции небольших компаниий такие системы нерентабельны [1] — даже самые простые средства OLAP достаточно дороги, а в случае применения свободного ПО возникают вопросы поддержки и сопровождения. Но если такие затраты и не обременительны для предприятия, то после выполнения всех работ могут возникнуть новые проблемы — например, потребуется переподготовка персонала, использующего полученную систему, а в штатном расписании отсутствует должность специалиста, отвечающего за анализ ситуации и подготовку решений, причем может не быть даже специалиста по ИТ. Получается, что внедрение системы потребует изменения организационной структуры предприятия и логики ее внутренних бизнес-процессов.

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

К системам многомерного анализа данных для малых и средних предприятий обычно предъявляются следующие требования:

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

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

Анализ

Как правило, информационные системы небольших предприятий основаны на реляционных СУБД, для которых информация представляется в виде многомерного куба [2] с небольшим количеством измерений, каждое из которых содержит иерархически организованное множество элементов. Структура такой базы данных обычно проектируется для задач оперативной обработки данных (OLTP) и не соответствует концепциям «звезда» или «снежинка», применяемым в ROLAP. Таким образом, необходима конвертация данных в более удобный для анализа формат, и при этом классические ETL-процедуры (выгрузка, интеграция, очистка, трансформация и подготовка данных) значительно упрощаются, а этапы очистки и интеграции данных полностью исключаются — исходная информация хранится в одной базе и хорошо формализована.

Для малых и средних предприятий суммарное количество фактов (заполненных ячеек многомерного куба), как правило, сравнительно невелико — например для среднего супермаркета это: две кассы, 14 рабочих часов, 5 покупок за минуту. Если чек включает несколько товаров, то они регистрируются как отдельные покупки, для каждой из которых известны код товара, сумма, дата и время. Код товара содержится в иерархическом справочнике из 100 тыс. товаров. За год в супермаркете делается примерно 1,5 млн покупок, и если информация о каждой покупке занимает 12 байт (4 байта на код товара + 4 байта на дату и время + 4 байта на сумму), то всего потребуется 35 Мбайт. Если справочная информация об одном товаре занимает 128 байт (код + название + служебная информация), то на хранение справочника товаров потребуется примерно 12 Мбайт. Все современные реляционные СУБД обладают достаточным быстродействием для того, чтобы выгрузить для обработки такой объем информации, поэтому можно строить аналитическую базу каждый раз заново, а не выполнять ее регулярное обновление. Поскольку суммарный объем анализируемых данных меньше оперативной памяти офисных ПК, аналитическая база должна строиться в памяти сразу после запуска системы.

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

Классические и легковесные OLAP

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

На данный момент существует ряд решений аналитической обработки данных в памяти, например QlickTech [3] и Jedox Palo. При создании системы многомерного анализа данных в оперативной памяти необходимо решить две технические задачи. Во-первых, организовать хранение иерархии элементов каждого измерения, при этом должны очень быстро выполняться операции поиска элементов по коду и названию, а также переход от родительского элемента к дочерним и обратно. Поскольку число элементов измерения сравнительно невелико, то можно задействовать любые из известных способов хранения и индексации (отсортированный массив, бинарные деревья, B-деревья, хэширование и т. д.). Во-вторых, требуется организовать хранение многомерных кубов, каждый из которых представляет собой набор фактов, состоящих из координат ячейки (идентификаторы элементов измерения) и ее значения. Факты представляют собой многомерные данные, которые нужно организовать таким образом, чтобы ячейки, относящиеся к одному и тому же срезу куба, оказались близко друг к другу. Тогда для индексации и поиска ячеек куба можно использовать любые из известных методов работы с многомерными данными (R-деревья, M-деревья, квадрантные деревья и т. д.). Поскольку суммарный объем данных невелик, при построении легковесных систем не нужно решать ряд технических задач, критически важных при построении «больших» систем анализа: кэширование, сжатие данных для снижения суммарного объема ввода-вывода, оптимизация запросов, многопоточная обработка и т. д.

Интеграция с офисным ПО

Существующие OLAP-системы позволяют в интерактивном режиме получать различные проекции многомерных кубов, и при необходимости полученный срез может быть выгружен в одном из популярных офисных форматов, например в виде файлов электронных таблиц. Принципиально иной подход реализован в СУБД Jedox Palo; это полноценная многомерная СУБД с открытым исходным кодом, предоставляющая функции для создания базы данных, настройки многомерных кубов, загрузки информации и выполнения аналитических запросов. На данный момент в Palo присутствует весь необходимый для построения систем принятия решений инструментарий: средства администрирования, средства ETL, клиентские библиотеки для различных языков программирования (Си/C++, C#, Java, PHP) и т. д.

Отличие СУБД Palo от других многомерных СУБД в наличии модуля интеграции c Microsoft Excel и OpenOffice Calc, позволяющего из формул вычисления значений ячеек обращаться непосредственно к многомерному кубу данных. Кроме того, плагин дает возможность быстро формировать листы электронных таблиц, выгружающие нужные проекции кубов. Идея плагина для электронных таблиц полностью укладывается в концепцию средств легковесного анализа. Сама же СУБД Palo остается в русле классических OLAP-систем, поскольку предполагает наличие аналитической базы и выполнение процедур ETL.

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

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

Интеграция с WWW

Для интеграции с WWW в системах легковесного анализа необходим веб-сервер с фиксированным функционалом и возможностью одновременной работы небольшого количества пользователей. Во многих практических случаях сервер может быть локальным и обслуживать только одного пользователя, что упрощает задачу построения и администрирования. Многие корпоративные OLAP-системы предоставляют пользователям веб-интерфейс, позволяющий строить нужные проекции многомерного куба и выгружать полученные данные в виде файлов популярных форматов, однако для легковесного анализа подобный веб-интерфейс неэффективен — удаленной работы пользователей не требуется, а все необходимые проекции куба можно будет получить с помощью электронных таблиц. Веб-интерфейс для доступа к системам легковесного анализа будет востребован только в том случае, если он окажется значительно проще, быстрее и удобнее использования электронных таблиц. Одним из вариантов построения такого интерфейса является организация схемы «запрос-ответ», применяемой в системах полнотекстового поиска. Согласно этой схеме пользователь в текстовом виде с помощью ключевых слов описывает необходимую проекцию, а сервер формирует необходимый срез данных и возвращает его в качестве таблицы.

Алгоритм выполнения запроса состоит из следующей последовательности шагов. Сначала запрос разбивается на отдельные слова и определяются те из них, которые указывают на конкретный многомерный куб. Далее анализируются остальные слова и с помощью специальных словарей определяются релевантные им элементы из каждого измерения куба. Два наиболее часто упомянутых измерения выбираются в качестве названий строк и столбцов формируемой таблицы, а в остальных измерениях фиксируются либо наиболее релевантные элементы, либо элементы, отображаемые по умолчанию. Все это однозначно задает проекцию куба и может использоваться для формирования ответа пользователю. Например, в запросе «продажи молоко февраль 2014» каждое слово трактуется следующим образом. Слово «продажи» указывает на то, что нужно выбирать данные из куба, содержащего сведения об объеме продаж. Слово «молоко» делает релевантным элемент «молочная продукция» в измерении «тип продукта», «февраль» — в измерении «дата» релевантными помечаются все элементы «февраль», «2014» — в измерении «дата» релевантными помечаются все элементы, относящиеся к году «2014», в результате чего «февраль 2014» помечается дважды и имеет наибольшую релевантность.

Формируемая HTML-страница должна содержать все необходимые элементы управления для интерактивной корректировки проекции: выбора других элементов, смены строк и столбцов, выполнения операций drill-up и drill-down, а также списка возможных уточнений исходного текстового запроса. В список предлагаемых уточнений заносятся запросы, показывающие либо часть уже отображенной проекции, либо более общую проекцию данных. Другим вариантом построения уточнений является вставка названий элементов, отфильтрованных из-за низкой релевантности или не принятых в качестве значений по умолчанию.

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

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

***

Существующие тяжеловесные OLAP-решения от Microsoft, Oracle, Vertica, Sybase или Greenplum неэффективны на предприятиях, которым при работе со скромными базами данных требуются системы легковесного анализа, функционально, однако, не уступающие дорогим и обладающие приемлемой производительностью. Системы легковесного анализа можно построить на базе готовых продуктов типа Qlick Tech и Jedox Palo или собрать из готовых универсальных модулей, создаваемых по заказу и настраиваемых под особенности конкретного предприятия. Но, несмотря на простоту реализации таких модулей, решение будет экономически оправданным как для разработчиков, так и для заказчиков только при большом количестве последних. Это же справедливо и в случае предложения систем легковесного анализа по модели SaaS, обслуживание инфраструктуры поддержки которой перекладывается на плечи предприятий-клиентов.

Литература

1. Андрей Сахаров. Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server) // СУБД. — 1996. — № 3. — С. 44–59. URL: http://www.osp.ru/dbms/1996/03/13031490 (дата обращения 18.09.2014).
2. Кристиан Йенсен, Торбен Бэч. Технология многомерных баз данных // Открытые системы.СУБД. — 2002. — № 1. — С. 45–50. URL: http://www.osp.ru/os/2002/01/180958 (дата обращения 18.09.2014).
3. Андрей Ревуцкий. Ассоциации против больших объемов // Открытые системы.СУБД. — 2011. — № 10. — С. 50–51. URL: http://www.osp.ru/os/2011/10/13012230 (дата обращения 18.09.2014).

Константин Селезнев (skostik@relex.ru) — ведущий инженер-программист «РЕЛЭКС» (Воронеж).